SOA: What's It For?

The Gartner "hype cycle" holds that new technologies go through a period of inflated expectations, disillusionment, and eventual productive usage. But with SOA, it seems the hype just won’t quit.

For me, the final straw came when attending two vendor presentations on application performance, where the logo for their new marketing campaign, emblazoned in the corner of each slide, proclaimed “Smart SOA.” The mind reels. What do JVM tuning and distributed caching have to do with service-oriented architecture?

Naught that I can see. SOA has simply become the miracle food additive of the IT industry. Vendors are straining to enhance the length and breadth of their product lines with “SOA enablers”, the same way food producers are jacking “heart-healthy” fish-oil extracts into everything from lunchmeat to orange juice, promising a revolution in IT health.

Reading the trade pubs, you must admit that ESBs are vital to ramping up your SOA. And governance? Can’t do without it. Help you manage the new services development lifecycle? You’re covered. Rules engines? Ready to fit your SOA. Metadata management? Check. Complex event processing? Check. And mashups? Hold on... those are now “enterprise” mashups, SOA’s killer app.

Do all these technologies actually enable service-oriented architectures? Let me allow Burton Group SOA maven Anne Thomas Manes to answer that:

It has become clear to me that SOA is not working in most organizations. … I've talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings. They've deployed the best technology the industry has to offer -- including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out. The techies just can't sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value.

For IT initiatives to make this level of investment and still not pan out shows an unsettling disregard for old-fashioned principles like clearly defined problems and rigorously worded requirements. In the case of SOA, we are hobbled from the start with a poor problem statement. Most are variations on the same theme. The one from Wikipedia, culled from several sources, will stand in as well as any:

Service-oriented architecture (SOA) is a method for systems development and integration where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications.

While technically accurate, the wording does little to help either technologists or business users understand when SOA should be used, what benefits it brings, and how its adoption impacts an organization.

To its credit, the article (and most resources on the subject) go on to say that SOA “unifies business processes by structuring large applications as an ad hoc collection of smaller modules called services” and “new applications built from a mix of services from the global pool exhibit greater flexibility and uniformity”, et cetera. But judging from the experiences reported by Burton Group, these gains are not clearly understood, nor does use of supporting technologies guarantee them.

Improving the definition

I find it helpful to explain SOA, not as a standalone, abstruse technical concept as above, but as a small delta from knowledge that is familiar to both businesspeople and technologists. If SOA is new, if it is a step forwards from the way most development shops work, then what is that way called, where are we now? It’s product-oriented architecture, or POA, and the evolution from one to the other is straightforward.

A bit of history: Prior to the client / server era, if you were to take a 50,000-foot view of application architecture, it would not look especially interesting. There was only one tier, the mainframe, and everything lived there:


With the desktop computing explosion in the 1980s, it became de rigueur to move the UI and a good chunk of business logic to a box that cost less, was easier to program and administer, and could provide users with richer interaction:


Came the Web in the 1990s, and abruptly all that capability on the client became a competitive liability. The web allowed companies to transact business via any desktop, anywhere, not just those that could accept a custom install. So the client tier split again, with the bulk of product software moving back to a new server tier for the web.


(Here I’ve renamed the original Server tier as the “Data” tier – this is a stand-in for databases, mainframes, any repository of customer information.)

This is the current state of most product-oriented architectures. There are other intermediaries like firewalls, routers and middleware, but by and large, this is where the assets of a business product reside.

It ought to be far enough. Managing applications is difficult enough without splitting them into progressively more pieces. But in large enterprises and organizations serving diverse markets, it isn’t enough.

Two things happen: one, multiple products are built atop the same data to serve different customers and channels, often on different platforms:


Two, as the organization grows, responsibility is partitioned, and new data providers arise, a product must draw from many data sources:


Often both occur simultaneously. Over time, duplication of work appears: the same data integration, reconciliation, and business logic is being written for multiple channels. This is especially hazardous when independent applications have direct dependencies on multiple databases; as Neal Ford noted, what you essentially have is one large application with UI partitioned across product groups, all of which much regression test when the database changes.

A service tier helps with both situations. It hosts platform-independent access to common business logic on behalf of many channel products, and provides a measure of insulation to applications that do not require direct data access.


I’ve settled on the terms Client, Channel, Service and Data, but they go by many names. Herzum and Sims use User, Workspace, Enterprise and Resource. A Forrester brief on N-tier uses Interface, Interaction / Service Composition, Business Logic, Data. Various J2EE references call them Client, Web, EJB and EIS (hmm, no conflict of interest there.) I’ve heard Client, Presentation, Logic, Database; Client, Web, Service, Database; still more.

In each viewpoint the role of the new tier is roughly the same, and the evolutionary view suggests a much simpler, more business-oriented definition of SOA:

Service-oriented architecture is the separation of business processes from business products in order to enable more rapid and cost-effective reuse.

SOA is not some dramatic departure from established practice; it is a natural, emergent property of distributed applications. It says you can get more value for your development dollar by investing in a common base of capabilities accessible from multiple products and platforms.

Pitfalls in practice

While the conceptual evolution from POA to SOA is straightforward, the organizational evolution is not – and this is why SOA so often falls down. Here are some common obstacles faced in SOA adoption:

• In counterpoint to the tired mantra, “IT must be aligned with the business”, services are not aligned with the business, that is, not with business unit product groups. They are aligned with business processes that potentially cross business units.

• Requirements, funding / ROI models and executive sponsorship are historically project-oriented, and this model is what your oldest, most senior business and IT managers understand. The end result of a product development effort is something users can see and touch. Services are seen as infrastructure because their primary audience is application developers – and infrastructure is always under relentless cost pressure.

• Development is divided between teams that provide common assets to product owners, and teams that actually build products. This demands that product developers cede a significant degree of control to service owners, leading to turf wars. SOA champions must be prepared to deal with these cultural issues.

• Without adequate governance, it is easy to build services that only address the needs of individual channel products or data providers. This gives rise to JaBoWS (Just a Bunch of Web Services), where SOAP or some other protocol is used simply as wire format, with no attention paid to service modeling, interface design, and limiting redundancy.

When you need it

Deciding where you need SOA is not rocket science. The core requirement is to provide business process functionality to a diverse set of consumers, both end users and other applications. If that isn’t the case, SOA should be viewed skeptically; adding more moving parts will raise development and maintenance costs and may not offer meaningful return on investment.

It’s also not hard to tell the difference between adopting SOA and just using SOAP (and ESBs, and repositories, and rules engines, et cetera.) With SOA, your development is split across channel product initiatives and supporting service teams, with the latter taking a healthy portion of project funding and engineering talent. There are governance structures in place to drive consolidation onto common services. Executive sponsorship is rock-solid, and finance is on board with cost and ROI models for service projects that demonstrate clear long-term value to the business.

(Disclaimer: The above opinions are mine alone and do not necessarily represent the views of current or former employers.)