SOA Obituary: Misinterpretations and Perceptive Enrichment

Blogger: Anne Thomas Manes

The cacophony generated by my SOA obituary post exceeded my expectations. Obviously, I hit a nerve.

Admittedly, the title was designed to draw a response. But I was still a bit surprised by the number of people that misinterpreted my meaning. I attribute the misunderstanding to the ambiguity of the term "SOA" itself, which JP talks about in his post from earlier today.

Misinterpretations of my meaning generally fall into four camps:

• "Big SOA" is dead, but "Little SOA" will survive: This is by far the most common misinterpretation: "Abandon your big vendor SOA infrastructure, forget governance, and just build services as needed with inexpensive and/or open source technologies." Now that I think about it, I can see why people got this impression. My "Long Live Services" message could easily lead you to this misinterpretation. But I also said, "Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change." That should give you a hint that I'm not recommending "Little SOA", which typically turns into JABOWS. A sound infrastructure and an effective governance program will be important going forward, and typically you need a "Big SOA" initiative to get them in place. Bear in mind, though, that I'm not saying you need to buy into a big vendor SOA stack to get them. See my "SOA doesn't need to be expensive" post.
• REST will fix everything: Many people took the "big" vs "little" debate one step further and thought I was referring to SOAP and WS-* when I said "SOA". I'm a bit surprised at this interpretation given that I characterized the WS-* vs REST debate as "silly". Shockingly enough, Jean-Jacques Dubray actually accused me of being a RESTafarian in the InfoQ Debate on the topic. Let me be clear -- I am not talking about technology. REST will not fix the problem. And the word "REST" is as bad as "SOA" even if it doesn't have a negative connotation yet.
• People should abandon all things previously known as SOA (or all things related to architecture) and go back to monolithic application design: I can only assume that people who came away with this misinterpretation didn't actually read the article.
• "SOA" is a bad word, but doing SOA is good, so we need to come up with a new name for "SOA": This interpretation is close, but not quite on the mark. Yes, SOA is a bad word. And yes, doing SOA is a good thing. (And we need to keep doing it!) But no, we do not need to come up with a new name. Emphatically not.

Obviously I was too obtuse in my description of what comes next. So let me explain:

My real point is that we should not be talking about an architectural concept that has no universally accepted definition and an indefensible value proposition. Instead we should be talking about concrete things (like services) and concrete architectural practices (like application portfolio management) that deliver real value to the business.

I am pleased to see that some people for the most part correctly interpreted the article. The following posts add a bit of perceptive enrichment to the conversation:

• Joe McKendrick
• Mike Kavis
• David Linthicum
• Kyle Gabhart
• Piet Jan Baarda and Martin van den Berg (which predates the SOA obituary)
• Brennan Spies
• Stefano Pogliani
• Dan Foody
• Neil Ward-Dutton

I also commend Darryl Taft on his coverage of the ensuing debate. (The first two comments on the article are definitely worth reading.)

The award for the most entertaining response goes to Miko Matsumura, and Steve Jones gets special recognition for his REST is Dead parody.

The award for the most offensive response goes to David Worthington for comparing me to Ann Coulter and claiming that I wrote the post purely for its sensationalistic value.

Comments

[Jason English]

Glad you started this - at least the tree didn't fall silently in the forest. No less than a little "Are ESBs Evil?" conundrum that played in July, people take out of it what they want to hear, and so much distinction and personal attachment is assigned to terms that represent what people are committed to delivering in the IT world. So can we now say "'SOA Is Dead' Is Dead" (at least until next year)?

[wfseube]

Use of hyperbole often leads to misinterpretation. You shouldn't be surprised at the result.

[Pierre Fricke]

My response came very late due to vacation. He it is again expanded...

I'll see Anne's Recession, raise it to a Depression, and still say, No Way SOA is dead... We (Red Hat/JBoss) are seeing similar things as Sandy at IBM... and have expanded the market with OSS.

I also recall how UNIX killed mainframes in the 1980s and then IBM proceeded to make more money (profit) on mainframes over the next 2 decades than all the UNIX vendors combined!

None of the SOA "offspring" solve the integration problem, but rather solve issues around the edges (e.g. cloud computing is ASP+virtualization+services, but not a solution to integration at large; and is much less mature)...are we going back to EAI? Or do we put an ESB, registry and repository in the cloud and call it cloud computing (when it really is still SOA)?

See http://blogs.jboss.com/blog/pfricke/2009/01/06/Economic_Depression_and_the_Rise_of_Open_Source_SOA_and_Business_Rules.txt

[Anne Thomas Manes]

I have another response I want to add to the list of recommended responses: Gary Barnett (http://www.thinkovation.com/blog/index.php/2009/01/14/soa-dude-its-alive-and-kicking/). His dissertation on why architecture is important is great reading. I agree with everything Gary said, but he missed my admittedly obtuse point as to why we need to stop using the word, "SOA". I was emphatically not recommending that people stop doing architecture. But there is a reality that IT people must face this year. If they go before the funding board with an expensive proposal to continue investing in “SOA”, the proposal will be shot down. If you want your IT investment proposal to succeed this year, you must talk about more concrete things than “SOA”.

[Maurizio]

A friend of mine pointed me to the below interesting article:

http://www.networkworld.com/news/2008/102908-bechtel.html?page=1

In summary, Bechtel Corporation is trying to create an internal SaaS infrastructure, they started first looking at what dynamic companies like Google, Amazon and SalesForce are doing internally.

"Bechtel's new strategy applies the SaaS computing model internally to provide IT services to 30,000 users, including 20,000 employees and eventually 10,000 subcontractors and other business partners."

"We operate as a service provider to a set of customers that are our own [construction] projects"

"What we learned is that you have to standardize like crazy and simplify the environment"

The SOA word was not mentioned, but isn't this an example of what Anne is trying to explain?

So, as the above article shows, SOA can be a very concrete practice if one doesn't misunderstand what it is all about. In the above example it seems a company has implemented a SOA practice to create an internal SaaS infrastructure, to rationalize and reduce costs in a tangible and effective way. SOA is good, is doable, but not that simple.

Kind regards

[Yves Caseau]

The debate that has grown these last 2 weeks is indeed quite interesting. The question of a practical explanation of what SOA is and how it works (one that could be given to a CEO) is still open.
I have been "doing the stuff" as a CIO for 5 years and now I am trying to teach what/why SOA is/works, a lot of pieces are still missing. My own 2 cents may be found on my blog:
http://informationsystemsbiology.blogspot.com/2009/01/soa-is-much-too-young-to-be-dead.html
SOA "in the small" is a no-brainer: it works, and the benefits are there. But they are smaller than what you can get if you deploy SOA "in the large". I don't think that "SOA in the large" is dead, I think that we are not there yet.
-- Yves

[Dimitre Tonev]

SOA as everything may be a good term or bad term. It depends on the context. When used with IT people it is a good term, because it allows you to communicate meaning in a condensed form. When used with business people or CEO it is bad term, because it does convey meaning to them.
Business people will invest money in projects that either deliver ROI or solve important business problem. When IT people go to the business with a proposal for SOA project, they are asking money to replace the existing IT technology with a vague promise that it will produce return ROI in the future. That is not good enough for most businesses even in a good time, much less in today environment. I agree with Anne that SOA is bad word in this context.
It reminds me of the Borland story. When I started work as software developer, Borland came up with great suites of software developer tools, Turbo C, Turbo Pascal, etc. They were about to overtake Microsoft in this market. Borland were one of the first to jump on the object-oriented bandwagon. Unfortunately they made the decision to rewrite all their tools using object-oriented technology. By the time they did that Microsoft was a lightning years ahead of them and Borland lost most of the market share they had.
We should learn from his lesson and not kill the business with expenses that do not produce immediate ROI or provide competitive advantage. We should use SOA to deliver business value.
SOA is our term and we should keep it for ourselves. After all even we cannot agree on a single SOA definition. I see ‘big SOA’ and ‘little SOA’ terms proliferating and that is troubling. If SOA is an architectural approach you either use or not. There is nothing wrong in applying it iteratively. A company may be in an early phase of SOA adoption, but I would call that ‘little SOA’.
Thank you all for the great conversation.