SOA & JSR 208: Reality Check
By dcb on Jan 30, 2005
A friend recently asked me what I'm hearing about SOA adoption and the buzz around JSR 208.
"JSR 208" might be a new term for some. Here is a brief overview: http://www.bijonline.com/PDF/Chappell%20oct.pdf
SOA is so over hyped these days that everyone probably has something different in mind when they hear that TLA (three letter acronym). Kinda like "Grid" - the concepts are real and useful, but the hype around SOA and Grid is running years ahead of reality.
Remember when N1 was first discussed... the vision of heterogeneous datacenters managed by a meta-OS that auto-provisions virtual slices into which services are deployed and managed to sustain business-driven SLOs based on priorities and charge-back constraints. Just roll in new equip and N1 will "DR" (read: dynamically reallocate) services into the increased capacity. If something fails... no problem... N1 will detect and adapt. We'll get there... eventually. And we've made important steps along the way. Investing almost $2B/yr in R&D will help. But it'll take (a long) time.
In some circles I'm hearing similar visions of grandeur around SOA. They talk of business apps described at a high level of abstraction (eg: business process models) loaded into an "application orchestrator" that broadcasts descriptions of the various components/services it needs, and then auto-builds the business app based on services from those providers (both internal and external) that offer the best cost point and service level guarantees. As new "service" providers come on-line with better value (or, if existing providers go off-line), business apps will rebind (on-the-fly) to these new service components.
Now, combine N1 and SOA and ITIL, and we could paint a beautiful picture of Service Delivery based on self-orchestrating business apps made up of discrete reusable and shared (possibly outsourced) components that each exist in their own virtual containers that are auto-provisioned and auto-optimized (based on SLAs and Cost and Demand) to maximize asset utilization and minimize cost, all while meeting service level objectives (even in the event of various fault scenarios).
Okay - back to reality :-) I'm finding there is a common theme from many of my customers/prospects. Many are seeking to increase efficiency and agility thru "horizontal integration" of reusable building blocks (eg: identity, etc), a shared services platform (grids, virtualization, etc), and higher-level provisioning (automation, SPS).
That isn't SOA, per-se, but is a good first step. The "building blocks" most are looking to share today are infrastructure services, rather than higher-level business app components. There is a maturity gradient that simply takes a lot of hard technical and political work to negotiate. Every customer is at a different place along that gradient, but most are embarrassingly immature (relative to the grand vision). It takes strong leadership and commitment at all levels, and a synchronization of people, processes, technology, and information, to even embark on the journey. It takes a tight coupling of S/W engineering, IT Architecture, and Business Architecture.
So, yes, I'm passionate about SOA, and JSR 208 will help integrate discrete business services. There are some firms that are pushing the envelope and building interesting business/mission apps from shared "service providers". But, in general, SOA is an abused term and the hype can derail legitimate efforts.
I'd be curious if others are sensing "irrational exuberance" around SOA, which can lead to a "Trough of Disillusionment"
and a rejection of the legitimate gains that an evolutionary
progression can provide. As Architects, we can establish credibility
and win confidence (and contracts) by setting realistic expectations
(hype-busting) and presenting not only a desired state "blueprint"
(something that gets them existed about the possibilities for their
environment), but a detailed roadmap that demonstrates the process and
the benefits at each check point along the way.