ARCHITECTURE FOR ARMY MODERNIZATION
specific enough to keep system development on track, but still allow for innovation and creativity. An architecture grounded in consistent, authoritative data and that clearly defines how systems work together will hasten the requirements generation process, stimulate integration across portfolio boundaries and align anal- ysis with decision-making.
A modernized approach to Army architecture starts with captur- ing individual system requirements from cross-functional teams during concept and capability development. Ten, with participa- tion 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 iden- tify cross-portfolio and enterprise requirements. Te architecture solution must include a digital implementation where all data is stored in an authoritative repository and accessible across the enterprise. (See Figure 1, Page 132.) Tis “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. Te architecture process can be used as a manage- ment 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. Addi- tionally, architecture can serve as a justification tool, useful for understanding decisions and confirming assumptions early in the system development process. Trough the use of a common data repository, all architectures can be consistent and traceable from concept to deployment. Finally and most importantly, architec- ture shows how systems are interdependent and interconnected, and how they 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 capabil- ities and maximize interoperability. Trough 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 (horizontal inte- gration) through standardization of methodologies and 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 acquisi- tion 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 positions and responsibilities.
DOD has defined a set of standardized architecture views, a mixture of pictorial diagrams, matrices and lists, known as the DOD Architecture Framework. Within the DOD Architec- ture 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. Stan- dards 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 avail- able early in the development cycle allows for timely identification of capability gaps and operational needs. Operational require- ments can then be derived from these products. System views of existing and legacy products are a source for performance require- ments, 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 vehi- cles. 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 submers- ible. 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. Te 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
130 Army AL&T Magazine Summer 2019
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84 |
Page 85 |
Page 86 |
Page 87 |
Page 88 |
Page 89 |
Page 90 |
Page 91 |
Page 92 |
Page 93 |
Page 94 |
Page 95 |
Page 96 |
Page 97 |
Page 98 |
Page 99 |
Page 100 |
Page 101 |
Page 102 |
Page 103 |
Page 104 |
Page 105 |
Page 106 |
Page 107 |
Page 108 |
Page 109 |
Page 110 |
Page 111 |
Page 112 |
Page 113 |
Page 114 |
Page 115 |
Page 116 |
Page 117 |
Page 118 |
Page 119 |
Page 120 |
Page 121 |
Page 122 |
Page 123 |
Page 124 |
Page 125 |
Page 126 |
Page 127 |
Page 128 |
Page 129 |
Page 130 |
Page 131 |
Page 132 |
Page 133 |
Page 134 |
Page 135 |
Page 136 |
Page 137 |
Page 138 |
Page 139 |
Page 140 |
Page 141 |
Page 142 |
Page 143 |
Page 144 |
Page 145 |
Page 146 |
Page 147 |
Page 148 |
Page 149 |
Page 150 |
Page 151 |
Page 152 |
Page 153 |
Page 154 |
Page 155 |
Page 156
