More on EA, DODAF and SOA

In a previous post, I talked about how EA can be used to influence SOA to provide the strategic perspective. Here are some more thoughts along those lines, with some guidance on service-oriented analysis using DODAF views.

I mentioned that SOA should be aligned to the organization's strategic objectives and that EA can help drive this. So how?

The DODAF defines a view called the OV-1 (high level operational concept) that describes/depicts the key entities (i.e. operational nodes), their activities, and interactions in support of the organization's mission(s). So once the organization's strategic objectives are determined, how the organization will execute on those objectives can be modeled using the OV-1. The OV-1 is a simple high level view, but the creation of it forces you to think about how the different groups/sub-organizations will interact to execute the strategic objectives. If you can't figure this out, then you have some unachievable objectives!

With the OV-1 created, you now have the organization's strategic objectives codified in an architectural artifact. Scoping your SOA using the OV-1 and using it as the starting point for service-oriented analysis ensures that your SOA is aligned to the organization's strategic objectives.

As I mentioned earlier, the OV-1 depicts the operational nodes (groups, departments, etc.), their activities, and interactions in support of the execution of the organization's objectives. Since SOA's all about creating and sharing capabilities across different ownership domains, the key things to focus on first from the OV-1 are the operational nodes and their interactions (the activities within each operational node can be useful later for further decomposition). With these operational nodes and their interactions, you have your candidates for the service providers, service consumers, and services. From that point on, it's just further analysis and decomposition to identify the services that comprise your SOA and who should provide them.

So there you have it--step-by-step guidance on how to ensure your SOA is aligned to the strategic objectives of your organization. Of course, this is all easier said than done.

Stay tuned, in a future installment I will discuss how other DODAF views can be used in that further analysis and decomposition.

Red Herring: DODAF vs. SOA

Those of you who work with the DoD are probably very familiar with DODAF and lately have probably heard a lot about how DODAF is incompatible/inadequate for representing Service Oriented Architectures. While there may be some truth to that, I consider it to be somewhat of a red herring. DODAF is primarily used to create Enterprise Architectures (EA). The real problem (at least based on what I've come across) is that those working on EA's don't really understand SOA and vice versa. Those working on EAs are usually more strategy and management focused and don't understand (or aren't interested) in the principles of service orientation. On the flip side, those working on SOAs are usually very technically-focused and don't understand many of the management and strategic objectives of EA (or find them boring and don't want to be bothered by them). As a result the two efforts are usually separate when they need to be interdependent. So how are they interdependent? There are a couple ways to look at it.

One, SOA is an architectural style and this style can be applied in the creation of the EA. An EA models how an enterprise works using multiple layers/views, e.g. organizational, operational, technical. Using a service-oriented style, the enterprise can be modeled as a set of service providers/consumers and the services through which they interact. This approach can be taken through all the layers of the EA. This is how SOA can be used to influence the EA.

On the other hand, the EA effort can and should also influence the SOA effort. As mentioned earlier, those working on the SOA effort are very technical and implementation-focused, they look at it as "let's build an SOA". The SOA needs to be aligned with the strategic objectives or problems that the enterprise is trying to address. Those that are very technical and implementation-focused will usually not be able to identify those strategic objectives/problems. For example, which parts of the enterprise are very dynamic such that they would benefit from the agility that can be achieved through SOA (and can justify the cost and effort)? An EA provides a holistic view of the enterprise such that the strategic objectives/problems can be identified and prioritized which in turn should be used to scope and define a roadmap for the SOA.

So stop arguing about whether or not DODAF can be used to depict SOAs and start figuring out how to reconcile the EA and SOA efforts!