ServiceTechMag.com > Issue LXII, May 2012 > SOA Analysis within the Department of Defense Architecture Framework (DoDAF) 2.0 - Part II
Dawit Lessanu

Dawit Lessanu

Biography

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.

Contributions

rss  subscribe to this author

Bookmarks



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

Published: May 23rd, 2012 • Service Technology Magazine Issue LXII PDF
 

This is the second in a two part series. The first part is published at SOA Analysis within the Department of Defense Architecture Framework (DoDAF) 2.0 – Part I.


The 4-Steps in Service-Oriented Analysis


Step 1: Determine the Scope of Your Service-Oriented Analysis

We will begin by discussing in greater detail the purpose of each particular model and how it aids in service-oriented analysis. The following table relates service-oriented analysis to the respective DoDAF viewpoints that help with defining and scoping our overall SOA activities.



Table 4 – Mapping of DoDAF Viewpoints to Step 1 Service-Oriented Analysis Process.


The enterprise architecture scope is typically much larger in scope than typically considered in traditional service-oriented analysis. However, EA certainly can provide a wealth of information, proper context and well-defined boundaries for an effective service-oriented analysis. EA activities closely parallel those of service-oriented analysis.

Using the models described above as guidelines, the following table discusses the relevance of specific DoDAF models to service-oriented analysis in greater detail.



Table 5 – DoDAF Models Relevant to Step 1.


The AV and CV viewpoints provide a broad contextual backdrop to the SOA architect. The OV scopes the activities at a high level and identifies organizations and performers that have a stake in the outcomes of both the enterprise architecture activities and service-oriented analysis. The OVs are developed early in the EA and service-oriented analysis phase and are critical models leveraged in the subsequent steps. Due to the relationship between many DoDAF viewpoints, it is critical in EA to get these views as precise as possible.

Now with scope and context well defined the SOA activities can begin considering the underlying data requirements. Contextualized data is what provides "information". Information is what customers are interested in receiving. Fortunately, the DoDAF 2.0 puts greater emphasis on a more data-centric view of the enterprise. Greater emphasis on understanding data up-front will enable an SOA solution to best meet the current and eventual needs of the clients served by it.


Step 2: Define and Understand the Data Requirements



Table 6 - Mapping DoDAF Models to Step 2.


The importance of understanding the data cannot be understated for either EA or service-oriented activities. Actually any enterprise undergoing enterprise architecture activities should have a data strategy in place. This strategy is central to SOA and should be well understood by all SOA architects. Data, or rather its contextualized derivative, information, is after all the core product that clients and consumers are interested in. Too often this upfront analysis is underestimated or considered late in the process which can lead to at best a weak SOA or at worst a failed one. While there is often a quick jump to service and contract design, let's not forget that the most unique aspect of any service contract is the data it works with. EA and service-oriented analysis seek to provide the "what" and "how" (respectively) of data that is persisted, exchanged, mediated, transformed and secured.

Data should be defined in such a way as to allow the SOA architect to understand its form, transport, frequency, persistence, ownership, and security. The last point should also be to consider external regulatory constraints such as in the case with health care information, personally identifiable information or financial records. Developing a data strategy can reveal tremendous data dysfunctions that affect the overall productivity of an organization. The goal of both EA and SOA is to remove or minimize these effects while providing additional opportunities to realize new capabilities.

The Data and Information Viewpoint is introduced at this stage and defines the operational and business information requirements and rules that are managed within and used as constraints on the activities. Additionally, key System and Service models provide greater clarity into the systems and services used to manage that data. The next stage of service-oriented analysis involves understanding data. The next table relates the service-oriented analysis to DoDAF models that communicate the understanding necessary for data analysis.



Table 7 - Models Relevant to the Understanding Data in Architecture.


The cumulative understanding of the enterprise data, and how it flows through the viewpoints in the architecture, plays well into the knowledge and understanding necessary to begin the next step in service-oriented analysis. The models discussed until this point allow the architect to firmly understand the scope, business processes, data, organizational stakeholders, risks, and the systems that are interacting to support the enterprise. The beginnings of the service modeling (Step 4) have actually already started at this point, albeit at a much higher level. Remember SOA is not a rigid formula and tends to be more fluid, evolving as information is available. However, care must be taken not to dive too deep into service candidate modeling just yet, as there is still a need to understand the existing application logic (e.g. the systems) that supports the enterprise.


Step 3: Identify Relevant Candidate Systems

Many of the models discussed in Step 2 are highly relevant in Step 3. The following table shows the additional DoDAF models of particular interest from the perspective of identifying automation systems in service-oriented analysis.



Table 8 - Mapping of DoDAF Step 1 of Service-Oriented Analysis Process.


Automation Systems are essentially business logic that can potentially benefit by exposing the underlying functionality as a service or set of services. Not all business logic will become service-enabled, but the exercise here is to identify and distinguish service candidates. The benefits include, but are not limited to, business logic reuse, interoperability and composability. The SV-10a, SV-10b and SV-10c models were designed with the intent to aid in service-oriented analysis specifically because they identify important dimensions of the enterprise through the description of dynamic behavior and performance expectations of systems.



Table 9 - Models Relevant to Identifying Systems.


The goal of this stage is to assess legacy, existing and future systems and accurately ascertain which systems within the scope of the architecture can be encapsulated and replaced by services. The models described before will aid in that mission. The SOA architect, at this point, has the necessary understanding of the activities, systems, and the underlying data. The EA activities have provided the necessary input to finish the final step in the service-oriented analysis methodology.


Step 4: Model Candidate Services (Service Inventory)

Modeling candidates is the final step before beginning the actual service design. This phase actually involves several sub-steps that have been addressed in many ways through the models developed in Steps 1-3. A full discussion of the service modeling is beyond the scope of this article and is well defined in Chapter 12 of Service Oriented Architecture - Concepts, Technology and Design by Thomas Erl [REF-2].



Table 10 - Mapping of DoDAF Step 1 of Service-Oriented Analysis Process.


Now we have arrived at the Services Viewpoints (SvcV) that aim to depict services in the DoDAF language. The SvcV models express the services and their compositions in support of the enterprise activities. In DoDAF typically these activities relate to either military business functions or war fighting. Either way, the service models must depict how the services will help fulfill this mission.



Table 11 - Services Models and Their Relevance to Service-Oriented Analysis.


Throughout Step-3 service-orientation is continually applied to the process. This injects consideration for things such as loose coupling, abstraction, reuse, autonomy, statelessness, discoverability and composability. Therefore service candidates, their respective functions and compositions continually evolve. An architect's work is never done. These views from a SOA perspective are in their infancy and will be matured as you move into the service design and service implementation phases of the SOA methodology.


Some Additional Considerations

Not all DoDAF artifacts produced will look the same. An OV-5b may look different depending on the architect and their client. This diversity in presentation is the underlying "fit-for-purpose" aspect of the DoDAF 2.0. It provides greater flexibility in depicting information to the extent necessary to your customer. In the end EA artifacts are meant to be effective communication tools to aid in the decision making process. Similarly, your SOA solutions must be traceable back to your customer goals that must be supported and to show value (e.g. cost efficiencies, productivity).

The views outlined in this article are critical DoDAF EA views to consider when implementing service-oriented analysis at a larger level within the organizations. This level of granularity may not be appropriate for smaller SOA efforts (enterprise architecture efforts typically are for large organizations). This is not to say that aspects of the DoDAF could not be performed. If you are on a smaller scale effort but would like to work in some EA models to aid your service-oriented analysis it may be beneficial to implement the OV-5a, OV-5b, SV-4, SV-5a and then pick and choose the relevant SvcV models you feel are necessary to express your candidate service inventory to your clients.


Conclusion

There are about a dozen more models that we have not covered in this article that can provide additional insight in helping service orientation activities. Certainly there are models that will aid in the subsequent steps of service-oriented design and service-development. The ones outlined in this article have provided benefit in the scope of service-oriented analysis. The intent of the article is to better acquaint the enterprise architect with the opportunities for realizing SOA through EA activities and conversely acquaint the SOA architect on how to navigate the DoDAF when performing service-orientated analysis. EA provides a fertile bed to plant the seeds of SOA. In future articles the alignment of SOA with other varieties of EA that are used within specific industries will be shown in an effort to emphasize the importance of SOA and its relevance to all organizations seeking to become mature in service management.


References

[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. http://www.soabooks.com/ctd/


Acknowledgements

Special thanks to Misty Stalder and Stephen Koob