au⋅top⋅sy [aw-top-see] noun
- inspection and dissection of a body after death, as for determination of the cause of death; postmortem examination.
- an analysis of something after it has been done or made.
Source: Dictionary.com Unabridged (v1.1)
On Monday, January 5, 2009, Anne Thomas Manes, a well respected analyst at the Burton Group, wrote a post on her blog pronouncing SOA to be DOA. My colleague, Hanu Kommalapati, brought the post to my attention and I was getting ready to dig in my heals and put up a fight. Once I read Anne’s post, I found that not only was a fight unnecessary, but that I agreed with most of her points.
Seeing that SOA has been one of the most visible and widely talked about technology initiatives of the past decade, the fact that it has been pronounced “dead” would seem to require an autopsy to determine the cause of death and discover any foul play that might have been involved in its untimely demise.
Positive Identification
Before we begin, we need to make sure we know the identity of the corpse. For the context of this discussion, we’re talking about “SOA,” not “service-oriented architecture.” “Aren’t those the same thing?” you might ask. Again, for our purposes here, I’m going to make the following differentiation.
Service-oriented architecture is a technical philosophy combined with a practical approach to building distributed, loosely-coupled systems, focused on business capabilities that embody (no pun intended) the following four tenets:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Service compatibility is based on policy
In other words, service-oriented architecture represents the best practices for building services and the systems that consume them. Fortunately, service-oriented architecture is alive, well and thriving in new ways thanks to cloud computing and software + services, but more on that later.
SOA is the ubiquitous panacea presented and re-presented over the course of the last ten or so years, a business cure-all that has generated a lot of hype and attention, but few tangible, measureable results. At some point in the middle part of this decade, SOA extended far beyond simply building a solid service-oriented infrastructure. It began to involve things like governance councils, enterprise service busses (ESBs) and a myriad other things. It was a simple, eloquent concept made huge and untenable.
“SOA” is the body on the table, so let’s begin.
Cause of Death #1: Morbid Obesity
It’s not only becoming the primary cause of death for people in the United States, but it’s also the number one reason SOA projects in the enterprise fail. Over the years, the term SOA has gained a reputation as being a kind of magical elixir, capable of curing bleeding budgets and making IT organizations young and virile again. It has been pitched by good intentioned people to be the ultimate solution for solving system integration challenges and as a holy grail of enterprise reuse. Additionally, many of the top industry analysts and journalist were saying very much the same kinds of things. These factors created a lot of top-down interest in SOA within large corporations, which means that there was a lot of money being put behind trying to implement SOA.
How do I know this? Well, I was one such “good intentioned” person.
A few years back, prior to my joining Microsoft, a group of fellow architects and I set out with the intention of trying to make things better for the IT organization in our company. We started out with a simple, self-imposed charter:
- Create a set of best practices for designing and developing services for software project teams
- Develop a means of making deployed services visible to project teams
- Evangelize service-oriented architecture to project teams, creating a common understanding of the principles and a specific context for our business
A simple, tactical approach, nes pas?
After awhile, management got wind of what we were working on and wanted to officially mandate the effort to ensure we were putting something together that would truly serve the entire organization. Once that happened, we found it impossible to keep our effort lean, tight and focused. The small group of five people that started the effort soon “blossomed” to eighteen people, with extended optional members, most in upper management, that would chime in when they felt it necessary.
Suddenly, we were trying to solve huge strategic problems with SOA. We were tasked with standardizing processes across several departments and business units. We were talking to dozens of people about services that would standardize key business capabilities in their part of the company. We were developing taxonomies, dictionaries and registries to manage an eventual service environment. We were talking about governance standards and protocols and trying to answer questions like, “How do you get services approved for enterprise use?” and “How do you submit your service for deployment into the enterprise infrastructure?” and “What is your SLA for the service and who owns it?” and “If that group owns the service, who owns the SLA for the underlying data?” And while we were doing all of this, we were not doing one very important thing: Designing and developing services.
Fifteen thousand empty calories a day, and suddenly our initiative was obese and hypertensive.
While this specific situation comes from my personal experience, I by no means think it’s unique. I’ve seen and heard this same story time and time again. Activities that would be absolutely ludicrous in a typical software development project become commonplace as soon as we start talking about SOA. The result is good intentioned people get mired down in politics and alternative agendas until the effort as a whole finally collapses under its own gargantuan weight.
Cause of Death #2: Cultural Shift Syndrome
The SOA effort of which I was a part was similar to other failed efforts for another key reason: The focus tends to be on the technology, not on the people and culture of an organization.
In general, services are not complex or difficult to build, deploy and manage. However, implementing SOA in the enterprise requires a different way of thinking about enterprise software development. Developers, architects and project managers have to begin thinking about the development process in a more holistic way. They need to include existing services in their system design while looking inward to determine if there are new services their project can produce to benefit the organization.
In general, this is fundamentally different from how just about every enterprise IT shop in the world operates, where projects are funded by customers, either internal or external, and project managers work a project to that level of funding. Being responsible for using that customer’s money responsibly causes project managers to focus on the requirements of their project exclusively and incents them to minimize risk at all costs. Relying on services outside the team’s control introduces risk and could, therefore, be discouraged or even banned by project managers. This, in turn, encourages the creation of multiple siloed applications sprinkled throughout the company. Ultimately, this might work very well for individual customers, but makes a cohesive and cost efficient enterprise architecture impossible.
The bottom line is that technology is pretty simple to change, but changing people is extremely hard, especially when the funding model of an organization provides incentives against sharing and collaboration. Trying to approach the classic view of SOA in the enterprise presents the non-trivial challenge of trying to modify an organization’s culture and long-held opinions and policies about how it does it’s day-to-day business. If this fundamental change is a requirement for SOA success, then most initiatives would be over before they began.
Cause of Death #3: Bad Medicine
I remember once sitting in a conference room with my SOA team listening to a major software vendor (whose name I will not mention because I have shame, even though they didn’t) explain that they were there in the hopes of “selling us SOA.” After I finished my fit of laughing and asked for clarification, they stated that, by buying their suite of SOA software, we would have everything we needed to implement an SOA. This wasn’t unique to that vendor either. Many big name companies were actively engaging customers purporting that implementing a SOA was a matter of buying software licenses and/or hardware from them.
This, of course, is ridiculous, but was demonstrative of how crazy things had gotten in the SOA world. Certainly, third party software had a role to play in helping an organization build and manage a service-oriented infrastructure, but the idea that it was all that was needed was disingenuous at best, fraudulent at worst. The truly unfortunate part of this was that many companies looking to streamline their path to SOA goodness purchased these products and services only to find that, in the end, they still had most of the same problems they had at the outset, now they just had better visibility and reporting for them.
The end result was that companies often spent millions and took months (or even years) to evaluate, purchase and implement these SOA solutions. In today’s economic climate, it’s little wonder that many of these companies are drastically reducing their SOA initiatives or simply throwing them out, chalking it up to experience and moving on to other, more pressing things.
SOA: Dead, or In a Coma?
So, now that we have identified the leading causes of SOA’s demise, we need to ask the question, “Is SOA really dead or simply in a coma due to blunt force trauma to the head?”
Honestly, I have concerns about making the proclamation, “SOA is dead,” because what it stood for at its inception was not only good, but still very relevant today. Seeking to build a loosely-coupled enterprise service layer deriving from key business capabilities as part of a larger IT infrastructure is a good idea and at the heart of what SOA once stood for. By pronouncing SOA dead, I do not want to give people the impression that this vision and perhaps even services themselves are dead as well. The service-oriented approach to software development is not only still alive, but gaining momentum and expanding in the form of cloud computing.
Services are also vital to perhaps one of the most important trends we’ve seen in technology in quite awhile: Software + Services. Again, one of the major misperceptions about SOA was that services in and of themselves would solve all of IT’s problems. The S+S approach to architecture provides a model that uses services to augment client applications running on potentially multiple platforms and using a plethora of technologies. This model has the potential to provide huge benefits to companies, leveraging a services layer to provide commonality of key business capabilities while fully utilizing the power and versatility to deliver those capabilities on clients throughout the enterprise.
Instead of pulling the sheet over SOA’s head and sending it to the morgue, I propose that we look at SOA like it has been in a deep coma, at the mercy of forces operating all around it, and recently woke up with amnesia and is starting anew, getting back to basics. As SOA leaves the hospital and starts to reintegrate with society, it should stay focused on its core principles:
- Stay Tactical: It’s far too easy to start out trying to make a bowl of soup and end up attempting to boil the ocean. Focus on activities that deliver real solutions to development teams. The time to take a larger, more strategic view will be obvious when it arrives.
- It’s About the Services, Stupid: Related to the first item, keep your focus on designing, building an deploying good services in your environment. As an organization, seek to find a way to catalog and expose the availability of different services to reduce functional redundancy and increase reuse and consistency.
- Focus on Architecture: Building reliable and extensible system architectures is hard, and no silver bullet exists from any software vendor that will supplant the need to think hard about the services in your environment and the role they should an can play to software development in your enterprise. Always remember that good architecture is platform independent.
- Evangelize…Gently: You will never have 100% success in getting people to think in terms of services. Become an advocate and help people understand the benefits of service-orientation without setting mandates or imposing policy. Success with tactical level services over time will eventually lead to policies that make sense and everyone can live with.
Ms. Mannes summarizes these suggestions nicely in her post:
But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services.
So I say: “The old SOA is dead; long live the new SOA!”
Subscribe