Modernizing the U.S. Army’s Live Training Product Line using a

Cloud Migration Strategy: Early Experiences, Current Challenges

and Future Roadmap

Jeremy T. Lanman

, Panagiotis K. Linos

, LTC John Barry

and Amber Alston

U.S.A. Army, PEO STRI, Orlando, Florida, U.S.A.

Butler University, Computer Science and Software Engineering, 4600 Sunset Avenue, Indianapolis, Indiana, U.S.A.

U.S.A. Army, Modeling and Simulation, Ft. Eustis, Virginia, U.S.A.

University of Central Florida, Computer Science, Orlando, Florida, U.S.A.

Keywords: Cloud Engineering, Training as a Service, Migration Strategy, Evolution, Testing, SOA.

Abstract: The integration of different networks, databases, standards, and interfaces in support of U.S. Army soldier

training is an ever-evolving challenge. This challenge results in U.S. Army organizations repeatedly spending

time and money to design and implement irreproducible architectures to accomplish common tasks. In

response to this challenge, the U.S. Army has made significant improvements on its Live Training

Transformation (LT2) product line to support the needs of live training simulations. Despite the progress with

LT2 the Army continues to struggle to support the dynamic needs of the training units. These improvements

have been inadequate due to growing technical complexities of interoperating legacy systems with emergent

systems arising from advances in technology that suit the users' ever-changing needs. To better address and

support the needs of the end-user, a cloud-based modernization strategy was crafted and deployed on the

existing Common Training Instrumentation Architecture (CTIA). CTIA is the foundation architecture that

provides software infrastructure and services to LT2 product applications. This paper describes some of the

U.S. Army’s initial experiences and challenges while crafting a cloud-based migration strategy to modernize

its LT2 product line and underlining CTIA. It starts by providing some background and rationale and then it

discusses the current state of this modernization effort followed by future directions including the U.S. Army’s

2025 vision of its LT2 product line. The overall vision entails an evolution plan from today’s standalone

products to a modernized cloud-based TaaS (Training as a Service) approach. The Army’s ultimate goal is to

reduce complexity as well as operational and maintenance costs, while providing enhanced training for the

Warfighter at the point of need, anytime, anywhere. Finally, this paper discusses some of the current

challenges including the exploration of appropriate testing methodologies and related security issues for the

SOA-based LT2 architecture and its services.

1 BACKGROUND

For over twenty years, the U.S. Army has addressed

interoperability requirements between training

systems through the creation and management of

several system architectures. These systems are

continually advancing in technology and growing in

operational use in order to support the evolving needs

of the U.S. Army's training communities. The Army

has made significant strides in improving their current

architectures, but these improvements have been

inadequate to meet the growing training and system

integration demands of users arising from technology

advancement. Thus, it quickly became apparent that

the need for a new architectural approach should be

either developed or adapted in order to support the

U.S. Army’s live training environment.

1.1 Live Training

The U.S. Army uses many types of training

simulations categorized as Live, Virtual, and

Constructive (LVC). The focus of this paper is the

architecture in support of the live simulation and

training domain. Live simulation and training,

defined by AR 350-1, is “real people operating real

equipment” and is used to train and develop Soldiers'

war-fighting skills (U.S. Army, 2011).

From an operations and training perspective, the

surge in simulation and training technology and use

was plagued by fragmentation and limited

coordination between the U.S. Army branches due to

552

Lanman, J., Linos, P., Barry, L. and Alston, A.

Modernizing the U.S. Army’s Live Training Product Line using a Cloud Migration Strategy: Early Experiences, Current Challenges and Future Roadmap.

In Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016) - Volume 1, pages 552-559

ISBN: 978-989-758-187-8

divergent operational demands, and the inability of

technology to provide a “one size fits all” solution to

the various needs of the operations and training

community. This led to the consensus that limited

interoperability was the highest level of integration

possible at the time, which in turn led to the

development of "stove-pipe" or “silo” systems across

the Army's war-fighting functions: movement and

maneuver, command and control, sustainment,

protection, intelligence, and fires (M. G. Geruti,

2003)). The stove-piped systems were "able to send

data to other applications within the same domain but

not across boundaries" (R. L. Hobbs, 2003)). The

impact of these stove-piped systems in live training

ranges and instrumentation restricts their reusability,

increases the cost to upgrade, and causes significant

amount of range downtime to modify. In addition,

the incompatibility between these disparate training

systems results in the replacement of expensive

components or requires the addition of adapters,

which increases both cost and development time (M.

Gomez, T. Kehr, 2011). The "stove-piped systems

were built with different suites of sensors, networks,

protocols, hardware, and software" (R. J.

Noseworthy, 2010). The challenge and risk of linking

stove-piped systems was identified in the 2006 Net-

Centric Services Strategy that stated, "Patching stove-

pipes together is a temporary solution; however, this

leads to a fragile environment, which will eventually

crumble under the high demands and unpredictable

needs of the users" (DoD, 2006).

In the attempt to break down the barriers created

by the stove-piped systems, the U.S. Army’s Program

Executive Office for Simulation, Training and

Instrumentation (PEO STRI) developed the Live

Training Transformation (LT2) product line to

support the needs of live training. The first goal of

the LT2 product line was to maximize commonality

and systematic component reuse and to ensure

interoperability across the live training community.

The second goal was to reduce fielding time and

acquisition cost and to provide "total ownership cost

reductions across the live training domain" (J.T.

Lanman et al, 2012). The LT2 product line supports

home-station training, deployed training, Military

Operations on Urban Terrain (MOUT) training,

Maneuver Combat Training Center (MCTC) training

and instrumented live-fire range training. Figure 1

depicts the initial three use cases for the live training

architectural migration. The first use case entails the

use of smart phones during combat training to capture

soldier situational awareness and/or other related data

and broadcast them to the command post data center

for strategic decision making. The second use case

presents various Army combat vehicles and soldiers

transmitting training instrumentation data through

defense or commercial satellite and network gateways

back to the command post data center. Finally a future

use case shows sharing and sending of information

using special sensor devices connected via Bluetooth

or other commercially available standards to various

edge devices (e.g. tablet or smart phone) back to the

command post data center for analysis.

1.2 Current Architectural Approach

The architecture that supports live training today is

the Common Training Instrumentation Architecture

(CTIA). CTIA is the foundation architecture of the

LT2 product line that was developed by PEO STRI to

specifically support live training. The benefits of

CTIA have been seen in the reduction of development

costs, sustainment costs, maintenance costs, and

fielding time of live training ranges (J. T. Lanman et

al, 2012). CTIA consists of architecture services,

software components, standards and protocols that

are Information Assurance (IA) certified to operate at

the secret level (U.S. Army, 2013).

Figure 1: Initial use cases for live training.

Although CTIA has enabled units to conduct

training through the benefits discussed in the previous

section, CTIA technology is reaching its limitations

to support the LT2 product line and ultimately the

needs of the training community. This inability to

evolve with user requirements has left a gap in

supporting web interfaces and wireless mobile

devices. This gap in support can be linked back to a

lack of LT2 architectural vision that ties standards

together resulting in live training components being

highly dependent on the CTIA versions and limited

backwards compatibility (J. T. Lanman et al, 2012).

Additional challenges with CTIA include

compatibility with other military systems, supporting

distributed training center support, and scalability of

footprint across LT2 product line. To address these

Modernizing the U.S. Army’s Live Training Product Line using a Cloud Migration Strategy: Early Experiences, Current Challenges and

Future Roadmap

553

Figure 2: Conceptual view of a SOA-based cloud migration strategy for CTIA.

challenges, the architecture team and PEO STRI have

adopted a Service-Oriented Architecture (SOA)

migration strategy (J.T. Lanman et al, 2011). Figure

2 depicts a conceptual view of such strategy including

a list of architectural layers and corresponding

services provided. The architectural layers are

mapped to the service layers of a conceptual Regional

Training Center (RTC), a cloud-based data center that

hosts services and data for training capabilities at

various Army installations and ranges. If an Army

range does not have a communications network, then

a private mini RTC can be deployed at the range and

later federated back to the main RTC data center.

1.3 Training as a Service

The term “Training as a Service” (TaaS) is used by the

U.S. Army in order to refer to an “on-demand training

environment” delivery model in which training

software and its associated data are hosted in a cloud

and are accessed by users using a thin client, normally

using a web browser over the Internet.

The U.S. Army has deployed a TaaS strategy in

order to develop simulation and training services (i.e.

Web services) and the supporting infrastructure (i.e.

networks, communications, sensors and computing

hardware). Moreover, such TaaS strategy aims at

building functional components and the supporting

intermediate infrastructure according to modern cloud

engineering principles and practices. It decomposes

the system into components and layers. To obtain

maximum flexibility and the greatest opportunity for

reuse, each component exposes its capability through

services available to the end-user and to other

applications on the Army’s Enterprise Network

(AEN). By designing software around a set of services

rather than a set of applications, TaaS aligns with the

DoD migration to net-centricity and architectural

patterns used in industry (DoD, 2012). Moreover, the

architecture segregates the software that exposes

persistent information (data services) from functional

(or business logic) and presentation services. Both

TaaS and the CTIA SOA and cloud infrastructure are

built upon layered architecture frameworks. TaaS and

CTIA SOA embraces consistent SOA and cloud-

based concepts and architectural tenets, but differs in

the sense that CTIA SOA is focused on defining

architectural patterns that, while consistent with the

TaaS objective architecture, focus on the unique issues

of the instrumentation training environment rather

than the holistic enterprise environment.

TaaS is now evolving while building common

Army training apps and software services for Web

browsers, desktop computers and mobile devices in

the cloud environment. Army units and individual

soldiers can access software applications such as a

GPS tracking app for land navigation and exercise-

control monitoring, tactical engagement simulation

apps for laser and simulated fire engagements, and

instrumented range apps for fixed live-fire targets.

TaaS will eventually support up to brigade and

battalion level force-on-force instrumentation and

home station training with constructive simulation

data feeds and battle damage assessment. TaaS is

cloud-based with a deployable software service

infrastructure to support the full live training domain.

Figure 3 illustrates the LT2 based CTIA domains

(home station, force-on-force, force-on-target)

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

554

supported by TaaS.

It is expected that CTIA will eventually support

fully the mobile computing world. One of the goals

here is to enable trainers to use mobile devices to

capture training observations and evidence just like

one might use an app to post a photograph to a social

networking site. Finally, a more detailed description

of how the Training as a Service (TaaS) delivery

model is deployed by the U.S. Army can be found in

(J. T. Lanman, P. Linos, 2013).

1.4 LT2 Vision

Figure 4 below summarizes the steps currently taken

to fulfill the US Army’s 2025 modernization vision of

its LT2 product line and related CTIA. As depicted in

Figure 4, the CTIA is migrated to a cloud-based

architecture and all related products are converted to

SOA services. This effort enables a transition from the

standalone model to a target cloud-ready model,

which will eventually reduce costs.

Figure 3: Training as a Service (TaaS) supporting the LT2

based CTIA domains.

In addition, all proprietary instrumentation

systems are moved to a robust family of standards

based sensor components. Also, the complete

enterprise is modernized to a stand-up persistent,

cloud-based LT2 enterprise of training services.

Finally, the overall user experience is now moved

from an operator-driven approach to a self-serve web

or mobile apps tactic.

As part of meeting the LT2 vision objectives,

Lanman and Linos discuss how decisions to change a

product must be driven by the goals and objectives of

the customer and other key stakeholders if they are to

be successful (J. T. Lanman, P. Linos, 2012). Just as

Figure 4: A plan included in the U.S. Army’s 2015 vision

to modernize its LT2 product line.

the decision to adopt a product line approach for LT2

involves recognition of avoidable duplication, the

decision to migrate to a cloud-based platform

involves recognition of deficiencies in meeting

upcoming fielding needs for CTIA based training

systems. To ensure that the adoption of a cloud-based

migration strategy addresses the true needs of the LT2

community, the architecture team, comprising key

stakeholders based on influence and interest, have

carefully defined and prioritized the strategic

business goals and objectives for the LT2

architecture. CTIA provides the foundation for this

architecture; however, business goals and objectives

were extended to the LT2 community at large to ensure

that the CTIA architecture aligns with community

needs. These goals were then used to determine the

priorities for the technology insertion effort.

1.5 Migration Roadmap

The migration roadmap of the current CTIA, to a

modernized state, entails six Transition Architecture

(TA) path-points (i.e. TA1 through TA6) as shown in

Figure 5. Each such TA is based on a specific use case

for tracking soldiers in both individual and small units

training. Services allocated to each TA instantiation

enable progressive levels of product team adoption. In

addition, product teams are able to orchestrate the

architecture services to meet their intended training

use case, and develop user level application interfaces.

Finally, each such transition architecture supports

integration with first generation CTIA to the extent of

the services provided. It is worth mentioning that TA6

was added to the migration plan later due to a funding

opportunity with an LT2 product. That opportunity

allowed the SOA to mature more quickly with

additional services; however, it pushed the migration

of other services out one year. The derived benefit was

a faster deployment of a critical training capability at

a major Army installation.

Modernizing the U.S. Army’s Live Training Product Line using a Cloud Migration Strategy: Early Experiences, Current Challenges and

Future Roadmap

555

Figure 5: A roadmap depicting the evolution of Transition Architectures with related timeline.

The adopted migration roadmap entails modern

cloud computing and virtualization technologies,

which ensure effective interoperability among the

Live, Virtual and Constructive (LVC) training systems

and related applications. In addition, typical cloud

engineering principles have been utilized while

developing and orchestrating reusable, highly cohesive

and loosely coupled software services at various

granularity levels. Figure 5 also depicts the timeline

and evolution of transition architectures TA1 through

TA6 and their impact on core software, products,

instrumentation, enterprise, and user experience.

As of today, transition architectures TA1, TA2 and

TA3 have been already released with reasonable

success. The future architectures will be evolving over

the next ten years into a series of the remaining

transition architectures (i.e. TA4 through TA6). More

specifically, TA4 will provide services to support

basic force-on-force instrumentation for brigade level

home station training with constructive data feeds and

battle damage assessment. Services will include asset

tracking and exercise replay. Finally, TA5 and TA6

will be the last instantiation of the migration effort.

Afterwards, the architecture transitions into

production and sustainment for objective architectures

OA1, OA2 and OA3. The target solution architecture

(a.k.a. Objective Architecture) will be fully cloud-

based with a deployable Service-oriented

Infrastructure (SOI) supporting the full live training

domain. Training will include up to battalion level

force-on-force exercises integrating with mission

command systems and entail full wrap-around live,

virtual, and constructive interoperability capability.

2 CHALLENGES

2.1 Current Testing Issues

Changing to a cloud business methodology to support

military requirements is unique because it changes the

paradigm of traditional testing methodologies. This

paradigm shift brings a new challenge of testing the

architecture prior to implementation.

The current testing practice lacks the necessary

metrics to validate the LT2's transition to a service-

oriented capability. The current method is to

"implement once ready" without putting the new or

modified application through the rigors of a

comprehensive testing framework. The current testing

must expand from a solely integration focus to

examining the effects of any new or modified

application, such as interoperability and composability.

Ignoring these effects may result in an open architecture

without boundaries creating a governance nightmare.

In addition, the length of the potential migration

amplifies this challenge. Currently, the new LT2

CTIA Objective Architecture Vision is a multi-year

plan requiring that the SOA evaluation framework to

be highly reusable and flexible. These characteristics

allow the framework to adapt as end-user

requirements naturally evolve over time as

technology advances. With the long-term goal of

developing testing criteria for the on-going evaluation

of the LT2 architecture components, a thorough

literature review is being conducted identifying

potential applicable and validated SOA testing

models that could support the LT2 cloud migration.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

556

2.2 Observations on Cloud-based

Testing Methods

Any reusable testing framework, including those

utilized outside of the immediate LT2 architectural

focus, must support the testing, data collection, and

effective evaluation of the dependability and quality

of services produced in a cloud-based services

environment. Our literature review so far reveals

various approaches and techniques for testing cloud-

based applications at different test levels. Although

these approaches and techniques seem promising,

they lack the maturity of a validated and repeatable

testing framework required to adequately assess the

LT2 SOA-based implementation.

According to research conducted by Petrova-

Antonova, et al., in support of their work to propose

a possible SOA testing framework, there are several

isolated testing tools and highly complex frameworks

used in proprietary fashion for web service

composition testing, however an available, proven,

complete solution to both test and validate a SOA

approach is still missing (D. Petrova et al, 2012).

Much of the challenge in developing a highly

useful and repeatable testing framework is that cloud-

based evaluation can be a highly complex computing

issue. Services are dispersed over different

deployment configurations; they must be highly

adaptive as new services are added without requiring

high levels of regression analysis. They may also be

highly complex services with specific functionality

offering differing operational tasks making on-going

automation testing highly difficult (Y. Basili, 2012).

Youssef Bassil offers, as a part of his SOA-based

framework development research, an overview of the

five levels of evaluation that should be considered in any

application of a SOA testing framework (Y. Bassil,

2012). They are as follows: Unit Testing (evaluating the

individual service as an isolated element), Integration

Testing (evaluating the SOA as a working group of co-

joined services), Regression Testing (re-evaluating any

recent updates to individual services across the working

group of services), Functional Testing (evaluating that a

service performs its intended purpose), Non-Functional

Testing (evaluating properties such as availability and

security vulnerabilities within the service).

In addition, Papastergiou and Polemi suggest that

a proper testing framework used to evaluate a SOA

approach to overcome interoperability challenges

must include the following elements in order to

confront recognized weaknesses in many of the

currently available testing frameworks (S.

Papastegiou, D. Polemi, 2010): Clarified (framework

requires that testing apparatuses and necessary

information are clearly defined as is the component

being evaluated), Adaptable & Extensible

(framework requires that new testing tools and

methods, as well as new services, are easily

integrated), Flexible (framework requires elements to

be able to be adopted as needed for specific test cases,

Structured (framework follows a concrete set of

evaluation steps), Interdependent & Scalable

(framework provides value independent of any given

testing technology or number of services under test).

Although we identified several framework

suggestions for testing a SOA-based implementation,

there is clearly not a one-size-fits-all methodology to

measuring the success of an implementation. Each

evaluation framework must be informed by an

understanding of the individual system needs and

capabilities. The Army’s live training systems, in all of

their architectural complexity, particularly emphasize

this need to take a customized approach of designing

any intended evaluation framework with the LT2 goals

and metrics of success top-of-mind. Therefore, we are

still looking for experiences and recommendations on

how to properly validate a SOA implementation

(especially in the cloud) to be highly diverse. We will

continue our literature review of related publications

such as the one in (S. Tilley, T. Parveen, 2012).

3 LESSONS LEARNED

This section discusses lessons learned to date based

on the on-going cloud-based modernization activities

for the LT2 product line.

3.1 Leveraging Reuse

A lesson that we learned quickly during the cloud

migration process is that common architecture

frameworks succeed by providing a uniform and

highly reusable feature-rich environment that allows

developers to focus on their primary objective of

implementing business-level use cases and not on

repetitive implementation details. The Army’s success

with CTIA can be realized by the fact that it forms an

average of 50% of the code base for all live training

systems deployed since 2006. More specifically, the

Army’s LT2 products typically use about 57% of an

approximate two million lines of code in the CTIA

framework (J. T. Lanman et al, 2012). Another

realization is that due to the large investment of the

current architecture and the multitude of component

dependencies it is unreasonable to expect that the new

architecture can be developed in an isolated

environment and deployed to replace completely the

Modernizing the U.S. Army’s Live Training Product Line using a Cloud Migration Strategy: Early Experiences, Current Challenges and

Future Roadmap

557

existing architecture. Therefore, it became apparent

that backwards compatibility must be maintained with

legacy software components through the existing

CTIA framework interfaces. For more information on

the historical evolution of CTIA we refer the reader to

(J. T. Lanman, P. Linos).

3.2 Mapping Business Processes

In the live training domain the technical problem does

not directly map to the IT business process for

producing goods and services which SOA is typically

modeled upon. As we know, the standard SOA

business process is an orchestration of multiple

business functions each of which rely on the results

of the previous function to accomplish a discrete task.

For instance, consider the archetypal example where

a business process entails: booking an order =>

updating inventory => shipping => billing. In the case

of a live training environment, business units are

providers of content and context to artifacts generated

within the system. The system collects artifacts and

then consumers generate review content from the

artifacts. The path through artifact generation,

manipulation and presentation is not dictated by a

predefined orchestration but by an ad hoc manner,

depending on the fidelity of the training environment.

A combat training center for example has multiple

organizations dedicated to providing context and

content for discrete aspects of the training exercise

such as fires, upper echelon support, or aerial support,

whereas a home station training range instantiation is

typically an individual assessing the time on target, or

efficiency in meeting the training objectives for a

single unit. As a result, the lesson here is that the U.S.

Army could not directly adopt a traditional IT

business process, but customized such process to

allow for scalability of multiple or simultaneous

training assets to accomplish discrete tasks in a

traditional SOA implementation.

3.3 Improving Deployment Time

In an archetypal cloud-based deployment the SOA

system is ubiquitous and accessible from multiple

disparate organizations. In addition, the system is

always available with no defined end state. In the case

of the U.S. Army’s live training systems however, as

they are deployed currently, installations exist as

isolated standalone systems. Also, training exercises

have specific training objectives and they access data

that are not shared between concurrent exercises at

different ranges. Moreover, service composition is a

function of the training audience and range, from

combat training centers with dedicated rack servers

down to individual ranges consisting of a single

workstation operated directly by an individual from

the training unit. These systems are accessed and

maintained onsite and their state is dependent on the

phase of the training rotation. Although the target

migration architecture (a.k.a. Objective Architecture)

will be a ubiquitous solution overall, the cloud-based

implementation of CTIA must account for the

different phases of training where different subsets of

services are available depending on the training

rotation state. As a result, we have learned so far that

additional architectural layers and specialized

federation services are needed in the Objective

Architecture in order to account for the various

asynchronous training phases.

3.4 Assuring Security

Any changes to the CTIA and LT2 architectures and

their components must consider the security and

accreditation impact in order to comply with the

Information Assurance (IA) policies and the DoD’s

Risk Management Framework (RMF) process. We

need also to consider that as the U.S. Army evolves and

in order to implement cloud computing and

virtualization, that the security and IA requirements are

also likely to evolve and introduce new requirements.

Therefore, the lesson that we derived from this is to

engage with security experts early in the cloud services

design process and build in security constructs in the

design, which allows for easier IA certification and a

more secure and cost effective solution.

3.5 Pending Technical Concerns

We found that cloud-based migration challenges

mostly concentrate around bandwidth, scalability,

and technical issues based on SOA related

implementation details such as limitations of

proprietary Enterprise Service Bus (ESB)

capabilities. Historical CTIA development has

resulted in a set of metrics that ensure that all

development activities comply with the required

Technical Performance Measures (TPMs), which are

internally defined by the U.S. Army. Continuous

integration and testing ensures that any time these

metric values are exceeded the development team takes

immediate action. Also, existing test harnesses and

training scenarios provide a baseline for validation

testing. It is worth mentioning that the current system’s

performance exceeds the performance of the previous

generation of CTIA. The first transition architectures

focus on the most reused and also the most

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

558

performance-sensitive elements within the system,

ensuring that these issues are addressed early and often.

The CTIA SOA is early in its development and we are

still collecting metrics on performance and testing.

However, since these technical concerns are an on-

going investigation, we will continue to identify and

address them as needed. We plan to include those

findings and related data in future reports.

4 CONCLUSIONS

In this paper, we briefly described the U.S. Army’s

overall effort, experiences and lessons learned while

modernizing its Live Training Transformation (LT2)

product line. To this end, the U.S. Army decided to

leverage the industry-wide knowledge and success of

cloud computing using SOA, and it has identified this

business approach as the new migration to its LT2

product line. Based on work accomplished so far from

such an effort, the U.S. Army believes that this transition

is already increasing the interoperability of its different

networks, databases, and interfaces that support live

training. At the same time, the U.S. Army also

acknowledges the fact that this paradigm shift poses

various new challenges. For instance, just as there is not

an "out of box" cloud-based strategy, there is not a "one

size fits all" testing framework. Based on such an

observation we have found and discussed above some

existing cloud-based testing techniques and approaches

that could be used for the LT2 transition. However, we

understand that further investigation is needed here

before any decisions are made.

We have also made an attempt in this paper to

explain how the U.S. Army’s PEO STRI has

incorporated the concept of TaaS (Training as a

Service) in order to successfully migrate and

modernize its simulation and training legacy software

for the live training domain. Based on early

observations, it appears that the TaaS strategy

addresses the need to reduce costs and leverage

technology developments in order to better support

the soldiers’ training needs. However, as we have

described in our lessons learned section above, there

exist some challenges. For example, SOA and cloud

adoption related caveats are typically centered on

network bandwidth, latency, software scalability and

other technical issues. Furthermore, any changes to

architectures and software services must consider the

security and accreditation impacts that might affect

information assurance.

REFERENCES

U.S. Army, AR 350-1: Army Training and Leader

Development, Washington, DC: United States Army, 2011.

M. G. Ceruti, "Data Management Challenges and Development

for Military Information Systems," IEEE Transaction on

Knowledge and Data Engineering, pp. 1059-1068, 2003.

R. L. Hobbs, "Using XML to Support Military Decision-

Marking," in In Proceedings of the 2003 Winter

Simulation Interoperability Workshop, Orlando, 2003.

M. Gomez and T. Kehr, "Leveraging Service-Oriented

Architectures (SOA) within Live Training: An Assessment,"

in Interservice/Industry Training, Simulation, and

Education Conference (I/ITSEC) , Orlando, 2011.

R. J. Noseworthy, "Supporting the Decentralized

Development of Large-Scale Distributed Realtime

LVC Simulations Systems with TENA (The Test and

Training Enabling Architecture)," 14th IEEE/ACM

Symposium on Distributed Simulation and Real-Time

Applications, pp. 21-29, 2010.

DoD, CIO, Net-Centric Environment to an Enterprise

Service Oriented Architecture, 2006.

U. S. Army PEO STRI, "Live Training Transformation (LT2)

Product Line," [Online]. Available: http://www.peostri.a

rmy.mil/PM-TRADE/lt2_productline.jsp. [Accessed 22

March 2013].

J. T. Lanman, S. R. Clarke, S. Darbin Hillis and D. Frank,

"Applying Service Orientation to the U.S. Army's

Common Training," in Iterservice/Industry Training,

Simulation, and Education Confernce (I/ITSEC) 2012,

Orlando, 2012.

J. T. Lanman, S. Clarke, R. Darbin and D. Frank,

"Applying Service Orientation to the U.S. Army's

Common Training Instrumentation Architecture," in

Interservice/Industry Training, Simulation and

Education Conference, Orlando, 2012.

J. T. Lanman, S. Horvath and P. Linos, "Next Generation of

Distributed Training utilizing SOA, Cloud Computing

and Virtualization," in Interservice/Industry Training,

SImulation and Education Conference, Orlando, 2011.

DoD, "Cloud Computing Strategy," Chief Information

Officer, 2012.

J. T. Lanman and P. Linos, "Employing Service Orientation

to Enable Training as a Service (TaaS) in the U.S.

Army," in International Conference on Cloud

Engineering (IC2E), San Francisco, 2013.

D. Petrova-Antonova, S. Illieva, I. Manova and D. Manova,

"Towards Automation Design Time Testing of Web

Service Compositions," e-Informatica Software

Engineering Journal, vol. 6, no. 1, pp. 61-70, 2012.

Y. Bassil, "Distributed, Cross-Platform, and Regression

Testing Arhitecture for Service-Oriented Architecture,"

Advances in Computer Science and its Applications

(ACSA), vol. 1, no. 1, 2012.

S. Papastergiou and D. Polemi, "A Testing Process for

Interoperability and Conformance of Secure Web

Services," in Radio Communications, A. Bazzi, Ed.,

Rijeka, Croatia, InTech, 2010, pp. 689-712.

S. Tilley and T. Parveen, Software Testing in the Cloud:

Migration and Execution, Springler, 2012.

Modernizing the U.S. Army’s Live Training Product Line using a Cloud Migration Strategy: Early Experiences, Current Challenges and

Future Roadmap

559