Getting the concept

If you don't "get it," you're not going to get there. If you think that using WS-* standards, licensing an ESB (enterprise service bus), and deploying service registry means you've arrived, think again. All of the above may be desirable, depending on what you're trying to do. But by themselves those piece parts won’t reap the savings or agility that SOA promises.

“Maybe 20 percent of IT folks understand SOA and half of the rest think they do,” says Roberto Medrano, executive vice president of SOA Software.

If you’re really going down the SOA path, your initial focus is on the basic map of business processes your company uses — and how those processes break down into business functions, both human and technological. Ultimately, SOA represents the IT view of business processes, while business process optimization and management become the business units’ view. Both center on a business-driven enterprise architecture.

It's easy to miss what SOA is really about. For example, SOA is not integration, although it’s easy to see why people think so. XML, the one standard most closely associated with SOA, was originally designed to foster open, message-based alternatives to proprietary integration. But integrating applications is incidental to creating services that map to business functions -- the underlying principle of SOA. Integration is a bridge; SOA is a whole new landscape.

Likewise, you may have heard that SOA is all about code reuse, but that's not true, either. "Reuse" is a programming term that refers to copying existing code and using it again it in different apps. SOA is about shared use. When multiple applications share the same service at runtime, that service provides a single point of control. Shared services are disruptive, increasing dependencies and raising questions about what it means to own a service and who should own it.

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. Efforts to follow specific “patterns” or “styles” of SOA run the risk of locking you into one vendor’s technology and may ultimately impede agility.

Back to intro | Next: Selling the dream