Excellent post on David Chappell‘s blog
The best approach to creating a service-oriented environment is obvious. Start by understanding the business, probably by grasping the most important business processes and determining which applications underlie those processes. Once you’ve figured out the business services that software implements, you can wrap existing apps and create new ones to expose just the right services. This top-down, business-process-first approach is elegant, clean, and sensible. It’s obviously the right way to do it.
Unfortunately, it’s also impossible in most organizations. Taking this approach requires getting a company’s business decision makers to understand and believe in the benefits of SOA. What this really boils down to is IT saying something like this to the business people: “Give us several million dollars, we’ll build this cool SOA thing, and in three years you’ll see a significant ROI on your investment”. I’ve spoken with dozens and dozens of organizations moving to SOA, and in all but a handful, this kind of request is a non-starter. Most often, ROI-based arguments for SOA are DOA, at least when they’re made to business people.
What actually is possible in a typical organization is a bottom-up approach. The IT organization builds a service-oriented application solely because doing so makes sense for them. The architects and developers who create this app know that it will be accessed by diverse clients or other applications, and so making it service-oriented from the start will make their lives easier. The IT organization then builds another service-oriented app, and so on. Whenever required, an existing application is wrapped with services to let it participate in this new world. Creating a service-oriented organization in this fashion is inelegant, certainly, even ugly. But it’s also the only viable approach in a majority of cases, and it’s what I see people doing most of the time.
Get just a little way down this bottom-up path, though, and problems start to appear: managing the services you’re creating, securing them in a consistent way, and more. Get further down this path, and the advantages of the top-down approach will become clear. You’ll hunger for a broader view of your organization and its business processes. Given this, organizations start bottom-up, then attempt to take some kind of broader view once they’ve gotten part way down this path.
If IT organizations had more credibility with business people, the top-down option would be more feasible. Given the reality in most companies, though, the bottom-up approach, followed later by some kind of broader perspective, looks like the path that most organizations will take.
So true ….