How to build SOA when executives don't care

When it comes to moving SOA forward when all of the top brass hasn't signed off on the concept (or is just totally oblivious to it), a "middle-out" approach may work best.

Of course, we all work in organizations with savvy, totally forward-thinking top managers, don't we? But for those few billion organizations out there that don't have such enlightened management, SOA may have to grow more organically, proving itself on a case-by-case basis.

Over the past few weeks, Nick Malik and I have been discussing the pros and cons of bottom-up SOA, starting small, and top-down approaches, and we both agree that starting small (not to be confused with bottom-up) is the best way to go, because the number of organizations with C-level executives ready and willing to promote SOA-style transformation are few and far between.

Nick recently provided some additional insights on how SOA should start, describing the path of least resistance to business agility: "How to develop SOA in an environment where you have no executive support?" he asks. "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."

Nick looks at the differences between bottom-up, top-down, and middle-out approaches to SOA:

"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," Nick writes. "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."

(And, as I opined in previous posts, this does not an SOA make...)

"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," Nick continues. "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."

Nick observes that middle-out is highly consistent with Start-Small SOA: "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."

One thing is important with middle-out, Nick adds. "that you communicate with other architects before you build a bunch of services."