Joe McKendrick asked a really good question in a recent blog that I'd like to tackle: how to build SOA when executives don't care. 

A little background: Joe McKendrick and I have been having an interesting discussion about SOA development styles: top-down, bottom-up, and middle-out. In his most recent post, Joe titled (rather humorously) my analogies for the different styles as "Service-Oriented Anarchy" (bottom up) and "Soviet-Oriented Architecture" (top down).  Gotta love that.

I had drawn the analogy that bottom up was very "local focused" and capitalistic/democratic, and that is why it appeals so much to us, but that enterprises are not democracies.  They are, at best, like a benevolent monarchy, with the CEO (and executive management) setting strategy.

In that post, Joe concluded with a very pertinent point:

"But, again, you have to be fortunate enough to have a benevolent monarch in charge. For too many enterprises, the monarchs are simply clueless and worrying about keeping their golden parachutes packed — not about SOA."

How do you build a SOA in an environment where management has no idea of its value?  What do you do when you are at 'ground zero' in a company that doesn't value elegant enterprise design?

First off, let's get something straight: there are two uses of SOA.

Use #1: Application Design.  I can use SOA to elegantly seperate my workflow from my activity and entity services when partitioning my application.  This is good.  This is an example of starting small, as Joe advocates.  If you can demonstrate, after you develop a SOA app, that it is easier to integrate with, you may get some good attention from management for doing more.  From the app perspective, SOA is extra goodness.  It doesn't deliver better functionality, just the ability to integrate better later.  It's actually a bit of a tough sell sometimes.

Use #2: Enterprise Agility.  If I build enterprise services, then I can compose altogether new applications from existing services.  This provides real speed and value to IT, and delivers on the promise of SOA.  Here, SOA is not just "added goodness."  When providing enterprise agility, SOA is the clear winner.  It is in support of this goal that SAP has added services to their huge ERP system, and Seibel provides services to their dominant CRM system. 

Everyone wants the Enterprise Agility.  So, how to get it?

• Bottom up advocates suggest that, in organizations where management doesn't understand or doesn't care, we can simply tell the dev leads and architects to use SOA in all applications (Use #1) and store the services in a catalog.  After a while, the catalog grows large enough that those same architects and dev leads can start using those services to achieve enterprise agility (Use #2).  It's a natural growth, like urban sprawl.
   
• Top down advocates (are there any left?) suggest that we need to describe and develop all services first, and then tell everyone to use them.  The catalog matters, but only as a directive center: you WILL use THESE services.  Kinda harsh.  Doesn't work.
   
• Middle out advocates suggest that a small group of people should get together and create a standard approach.  That approach will set standards for identifiers, formats, and protocols.  They will pick patterns and naming conventions that allow flexibility later without sacrificing the ability to deliver now.  They will name the services they need (without designing them).  They will share this information with architects and dev leads, and offer reviews and test harnesses to insure that services, once developed, will be enterprise ready.  They then step back and follow the bottom-up path, allowing applications to develop the services according to those standards.  Gabriel Morgan does a good job of taking a whack at the middle out approach in his blog. 

So, how to develop SOA in an environment where you have no executive support?  First, start small.  Second, use middle out.  Top down builds documentation, but is usually cancelled before a single service is built.  Bottom up builds the wrong services, giving you a sprawling landscape of useless points of integration.  Bottom-up is like trying to make sense of a Pentacostal congregation when they are "speaking in tongues."  (There's a lot of noise, but no one is sure what anyone else is saying). 

Middle out is your best hope. 

You can do middle out in a small way.  You don't need 30 people for a year to make decisions for you, or some huge expensive project to decide what services to build.  A small virtual team can build the standards, and they can be written down in a single document of less than 30 pages, along with some sample code that developers can share.  You can even use a domain-specific language or a software factory if you want to mess with the new stuff in Visual Studio.  I'm working on standards of this kind right now, and hope to publish something by the end of the year for Microsoft IT to use.  (Yes, I will share).

The point is: middle out requires one thing: that you communicate with other architects before you build a bunch of services. 

We can do that much, even without getting the monarchs to notice.