Technology Won't Clear SOA Bottlenecks; Here's What Will

SOA in Action Blog

« Five Rules for Design-time Governance | Main | Tough Questions for a Tough SOA Machine »

May 14, 2007

Technology Won't Clear SOA Bottlenecks; Here's What Will

InfoWorld is preparing for this week's SOA Executive Forum in New York, and I and other members of the ebizQ community had the opportunity to help prepare of collateral material around the event, including a series of podcasts and articles with conference speakers. We'll provide links when ready.

InfoWorld's Galen Gruman has also just published this overview of what it takes to break SOA bottlenecks within enterprises.

As Galen observes, "tools and applications, even those totally relevant to SOA, get you only so far. Any enterprise embarking on an SOA journey needs to know where it’s going and how to make the right preparations. Fortunately, SOA has been around long enough for some top-level best practices to emerge. And frameworks and maturity models from vendors and consultancies are beginning to crystallize. So are the barriers and bottlenecks that thwart SOA efforts. Some are technical, but most are managerial — tough issues that will put IT in new, often uncomfortable roles that may test all participants’ faith in whether IT and business are truly aligned."

Here are some of the major bottlenecks Galen has identified:

Getting the concept: "If you think that using WS-* standards, licensing an ESB and deploying service registry means you've arrived, think again.... It's easy to miss what SOA is really about.... SOA is an architectural concept not necessarily tied to any specific set of technologies. Think of it as a many-to-many topology: many services and many applications — and that’s pretty much it."

Selling the dream: "The key to getting a buy-in is to explain SOA not as a technology, but as a way of operating the business more effectively by being process-oriented."

Hammering out the architecture: "An effort of several months involving business managers and enterprise architects can create the basic blueprint a company needs to begin guiding its SOA effort; you fill in the details as you work on specific deployments.... Businesses can’t improve unless they understand what they are doing and what they want to do. That requires understanding the business processes, which companies often don’t do, instead acting on instinct or autopilot."

Scoping out services: "There are several dangers in mapping processes to services: defining them just for the current project’s needs, defining them at the wrong level of granularity, and building services that aren’t needed. Developers have to anticipate how the service — whether created from scratch or derived from a legacy application — might be used in other processes, so the service can be employed in both current and future projects."

Timing the technology choice: Too many companies buy SOA technology tools before planning out their SOA. "it’s a mistake to buy SOA infrastructure, governance, or development tools until you have your enterprise architecture in place, along with the operational architecture -- that is, the design for how you will actually run your services."

Addressing the data problem: "SOA requires an underlying data architecture, so no matter where the data originates, the metadata describing it is consistent enough to be understood the same way by all services using it... That's one big cleanup job."

Governance, governance, governance: "Although specifics vary from company to company, it’s becoming clear that there needs to be a central entity to establish and maintain policies for building and using services, including monitoring compliance and resolving disputes. This can be a center of excellence, an architectural review board, a competency center, or a program office."

Changing developer culture: "The last thing developers want are SOA "governance cops" telling them what they can and can't do. To change the individualist developer culture, create the right incentives."

Avoiding vendor lock-in: "With the sprawling nature of SOA, and the immaturity of some SOA-related standards, vendors want to reel you into their proprietary world."

Putting services to the test: "Dependencies among services increase the complexity of testing, especially when you can't possibly predict all the future applications that may consume a service."

Posted by joemckendrick in SOA | Digg This | Add to del.icio.us