Another view: avoid bottom-up SOA like the plague

Just the other week, I posted the case for Start-Small SOA, which not only helps enterprise service developers and consumers learn as they go, but also deliver a growing series of incremental wins that will help build a constituency of support.

However, not everyone buys into the "start-small SOA" case, especially if it involves individual efforts without an enterprise focus. Nick Malik, for one, has come out against "bottom-up" SOA approaches, saying they are "actively harmful to the enterprise as a whole and should be discouraged at all costs." (Thanks to SOA Digest for the pointer to this story.)

Nick says that the top-down, centralized approach may be slow and somewhat bureaucratic, but it ultimately works out a lot better that taking a bottom-up approach:

"Bottom up is an answer to top down seen as 'the wisdom of crowds' or 'economics in IT,'" he observes. "The idea being that many services can be developed without much central control, as long as they are in a directory. Everyone would look in the directory to find the services they need and adopt the best or least expensive, and we'd get SOA adoption. This one has the advantage of scale. The larger the organization, the argument goes, the better the case for bottom up."

Nick acknowledges that he's going against the grain, observing that "a lot of the literature in the SOA field says 'build the catalog first,' effectively supporting the bottom-up approach. And that is a mistake."

Why is bottom-up a mistake? "Bottom up is a mess," Nick says. The most common goals of SOA include the ability to share a common concept of customer, order, sale, shipment, and inventory; loosely couple applications to decrease maintenance costs; and build applications that can be quickly and easily integrated.

However, bottom-up approaches either will be ignored because no one participates, or at the other extreme, wildly adopted by contributors or adopters. A third outcome will be to have adoption driven by departments with their own agendas.

In the case where there is widespread adoption, those services that are contributed will likely be designed for one specific user and purpose, and not adaptable to the enterprise. As a result, many of the services in the catalog will not enterprise ready. Rather, they "will be 'local-specific,'" Nick points out. "That means that the service will serve the needs of the paying customer (a business leader) but not the enterprise as a whole."

As a result of enabling bottom-up SOA, you may end up with an SOA "based on Division A's CRM system. You have another that feeds Division B's ERP system. You have a third in Division C to surround their mainframe operations management system, and a fourth in Division D focused on their home-grown Web-order management infrastructure."

"'Bottom up' is simply a mechanism to allow those strong-willed leaders to create multiple infrastructures in the company 'because they want to' without any consideration for creating a common and stable foundation for the business," Nick says.

A couple of thoughts here. While I feel that individual initiatives should be encouraged or incubated, a series of detached bottom-up SOA efforts across the enterprise will not an "SOA" make. What's confusing the issue is that such efforts are even called "SOA" at all -- let's call them for what they are; an Agglomeration of Services (AOS).

That's why governance is so key even early on in the process. It's actually never too soon to start putting governance in place, even if you only have just a few services in production.

A bottom-up approach -- which I see as the best way to spur SOA innovation and participation -- will work if there's an effective enterprise governance process in place to ensure that efforts don't go astray. Plus, many are in hidebound organizations that wouldn't understand how to leverage the value in SOA -- and therefore have no choice but to start small or "bottom-up."

Miko Matsumura (webMethods) drew up a good working definition of governance: "the creation, communication, enforcement, maintenance and adaptation of policies across the SOA lifecycle of design time, runtime and change time."

Burton Group's Anne Thomas Manes made the case for SOA governance so well a couple of months back: Without governance, there is no SOA. Period.

Unlike previous IT initiatives, SOA has a lot of compounding factors, Manes points out. "Number one, it’s unfamiliar territory. Designing services for SOA is different from the way people have been building things in the past. In the past, people built applications to solve a business problem. But they weren't really thinking about what capability is going to be used by another line of business. How do you design a service so that it can actually be reused?"

The design of unreusable services for single purposes is Nick's concern as well. How does an organization go about assuring that services are created for reuse across the enterprise? Governance is the key. "Without that governance, your SOA is going to spiral into chaos," Anne said. "Those systems that you’re building are going to end up as brittle as inflexible as ever before. That would be a shame, because you’re spending a lot of money of this stuff, and you’re going to wind up with the same old, same old."

In SOA, Miko says the best approach is to "think globally and act locally. You have to know where you’re going before you begin your journey."

Over the course of the SOA journey, of course, culture and politics will derail many SOA projects. "In order to be successful with SOA, you have to treat cultural and political issues associated with SOA," Anne says. "To make that happen you have to put together a decent governance program that addresses the entire service lifecycle." In addition, she adds, "governance should be as helpful and as automatic as possible. If it is a hurdle, if people have to do stuff they’ve never had to do before, it typically produces a bunch of resentment -- and people will figure out ways to avoid it."

And lead back to bottom-up activities.