Yes, SOA is Still Dead (or is it?)

The rumors of its death were greatly debated

There was a blog post in January 2009 proclaiming the death of SOA. It was a short, simple statement by Burton analyst Anne Thomas Manes. Despite the resurgence in some circles of a ‘new’ SOA, SOA 2.0, microservices, services fabric or extended SOA, this dirty little acronym is still dead. And by the way, whether microservices is a subset of SOA or fabric is a variant of SOA or whatever, the fact remains that none of it really matters.

I’m negative about SOA for one reason. It is the same reason I have antipathy to some other technology concepts (like “portal”). It is because of how squishy and vacuous the entire concept is. Despite the best intentions of its champions, SOA is a case study in consultants run amok. It is so vague and amorphous that years after Gartner coined it, people are still creating slide decks to define and redefine it. It can solve every problem. It is the future. It is the web. It is social. It is powerful and flexible and adaptable and…and… and you can have it all today for just one million payments of $1! That’s right! And that’s not all! If you order right now you also receive this can of integration pixie dust to confuse and befuddle your business champions!

It is, frankly, too conceptual and too open to interpretation at this point, regardless of its original meaning. Anytime a technology or concept means different things to different people, it is effectively meaningless.

Perception is King

Yes I understand there are some very clear definitions and specifications for implementation of SOA. I understand most companies have or had a SOA “project” and in some cases it has paid off. But that isn’t the point, is it? The acronym SOA is perceived to be a consultant-justification construct whose only purpose is to extend engagements indefinitely. “When is SOA done?” Ask the people paying those consulting invoices. “When do I achieve SOA?”

The reality of course is if you’re asking that question, the answer is never.

Everybody does it

But even as the acronym is meaningless and dead, the notion of representing the enterprise in terms of services and architecting solutions based on those services is alive and very critical. No one could believably argue that reuse, modularity, componentization, interoperability and standards-based compliance are out of vogue or somehow don’t have measurable benefit. I take it as accepted gospel at this point that simplicity and flexibility are critical success factors for the modern enterprise. These are SOA concepts. But more importantly, they are merely standard ways of running Enterprise IT today. So… basically everyone espouses SOA without calling it SOA.

Today’s SOA is about services not Services

It is useful to go back to some of the original concepts of SOA and give them a new coat of paint. At its root, a SOA is an enterprise IT architecture that links resources in a dynamic fashion, nothing more fancy than that. Representing these resources as conceptual buckets of technical services is how I see SOA playing today.  This is an approach that uses a services-based architecture to depict technical capabilities as services. Not web services or Services that live in a JVM somewhere. These are merely high-level, conceptual entities that are used in conjunction with the guiding principles of reuse, modularity etc., to credibly respond to the business problem at hand. Rather than talking about Services as discoverable software assets with externalized descriptions, we’re talking about services being conceptualized building blocks representing all that IT can do.

These services are real, distinguishable, immediately identifiable, easy to understand and can be traced to actual products in the inventory if need be. The business can comprehend them. The business can understand how a service called ‘automated workflow’ plays a part in solving their particular business problem. They don’t care if ‘automated workflow’ is a conceptualized entity representing all sorts of detailed techno-babble under the covers. They just know it maps cleanly and directly to their requirements. They know it enables the business capabilities sought after as part of their program. Successful problem resolution, enablement, completion (on time, on budget) and conclusion to the project are the most important elements to a business stakeholder. If the technical solution is SOA, BPM, SaaS or apple, cat, dog, spaghetti, it ultimately doesn’t matter provided their concerns are addressed. Why confuse them with a term like SOA that they’ve come to regard as meaningless jargon? You lose credibility, believability and the solution becomes suspect to those predisposed to dislike consultantese.

Pretend it never existed

Ditch the acronym SOA.  Start using the language of services that link enterprise resources, of IT building blocks that can be used to construct a solution that solves a business problem. Let Forrester and Gartner hash out whether SOA is alive or dead or morphed or evolved or reborn. Representing technical capabilities as services that people can understand will breach the business-IT language barrier. You’ll communicate more effectively, look smarter, gain credibility at the expense of jargon-bound consultants and gain the trust of the business.

You don’t have to give up SOA’s principles or benefits. You need to market them in a more digestible fashion.