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 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.>>
