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:
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 offensive response goes to David Worthington for comparing me to Ann Coulter and claiming that I wrote the post purely for its sensationalistic value.