> Archive > Issue LXI, April 2012 > SOA Analysis within the Department of Defense Architecture Framework (DoDAF) 2.0 - Part I
Dawit Lessanu

Dawit Lessanu


Dawit Lessanu is an SOA and EA technology consultant with over 15 years of full application life cycle management (ALM/SDLC), SOA, Enterprise Architecture, and agile process improvement experience across diverse industries, including government, military, defense, brokerage, finance, and accounting. Dawit's implementation background is primarily focused on Microsoft .NET technologies.

Dawit holds a BA in Africana Studies and BS in Mechanical Engineering from Rutgers, The State University of New Jersey. He also holds an MBA in IT Management from Phoenix University.

You can connect with Dawit on LinkedIn.


rss  subscribe to this author


SOA Analysis within the Department of Defense Architecture Framework
(DoDAF) 2.0 – Part I

Published: April 26, 2012 • Service Technology Magazine Issue LXI PDF

Abstract: Over the past decade IT systems have grown in the variety of solutions, platforms, frameworks and implementation approach options available to organizations. This growth points to greater heterogeneity across and increased complexity within these systems. Coupling this with the drive to organize, reduce costs and gain efficiencies creates a need for a proven methodology towards tackling both the complexity and the discipline necessary to successfully achieve a mature first-class IT organization. Enterprise architecture (EA) is increasingly becoming acknowledged as a methodology to help address a wide variety of industry-specific needs based on best practices. Similarly service-oriented architecture (SOA) as a discipline has become increasingly popular as a methodology of improving organizational agility and reducing costs. SOA and EA have evolved into mature approaches to solving many of the goals and challenges businesses face today. This article explores possibilities of where service-oriented analysis, the first step towards achieving an SOA, can and should take place within an EA, specifically concerning the Department of Defense Enterprise Architecture Framework (DoDAF) version 2.0.


Service-oriented analysis is the first step in migrating towards an SOA. The goal of service-oriented analysis, while multifaceted, primarily seeks to deliver a standard set of services that comprise a service inventory. The SOA methodology addresses the question of what services need to be built and what logic should be encapsulated by each service. The process through which one conducts service-oriented analysis is supported in many ways within the strategic top-down approach of the enterprise architecture (EA) methodology. Service-oriented analysis, therefore, can and more importantly should be seen as a necessary part of any successful EA endeavor. With that, let us begin exploring the roles of service-oriented analysis and EA.

The Role of Service-Oriented Analysis

SOA is an established and effective methodology for evolving IT systems through the introduction of services. The SOA methodology has many phases (see Figure 3 below), but generally starts with service-oriented analysis. Embarking upon the path of service-orientation implies that an organization has made a cultural decision to become service-oriented (SO), with the eventual goal of designing, developing and deploying service-oriented architectures.

Service-oriented organizations when compared with their non-service-oriented counterparts are much better suited to adapt to the rapid advance of technology, market competition, security threats, and user needs. Service-oriented organizations typically establish an SOA governance committee in conjunction with an EA committee. While this structure is often loosely realized, it does provide for the right blend of architecture subject matter for experts that closely work with the business analysts to depict the enterprise.

Service-oriented analysis can be performed from a top-down or bottom-up approach or even a hybrid blend of both. Top-down is the preferred and more strategic approach towards service-orientation. The bottom-up approach is often project-specific addressing a very narrow “I need it now” scope. EA is typically performed top-down and therefore provides the preferred approach for an SOA architect. Service-oriented analysis is the first step, but is the most critical as it sets the groundwork for the design and implementation phases. A top-down approach affords greater long-term benefits towards meeting more of your strategic business goals. As an SOA architect it is critical to identify and realize the opportunities where service-oriented analysis can play a role within an organization’s IT strategy. More and more often the decisions made to formulate a business strategy, and the artifacts that support decision-making, rely on clearly articulated enterprise architecture.

The Role of Enterprise Architecture

Enterprise architecture (EA) has many nuanced definitions, however it is generally accepted as a method of defining existing and objective business processes to effectively execute a strategy and achieve the overall business vision. There are several approaches to express complex business processes which results in the wide variety of complementary and competing consortia, open-source, proprietary, and government frameworks out there today. Within the Department of Defense (DoD) the DoDAF is the accepted methodology for EA activities. The DoD is one of the government’s largest and oldest agencies. It has oversight across all the armed services that consist of over 2.2 million individuals mixed across both military and civilian occupation. There are hundreds of large-scale projects with thousands of encapsulated smaller projects. As previously stated, evolving needs to become more organized, gain efficiencies and reduce costs has resulted in the DoD embracing a “net-centric” vision for all its operations. This strategic transformation has brought EA to the forefront across the entire DoD. The current climate affords the SOA architect tremendous opportunity to help the DoD adopt and realize the many benefits of SOA, such as: increased reuse, interoperability, scalability, and value (just to name a few).

Introducing the DoDAF 2.0

The DoDAF provides the “overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries” [REF-1]. The DoDAF EA is conveyed through a collection of viewpoints that contain one or more models.

Figure 1 – The Complete DoDAF 2.0 Model with Categorized Viewpoints and Their Corresponding Models.

Each viewpoint has a specific purpose and is relevant to a specific audience; furthermore each model within has flexibility in its depiction. This flexibility is commonly referred to as “fit-for-purpose”. Ultimately, viewpoints and their respective models aid stakeholders in making decisions. Since its debut in 2003 the DoDAF has undergone 2 revisions and, with the release of DoDAF 2.0, the framework has introduced new Services Viewpoints. This is where the results of an SOA analysis can bear fruit within the EA process. We will touch on each of these viewpoints, highlighting the models that are highly relevant to the service-oriented analysis methodology.

Table 1 – High Level Purpose of Viewpoint Families Used within the DoDAF 2.0.

It is important to note that the presence of dedicated service views does not imply that proper service-oriented analysis, design and development processes have been incorporated. Therefore, it is the job of the SOA architect to ensure that proper SOA principles become woven into the architecture. Each viewpoint category is composed of several descriptive models. For instance, the All Viewpoint is made of an AV-1 (Overview and summary Information) and AV-2 (Integrated Dictionary) model. A complete discussion of all viewpoints is beyond the scope of this article; however, we will discuss most of them and how they specifically aid in service-oriented analysis. The following diagram shows a narrow slice of an enterprise showing how, in this case, a marketing department is broken out to align with viewpoints.

Figure 2 – Example of Architecture as it Relates to DoDAF 2.0 Viewpoints:
Data Supports Services, Services Support Systems, Systems Support Activities,
and Finally Organized Activities Produce Capabilities.

Beginning at the bottom of the diagram (Figure 2) data becomes information provided to services. Services, in-turn, are designed and composed through service-orientation to, in some cases, replace or support systems. Systems in-turn support activities (e.g. Design, Research). Aggregating activities creates processes that provide a capability (e.g. Marketing) to the enterprise.

Before we delve deeper into how SOA fits within the DoDAF and how the DoDAF, in-turn, expresses service-oriented analysis, it is important to note the definition of the term “service”. Surprisingly, not all enterprise architects come from a service-oriented background and more importantly most stakeholders often do not understand or appreciate SOA. In interacting with the later, the SOA architect must clearly define what is meant by the term “service”. A service in the SOA paradigm is defined as an encapsulated unit of logic implemented as a Web Service that has undergone service-orientation and refinement that can be accessed through a standard well-understood interface. A service should not be defined as a business function/activity such as a “help-desk”. Depending on your audience this term may often be used very loosely. Another point of contention is the proper definition of “capability” and “function”. Any EA architect can attest to the importance of solidifying the taxonomy upfront.

The 6-Steps in DoDAF EA

Guidance under the DoDAF outlines six recommended steps that should be conducted to properly conduct and realize enterprise architecture.

Table 2 – The 6 Steps of DoDAF Methodology.

In practice, steps five and six are done in parallel. As data is analyzed and validated, the architect creates specific models within specified viewpoints (assuming dependent models are also valid). Models are updated as information changes or as it is validated. The steps bolded above will have direct tie-in within a service-oriented analysis approach. Before we make this correlation, let us additionally outline the steps involved in service-oriented analysis.

The 4-Steps in Service-Oriented Analysis

At the highest-level service-oriented analysis is organized into four major steps as outlined in the following table:

Table 3 – Service-Oriented Analysis Methodology.

Service-oriented analysis is the first step in the overall SOA methodology. As illustrated in Figure 3, it starts the process and SOA should be thought of as iterative methodology. The key to successful service-oriented analysis is to apply service-oriented principles at each step and continually revisit and revise decision points as circumstances change.

Figure 3 – SOA Methodology.

Now we can begin to map where and how service-oriented analysis activities fit into the exact DoDAF development steps and the viewpoints that are the inevitable result. The following sections breakdown the service-oriented analysis phases/steps and demonstrate which models within the DoDAF map relatively well in support of service-oriented analysis.


In Part 2 of this article series we will explain each of the four steps in detail.


[REF-1] U.S. Department of Defense Chief Information Officer, “DoD Architecture Framework Version 2.02 DoD Deputy Chief Information Officer”, 2012

[REF-2] Erl, Thomas, Service-Oriented Architecture: Concepts, Technology & Design, Prentice Hall, 2005,


Special thanks to Misty Stalder and Stephen Koob.