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!