Architectural Frameworks, Models, and Views
Definition: An architecture framework is an encapsulation of a minimum set of practices and requirements for artifacts that describe a system's architecture. Models are representations of how objects in a system fit structurally in and behave as part of the system. Views are a partial expression of the system from a particular perspective. A viewpoint is a set of representations (views and models) of an architecture that covers a stakeholder's issues.
Keywords: architecture, architecture description, architecture frameworks, models, viewpoint, views
MITRE SE Roles & Expectations: MITRE systems engineers (SE) are expected to assist in or lead efforts to define an architecture, based on a set of requirements captured during the concept development and requirements engineering phases of the systems engineering life cycle. The architecture definition activity usually produces operational, system, and technical views. This architecture becomes the foundation for developers and integrators to create design and implementation architectures and views. To effectively communicate and guide the ensuing system development activities, the MITRE SE should have a sound understanding of architecture frameworks and their use, and the circumstances under which each available framework might be used. They also must be able to convey the appropriate framework that applies to the various decisions and phases of the program.
Because systems are inherently multidimensional and have numerous stakeholders with different concerns, their descriptions are as well. Architecture frameworks enable the creation of system views that are directly relevant to stakeholders' concerns. Often, multiple models and non-model artifacts are generated to capture and track the concerns of all stakeholders.
By interacting with intra- and extra-program stakeholders, including users, experimenters, acquirers, developers, integrators, and testers, key architectural aspects that need to be captured and communicated in a program are determined. These architecture needs then should be consolidated and rationalized as a basis for the SE's recommendation to develop and use specific models and views that directly support the program's key decisions and activities. Concurrently, an architecture content and development governance structure should be developed to manage and satisfy the collective needs. The figure below highlights the architecture planning and implementation activities.
MITRE SEs should be actively involved in determining key architecture artifacts and content, and guiding the development of the architecture and its depictions at the appropriate levels of abstraction or detail. MITRE SEs should take a lead role in standardizing the architecture modeling approach. They should provide a "reference implementation" of the needed models and views with the goals of: (1) setting the standards for construction and content of the models, and (2) ensuring that the model and view elements clearly trace to the concepts and requirements from which they are derived.
Determining the Right Framework
While many MITRE SEs have probably heard of the Department of Defense Architecture Framework (DoDAF), there are other frameworks that should be considered. As shown in Figure 3, an SE working at an enterprise level should also be versed in the Federal Enterprise Architecture Framework (FEAF). To prevent duplicate efforts in describing a system using multiple frameworks, establish overlapping description requirements and ensure that they are understood among the SEs generating those artifacts. The SEG article on Approaches to Architecture Development provides details of the frameworks.
Best Practices and Lessons Learned
A program may elect to not use architectural models and views, or elect to create only those views dictated by policy or regulation. The resources and time required to create architecture views may be seen as not providing a commensurate return on investment in systems engineering or program execution. Consider these cultural impediments. Guide your actions with the view that architecture is a tool that enables and is integral to systems engineering. The following are best practices and lessons learned for making architectures work in your program.
Purpose is paramount. Determine the purpose for the architecting effort, views, and models needed. Plan the architecting steps to generate the views and models to meet the purpose only. Ultimately models and views should help each stakeholder reason about the structure and behavior of the system or part of the system they represent so they can conclude that their objectives will be met. Frameworks help by establishing minimum guidelines for each stakeholder's interest. However, stakeholders can have other concerns, so use the framework requirements as discussion to help uncover as many concerns as possible.
A plan is a point of departure. There should be clear milestone development dates, and the needed resources should be established for the development of the architecture views and models. Some views are precursors for others. Ensure that it is understood which views are "feeds" for others.
Know the relationships. Models and views that relate to each other should be consistent, concordant, and developed with reuse in mind. It is good practice to identify the data or information that each view shares, and manage it centrally to help create the different views. Refer to the SEG Architectural Patterns article for guidance on patterns and their use/reuse.
Be the early bird. Inject the idea of architectures early in the process. Continuously influence your project to use models and views throughout execution. The earlier the better.
No one trusts a skinny cook. By using models as an analysis tool yourself, particularly in day-to-day and key discussions, you maintain focus on key architectural issues and demonstrate how architecture artifacts can be used to enable decision making.
Which way is right and how do I get there from here? Architectures can be used to help assess today's alternatives and different evolutionary paths to the future. Views of architecture alternatives can be used to help judge the strengths and weaknesses of different approaches. Views of "as is" and "to be" architectures help stakeholders understand potential migration paths and transitions.
Try before you buy. Architectures (or parts of them) can sometimes be "tried out" during live exercises. This can either confirm an architectural approach for application to real-world situations or be the basis for refinement that better aligns the architecture with operational reality. Architectures also can be used as a basis for identifying prototyping and experimentation activities to reduce technical risk and engagements with operational users to better illuminate their needs and operational concepts.
Taming the complexity beast. If a program or an effort is particularly large, models and views can provide a disciplined way of communicating how you expect the system to behave. Some behavioral models such as business process models, activity models, and sequence diagrams are intuitive, easy to use, and easy to change to capture consensus views of system behavior. Refer to the SEG Approaches to Architecture Development article for guidance on for model characterization.
Keep it simple. Avoid diagrams that are complicated and non-intuitive, such as node connectivity diagrams with many nodes and edges, especially in the early phases of a program. This can be a deterrent for the uninitiated. Start with the operational concepts, so your architecture efforts flow from information that users and many other stakeholders already understand.
Determining the right models and views. Once the frameworks have been chosen, the models and views will need to be determined. It is not unusual to have to refer to several sets of guidance, each calling for a different set of views and models to be generated.
But it looked so pretty in the window. Lay out the requirements for your architectures what decisions it supports, what it will help stakeholders reason about, and how it will do so. A simple spreadsheet can be used for this purpose. This should happen early and often throughout the system's life cycle to ensure that the architecture is used. Figure 4 provides an example of a worksheet that was used to gather architecture requirements for a major aircraft program.
How do I create the right views? Selecting the right modeling approach to develop accurate and consistent representations that can be used across program boundaries is a critical systems engineering activity. Some of the questions to answer are:
- Is a disciplined architecture approach embedded in the primary tool my team will be using, as in the case of Activity-Based Modeling (ABM) being embedded in system architect, or do we have to enforce an approach ourselves?
- Are the rules/standards of the modeling language enforced in the tool, as in the case of BPMN 2.0 being embedded in iGrafix?
- Do I plan to generate executable models? If so, will my descriptions need to adhere to strict development guidelines to easily support the use of executable models to help reason about performance and timing issues of the system?
Bringing dolls to life. If your program is developing models for large systems supporting missions and businesses with time-sensitive needs, insight into system behavior is crucial. Seriously consider using executable models to gain it. Today, many architecture tools support the development of executable models easily and at reasonable cost. Mission-Level Modeling (MLM) and Model Driven or Architecture-Based/Centric Engineering are two modeling approaches that incorporate executable modeling. They are worth investigating to support reasoning about technology impacts to mission performance and internal system behavior, respectively.
How much architecture is enough? The most difficult conundrum when deciding to launch an architecture effort is determining the level of detail needed and when to stop producing/updating artifacts. Architecture models and views must be easily changeable. There is an investment associated with having a "living" architecture that contains current information, and differing levels of abstraction and views to satisfy all stakeholders. Actively discuss this sufficiency issue with stakeholders so that the architecture effort is "right-sized." Refer to the Architecture Specification for CANES .
Penny wise, pound-foolish. Generating architecture models and views can seem a lot easier to not do. Before jumping on the "architecture is costly and has minimal utility" bandwagon, consider the following:
- Will there be a need to tell others how the system works?
- Will there be a need to train new personnel on a regular basis (every one to three years) in system operations?
- Will there be a need to tell a different contractor how the system works so that costs for maintaining and refreshing the system remain competitive?
- Will there be a need to assess the system's viability to contribute to future mission needs?
If the answer to one or more of these questions is "yes," then consider concise, accurate, concordant, and consistent models of your system.
References & Resources
- IEEE Standard 1471, accessed February 26, 2010.
- Navy PMW 160 Tactical Networks, May 20, 2009, "Architecture Specification for Consolidated Afloat Network and Enterprise Services (CANES), Increment 1."
Additional References & Resources
"Approaches to Architecture Development," MITRE System Engineering Guide
"Architectures Federation," MITRE System Engineering Guide
"Architectural Patterns," MITRE System Engineering Guide
CIO Council, September 1999, "Federal Enterprise Architecture Framework," accessed February 26, 2010.
"Concept Development," MITRE Systems Engineering Guide
DoDAF Architecture Framework, version 2.0, 2008, accessed February 26, 2010.
The Open Group Architecture Framework (TOGAF), version 9, accessed February 26, 2010.