Here’s a sneak peak of Dr. Steven Dam’s new book: “DoDAF 2.0: A Guide to Applying Systems Engineering to Develop Integrated, Executable Architectures.”
This figure on the right shows SPEC Innovations’ process in a compact timeline format. The steps are numbered to indicate their nominal start sequence. Notice that most of these steps overlap, which demonstrates the concurrent, iterative nature of this process. Since it assumes that this process is not an end process, our process goes slightly beyond the minimum requirements for developing DoDAF products. It provides the necessary information for executing the resulting architecture, including the requirements analysis and operational demonstration.
Now let’s go through each of the steps, so that it will become clear how they work.
Step 1: Capture and Analyze Related Documents. First obtain any related documents, capture them in the architecture repository (Innoslate® or the AV-2), and analyze them to identify issues, risks and assumptions for other activities and capabilities.
Step 2: Identify Assumptions. Identify the assumptions made in Step 1 and review those assumptions with the Government to ensure that subsequent steps in this process will meet project objectives. You should capture these assumption and decisions in your tool of choice and document them in the AV-1.
Step 3: Identify Existing and Planned Systems. We recommend conducting a survey of the current and on-going activities related to this architecture, thus ensuring that capabilities already available or planned are taken into account in this architecture. This step reduces an unnecessary duplication of effort. Coordination and monitoring of the progress of planned systems must also be included in this step. Planned systems that are incorporated as part of the architecture should be included in a SvcV-8/SV-8 and/or SvcV-9/SV-9 diagrams to enhance transition planning.
Step 4: Capture Constraints. In this step, capture the technical, schedule, and political constraints imposed by external laws, policies, regulations, and standards. These constraints often come from the previous three steps, as well as later analyses. This step results in the development of the technical standard views (StdV-1 and StdV-2).
Step 5: Develop Operational Context Diagram. The operational context diagram is an extension of the classical context diagram used in system engineering. You extended it to include interactions between external systems. It describes the overall architecture environment, including interactions between stakeholders, external systems/architectures, facilities, and resources. The operational context diagram shall form the basis for the
CV-1, OV-1, OV-2 and SV-1 DoDAF products.
Step 6: Develop Operational Scenarios. In this step, you will develop a set of operational scenarios that represent the scope of potential uses of the “As-Is” architecture. Some call these use cases or threads. You have found that building a set of scenarios from the simplest case to the most complex and reusing activities/functions provides an effective way to create a concept of operations (CONOPS) at a reasonable size. These scenarios represent typical user and system processes. The results of this step provide the initial OV-5/OV-6c, SvcV-4/SvcV-10c, and SV-4/SV-10c products. These scenarios can also form the basis for the test scenarios in the Operational Demonstration Master Plan (ODMP).
Step 7: Derive Functional Behavior. In this step, you will derive the overall functional behavior from the individual scenarios developed as part of Step 6. If you are clever in selecting a scenario set that builds upon each other, instead of coming up with a dissimilar, but overlapping set. The results of this step provide the final OV-5/OV-6c, SvcV-4/SvcV-10c, and SV-4/SV-10c products.
Step 8: Derive System Elements. In this step, you will derive the system elements from the functional behavior (packaging the functionality) and the potential COTS, GOTS, and legacy systems. You will create components that provide as simple as possible interfaces between system elements. The outcome of this task results in the final SvcV-1/SV-1.
Step 9: Allocate Functions to System Elements. Obviously, this step goes hand-in-hand with Steps 7 and 8. During this step, you will allocate functions to system elements to establish the traceability between functional behavior and the system elements. You can also use this step to distinguish between operational activities and system functions
Step 10: Prepare Interface Diagrams. This step continues the allocation process, ensuring that you have documented what data elements flow through which interfaces. Most of this becomes obvious when you complete Step 9, during which the functional allocation to system elements defines the data that must flow between the elements. However, after Step 9, you need to determine the mechanism for the data transmissions and creating the resulting diagrams. While in Step 10, we finalize the OV-3, SvcV-6, and SV-6.
Step 11: Define Resources, Error Detection, and Recovery Processes. As part of the scenario development and functional behavior analysis, you need to include the effects of non-ideal processes, where errors and other alternatives are detected and corrected (as part of the process). In addition, the use of any resources will be included in the functional analysis developed under Steps 6 & 7.
Step 12: Perform Dynamic Analyses. Just like in Step 11, you need to perform dynamic analyses of the individual scenarios, the overall functional behavior, and the overall behavior as constrained by the physical architecture, including the interface capacities and latencies. Clearly, this step must be performed concurrently with Steps 6, 7, and 9 to develop an executable architecture. You can also document the results of this analysis in the Findings section of the AV-1.
Step 13: Develop Operational Demonstration Master Plan. It is critical that you create a draft of the Operational Demonstration Master Plan (ODMP) or Test and Evaluation Master Plan (TEMP)—as part of the architecture development process. The document purpose is to enable the future acceptance testing of the resulting architecture design and to demonstrate potential issues and problems that will require resolution in the architecture. You should include people who know test and evaluation processes and capabilities as part of their team in developing this document.
Step 14: Provide Options. It’s important to realize that creating an architecture it is not a useless activity. During the process, you will identify any potential problems (shortfalls or gaps) with the “As-Is” architecture and provide options to resolve these problems. Plan to create a briefing that summarizes these options, even if the options have been decided during the process, and incorporate them in the Findings section of the AV-1. Note also that you should have the information necessary to develop the Project Views (PV-1, PV-2, and PV-3) to create/update the plans for the detailed development, acquisition, integration, and verification phases of the project. In addition, all the Capability Views (CVs) can now be completed and presented. In a pure top-down approach, you might generate these first. Rarely have I had the insight to do so, particularly not at the architecture level.
Step 15: Conduct Trade-off Analyses. Clearly, all through this process, you will perform trade-off analyses, using stakeholder validated evaluation criteria, to derive requirements, select scenarios, and select components, including COTS and GOTS, and other potential options. Summarize these as part of the options (Step 14) at the end of the process and present them to the customer. You can also document these trade-off analyses in the Findings section of the AV-1.
Step 16: Generate Views, Briefings, and Reports. This last step recognizes that throughout any architecture project, you will have to produce reports and briefings to show status and progress. By using the technique and tools selected (particularly Innoslate®), we have found that the development of reports and briefings is now a simple by-product of the process.
The figure on the right summarizes the production of DoDAF products throughout the process. We recommend delivering an early draft of the AV-1 at the beginning of the project. Final versions of the products are shown at roughly the time that they should be finished and associated with the steps that produced them. Note also that midway through this process you have sufficient information to develop a solid concept of operations (CONOPS). We have found developing one early and updating it as the design matures provides a great communications mechanism between you and the users.
Hope you enjoyed a sneak peek of Dr. Dam’s new book, “DoDAF 2.0: A Guide to Applying Systems Engineering to Develop Integrated, Executable Architectures.” The book will be released this November. Look for a preview here in Resources or find it on Amazon.