Okay, enough wrangling over whether SOA is dead, or is thriving, or never even existed, or crashed somewhere near Roswell, New Mexico. The indisputable fact is many organizations are now working toward service orientation for at least part of their business application offerings, and this will only grow.
For Joe, the way forward can be found in an article written by Bob Violino a couple of years ago, who argued at the time:
There is no doubt about it: service-oriented architecture, or SOA, has gained acceptance as a way to exchange data previously trapped in legacy systems and isolated databases.
In the mean time, lat week, Ted Neward tempered:
In the rush to embrace new technologies and demonstrate “cutting-edge awareness”, companies (and individuals) sometimes create mountains out of molehills. Such was the case with XML a few years ago, relational databases before that, object- orientation, Java, graphical user interfaces…. in fact, it’s hard to name a recent technology trend that hasn’t spawned this kind of “rush to embrace” that leads to nonsensical claims, bizarre architectural suggestions, or blatant bald-faced attempts at capturing clueless consumer dollars. One of those more recent trends has been the SOA bandwagon.
He asks if we remember:
Originally, though it’s hard to remember in the frenzy around SOA, the whole point of services, ... was about designing distributed systems to be loosely-coupled and thus easier to interoperate with.
Yet, he notes that:
Nowhere in here do we find reference to SOA governance, SOA enablement, or any of the other elements that have been attached to the SOA name. In fact, it’s gotten to the point where CTOs and CEOs are talking about SOA as a general strategy for running their entire IT department.
This is in sharp contrast with what Joe think will take SOA Forward:
1) Increased visibility as SOA moves from theory to practice
2) New types of jobs
3) The rise of best practices and competency centers
4) More governance and reuse
5) More measurement
Ted justifies his argument by asking why is it really the role of the CTOs and CIOs to worry about SOA? In the meantime he explains:
Too many CEOs and CTOs just assume that their back-end IT systems are capable of talking to anything at any time–in fact, one CTO once told me, to my face, “The only reason you’re saying it’s hard is so that you can charge me more money as a consultant. Well, I’m not buying it, and I’m not buying you.”
Ted continues:
So what are we to make of all the “service-oriented” bells and whistles currently being hung on every product, language, or release?
In his view,
There is a point in the IT implementation, where the technology simply can’t help.
Eric Roch seems to agree, one of the problem he sees is ROI:
many companies have spent millions of dollars on SOA software, infrastructure and consulting dollars with no idea how to justify the costs. That's bound to get noticed.
Ted concludes:
Moral of the story? We learned that objects are a useful way of structuring the way programmers think. Nothing more.
Another look at the “four tenets” makes it pretty clear that services aren’t much more than that, either–it’s a way of structuring the way programmers think, and has nothing to do with “governance” or “enablement”.
Where does SOA go from here? Do we have enough middleware between Web Services, HTTP/APP, SCA or distributed-OSGI? What is the role of Resource Orientation or Event Orientation in Service Orientation? Is it time to let developers loose with these technologies? or Do we still need competency centers? Can you build connected systems without governance? Should you rush to explain your CEO how successful your project was because of OSGI? Are to current programming and integration models enough to build complex connected systems? Is it just an interoperability problem? A cost problem? What is your opinion?
