Regardless of whether the abstractions are business- or technology-centric, it often falls to the architect to wield the tools of abstraction as a core part of what it means to do architecture. Another important role of the architect is to negotiate between different levels of abstraction. Fortunately, as the practice of architecture matures, separate conversations become more distinct over time.
Architecture tools like the Zachman Framework help architects define such separations for the organization. And yet, while Zachman strives to define models for the business as well as for technology, it falls short of providing much meaningful business/IT alignment for most organizations that attempt to use it; often due to the Framework’s ambitiousness and complexity.
Instead of the numerous, diverse conversations that tools like the Zachman Framework encourage, therefore, service orientation centers on only three: the business conversation, the IT conversation, and the third conversation (which doesn’t have a formal name, but falls squarely in the overlap between business and technology, what we might call the service orientation (SO) conversation, for want of a better term).
Both business people and IT people can and should be able to carry on an SO conversation, even though this third conversation is not strictly speaking either a business or technology discussion in its own right.
Conducting the SO Conversation
Conversations break down into sentences, which consist of words. The three conversations sometimes use different words, while at other times the same terms are used in different ways. Take, for example, the word “service”:
Note first of all that the first two definitions taken together look like night and day. Put a business person who sees a service as in #1 in a room with a techie who has perspective #2 and they might as well be speaking Greek to each other. Secondly, note that from the business perspective, definition #3 looks rather technical, and yet from an IT perspective, the third definition has a distinctly business-oriented context.
That’s the fundamental nature of the third conversation: it operates at the overlap of business and IT, and yet falls squarely in neither.
While the example above deals with the noun “service,” let’s work through a second example that deals with verbs. What actions might someone take to create and use a service? Here are some ideas:
The business, of course, places the acquisition of services in the context of a business transaction: Want it, buy it, use it. You techies out there will instantly recognize #2 as the core verbs in the software development lifecycle.