Big ‘A’ Systems Architecture From Strategy to Design: Systems Architecting in DoD

To print a PDF copy of this article, click here.

Author: Chris Robinson

As a Systems Engineering instructor at DAU, I have engaged in a number of discussions and debates, both in and out of the classroom, on architecture in systems acquisition. Over time, I began to see there was a real lack of consensus about the importance of architecture, how it fits in to the Defense Acquisition System (DAS), and how it relates to system engineering.

I, admittedly, had a somewhat narrow view of the subject when I first got into the acquisition business. I viewed architecture as simply an output of the design process. I understood architecture to be, simply, the block diagram that depicted all the major components of a system and illustrated how those components are logically or physically connected together. Certainly that block diagram was part of it, but as I worked in various engineering and management roles at different stages of the development life cycle, I started to see a bigger picture. I began to understand the importance of architecture as a discipline that goes well beyond that block diagram.

DAU has afforded me the opportunity to learn more about the various perspectives on architecture and system architecting from colleagues, students, and the broader acquisition community. I also have had the opportunity to study the subject in more depth.
My observation is that systems architecting in DoD is best understood from the perspective of the broader Big ”A” acquisition enterprise that includes not only system developers, but strategy and policy makers, resource sponsors, and combat developers. I refer to this framework as Big ”A” systems architecting.

Systems Architecting As Design

Fundamentally, system architecting is part of the system engineering design process where decisions are made that significantly affect stakeholder needs and life-cycle costs. A system’s architecture defines the components of the system, the interfaces among those components, and the processes or rules that govern how the components and interfaces change over time.

This definition, however, does not tell the whole story, nor does it capture the vital role that effective system architecting has in achieving successful acquisition outcomes. During system development, the emerging structure of a system sets the baseline for the work to follow. Early life-cycle decisions that affect this emerging structure will have a large impact on the evolution of the system’s design, verification, production, sustainment, and disposal, and, therefore, a significant impact on the system’s life-cycle costs. Consequently, architectural decisions provide the basis for the detailed technical planning needed to effectively manage these life-cycle activities. The evolution of the technical plan will parallel the evolution of the behavior and structure of the system.

Early life-cycle decisions that affect this emerging structure will have a large impact on the evolution of the system’s design, verification, production, sustainment, and disposal, and, therefore, a significant impact on the system’s life-cycle costs.

Architecting is the part of the system engineering design process that involves decisions related to the behavior and structure of a system that are significant in achieving an optimal balance among stakeholder objectives and total system cost. Systems architecting develops a deep understanding of the required system behavior that is traceable to an overall goal and achievable within established constraints. This understanding informs the thoughtful partitioning of the whole into constituent components, the definition of the relationships among these components, and the processes that govern how the structure and relationships among system components change over time. Architects set the boundaries of the system, define the system’s relationship with the larger context (i.e., system of systems or business enterprise), and provide focus for detailed component-level engineering. This partitioning facilitates collaboration by helping stakeholders visualize emerging solutions from their unique perspectives, helps systems developers get a handle on complexity, and supports analytical activities used to evaluate and assess system performance.

Figure 1 illustrates the relationship of the systems engineering design process to architectural descriptions that are both artifacts of and inputs to the process. Architectural descriptions capture the results of each step in the process, but also set the stage for subsequent steps. Composing architectural descriptions is a discovery and learning process that helps drive the iterative refinement of a system’s high-level design as steps in the systems engineering process are repeated to converge to a solution.

Figure 1. Systems Architecting and the Systems Engineering Technical Processes


Systems Architecting As Art With Engineering

The transformation from strategic objectives to the structure of a system solution often is characterized by great complexity. This complexity is driven by myriad competing stakeholder concerns as well as technological and environmental challenges. Thus, the architecting process depends as much on the “artistic talents” of the architects involved as it does on their engineering acumen. The architecting process makes extensive use of heuristics (“rules of thumb” based on lessons learned from experimentation and experience) and judgment in order to deal with complexity, and places less emphasis on engineering analysis to decide on the best approach (see The Art of Systems Architecting by Mark W. Maier and Eberhardt Rechtin for a more in-depth discussion on the use of heuristics in architecting systems). Understanding and defining the problem to be solved, applying experience and lessons learned, balancing the needs of all stakeholders, evaluating alternative approaches, and choosing the best way forward constitute a highly creative, artistic process. The creative aspects of systems architecting require architects to be effective communicators and to possess a sound understanding of the technical landscape (i.e., knowledge of technical standards and certification requirements, knowledge of the relevant engineering domains, and knowledge of enterprise-level rules and processes). This thoughtful aspect of systems architecting, with its application of heuristics and ”soft” engineering, is necessarily complemented by the rigorous ”hard” engineering analysis required to evaluate architectural decisions and assess the performance of alternatives.

Systems Architecting As Modeling

In addition to its artistic nature, the architecting process is characterized by its use of modeling. Models serve as the canvas on which the systems architecting process is realized. Modeling helps architects think about, understand, and present the system of interest. Each step in the systems architecting process is captured in a set of models that organize underlying architectural data so as to clearly describe a solution from various perspectives. Architects, engineers, and managers use these architectural descriptions to plan for and manage subsequent development efforts and to communicate technical information to stakeholders. Models can be documents, spreadsheets, dashboards, block diagrams, or other graphical representations that serve as a template for organizing and displaying complex information in a more comprehensible format.

When data are collected and presented as a “filled-in” model, the result is called a view. The Department of Defense Architecture Framework (DoDAF) provides a standard set of building blocks and conventions for capturing architectural data and presenting those data in various formats that target specific perspectives or concerns. The DoDAF defines a set of templates (DoDAF-defined models) that, when filled in with solution-specific architectural data, provide a completed architectural view. Logically organized collections of views are referred to as viewpoints. A set of viewpoints related to a specific system solution is collectively called the architectural description of that system.

Figure 2 describes the relationship among a system, its architecture, and the description of the architecture. A system can support one or more missions, but each system is understood to have just one architecture. This architecture can have multiple architectural descriptions, and those architectural descriptions typically conform to an architectural framework. An architectural framework defines a set of models (standard templates), views (filled-in models), and viewpoints (logical groupings of views) that can be used to capture and present architectural data in standardized or custom formats. Architectural frameworks like DoDAF typically define a set of fundamental building blocks—an architecting ”vocabulary”—that provides the basis for composing architectural views. The building blocks are the primitive elements and rules used to create architectural views in much the same way the Periodic Table of Elements is used to describe the structure of chemical compounds and chemical processes.

Figure 2. Systems, Architectures, and Architectural Descriptions (adapted with permission from lecture notes of Matthew Henry, Johns Hopkins University)


The DoDAF Meta-Model (DM2) is the ”vocabulary”’ of DoDAF. A meticulously defined, comprehensive set of basic modeling elements like the DM2 is necessary to ensure that architectural descriptions are standardized down to the data element level, and, as a result, portable between modeling tools and easily communicated and understood across organizational boundaries. This aspect of architecting is especially important with regard to interoperability requirements and interoperability design for systems that exchange information with other systems within an enterprise like DoD. This is why, as a matter of policy, the mandatory Net Ready Key Performance Parameter (NR-KPP)—a mandatory KPP that helps DoD ensure systems are interoperable—is elaborated for each system through the development of DoDAF-compliant architectural descriptions.

In my experience, too often the acquisition community fails to integrate architecting activities into its plans efffectively. Architecture is viewed as a retrospective chore used only to document what has already been decided. The production of architectural descriptions frequently is treated as a “check in the block” required to get past the next major program decision review.
Instead, program offices and the broader acquisition community must look at architecture (or systems architecting) as a proactive endeavor. This proactive endeavor leverages modeling as a learning and discovery process vital to systems acquisition, enabling the sound decision making required to successfully transform strategic objectives into system solutions. I believe the right approach for the acquisition community is to focus on architecture and architecting as a discipline essential to the system engineering and management processes, and also to recognize that, in DoD, the application of this discipline actually goes beyond the boundaries of the acquisition program management office (PMO) and DAS, and is a process that includes the broader acquisition enterprise.

Big ”A” System Architecting in DoD

The DAS is responsible for managing development, production, and sustainment of systems and for doing the technical planning that supports these activities. Accordingly, it might make sense that the DAS (or acquisition program manager) also controls the systems architecting process, and that this process proceeds in a linear fashion, starting with a set of stakeholder requirements and ending with an architectural description of a solution that provides the basis for the detailed design work to follow. However, I believe this is too narrow a perspective.

Certainly, the DAS plays a leading role in the architecting of defense systems, but I believe a broader perspective is needed. My observation is that the systems architecting process in DoD transcends the DAS and involves the other major DoD decision supports systems—the Joint Capabilities Integration Development System (JCIDS); the Planning, Programming, Budgeting, and Execution System (PPBES); as well other strategic operational-level planning and decision activities. This holistic enterprise view of the architecting process for complex weapon and information systems sees a process that cuts across organizational boundaries and is characterized by a high degree of concurrency among its constituent stages (see Figure 3).

Figure 3. Big “A” Systems Architecting in DoD


Accordingly, systems architecting, in light of this broader perspective, involves Resource Sponsors and Strategic Planners (responsible for setting the strategic context and allocating resources), Combat Developers (responsible for operational or mission viewpoint), as well as System Developers (responsible for developing the materiel or technically focused system viewpoint). As shown in Figure 3, I refer to this process as Big “A” systems architecting to reflect the cross-organizational involvement and its enterprise-wide characteristic. By this convention, the piece of the process that falls under the purview of the DAS and focuses on the technical/technological aspects of systems architecting, rather than the strategic and operational, can be thought of as Little ”a” systems architecting.

Figure 3 is in relation to the early acquisition life-cycle phases and depicts the concurrency that exists among the stages. What this concurrency suggests is that lower-level architectural definition—the more technically focused stages managed by the DAS—in reality begins to emerge even before the outcome of higher-level architectural artifacts are fully established and base lined. The nature and degree of concurrency will vary from program to program, but I strongly believe the effectiveness of cross-organizational collaboration during this highly concurrent Big “A” architecting process substantially influences acquisition outcomes.

In short, the idea of Big “A” Systems Architecting in DoD suggests that the decisions on how to partition a system, connect those parts, and define the processes and rules that govern its evolution are the results of a highly concurrent process that includes the range of activities from modeling and documenting department-level strategic goals to the development of models that describe system solutions from an operational, functional, physical, and technical perspective. These models, as they are developed, provide the foundation for communication among stakeholders, drive analyses that support key decision making, and provide the basis for the detailed technical planning required to efficiently and affordably execute an acquisition program.

The significance of the Big ”A” systems architecting perspective is that it reveals opportunities to improve the overall acquisition process. I believe the biggest opportunities rest with the institutionalization of emerging modeling methodologies such as Model Based Systems Engineering (MBSE) and modeling standards such as Systems Modeling Language (SysML). These tools have great potential to facilitate collaboration and improve the productivity and efficiency across the Big “A” systems architecting stages in the early acquisition life-cycle phases. Ideas on the application of MBSE and SysML to Big “A” systems architecting and the potential benefits to acquisition outcomes are planned to be the subject of a future article.

Summary and Conclusion

Systems architecting is part of the systems engineering design process that results in the partitioning of a system into components, the defining of interfaces among those components, and the processes that govern their change over time. This is a critical step in the acquisition of a system since it sets a framework and provides a roadmap for all the work that follows. More important is that systems architecting supports the holistic perspective of systems engineering and combines the art of balancing stakeholder concerns with the rigorous use of engineering analysis to handle complex problems that require a system solution. The systems architecting process is captured in models—architectural descriptions—that describe the system from various perspectives related to stakeholder concerns. Systems architecting is a learning process that leverages models and modeling to understand and define problems, communicate alternative solutions, support analysis, and ultimately capture the high-level design of a system. In DoD, this process extends beyond the DAS and involves the other major DoD decision-support systems (JCIDS, and PPBE) as well as decision making at the strategy and policy level.

This cross-organizational, Big “A” systems architecting process is characterized by a high degree of concurrency where, early in the system life cycle, lower-level system and technical views of candidate solutions begin to emerge in parallel with the higher-level strategic and operational perspectives.

Emerging modeling methodologies present an opportunity for DoD to improve collaboration and productivity during the concurrent evolving stages of the Big “A” systems architecting process, and this can contribute to better acquisition decisions with concomitant improvement in acquisition outcomes.

To print a PDF copy of this article, click here.

Robinson is a DAU professor of Systems Engineering at Fort Belvoir, Va.

The author can be contacted at Christopher.Robinson@dau.mil.



Leave a Reply

Your email address will not be published. Required fields are marked *