IT Sense: SOA: So What?

It seems everywhere I turn, there’s another story about Service-Oriented Architecture (SOA). What is SOA exactly? No one agrees.

A definition put forth by the Organization for the Advancement of Structured Information Standards (OASIS) offers that SOA is “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.” Others define it as a new word for Web services, promulgated mainly by folks who want to sell us something—whether it be hardware, software, or consulting.

Depending on who you ask, SOA is delivered via a metadata model that maps transactions or messages back to the business processes-qua-applications that produce them. That way, as the messages move through infrastructure, they can be exposed to the appropriate data management and data protection services. (OK, I can see the value of that.)

Ask someone else, and they will launch into a longwinded discussion of how SOA is all about reuse, granularity, modularity, “composability,” componentization, and interoperability. It further standardizes, in ways both common and industry-specific, the identification and categorization of services, techniques for service provisioning and delivery, and ultimately monitoring and tracking services and their applications. (Not sure I know what “composability” is, but I get most of the rest of these descriptions.)

When it comes right down to it, SOA is another word for what we should have always been doing in IT; certainly, it’s what we’ve done in the many shops I’ve managed over the years. For example, we always began new application development with a requirements definition, and we used it to tailor the IT services we were building to meet the needs of the company (or at least the business unit footing the bill).

If we didn’t do this, I was taught early on in my career by my first MIS director, there would be no point for the company that paid my salary to have an internal IT organization. They would be better off outsourcing everything to a service provider.

So, I find myself scratching my head, trying to figure out what SOA brings to the practice of IT. Is it like the IT Information Library (ITIL)—something begun by the British Government seemingly to dumb down even the most obvious aspects of management so someone with a less-than-grade-12-reading-level can do an adequate job? (The ITIL Security reference actually includes an instruction to the reader not to share confidential information with those who lack security clearances. In the words of my 10- year-old, “Well, no duh!”)

Or, is it comparable to the International Standards Organization (ISO) standards, which are a set of recommendations proffering relatively simplistic guidance about all-things IT? ISO has become institutionalized over the years less for the value it provides than for the ecosystem of consultants and specialized training and certification authorities it has created. Again, most ISO standards state the obvious, and any organization that doesn’t already have processes in place that could be “ISO certified” is probably managed by folks who need some remedial education in DP 101 or Basic Business Administration.

If I sound perturbed—and a bit perplexed—by SOA, it’s only because I fear we’re putting down the IT practitioner and playing into the whole “Does IT Matter?” mantra. SOA is common sense, pure and simple. It’s the purpose-building of IT infrastructure to meet business needs, eschewing a one-size-fits-most architecture in favor of tailored solutions.

Most SOA theories do add automated middleware for resource/service (de)allocation, assuming any of it catches on in a big way, to replace what we cobble together ourselves to share data and efficiently provision resources. I’m all in favor of that, though I doubt there will ever be widespread industry adoption of any of the wares developed by any particular vendor. Call it the tragedy of the commons, if you like: Vendors are looking out for themselves rather than for their customers.

I know this position will irritate SOA advocates within vendor shops and SOA champions within business organizations, but I’m going to hang it out there anyway in the hope it will stimulate a bit of rational debate. Your input is welcomed at Z