A reader comments: "I guess I have never quite understood how 'alignment' has anything to do with SOA as a technical architecture."
This comment was made by Matt M. on ESB-Oriented Architecture, in response to the statement in my article, "The primary goal of SOA is to align the business world with the IT world in a way that makes both more effective."
Matt, thanks for sharing your reaction. I think this topic--does SOA align business and IT?--is very interesting and worth discussing.
IBM feels that business/IT alignment is very important to SOA. I actually didn't author that statement in my article; it's a quote from IBM SOA Foundation. The action involved is sometimes expressed as aligning IT to the business, but I prefer the perspective of aligning them to each other so that both business and IT are active participants. (See Service Oriented Business.)
This alignment idea is not completely new. My COBOL programmer brethren can probably talk about writing business-oriented code back in the 1970's and even '60's. I know that back in the early 1990's (when object-oriented programming was really gaining momentum), Booch wrote books about developing OO domain models that simulate the business; so did Rumbaugh (and Grady and Jim are now both with IBM via Rational), as did Jacobson with use cases. Services perform the same sort of simulation, but at a coarser-grained level; services also add support for defined interfaces, context-free (aka stateless) invocation, and dynamically discoverable providers. Reusable SOA services are an evolution of reusable domain objects and use cases, not some completely new concept. (I even talk about "service use cases"; see Streamline SOA development using service mocks.)
What is new (or at least newer) is thinking of business in terms of reusable services that IT can then implement as reusable services. A lot of this thinking comes from business process modeling (BPM, aka workflow) (these days coded as BPEL), which models the business as reusable processes composed of repeatable actions. With SOA, the overall process and each of the actions are services. (I call these the service coordinator and service providers; see The Two Parts of an SOA Application.)
We also often distinguish between business services and technical services. The former have meaning to business people, such as process an order or check inventory. The latter do not, but are needed as part of a technical architecture, such as verify authorization or perform data transformation. The thing to realize is that while technical services are often (always?) necessary and valuable for implementing a working application, because they are not business services, they have no value to the business. Or to be more precise: The value of technical services is indirect in that they support business services which do have direct value to the business.
The focus of business applications needs to be on creating business value. That's how the business pays for the applications and the IT to develop and operate them. By modeling the business itself as a bunch of business services, those services embody the value that the business generates. By implementing those business services in IT applications, the applications create the value for the business. By supporting the business services, technical services create value for the business indirectly.
Just remember: It's the business that drives the business services that drive the technical services, not the other way around.