Approaches to Architecture Development
Definition: Architecture development can be thought of as both a process and a discipline that aids the development of mission-effective systems.
Keywords: DoDAF 6-step architecture development process, functional decomposition, object-oriented analysis, structured analysis, TOGAF ADM
MITRE SE Roles & Expectations: MITRE systems engineers are expected to understand how to tailor and apply approaches, processes, and methodologies to develop architectures that support decision making. They should understand the scope, methodology, strengths, and weaknesses of various approaches so they can apply them, separately and in combination, to architecture development efforts.
Multiple complementary approaches and methodologies are used to develop enterprise and system architectures. Some of the most popular approaches used in government departments and agencies are:
- U.S. Department of Defense Architecture Framework (DoDAF)
- The Open Group Architecture Framework (TOGAF)
- Object-oriented with Unified Modeling Language
- Spewak architecture process and Zachman Framework
The key steps of any architecture development approach are:
- Define the architecture purpose, value, and decisions it will support.
- Get information needed to define the architecture from stakeholders as early as possible.
- Create, refine, and update the architecture in an iterative way throughout the acquisition life cycle.
- Validate the architecture will meet expectations when implemented.
- Define roles for team members to guide and coordinate their efforts.
- Create estimates and schedules based on the architectural blueprint.
- Use the architecture to gain insight into project performance.
- Establish a lightweight, scalable, tailorable, repeatable process framework .
Determining the Right Process/Method
Many systems engineers believe there is an "either-or" decision to be made regarding different architectural frameworks (e.g., DoDAF or TOGAF), but this is not necessarily the case. Some architectural standards address completely different elements of the architecting process, thus there may be a natural synergy among the frameworks. For example, TOGAF has a primary focus on architecture methodology—the "how to" aspect of architecting, without prescribing architecture description constructs. DoDAF has a primary focus on architecture description via a set of viewpoints, without a detailed specification of methodology .
DoDAF 6-Step Architecture Process
The primary focus of DoDAF is architecture description – the architecture depiction consisting of several models (called products in DoDAF-2004). Initially the primary objective of DoDAF was to facilitate interoperability among DoD systems; however, that objective has been broadened to assist decision making by DoD managers at all levels on issues relating to DOTMLPF—Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities—and DoD information technology systems.
Although a 6-step architecture process, depicted in Figure 1, is described, it is meant to remain simple, tailorable, and able to be augmented by other architecture development processes. The method described within DoDAF is generic and can be used with other frameworks. The process supports both the structured analysis and object-oriented analysis and design modeling techniques and their specific notations .
Figure 1. 6-Step Architecture Process
TOGAF Architecture Development Method (ADM)
The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. It is a generic method for architecture development that is designed to deal with most systems. However, it will often be necessary to modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate.
Phases within the ADM are described below.
- The Preliminary Phase describes the preparation and initiation activities required to prepare to meet the operational directive for a new architecture, including the definition of an organization-specific architecture framework and the definition of principles.
- Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope, identifying the stakeholders, creating the architecture vision, and obtaining approvals.
- Phase B: Business Architecture describes the development of a business architecture to support an agreed architecture vision.
- Phase C: Information Systems Architectures describes the development of information systems architectures for an architecture project, including the development of data and application architectures.
- Phase D: Technology Architecture describes the development of the technology architecture for an architecture project.
- Phase E: Opportunities and Solutions conducts initial implementation planning and identifies delivery vehicles for the architecture defined in the previous phases.
- Phase F: Migration Planning addresses the formulation of a set of detailed sequences of transition architectures with a supporting implementation and migration plan.
- Phase G: Implementation Governance provides an architectural oversight of the implementation.
- Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
- Requirements Management examines the process of managing architecture requirements throughout the ADM .
As a generic method, the ADM may be used in conjunction with the set of deliverables of another framework where these have been deemed to be more appropriate, e.g., DoDAF models.
Once the decision about the architecture development methodology is resolved, selecting a technique to discover the architectural structure and processes is important. Currently, two approaches are in use—object-oriented analysis and design, and structured analysis and design. Both have strengths and weaknesses that make them suitable for different classes of problems; however, the object-oriented methodology is better for complex, interactive, and changing systems with many interfaces, which are the kinds of systems most MITRE systems engineers face.
Structured functional techniques tend to be rigid and verbose, and do not address commonality. Functional decomposition does not lend itself well to cases of highly complex interactive problems and is generally not used in modern development environments. Functional solutions are often difficult to integrate horizontally and are costly to sustain.
Figure 2. Integrated Definition for Function Modeling (IDEF0)
The object-oriented method takes a value-based approach to discovering system capabilities. Use cases describe the behavior between the system and its environment (see Figure 3). From the use case, the services the system must provide are derived. Those services are then realized by the internal structure of the system elements in iterative steps until system elements are simple enough to build. The resultant set of diagrams traces the composition of the system from its parts to the aggregated behavior captured within the set of use cases.
Figure 3. Use Case Diagram
Object-oriented approaches focus on interaction from the beginning, which has the beneficial side-effect of defining the boundary between the system and its environment. The use cases identify the ways in which the operator will use the system. Sequence diagrams graphically illustrate the interactions the system must support. The "lifelines" of the diagram gather the behavioral responsibilities of each "object" participating in the use case. These responsibilities are the requirements to share data across the collection to produce the required result.
Figure 4. Sequence Diagram
The advantages of the object-oriented method are that it embraces the concept of effects-driven process development, and it promotes reuse, facilitating the federation of cross-functional domain architectures. The focus on system interfaces also supports the service-oriented architecture implementation pattern .
For an example of a functional specification using use cases and sequence diagrams, refer to the Functional Specification for Consolidated Afloat Network and Enterprise Services .
Best Practices and Lessons Learned
- Purpose before architecture. Purpose must drive the architecting effort or the effort will be subject to the criticism of architecting for its own sake.
- Architecting is integral to systems engineering. Significant analytical insight into the system is gained through the process of architecting.
- Think "both-and." Various architecture methodologies and approaches exist. When properly understood, they can be complementary. Some approaches and frameworks address architecture content, and others address the architecture process. Understand the value of all to apply the best course of actions for the purpose. Actively consider mixing and matching them to achieve your purpose.
- Different models for different situations. Basic modeling techniques include a structured approach and an object approach. Understand their application strengths and weaknesses. The object approach provides many features to support complex system architectures and their interactions.
References & Resources:
- Lattanze, Anthony, 2005, "The Architecture Centric Development Method," Carnegie Mellon University report CMU-ISRI-05-103.
- Blevins, Terry, Fatma Dandashi, and Mary Tolbert, 2010, TOGAF ADM and DoDAF Models, The Open Group White Paper.
- U.S. Department of Defense, 2009, DoD Architecture Framework (DoDAF) Version 2.0.
- The Open Group, 2009, The Open Group Architecture Framework (TOGAF).
- Folk, Tom, 2006, Architectural Structures and Specifications.
- Navy PMW 160 Tactical Networks, May 20, 2009, "Architecture Specification for Consolidated Afloat Network and Enterprise Services (CANES), Increment 1."
Additional References & Resources:
- Draft Federal Information Processing Standards Publication 183, December 1993 (withdrawn September 2008), Integration Definition for Function Modeling (IDEF0).
- Federal CIO Council, 2001, A Practical Guide to Federal Enterprise Architecture.
- Wikipedia contributors, Steven Spewak, viewed February 25, 2010.
- Wikipedia contributors, John Zachman, viewed February 25, 2010.
Not all references and resources are publicly available. Some require corporate or individual subscriptions. Others are not in the public domain.
References and resources marked with this icon are located within MITRE for MITRE employees only.
For more information on the Systems Engineering Guide, or to suggest an article, please Contact Us.