1. Tailoring DoDAF for SOA
January 9, 2006
Huei-Wan Ang
Christopher Bashioum
Fatma Dandashi
Will Kirkman

2. Agenda What We Did Why We Did It Impact
How This Relates To The DoDAF 2.0 Overlays
Recommended Next Steps
Details

3. What We Did How To Tailor DoDAF for SOA Begin with semantic model
Describe specific SOA characteristics that must be represented in DoDAF products
Define artifacts useful to Enterprise Architects
Use terminology suited for SOA

4. What We Did: Historical Context
04/2004
SOAF draft published
Exploration of framework to show SOA
11/2004
“Tailoring DoDAF for SOA” paper published
Presentation at 1st Mitre SOA TEM
03/2005
MITRE Architecture Council Working Group
Started discussion of SOA and EA
05/2005
MITRE Architecture Council WG merged into ESE
Accepted industry broad consensus on SOA
Started 2nd iteration of how to tailor DoDAF for SOA
Used Architecture Specification Model* (ASM) for baseline metamodel
* ASM is sponsored by AF SAF XCX (Policy Planning and Resources Division of USAF CIO), with original funding and collaboration from OSD NII

5. Why We Did It
NII/CIO Decision That DoD Will Evolve To SOA As Rapidly As Technically Feasible
Argument For Using DoDAF Can Be Summed Up As Follows:
Minimal tailoring needed
Leverages existing body of knowledge and architecture products
e.g., NCES, BMMP, USCG EA, Army EA, FORCENet EA, USAF C2 Constellation, etc.
Arguments For Not Using DoDAF Are Based On Misconceptions

6. Why We Did It (2)
Misconception 1: DODAF Is “Point-to-Point”, SOA Is “Everything-to-Everything”
Counter: Not Necessarily …
DODAF is intended to show key information flows and interfaces
Maps to well-defined info flows in SOA
Neither DODAF nor SOA claim to show all possible information flows or interfaces
Misconception 2: SOA Is Dynamic, DoDAF Is Static
Counter: Not Always …
SOA Infrastructure services are fairly static
Other services are building blocks
What is dynamic is allowed for in both SOA and DODAF
Misconception 3: Its Got To Be “Either/Or”
Counter: Can actually work together “both/and”
SOA is a methodology, DODAF is a framework
The following three common arguments against using DODAF to show a Services Oriented Architecture have been made at various times. It is our assertion that these arguments are based on a misunderstanding of SOA and/or a narrow view of DODAF. We will answer each argument in turn.
Argument 1: DODAF can only show ‘point to point’ connections whereas SOA is “everything to everything” connections
Counter to Argument 1: the assertion that DoDAF is point-to-point and SOA is everything-to-everything does not accurately identify the real issue. When people say that DoDAF is “point-to-point”, they generally mean that DoDAF shows an exhaustive list of connections between systems or services and the systems or services on the two sides of a connection have knowledge about how to interface with each other. In other words, the only information flows (shown in the operational views) and data flows (shown in the system views) that can exist in the enterprise are those that are defined in the architectural artifacts and there is tight coupling between each pair of systems or services on the two sides of each connection. No other information/data flows exist or can exist. When people say that SOA means “everything-to-everything” they imply that there is no value is highlighting specific information/data flows and service providers and their prospective service consumers don’t have to know about each other a-priori. Both of these statements are false.
DoDAF is not constrained to show all of the possible information flows in the enterprise being architected – the artifacts only show those flows that are of interest at a given point in time. The implication is that other flows of information/data are still possible, and may show up in later revisions to the architectural products. It is better in this sense to consider the DoDAF artifacts as a snapshot in time of “key” information/data flows. In addition, DoDAF is not constrained to only show information/data flows between two tightly coupled parties that know about how to connect to each other.
Pre-defined flows of information and of data between known endpoints are important in SOAs as they give justification for the creation of a service in the first place, and they are helpful in identifying sizing requirements for the service. In DoDAF or SOA, there is nothing precluding the service from being re-used in another ad-hoc information or data flow. Additionally, this a-priori knowledge captured in the DODAF can be used to validate the usefulness of existing services or to identify where services may be missing. The SOA infrastructure, and use of Web Services standards in implementing the SOA allow for much lower overhead in creating new (ad-hoc, or temporary) information and data flows, but these flows have to be constructed from and are completely dependent on the pre-defined flows and the SOA infrastructure and can’t be created arbitrarily.
Argument 2: DODAF can only show a static architecture vs. the dynamic architecture of an SOA
Counter to Argument 2: the dynamic nature of a service orientated architecture has to do with the fact that service endpoints may appear on or disappear from the enterprise network at will, and that DoDAF cannot capture this ad-hoc nature of the enterprise SOA. In answer to this, consider that in order for the ad-hoc nature of the enterprise SOA to “work”, there must be a relatively static SOA infrastructure (registries, discovery tools) to support this capability. Otherwise, nobody on the network would ever know that a service became available. In this paper, the authors provide a metamodel and examples of how DoDAF can be used to show the infrastructure as well as ad-hoc data flows that are supported by the described SOA infrastructure.
Argument 3: DODAF and SOA are competing architectures
Counter to Argument 3: The third argument is really based on a fundamental misunderstanding of both SOA and DODAF. DODAF is a framework that organizes architecture products according to the “view” or “perspective” of the architecture that the specific products expose. This is similar to having different perspectives or views of a building architecture (plan view, front view, side view, etc.). SOA, on the other hand, is an orientation or methodology applied when defining the primitives used within the DODAF (or any other framework). This is similar in concept to an architect applying an object orientated methodology to create an architecture model using DODAF elements and relationships. DoDAF does not prescribe OO, but it is a framework that supports it. In the same way, the service orientation (or SOA methodology) can be used within DoDAF. (Note – a corollary of this is that SOAs can be described with other frameworks).

7. Impact Leverages Existing DoDAF Products, Expertise, Toolset
Helps Improve Consistency Among Architecture Products
Enables Architects To More Effectively Take Advantage Of SOA
Alignment of services to business processes
Identification of common functionality
i.e., re-usable services

8. How This Relates To DoDAF 2.0 Overlays
Portfolio Management (PfM)
Service Oriented Architecture
Executable Architectures
DODAF 2.0
JCIDS
Systems Engineering
Architectures…
– Means to an end
– NOT an end to themselves

9. Recommended Next Steps
Need To Develop More Robust Example Architecture
Identify program moving towards Net-Centricity that needs help with architecture effort
Help program create the architecture according to "tailoring" paper
Use selected portions of that architecture as example
Need To Communicate With Other Organizations
Within DoD
Other Government Agencies
Industry

10. Details: Assumptions/Issues/Constraints
Broad congruity on SOA concepts between Government and Industry
Can feed metamodel issues/gaps back into ASM process
Previous work (SOAF, Tailoring DoDAF) is not "in concrete"
This continues to be an evolutionary process
Issues:
OASIS SOA Reference Model in process
OASIS SOA Blueprints Technical Committee being formed
Constraints:
Base this effort on ASM metamodel
Use previous work on SOAF and "tailoring DoDAF for SOA"
Use OASIS SOA Reference Model as much as possible

11. Details: Philosophy For Organizing ViewsOV
(Requirements)
Functional spec of operational processes, mission threads, capabilities.
Requirements for the "how", or desired behavior
Resource specification of management responsibility
After requirements are defined, who is responsible for them (e.g., PMO) SV
(Solutions)
Allocation to human processes and services
E.g., service specifications
Implementation of execution responsibility
I.e., who actually gets the work done (e.g., service implementation) TV
(Constraints)
Current Standards
Future Standards

12. Details: SOA and relevant Views

13. Backups

14. OV-1 for PKI Architecture

15. OV-6a showing Rules for Certificate Management Authority
IF application is received (event) AND application is valid (condition) AND subject is not registered (current state) THEN register subject (ACTION) AND transition to subject registered (next state).
IF revoke request is received (event) AND subject is registered (current state) THEN revoke subject (ACTION) AND transition to subject not registered (next state)

16. OV-6c showing several process flow diagrams for PKI Administration

17. SV-1 (S) showing groupings of human processes and services by physical locations

18. SV-4 (S) showing the human processes and services that interact with them for registering an applicant

19. SV-4(I) showing a breakdown of the Register Subject service and Create Token service

20. SV-10c (S) Showing human and service registration thread

21. SV-10c (I) showing details of the Register service thread

22. SV-12 showing a generic structure for an SDF (replaces need for SV-6)

23. Background: What is SOA?
SOA is a Pattern, Methodology, or Orientation Applied When Creating An Architecture, where …
Functionality Is Implemented As Services,
With The Following Characteristics:
Loose Coupling
Location Transparency
Protocol Independence

24. Business Process Specification Sub-Model

25. Business Process Allocation Sub-Model

26. Business Process Exchange Sub-Model

27. Human Process Specification Sub-Model

28. Human Process Implementation Sub-Model

29. Human Process Exchange Sub-Model

30. Service Specification Sub-Model

31. Service Implementation Sub-Model

32. Service Exchange Sub-Model

33. Effect Sub-Model