Why SOA works for the government

The feds have been early SOA adopters, because they really need its advantages. That'll be truer with a new administration and today's challenges.

With the new administration coming into town (I live and work in D.C.), there is much talk of change, but not enough planning as of yet.

Clearly, there is going to be some refocusing of resources, and shifts in priorities, and at the same time an opportunity to make some improvements.

The fact is that the government, especially the Defense Department, as been very proactive when it comes to SOA, in many cases more so than my commercial clients.

What's driving this effort is a mix of architectural need, the fact that most agencies have a mess on their hands, and mandates coming from the top in the form of architecture guidelines and standards.

Thus, in the world of the U.S. government, SOA is nothing new.

The fact of the matter is that government has much to gain from SOA. The ability to reuse services intra- and inter-agency will save many millions a year on application development costs. However, the real prize is the ability to shift the architecture to adapt to new missions and agency objectives.

Case in point: the shifting directions and priorities of the new administration, meaning new and changing business processes, as well as adding and deleting core enterprise systems.

SOA, if done right, allows you to put volatility into a single domain, and make adjustments within that domain to alter the architecture at will, adapting to new or changing business needs, without requiring a complete rip and replace, or rewrite.

Remember, the value of SOA is the ability to create an architecture that's able to change, not just creating an architecture that meets the needs of the agency or business at a particular point in time.