“SOA is Dead”: Or Are The Rumors Greatly Exaggerated?
If you follow the pulse of the software development community, you’ve heard numerous reports that SOA is officially—stick a fork in it—done.
Perhaps the highest profile obit comes from long-time and well-respected SOA analyst, Anne Thomas Manes. Anne literally wrote the book on SOA and has built a personal brand and cult of personality on its rise—and now its alleged fall.
Does Anne truly believe SOA is dead? I think it’s more likely that she—and others—feel that SOA has wandered off track. “SOA is Dead” is little more than a rhetorical devise to provoke a change in thinking and confront the reality that SOA—in its present incarnation—has dramatically under-delivered on promises.
Anne acknowledges that the principles of SOA remain as necessary as ever before. As IT budgets are slashed, organizations need to focus on faster, more efficient ways to develop applications. What’s more, prevailing distributed and cloud compute models require the sort of self-describing, interoperable services that SOA promises. SOA may have failed as a category—under the weight of unrelenting, hammering, merciless hype—but its principles remain alive and well.
So, where did SOA go wrong?
My theory is that SOA focused too much on “apps” at the expense of “ops.” SOA was often an ivory tower experiment that didn’t adequately account for the operational realities of application deployment and maintenance. While SOA abstracted away complexity for the lucky few composing apps, the folks responsible for deploying and maintaining them weren’t quite so lucky. It’s this deployment complexity that made SOA-style applications a better idea in principle than it was in practice.
The first act of SOA focused on service abstractions that still needed to be deployed. This is when the promise of SOA ran headlong into the fact that many IT shops simply weren’t set up to take advantage of SOA—and much of the goodness of loose coupling and interoperability was undone by applications that were implemented in a much more tightly coupled, less architecturally elegant manner.
The reality is that what makes complete sense in the relative isolation of application development doesn’t always translate to the harsh realities of IT operations. When apps meets ops, architectural ideals meet pragmatic realities—and loosely coupled and standards-based applications often become hard-wired systems invented on the fly under the guiding principle of “make this stuff run, now!”
But there is a new wave of innovation that promises to bring SOA-style value to the deployment context—where the reusable services aren’t the design-time definitions of yore, but running systems themselves!
rPath’s approach to automating the creation, deployment and maintenance of complete and ready-to-run systems begins to foreshadow what SOA could become if you removed yesterday’s shroud of deployment and maintenance complexity.
Yesterday, the building blocks for composing applications were little more than design definitions that still needed to be implemented. With this new approach, the building blocks can be complete ready-to-run systems.
Imagine rapidly composing an application that is ready to deploy? Perhaps that is the future for “the architecture formerly known as SOA.”
I think I’ll stick around for the second act.
Comments
Leave a Reply
