[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.
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, 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.)
Tags: architecture, gtsoftware, services, soa, soasoftware
Isn't this like the dream of the Network Appliance: "Ya just plug it in and it goes."?
it's sort of like Compliance, in that respect. for a while, everyone was slapping the "Compliance" label on their products in hopes of riding the wave of investments in there.
". . .that Holy Grail task of bringing the propeller heads and the suits together."
Sorry for the long post, but this one hit a nerve. Maybe I've been drinking too much business-side kool aid lately but BPM/S is starting to make headway here, and the smartest BPM/S minds aren't buying into the false dichotomy between BPM/S and SOA that a lot of trade writers have been pushing so hard on. Instead they're pushing real collaboration and from what I've seen (and a number of analysts I respect agree on this point) non-siloed collaboration is waiting on a cultural shift, not technological progress. We're already there, but no one seems to be admitting it. Maybe we're all just confused and afraid to tell anyone! And you're right, the taxonomy/nomenclature out there is seriously gettin' outa hand, so thanks for your clarifying efforts, that's a big part of what I think is contributing to the problem. If I sound like like Tim Robbins in the opening scene of "The Player" every time I have to describe a new technology, something is seriously wrong! Though I thoroughly enjoyed your attempt;) And I'm with you on the marketecture theivery too, if I hear one more marketing director say something along those lines re: SOA and "solutions," I just might pop. And I'm on the PR side for crying out loud! On this topic Bruce Silver is worth reading:
http://www.brsilver.com/wordpress/2006/06/05/the-…
Cote,
Weird,
I was on a this track this morning, but coming from the opposite direction.
http://theotherthomasotter.wordpress.com/2006/10/…
I think the SOA talk is too technical and ethereal for most audiences. (there is smallish group of clever high priests who need to debate the religious and philosophical forms of what is SOA and what isnt SOA, what is heretic and what is blessed etc)
We need some parables and a couple of miracles to grasp onto. What we really need are some clearly articulated examples of SOA in action, and a whole less theology. At the moment the SOA stuff is a bit like monty python's Spanish inquisition. We have one SOA weapon, services and standards, no we have two SOA weapons, services, standards and simplicity, no wait we have three SOA weapons, services, standards, simplicity and platform….
http://www.youtube.com/watch?v=zO68fUMWx3g&mo…
We really need the adverts for the stomach flatteners and major cleaning products. PLease-
ie before SOA it looked like x, and now it looks like y. You too can look like Charles A, or have clean carpets.
(bugger I should have posted this)
"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."
Alas, the technical ideas are *not* great. They ignore at least 20-30 years of experience the industry has had with building Internet scale systems.
HTTP was/is the evolution of distributed OO.
Re: branding – this is a common pattern when a new buzzword comes along. Just like when MS announced .NET, they re-branded everything .NET, until they realized it diluted the brand.
Re: SOA – Danny Sabbah described this very well a few weeks ago (paraphrased) "SOA's simply 30 year-old good software design principles applied to enterprise computing and implemented on top of standardized protocols and formats" (BH comment – I believe he was talking about XML/HTTP/TCP/IP, not necessarily WS-*).
While I'm not a big fan of buzzwords and hype, I am a big fan of good software design principles and standards, so I look at the technical side of SOA as a good step forward on that front. And if you've spent much time trying to understand a large enterprise architecture *not* developed with SOA principles (i.e. lots of undocumented, one-off point-to-point connections between systems), you'll definitely look at the SOA approach as a very good thing.
Danno: just plug-in and go is the everyone's dream…so yes 😉
Steve: indeed, I used the example of "Java" and "WebSphere" as over used prefixes. Bill points out an even better example, .Net.
Mark: yes, given how expansive the umbrella of SOA is — that is, how much is gets applied to — that's inevitably right. I have that problem of switching between "what I think the idea should mean" and "what the idea really means" when talking with things, and that quote is an instance of that. I think he problem may be — and this might have been the misstatement on my part — that the technology doesn't exist, collected as something you could point to and say "SOA!" Instead, it can/could be pieced together into what I would call an SOA. But again, I'd also lean towards just calling it "programming" ;>
Bill: you're parenthetical note is correct. And, yes, an enterprise system built without "any" architecture, and even more so, those "30 year-old good software design principles" is terrible.
Interesting musings!
Yes, SOA is largely a technological story but it has a fraternal twin, shared services, that is the business side of the narrative.
As for how service orientation might differ from regular old architecture and programming… I think it's in the coarseness of the components. I'm reviewing a supposedly service-oriented architecture right now that's nothing of the sort, because the "services" are such tiny pieces that they are almost worthless when separated from the rest of the system. This is important when you think of trying to get the suits (shared services) together with the propeller heads (SOA). Shared services business units depend on very coarsely defined services.
It's really important to (as Coté does) make the distinction between being able to be *part* of a SOA and being "an *implementation* of a SOA". The former is good design; the latter is the inward-facing, technology-centric, millions-of-lines-of-code-behind-the-firewall horror that all of us except Enterprise Architects dislike.
"Long ago, when I was working at The Cobalt Group as a young J2EE developer" – I didn't think J2EE developers existed long ago 🙂
Bill W.: Indeed!
I'd say that the purely technical ideas are a distraction. This is unfortunately what tool vendors will focus on.
The most worthwhile aspect of SOA is about effectively supporting business processes that are shared between business units. That requires certain technical approaches but the approaches themselves are not the point of the exercise.
What is it with Oriented – is that some sort of abstract sexual preference on the part of programmers? IT should be Services Based Architecture. And even then Architecture sux. It presupposes that 'architecture' is the be-all and end-all. It may be in the minds of some but I doubt many CIOs would agree.
Service Orientation in itself does not bring any real new value than Object Orientation did not offered already. It can be even seen as a variant of it.
What has made Service Orientation so popular is actually web services. Web services do provide a novelty that was not available before: real interoperability across any platform, tool and vendor (OK not perfect but the best one ever achieved). Web services is the only realistic technique to build software that can interoperate with any tool from any vendor in any platform. This was never achieved by CORBA, DCOM, RMI or whatever because they did not enjoyed universal vendor support. Web services, SOAP, XML and the like do.
And interoperability is the sinequanon requisite for reuse, aka the holy grial of software. Try to reuse C++ in Java: a a joke. "Orientation" is not enough.
This huge difference is what has made web services so popular, and then somebody sublimated the thing from the concrete web services into the abstract, generic Service Orientation. Its actual rationale is the interoperability of web services.
But in the end this means that [Web] Service Orientation delivers a great deal of real value to IT, and this is why it will govern most of the IT landscape for the upcoming years.
The rails community really should do something about support for SOA as this will be yet another reason why it isn't enterprise class.
Another problem may be that SOA is done in a big way but the problem lies with analyst firms not desiring to tell the story of how customers use SOA for business purposes and instead prefer to talk about products from vendors.