NEWS AT SEI
This article was originally published in News at SEI on: March 1, 2004
The Department of Defense Architecture Framework1 (DoDAF), which is mandated by the DoD for large-scale systems, describes how the architecture for a system or system of systems (SoS) should be documented. The framework breaks that documentation into three major views: operational (OV), system (SV), and technical (TV), and one associated view, the all view (AV). Each view contains one or more graphic, tabular, and descriptive representations of the system. Because using any framework for the first time can be difficult, the SEI set out to discover how DoD organizations and their contractors can make the process easier.
Researchers at the SEI did this in two ways. First, they held an invitation-only workshop with researchers from government, industrial, and academic institutions. Second, they conducted eight interviews with architects, designers, architecture documentation reviewers, and program managers who are associated with acquisition category I (ACAT I) programs. Each program team was developing large-scale software-intensive SoSs using the DoDAF.2 The architectures they were creating consisted of many OV, SV, and TV representations and served as the bases for the SoSs’ acquisition planning, development, and deployment.
What the Workshop and Interviews Revealed
- The DoDAF and current software architecture approaches were developed separately, by different organizations, for different purposes, and with little overlap. Hence, the views they use to document systems are significantly different, making compatibility and consistency among those views problematic.
While the DoDAF is used to document system architectures, it does not address software architectures. For this reason, software views are often needed to supplement the DoDAF representations so that architects can better understand how well the systems will operate. Architects must determine which views are needed for a particular system. IEEE Std 1471-2000 3 and the SEI’s Views and Beyond4approach (which leads to 1471-compliant documentation) both provide guidance on selecting views.
- Program teams must tailor the DoDAF representations they use. Without this tailoring, reviewers will be inundated with information that they have neither the time nor the expertise to comment on. Tailoring may include annotating representations, providing more or less detail within specific representations, or adding guidelines for understanding them.
Program teams may also consider adding other views such as those that provide additional information about software. Team members should ask only for the details that can be reviewed effectively by the available reviewers within the specified time frame.
- None of the views conveniently represents multi-stage transitions from stovepiped legacy systems to interoperable SoSs, even though that is a common concern among those developing mission-critical systems. Some additional views, such as a master evolution plan, are needed to show when new systems and capabilities will be introduced and old systems retired.
- Currently, each program office and its contractor must struggle with the differences between the DoDAF and other software architecture approaches when developing their own problem-solving approach. They must then train their staff members to follow that approach, using available tool sets as much as possible. Organizations also need to develop a process for using and building the DoDAF representations and any additional representations. That process will control the flow of building and reviewing the architecture, and relating the architecture to the system. Cross-service workshops, discussion forums, and documentation on lessons learned can promote a shared understanding of the architectural issues involved.
- Tool usage requires specific rules for successful application within a program. Both commercial off-the-shelf (COTS) and custom tools are insufficient to meet the needs of architects or reviewers. Without training, architects will not use tools—even tailored ones—consistently across a program, and different contractors will apply the tools in different ways. Organizations may consider the use of different tool sets by contractors, provided the latter are given adequate guidance in defining the information that must be provided. Government organizations also need guidance on using the tools, so they can understand and review the representations.
Crosscutting attributes such as performance, availability, modifiability, and security are at least equal to functionality in determining the architecture. Architecture evaluation in the form of the SEI Architecture Tradeoff Analysis Method (ATAM) or architectural requirements elicitation in the form of an SEI quality attribute workshop (QAW) can help explore these attributes.
Learn More About the SEI’s Research on Using the DoDAF
Because the DoDAF is now mandatory for DoD organizations, the SEI is striving to help them make the best use of it. To learn more about the SEI’s findings on using the DoDAF, see the following two technical notes
DoD Experience with the C4ISR Architecture Framework
DoD Architecture Framework and Software Architecture Workshop Report
1 DoD Architecture Framework Working Group. DoD Architecture Framework Version 1.0. Washington, DC: Department of Defense, 2003.
2 The actual framework inquired about was an earlier version of the DoDAF—the Command, Control, Communications, Computer, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework. At the time of the interviews, the DoDAF had not yet been officially released.
3 Institute of Electrical and Electronics Engineers. IEEE Std 1471-2000. Piscataway, NJ: IEEE Computer Press, 2000.
4 Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; Ivers, J.; Little, R.; Nord, R.; & Stafford, J. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley, 2002.