Airchitecture for Army Modernization!

To reach its goal of an acquisition “renaissance,” the Army must create an architecture for modernization that provides a blueprint for how all of the pieces fit and work together.

by Nickee Abbott and Richard Haberlin, Ph.D., Cmdr., USN (Ret.)

Preparing for conflict requires the Army to not only modernize how it organizes, trains and equips the force, but also how its makes decisions. The Army budget narrative, in which the Army lays out its rationale for the funding it requests of Congress, calls for “a bold change—a renaissance—across the Army.” To achieve that renaissance by 2028, the Army has to field the next generation of combat systems, write new doctrine for the optimized use of those systems and reorganize the service into the formations that will fight with those systems. Developing those new systems will require continuous, iterative interaction among all of Army acquisition’s stakeholders. Engineering them will require architecture, analysis and experimentation.

The Army’s newly established cross-functional teams each focus on assigned modernization initiatives, leading to improvements in key capabilities. Unfortunately, the mechanism to ensure these improvements achieve the intended synergy in practical operation is immature. Capabilities must work together in a seamless and intuitive Soldier experience or they will never make it to the fight. Senior leaders have acknowledged that current processes and tools suffer from three critical flaws:

• The requirements development and refinement process does not execute at the speed necessary to meet the Army’s goals. It often takes years to generate requirements.
• The requirements development process does not clearly align to Soldier needs when integrated across the capability portfolios. Capabilities that increase Soldier burden will be abandoned.
• The analysis of performance is not clearly aligned to support acquisition decisions. Analysis often comes too late to help decision-makers or is only representative of the best and most ideal use cases.

In a recent example, the Mobile Short-Range Air Defense system was developed by the Air and Missile Defense Cross-Functional Team to fit an immediate need for maneuver units to identify and counter air threats quickly and effectively. However, the solution design does not include requirements for integration with the existing defensive and offensive fire control systems: the Integrated Fires Control Network or the Advanced Field Artillery Tactical Data System. The operational benefit of an integrated solution was lost during requirements generation.

SOLUTION

To achieve a modernization renaissance, the Army needs to address the three critical flaws in the acquisition process. The best way to address them is a robust architecture development process. Architecture, like a blueprint for a building, serves as a planning guide for system development. In the same way that a blueprint indicates where walls should connect but does not define what color they are painted, the architecture should be specific enough to keep system development on track, but still allow for innovation and creativity. An architecture grounded on consistent, authoritative data and that clearly defines how systems work together will hasten the requirements generation process, stimulate integration across portfolio boundaries and align analysis with decision-making.

A modernized approach to Army architecture starts with capturing individual system requirements from cross-functional teams during concept and capability development. Then, with participation from stakeholders in the Office of the Assistant Secretary of the Army for Acquisition, Logistics, and Technology (ASA(ALT)) and the U.S. Army Futures Command, the approach must identify cross-portfolio and enterprise requirements. The architecture solution must include a digital implementation where all data is stored in an authoritative repository and accessible across the enterprise. This “capture once, use many times” construct streamlines processes, reduces errors and establishes a common baseline for prototyping, experimentation, analysis and materiel development.

WHAT IS ARCHITECTURE?

In its simplest form, architecture is the visual depiction of a complex system documenting its components, connections and functions. The architecture process can be used as a management tool: a blueprint for cross-functional teams to follow while conducting system development. Architecture can also be a communication tool to express complex logic, hierarchies and interfaces to stakeholders of varying technical prowess. Additionally, architecture can serve as a justification tool, useful for understanding decisions and confirming assumptions early in the system development process. Through the use of a common data repository, all architectures can be consistent and traceable from concept to deployment. Finally and most importantly, architecture shows how systems are interdependent and interconnected, how those systems are working synergistically toward operational goals.

As the blueprint for Army modernization, architecture enables transformation of business processes and integration of systems across the enterprise to minimize duplicative capabilities and maximize interoperability. Through the architecture process, Army acquisition will realize significant benefits as a well-managed federation of systems. Architecture enables the integration of systems-of-systems within portfolios, often referred to as vertical integration, and across portfolios, or horizontal integration, through standardization of methodologies, lexicons and better understanding of external interfaces.

Architecture ensures effective and efficient processes, systems, services and resource allocation through the capture and reuse of enterprise knowledge. It supports the collaborative engagement of ASA(ALT), Army Futures Command and all other acquisition stakeholders by providing templates for views to support decisions. Consumer and producer roles for collecting data and developing these views should be aligned to established roles and responsibilities.

DOD has defined a set of standardized architecture views, a mixture of pictorial diagrams, matrices and lists, known at the DOD Architecture Framework. Within the DOD Architecture Framework, capability views (defining the abstract system capabilities) and operational views (detailing activities and tasks the systems might accomplish), align to the Futures Command through the concept development and requirements definition processes. Systems views, describing physical components, align to ASA(ALT) through the systems engineering processes of program executive offices and program management offices. Standards views, containing the rules, policies and guidance systems, must adhere to, are established and are maintained by the Office of the Army Chief Information Officer/G-6. When assembled, all of these views become an integrated architecture model.

ARCHITECTURE AS AN ENABLER

Making approved capability views and operational views available early in the development cycle allows for timely identification of capability gaps and operational needs. Operational requirements can then be derived from these products. System views of existing and legacy products are a source for performance requirements, which are particularly important when one system needs to be integrated into another larger system (e.g., a new radio for a vehicle). Standards views serve to identify relevant standards that, when followed, should address interoperability requirements.

For example, an operational view of a new ground combat vehicle clearly depicts how it is used to defeat bunkers and armored vehicles. At the same time, the operational view also clearly depicts capabilities the vehicle will not have. Stakeholders will know by looking at the operational view―which could be a diagram, a flow chart, a matrix, a table of activities, etc.―that the new vehicle is not intended to defeat enemy tanks or be submersible. A system view of all the command-and-control systems that will be integrated into the new vehicle defines size and weight requirements for the vehicle. The standards view prescribes that the power bus on the new vehicle have a certain voltage so that all the equipment integrated will work properly. Architecture views developed early in the system-development process reduce uncertainty and re-engineering while increasing common understanding for stakeholders.

When the development and maintenance of these architecture products are managed by the acquisition stakeholder community in an upfront plan, requirements generation can follow a documented process from initial concept to prototype. The architectures can be used to communicate operational goals and system constraints between disparate groups. Decisions made or not made in system development can be adjudicated in terms of the architecture. Program managers can consult the architecture to check if a capability, operation or component is affected by a decision to add or remove a function from a system. Second- and third-order effects that are not obvious in stove-piped system development can be easily identified when the system is placed in the larger system-of-systems or enterprise architecture.

ARCHITECTURE AS A PROVIDER

Leveraging the data stored in an architecture model provides several benefits. First, it links concepts to capabilities to solutions and provides operational context, processes, activities and requirements. This end-to-end traceability ensures that the developed system remains focused on Soldiers’ needs. Architecture defines the standards for implementation necessary to field an interoperable system. Setting standards not only ensures interoperability with existing systems, but it also creates more opportunity for development of future capabilities that may also be integrated by setting expectations and enabling modular integration.

A linkage from concept to capability to solution ensures that a Soldier’s needs continue to be met in increasingly complex systems through simplified configuration management. The ability to trace architectures from concept view to system view ensures that cross-portfolio requirements are identified and not ignored or casually traded away later in the development process. A standardized architecture methodology and diagram set allows different stakeholders to communicate their interests and concerns across portfolio boundaries in a language that can be universally understood. The architect is able to capture the warfighter’s requirements and translate them into the language of the materiel developer. Traceability works in both directions, giving materiel developers insight into how a particular requirement meets warfighter needs, and showing the warfighter why a particular materiel solution was chosen given the cost, schedule and performance constraints that the materiel developer must adhere to. This makes it easier to understand the decisions made by all parties in the Army’s modernization process.

ARCHITECTURE AS A VALIDATOR

Through the requirements generation process, architecture captures and defines system attributes and provides a basis for comparing system performance against operational requirements. Architecture may be used to link analysis with early experimentation using the operational requirements, system attributes and underlying data stored in the architecture model. Prototyping, experimentation and analyses, via modeling and simulation, will help refine requirements and help set the threshold and objective specifications for materiel development. High-fidelity models and complex scenarios are challenging enough to build and maintain without analysts spending time combing stakeholders’ repositories for data—much of which is unusable as it is incomplete, has dissimilar formats or only accounts for inter-portfolio connections. An architecture model can be referenced for standardized performance, integration and interoperability requirements that can be analyzed before the evaluation of alternate solutions. Architecture model availability would accelerate expected system performance analyses, increasing the chances that they would be completed in time to inform acquisition decisions, often not the case in acquisition today.

With a single, authoritative architecture model, analysis can be better managed to support acquisition decision-making. Model fidelity and scenario development will take precedent over data gathering and corroboration. With a clearer understanding of the architecture, decision-makers will be better able to direct analysis efforts to be more refined and better answer difficult questions before making a potentially irreversible acquisition decision. Analysts will be able to use to architecture to further improve model and scenario fidelity as they are able to quickly and efficiently communicate in a common language with both operational requirements owners and material developers. With clear, relevant, high-fidelity model data in hand, decision-makers will have the justification to defend their acquisition decisions.

ARCHITECTURE IN A DIGITAL WORLD

For an architecture to be successful in a highly connected, digital enterprise, it must include all stakeholders, be readily accessible and be easy to navigate from concept to deployment. A digital architecture model has the additional role of being the authoritative data repository for all data pertaining to solutions under development and their integration with other systems. This repository becomes the single launch point for analyses performed on the system, providing a consistent data source for modeling and simulation tools to link directly into.

In this way, the repository serves as a mechanism to manage configuration of the current state of the enterprise and an enabler for analyses of future designs. Reusing system data stored in an authoritative digital repository establishes a common baseline for various solutions under development. Mapping solutions to the common baseline provides the justification for analyses of expected performance of alternative solutions. Analysts will be able to clearly point to how their work supports the acquisition decision-making process. In the same way, the common baseline simplifies future integration of additional components as technologies mature. Common baselines enable “plug and play” solutions to be developed, instead of designing a system from the bottom up whenever a new function needs to be added.

Using data from the architecture model, context and decision-specific views, outside of the standard set of DOD Architecture Framework views, could be customized for specific discussions and decisions. Creating unique views from the same underlying data ensures consistency across the enterprise. Through this data repository, enterprise knowledge can captured efficiently and made available for reuse. Reuse may include new collaborative communications between portfolios, or new and innovative analyses.

HORIZONTAL INTEGRATION STUDY

As a recent example, the Army Futures Command implemented a horizontal integration “tiger team” to document first-order expected interdependencies, systems or functions that rely on other systems to work properly, between the cross-functional teams’ systems. The team developed an architecture methodology to capture these interdependencies from both an operational and system perspective. Recognized interdependencies for this effort included communications; networking position, navigation and timing; synthetic training; power distribution and generation; sustainment; interoperability; autonomy; and commonality of sensors and subsystems. The team used the architecture methodology developed during the study to inform subsequent analyses, modeling and simulation, course-of-action development and near-term resourcing decisions for senior acquisition leaders. This architecture methodology was recognized by Army Futures Command leadership as valuable—so much so that it was approved for inclusion in their Future Force Modernization Enterprise requirements documentation.

CONCLUSION

In a January 2018 interview with Defense News, Army Secretary Mark T. Esper summed up the role of architecture by noting that “the key, or part of the key going forward, has to be to understand the architecture and to map it out so we have the plan. … It’s like building a house—you have to have a blueprint. Having a blueprint doesn’t necessarily mean deciding who will supply the fixtures or materials or what will be used, but it defines what is needed.”

Architecture supports the identification and documentation of system interdependencies with technical rigor, frames and quantifies opportunities for resolution, and enables informed decision-making. As a living product, architecture supports timely requirements development and updates in the face of new systems and emerging threats. Architecture ensures the end-to-end traceability of requirements to solution as a system goes through concept, requirement generation and deployment. The architecture confirms that a Soldier’s equipment aligns to an initial need for that equipment. Finally, architectures support comprehensive analyses to refine operational concepts and system solutions, and can serve as blueprints for force modernization.

For more information, contact Fred Buchanan in ASA(ALT)’s Office of the Chief Systems Engineer at fred.b.buchanan.civ@mail.mil.

NICKEE ABBOTT is director of the Architecture and Analysis Directorate in the ASA(ALT) Office of the Chief Systems Engineer. She holds an M.S. in strategic planning from the Carlisle Army War College, an M.S. in electrical engineering from the New Jersey Institute of Technology and a B.S. in electrical engineering from Drexel University. Her organization focuses on modernizing Army materiel systems to deliver engineered, integrated and validated solutions for the Soldier at all echelons. She leads the organization in production of a synchronized ASA(ALT)-integrated master schedule, capability set architectures and Army network analyses that follow a disciplined system-of-systems engineering process. As a key figure in the coordination and collaboration with key stakeholders, she works to ensure that the Army’s modernization initiative is engineered and validated to meet the needs of the Soldier. She is Level III certified in program management and in engineering.

RICHARD HABERLIN, Ph.D., Cmdr., U.S. Navy (Ret.), is senior technical adviser in the Modeling, Simulation, Experimentation and Analysis Division at MITRE Corp. He leverages 20 years of Navy operational and staff experience to produce tailored, relevant and defensible analyses informing executive-level decisions across DOD and the broader government. He earned his doctorate in systems engineering and operations research at George Mason University, and holds an M.S. in operations research from the Naval Postgraduate School and a B.S. in ocean engineering from the United States Naval Academy.