Model Driven DoDAF Architecture: Building for Change
On first glance, the marriage of Dovèl Technologies and ZapThink might appear to be somewhat of a mismatch: boutique Federal contractor acquires iconoclastic architecture thought leadership firm? But look below the surface, and the synergies become apparent, as Dovèl has long had an iconoclastic approach to architecture, since after all, we focus on architecture that actually works.
In the commercial world, delivering software solutions that work is the norm (or at least, relatively common), but unfortunately, in the world of government contracting, it seems that so many initiatives are little more than thinly veiled money pits – a fine example of our tax dollars at work. Federal architecture initiatives are a case in point: so many architecture projects in the government yield little more than checklist architectures, a problem ZapThink discussed in irreverent detail about a year ago.
In that article, ZapThink called out the Department of Defense Architecture Framework (DoDAF) as a blatant example of the checklist architecture problem. To be sure, many DoDAF efforts yield little more than multiple binders of documentation. But any architecture framework is nothing more than a tool, and whether a tool helps solve a problem depends more on how it is used than on the tool itself. In fact, at Dovèl, we have found DoDAF to be valuable for architecting systems that not only work, but that meet evolving business needs. Our secret? Combining DoDAF with Model-Driven Architecture (MDA) to implement a dynamic delivery approach that gives our client a solution that automatically responds to change.
Connecting MDA and DoDAF
MDA is a software design approach from the Object Management Group (OMG) which provides a set of guidelines for structuring specifications expressed as models. It also offers a common approach for designing and building systems that remain decoupled from the eventual languages, platforms and middleware environments that will support them. Architects use MDA to define platform independent models that can be translated into one or more platform specific models for the actual implementation.
For many years the US Department of Defense (DoD), and in fact, the entire Federal government, has been struggling to connect their business initiatives to the technologies that help realize these initiatives. For this reason, the DoD leveraged MDA to develop DoDAF. The intent of DoDAF was to provide a different way to specify and build systems: a mechanism for DoD programs to design their systems once and then transition them over time when new technology comes along.
Unfortunately, typical DoDAF initiatives end up with unimplemented architectures, or at a minimum, architecture artifacts that are not reusable during implementation. To address these problems, Dovèl developed an MDA-based approach for a Federal agency that assisted in continuous code generation – one of the more advanced capabilities of MDA. We provided an end-to-end integrated architecture from requirements through execution. This forward-engineering approach was continuously repeatable, helping to establish a living architecture that actively guided and governed system development through system delivery.
The figure below illustrates the deployed system. We used a model-driven approach that generated reusable artifacts that implementation specific tools can consume, thereby enabling forward compatibility, and that supported tracing to requirements for backward compatibility. In essence, we achieved continuous code generation. Basically, every artifact that the MDA tool generated was consumable by the implementation tools.
Integrated MDA Process
We used an integrated Enterprise Architecture tool to model the various DoDAF views. It also supported the ability to export the views for development, in XML Process Definition Language (XPDL) format compatible with a chosen development tool.
Multiple DoDAF viewpoints captured the integrated architecture, each of which conveyed different aspects of the architecture across several products, as shown in the table below.
DoDAF Architectural Viewpoint
|Operational Viewpoint (OV)||Describes the tasks, activities, participating nodes, and associated information exchanges required to perform a mission.|
|Systems Viewpoint (SV)||Describes the systems of concern and their connections in the context of the OV.|
|Services Viewpoint (SvcV)||Identifies the Services, Service items and the information exchanges between the Services.|
|Data and Information Viewpoint (DIV)||Models the data structure and identifies the entities and attributes.|
We initiated the effort by creating the Operational Models, as shown in the following table.
DoDAF Operational Model
|Operational Activity Decomposition Tree (OV-5a)||Describes the breadth and depth of operational activities in scope.|
|Operational Activity Model (OV-5b)||Extends the OV-5a and identifies the inputs and outputs and mapping them to information exchange requirements (IERs) where appropriate.|
|Event Trace Description (OV-6c)||Orchestrates OV-5 operational activities in an end-to-end flow.|
|Operational Resource Flow Description (OV-2)||Identifies performers (operational nodes) for the activities defined in the OV-5a.|
|Operational Resource Flow Matrix (OV-3)||Contains the operational exchanges defined in OV-2, correlating sending and receiving performers and associated producing and consuming operational activities.|
|Operational Relationships Chart (OV-4)||Represents the context, role and their relationships to the enterprise operations, as defined in the OV-2.|
We also created the corresponding System Models, which appear in the table below.
DoDAF System Model
|Systems Interface Description (SV-1)||Defines all the systems that will be interacting using a system connector.|
|Systems Resource Flow Description (SV-2)||Includes additional posts and/or organizations defined in the OV-2.|
|Systems Functionality Description (SV-4)||Defines the system functions that implement operational activities from OV-5a. It also defines systems function actions that take function parameters from the IERs defined in DIV-2.|
|Operational Activity to Systems Function Traceability Matrix (SV-5a)||Establishes a map of the system functions in the SV-4 to the operational activities defined in the OV-5.|
In many cases, the creation of these views is where the architecture initiative stalls, leading to dreaded checklist architectures. In this project, however, the next step of our forward-looking architectural development approach was exporting the architecture model into XPDL and XML Metadata Interchange (XMI) documents following the DoDAF Standards Profile (StdV-1), which the tooling automatically transformed into Business Process Models (BPM), XML Schema Definitions (XSD), Web Services Description Language (WSDL) files, and executable Java code as appropriate.
We implemented this transformation using the XML Style Sheet Transformation (XSLT) standard and best-of-breed open source technologies including the Apache CXF open source Web Services framework. These generated artifacts – XPDL files, persistence layer Java classes, WSDL files and XML schemas – formed the foundation for the development effort. We even packaged these artifacts for each process area and provided them to the software developers for implementation as Service Component Architecture (SCA) composites. The end result was the ability to automatically generate running software directly from the DoDAF Viewpoints, which in turn dynamically represented the business requirements, providing a closed loop (requirements to deployment, traceable back to the requirements).
The ZapThink Take
In traditional systems engineering, we build to a given set of requirements. ZapThink has long espoused, however, that SOA deployments are complex systems, where the business requires something agile, so we build them something agile – that is, a system that responds to changing requirements, rather than a system that meets any particular set of requirements. In essence, we have architected and deployed just such a system on this project. Clearly, if the DoD had fixed requirements, the system wouldn’t have had so many moving parts. But such a scenario is overly simplistic: in the complicated global theater today’s DoD plays in, when would their requirements ever be stable?
Furthermore, we’ve turned the checklist architecture context for DoDAF on its head. After all, the spirit of the Clinger-Cohen Act which mandated architecture at the Federal level was to improve the agility of our government, not to waste money by generating reams of documentation. Too many agencies – and too many Federal contractors – have lost sight of these simple goals of architecture, instead spending their time and money on implementing inflexible systems while paying lip service to Congress’s architectural mandate. With this project we have shown that it doesn’t have to be that way. Architecture done right is the key to agility, not an impediment to it.
- » CloudBees, Google and Linux Foundation launch Continuous Delivery Foundation
- » Gartner says tipping point in cloud PaaS is almost complete – with $20bn market revenue in 2019
- » Practical cloud considerations: Security and the decryption conundrum
- » Why standardisation is good for NetOps: Innovation instead of impediment
- » How ideal DevOps recruitment requires a mix of soft and technical skills