This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: PeopleOverProcess.com: SOA on the Brain
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
[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 brining the propeller heads and the suits together.
Vendor Bullshit
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, that the architectural simplicity that JP outlined, an early understanding of "SOA," for me 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 questions I've started asking when I hear a story about how great SOA is -- how much better a customer's IT-scape is doing because it's now got "SOA Inside!" -- "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.)
Previous Topic
