Posted by: Jack Vaughan
SOA development, SOA governance
By Ted Neward
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. Originally, though it’s hard to remember in the frenzy around SOA, the whole point of services, at least in their original form, was about designing distributed systems to be loosely-coupled and thus easier to interoperate with. Consider these original classic “four tenets of service-orientation” (http://msdn.microsoft.com/en-us/magazine/cc164026.aspx):
1) Boundaries are explicit
2) Services are autonomous
3) Services share schema and contract, not class
4) Service compatibility is determined based on policy
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.
I always thought CTOs and CEOs had something… I don’t know… *better* to do. For some reason, I always thought it was the job of the architect to think about these things, rather than let the CTO or CEO sit around and think about how their various software systems should be designed.
Don’t get me wrong: any organization that spends time thinking about how their various software systems are going to interact with one another is already a huge step above those that don’t. 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.”
Said CTO went on to buy a “service-oriented” software package that he claimed would solve all their integration problems. The company went under about a year later. I won’t suggest it was anything to do with my inability to convince him that he really needed to invest more in thinking about his software infrastructure instead of just buying something “service-oriented”, but I can’t help but wonder….
So what are we to make of all the “service-oriented” bells and whistles currently being hung on every product, language, or release? In the end, the same thing we eventually made of objects, XML, Java, relational databases, XML, and every other technology that’s been put in front of us.
It’s useful, but it has an “end”. There is a point in the IT implementation, where the technology simply can’t help. Consider object-orientation, for example: back in the heyday of objects, various vendors, including one three-lettered vendor who was seriously looking to displace their rival in the operating system market, slapped “object-oriented” around everything, with the full expectation that not only customers *think* the product was better, but that the product really *would* be better. Another company, headed by a would-be jazz musician, tried the same thing for its office suite, and almost jazzed itself out of existence.
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”. Service-orientation describes an approach by which we create distributed systems, and that’s all.
When a CTO starts thinking about objects, or services, or other low-level activities, she may as well be conducting code reviews, too.
CTO-driven refactoring, anybody?