|
Large government contracting projects often use a software life-cycle process that has its roots in pre 1990's waterfall style functional decompositions. In this process, system engineers perform functional decompositions from requirements that then break down into components for the software engineering team to develop. The problem with this process is that the system engineering functional decompositions tend to overlap and impose architectural constraints on the software architecture in ways that don't map well to the actual computing environment the software system is developed in.
Building large complex software systems requires people with specialized skills that apply at different levels of abstractions of the computing system. For example, system engineers may be familiar with the high level distributed capabilities required for a system while software architects are knowledgeable of the distributed software architectures and technologies to realize the higher level system concepts. The Department of Defense Architecture Framework (DoDAF) combined with SOA can facilitate a clear separation between system engineering and software architecture/development.
The Department of Defense Architecture Framework (DoDAF) was created in 2003 to help facilitate the construction of architectural views for large computing systems. The following provides a brief overview of DoDAF, see wikipedia-DoDAF for more information.
DoDAF views are organized into four basic view sets: overarching All View (AV), Operational View (OV), Systems View (SV), and the Technical Standards View (TV). Only a subset of the full DoDAF viewset is usually created for each system development.
- All View (AV)
AV products provide overarching descriptions of the entire architecture and define the scope and context of the architecture. The AV products are defined as:
- AV-1 Overview and Summary Information
- AV-2 Integrated Dictionary
- Operational View (OV)
OV products provide descriptions of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. The OV provides textual and graphical representations of operational nodes and elements, assigned tasks and activities, and information flows between nodes. It defines the type of information exchanged, the frequency of exchanges, the tasks and activities supported by these exchanges and the nature of the exchanges. The OV products are defined as:
- OV-1 High Level Operational Concept Graphic
- OV-2 Operational Node Connectivity Description
- OV-3 Operational Information Exchange Matrix
- OV-4 Organizational Relationships Chart
- OV-5 Operational Activity Model
- OV-6a Operational Rules Model
- OV-6b Operational State Transition Description
- OV-6c Operational Event-Trace Description
- OV-7 Logical Data Model
- Systems View (SV)
SV products provide graphical and textual descriptions of systems and system interconnections that provide or support functions. Interconnections between systems defined in the OV are described in the SVs. The SV products are:
- SV-1 System Interface Description
- SV-2 Systems Communications Description
- SV-3 Systems-Systems Matrix
- SV-4 Systems Functionality Description
- SV-5 Operational Activity to Systems Functionality Traceability Matrix
- SV-6 Systems Data Exchange Matrix
- SV-7 Systems Performance Parameters Matrix
- SV-8 Systems Evolution Description
- SV-9 Systems Technology Forecast
- SV-10a Systems Rules Model
- SV-10b Systems State Transition Description
- SV-10c Systems Event-Trace Description
- SV-11 Physical Schema
- Technical Standards View (TV)
TV products define technical standards, implementation conventions, business rules and criteria that govern the architecture. The TV products are as follows:
- TV-1 Technical Standards Profile
- TV-2 Technical Standards Forecast
Getting back to the problem of functional decompositions imposing impractical constraints on the software architecture. SOA is all about distributed capabilities and how to bring needs and capabilities together. System engineers who develop large complex computing systems using DoDAF are really defining distributed capabilities and how those distributed capabilities interoperate. If DoDAF, SOA, and business process modeling are combined there then becomes a very clear dividing line between system architecture and software architecture. The system engineers stick to defining distributed capabilities and interoperability and the software engineers focus on the computing technologies and development of the software systems that provide the distributed capabilities. Another way to think of the dividing line between system engineering and software engineering is that the system engineers define the public side of services and the software engineers build the inherently private side of services. In order to incorporate business process modeling into DoDAF, the suggestion is to drop the OV6a-c's and the SV-10a-c's and use business process modeling in its place. The business process models can then be handed off to software engineering for software architecture development and construction. The business process modeling provides the flexibility of orchestrating SOA services and replaces the point to point communications defined in the OV6a-c's and SV-10a-c's.
When thinking of distributed capabilities, there is much more to consider than what methods need to be called and what data needs to be passed to the method. An example of a meta-model (under construction) for distributed capabilities is provided on the OASIS SOA Reference Architecture Wiki for Service Descriptions. For interface control documents, this is a good place to start to see what to incorporate for distributed systems.
So how about those OV7 Logical Data Models? Standards are currently under development for registry/repositories that will make the OV7s a nice fit for publicly visible meta-data contained in registries/repositories. SOA registry/repositories provided by vendors will incorporate capabilities to allow the storage of information meta-models, allow multiple views of an information meta-model based on roles or attributes, incorporate identity and authorization mechanisms, provide the storage of public data in intrinsic repositories, and provide event notifications when data values change in the intrinsic repository. The OV7 Logical Data Model becomes a context for the understanding of an information model for a particular orchestration of distributed capabilities. Each orchestration of services can mean a different context for the distributed computing system and thus there could be many OV7 Logical Data Models for many orchestrations of distributed computing capabilities. When discussing SOA, information models relate to aspects of the public shared state and provide one means of measuring real world effects.
An observation about the application of system engineering processes in the government sector is that there is frequently not enough feedback between software/hardware engineers and system engineering. During the construction of DoDAF artifacts, software/hardware engineering and subject matter experts should continually review DoDAF artifacts for validity. At any point in the construction of DoDAF views, system engineers and software/hardware engineers should be able to task prototyping activities to weed out false assumptions that can propagate inefficiencies through the system engineering design. And of course best practices of iterative development should also be closely aligned with the system engineering process.
A broader perspective of the environment/ecosystem for SOA systems and ultimately the environment that DoDAF will apply has been captured well in the ongoing work for the OASIS SOA Reference Architecture - Business via Services view.
Danny Thornton
|
