[A]t that Rails conference and the question came up in both, and in the hallway talk too: “What do you think we should do about SOA?” Which weirdly, nobody had asked me before, and I could find only one answer: “Don’t do anything. ‘SOA’ may have meant something once but it’s just vendor bullshit now.” —tbray
I’ve been soaking in the vast SOA pools quite a bit of late: from very large vendors to small ones. James and I just got off the phone with Rob Morris of GT Software and had a delightful discussion about The State of SOA Marketing. Yesterday I talked with SOA Software for awhile about the challenge of getting a pragmatic definition of the area. It gave me a good chance to further hash out several of the below thoughts I’ve been having in the area of late:
- The technical ideas are great. It’s the further evolution of OO. In fact, it’s almost the child of distributed OO and HTTP/XML. Somewhere along the lines, WS-* came in and kidnaped that child.
- Unsuccessful — confusing, boring, and/or unhelpful — SOA stories are usually caused by by a vendor trying to be an SOA platform instead of a component in an SOA-leaning IT environment.
- To me, the public web is the first and most successful (by quantity) SOA. Web sites and web applications are services, and they hook together in, to use be extremely charitable in applying he term, loosely coupled fashion. Once “enterprise” and “behind-the-firewall” get laced into the technology, things start to go wonky if you don’t take a lesscode approach.
- SOA is, fundamentally, a technological story. The “solutions”/business side of the fence has hijacked it as a marketecture gold-mine. There’s a sort of paradox here as SOA is supposed to be in terms of business and solution…but I think it’s largely failed in that Holy Grail task of bringing the propeller heads and the suits together.
Long ago, when I was working at The Cobalt Group as a young J2EE developer, my pal JP schooled me on the idea of building your code as a series of services. It made complete sense, at a code-monkey level, and was great for both the technology and (more importantly) the way you could run the organization.
Somewhere along the lines, the architectural simplicity that JP outlined for me, an early understanding of “SOA,” was widened to mean “whatever (enterprise) software we’re currently selling.”
And that, is the “vendor bullshit” that Bray mentions above. Increasingly, I find that large vendors use SOA to describe whatever it is they have and are selling. Under the covers, sure, it may be that services-based, distributed, HTTP/XML (or events/ESB) system, but at the marketing level, it’s a bit more, as I said, “hijacked.”
The question I’ve started asking when I hear a story about how much better a customer’s IT-scape is doing because it’s now got “SOA Inside!” is “compared to what?” That is, what were the alternatives? The snarky, between the lines question being, “what makes ‘SOA’ different than ‘programming'”?
(Of course, that’s more of a conversation starter than an end-point.)