ZapThink </>
_ZapFlash: In this Issue Jan 15, 2009_
The Rumours of SOA's Demise...
Document ID: ZAPFLASH-2009115 | Document Type: ZapFlash
/By: Jason Bloomberg/
Posted: Jan. 15, 2009
OK, everyone, calm down. SOA isn't dead, in fact, it isn't even sick.
Thousands of organizations are showing real success with SOA around the
world, and more are ramping up their SOA efforts every day. Even in
today's economy, plenty of smart organizations realize the cost savings
and agility benefits of SOA warrant continued investment in the
approach, even in times of tightening belts.
So, why the consternation? Well, if you haven't been paying attention to
the SOA blogosphere for the last few weeks, you missed the firestorm
that Anne Thomas Manes from the Burton Group caused with her "SOA is
Dead"
<http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html>
blog post. In the intervening time, virtually every SOA pundit has
pitched in on this topic. However, due to the biweekly nature of our
ZapFlash newsletter, ZapThink is in the enviable position of batting
cleanup on this issue.
What amazes us most of all about the "SOA is dead" controversy is that
there's nothing new here. In fact, the core themes of both Manes's
comments and the reactions to those comments have been themes in
ZapThink's writings for several years now. So, in an effort to move past
the noise and provide a post mortem of sorts -- not on SOA itself, but
rather on the "SOA as dead" meme -- let's review the relevant ZapThink
insight on this topic:
* Calling a project SOA isn't as important as solving real business
problems. (Avoiding Bad SOA
<http://www.zapthink.com/report.html?id=ZAPFLASH-200531>, March 1,
2005). In fact, the term "SOA" often gets in the way. Instead,
both business and technical people should work to communicate
using a common language of Service Orientation that's neither
entirely business-centric or technically oriented (The Third
Conversation
<http://www.zapthink.com/report.html?id=ZAPFLASH-2007416>, April
16, 2007).
* SOA is part of a larger trend toward location independent, loosely
coupled computing -- a trend that includes Cloud Computing (The
Buckaroo Banzai Effect Location Independence, Service-Oriented
Architecture, and the Cloud
<http://www.zapthink.com/report.html?id=ZAPFLASH-2008625>, June
25, 2008, and Goodbye 2008... Here we Come, 2009!
<http://www.zapthink.com/report.html?id=ZAPFLASH-20081229>,
December 29, 2008).
* SOA is a loose collection of best practices, and as organizations
more broadly adopt these best practices as SOA becomes mainstream,
then people will talk about SOA less (Thinking Outside the SOA Box
<http://zapthink.com/report.html?id=ZAPFLASH-20061115>, November
15, 2006). In fact, we're seeing this trend now.
* SOA has a clear, specific definition, (Forensic SOA
<http://zapthink.com/report.html?id=ZAPFLASH-2008428>, April 29,
2008) even though there's still confusion on this point, in large
part because vendors are sowing misinformation (Avoid
Vendor-Driven Architecture (VDA)!
<http://zapthink.com/report.html?id=ZAPFLASH-2007920>, September
20, 2007.)
* SOA is especially important now that we're in a downturn, as long
as you're able to realize the cost savings and agility benefits
short-term (Investing in SOA in a Down Economy
<http://www.zapthink.com/report.html?id=ZAPFLASH-2008109>, January
8, 2008). While tightening budgets will lead to the cancellation
of some SOA projects, numerous organizations are succeeding with
SOA, and as a result, realize the importance of continuing their
SOA investment.
* Certain industry analysts are lowering the chance of success for
SOA initiatives, especially the ones who would rather define
markets and rank vendors than uncover and communicate best
practices (Who's Killing SOA?
<http://zapthink.com/report.html?id=ZAPFLASH-20071001>, October 1,
2007).
The most important thread that winds its way around all of these
principles is the perspective that SOA consists of /best practices/. The
problem is, best practices are slippery things, for a few reasons.
First, they describe human behavior -- the proverbial SOA as something
you do, not something you buy. Second, among all the various practices
an organization might undertake, only a relatively small subset are the
best ones, and which ones are best changes over time as people figure
out new ones.
*The Challenge of Best Practices*
There is no hard and fast rule as to which best practices are SOA, and
which are not, because best practices are problem-dependent, not
terminology-dependent. In other words, which business problems you're
trying to solve will in large part determine which practices are best
for that particular situation, a classic example of the right tool for
the job. SOA best practices don't solve all problems, and for any given
problem that SOA might be appropriate for, there's a good chance that
some of the best practices that the situation calls far aren't
specifically SOA best practices.
One way of looking at this problem is that there are best practices for
how to apply best practices. Just because your SOA textbook says you
should do something doesn't mean that you should do that thing in every
situation. On the contrary, what distinguishes a good architect is the
knowledge of when /not/ to apply a particular practice, even if that
practice might be a best practice in a different situation. When we list
SOA best practices -- leveraging the intermediary pattern to build
loosely-coupled Services, governance best practices like those for
Service versioning or reuse, etc., we're not expecting everyone to apply
all of them in every situation.
In fact, the belief that to do SOA right you have to do some fixed set
of things every time is a fallacy. Belief in this fallacy,
unfortunately, is still quite prevalent, and turns SOA into a straw man.
Virtually all failed projects with the name "SOA" failed because the
organization didn't properly apply best practices. In other words, they
weren't really doing SOA at all, because SOA consists of best practices,
and what they were doing consisted of practices that clearly weren't the
best.
This point brings us back to the "SOA is dead" meme. Solving business
problems the best way available isn't dead, of course, and never will
be. But misapplying practices under the name of SOA can't die soon
enough, especially in tight economic times. Organizations simply cannot
afford to waste money doing things they think are SOA, but aren't.
*Should you Call your Initiative "SOA"?*
If you are following best practices, then using the "SOA" label is, yes,
a best practice if there's a good reason to do so. For example, if
there's understanding and support for SOA among business stakeholders,
then calling the initiative SOA will help firm up that support. Such
stakeholder understanding is by no means guaranteed, however. In many
cases, the best name for your SOA initiative is a name that ties the
project to the business problem you're addressing. Some of the most
successful SOA projects go under names like "Sarbanes Oxley compliance
initiative" or "improved customer visibility" or some other phrase that
ties the effort to the solution it promises to deliver.
If your organization isn't following best practices, however, then
calling your project "SOA" isn't going to help -- but then again, you
have bigger problems. These are the situations where the SOA moniker is
a straw man: "I was doing X, I called X SOA (even though it wasn't,
since it wasn't best practices), and it failed -- therefore SOA failed."
Well, we don't have the time or money to play such games any more. SOA
isn't dead -- what's dead is the fake SOA straw man.
*The ZapThink Take*
While some of you were no doubt taken aback by the "SOA is dead"
conflagration, my guess is that far more of you looked on with more of a
sense of bemusement. After all, we talk to dozens of architects every
month who are showing real successes with their SOA initiatives, and no
single blog post will cause them to rethink their approach to
architecture. Sure, there are challenges, and the tight economy isn't
making life any easier, but nobody is trying to tell you to stop doing
what you are doing if it's working for you.
We're so used to all the hype around SOA that now that SOA is becoming
mainstream, the decrease in the hype is both refreshing and possibly
worrying. After all, shouldn't we all be working on the next big thing,
be it cloud computing or something else? The fact of the matter is, the
answer is no! We should seek to have a laser focus on addressing
business needs, and we shouldn't let hype, or the absence of it, steer
us astray.
The "SOA is dead" meme, in fact, might be thought of as a kind of
"anti-hype" -- which is really just more hype. If SOA really were dead,
then either SOA isn't best practices (the straw man), or best practices
are dead, which is just plain silly. Focus on the business problems at
hand, apply true best practices to those problems, and ignore the hype,
and you will inevitably be successful in your endeavors -- regardless of
what you call them.
