A recent blog post by Anne Thomas Manes on the alleged “Death of SOA” has been causing quite a stir. (In fact, my colleague at Cutter, Doug Barry, wrote (The Acronym) SOA is (Perhaps) Dead (at Some Companies) in reaction.) The contention is that the bad economic situation has finally finished the “SOAsaurus” off and that we must now concentrate on services, along with mashups, cloud computing, and software as a service (SaaS) — and not service-oriented architecture (SOA).

Knowing full well that SOA is alive — if not always exactly flourishing — in many organizations, my first reaction was that here were some sexy sound bytes designed merely as a marketing ploy.

At the same time, I had to admit the piece did strike a chord somewhere. In particular, I was reminded of a piece written nearly 20 years ago by Cutter Fellow Ed Yourdon — “Sayonara Structured Stuff? Long Live Object Stuff!” (in Byte, October 1990) — on the alleged demise of structured techniques in the face of object orientation (OO). Subsequently, in my early days at Select Software Tools, my boss had urged me that objects were dead, components were now the thing. Component-based development (CBD) took over from OO. Later on, on turning into the new millennium, components were suddenly passé — SOA was the new focus!

Despite the rebranding, of course, the underlying principles and practices of software methodologies have progressed in a process of natural evolution. We always agreed that modular software designed to be as technology-neutral as possible was a good thing. It was just that the software “capsules” — modules, then objects, then components, then services — grew closer to the business with each progressive wave of methodology. So, maybe our methodologies just need a makeover?

Well, yes and no — if you’re going to rebrand then you better have a good new brand name. Apparently, “services” are now the thing, not SOA. However, you need good techniques to identify services, especially those that are to support business needs, and you need good patterns and structures if you’re going to come up with agile services. To do that, you need architecture, so we’ve come full circle back to SOA!

Fact is, the search for a new brand is ultimately misplaced, at least at this time. The much bigger point is that the realities of the economic gloom spell the final death knell for big enterprise-wide SOA efforts — something that had always struck me as a luxury even in the best of times. As I have pointed out elsewhere, there is a need for much better approaches to solution-driven SOA. The ship’s engine has to be strong enough to move it but not so heavy as to sink it!

While “death of SOA”-type messages have their place in that they help to provoke good debate, taken too seriously, they can do more harm than good. This is no more the case when sound bytes bubble up from the Internet on to the boardroom table, especially in today’s challenging economic climate, which is forcing many organizations into cutting costs. Business leaders who get the wrong end of the stick might see an easy option in: “If SOA is dead then let’s cut SOA projects, along with the jobs of those that staff them.”

The irony here is that SOA can actually help, and not hinder, the organization’s requirement to get leaner and meaner if positioned in economic terms that business executives will understand. As I have described elsewhere, core services should be clearly distinguished from context ones. Good SOA design and specification helps isolate out context services for outsourcing using clearly defined contracts. In other words, to focus the organization’s investment where it has the greatest benefit:

  • Avoid SOA as religion — steer clear of enterprise-wide, heavyweight, and technocratic approaches.
  • Be pragmatic and hook into specific business projects with clear goals. It doesn’t matter if these goals are not the ideal long-term ones, such as increased agility. Be prepared to take a zigzag path!
  • Recognize that, contrary to the “death of SOA” message, concentrating solely on services — along with such technologies as mashups, cloud computing and SaaS — without paying sufficient attention to the business drivers and SOA practices, is doomed to land your organization with a “service spaghetti” nightmare.
  • Understand that overhyping the promised benefits of SOA as a technology has actually caused the term “SOA” to be banned in some quarters, as at a large insurer I worked with. Although SOA was instrumental in the success of its “business agility” program, because of overegging of previous business cases with inflated SOA promises, the term “SOA” was outlawed.
  • Like me, be prepared to shed your anorak in your quest for SOA nirvana — listen to what business managers have to say and avoid technospeak with your users!

[Update: I've been asked about the "elsewheres". Re: approaches to solution-driven SOA, see Cutter's Enterprise Architecture Executive Update, Solution-Driven SOA, Vol. 11, No. 18; re: core services, see my book, Service Orientation: Winning Strategies and Best Practices, Cambridge University Press, 2006]

avatar

Paul Allen

Paul Allen is a Senior Consultant in Cutter Consortium's Business & Enterprise Architecture practice. With more than 34 years' experience in most areas of IT, he has earned international recognition for his pioneering work in the application of component-based development (CBD) and service-oriented architecture (SOA) to achieve practical business value.

Discussion

  One Response to “The King (SOA) Is Dead; Long Live the King”

  1. avatar

    Paul:

    I agree that the problem is with acronyms. We did the same with TQM-BPR-KM- and finally ended up with ‘wisdom’, if anyone could figure out what what that meant. Today, enterprise architecture does much the same in terms of models and views that BPR did, but instead we call it BPM to avoid the bad rap.

    SOA as a technique will continue into the future because people increasingly use services rather than develop their own applications that require maintenance. Who cares what the acronym is, we care about services, and how they relate to the rest of the enterprise.

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>