Don't you just want to scream every time you hear the dreaded phrase "Business/IT Alignment"? It seems that every consultant since the dawn of the computer age has been touting their ability to achieve this visionary concordance, and yet here we are, over half a century since enterprises first began using computers, and the business and IT worlds seem to be less aligned than ever before. Yet, dare we say it, the rise of Service-Oriented...
Architecture (SOA), especially when we place it in the context of Enterprise Architecture, is yet one more attempt at lining up the suits and the geeks. What is it about this latest technique that promises to make progress where so many approaches of the past have fallen short?
Rethinking business/IT alignment
Looking closely at what people actually mean by this tired cliché can begin to shed some light on the problem. From the business perspective, business/IT alignment means getting IT folks to speak the language of business. "If only those techies understood business and could speak my language," the suits say, "then they'd be aligned with the business." The perspective from within the ranks of IT, however, is predictably contrary. "If only the suits could understand the issues of IT," say the tech set, "then they'd be much better able to leverage the technology to meet their needs long term, instead of throwing short term requirements over the cubicle wall, expecting us to deliver on them in as little time and with as little money as possible." Yet after all these years, neither side has come to speak the language of the other sufficiently well to achieve alignment.
The problem is, neither group is ever going to get what they want if they expect the crowd on the other side of that wall to change their ways and speak the language of the other group. Business conversations and IT conversations come from fundamentally different points of view, even when they are speaking about the same issues. In order to finally make progress on the heretofore unreachable alignment, therefore, everybody in the organization must be able to carry on a different conversation altogether.
Multiple conversations and the role of the architect
Carrying on separate conversations, in fact, is nothing new in the world of IT. From the earliest abstractions like compilers and user interfaces, to today's separation of logical and physical models, an essential technique for conducting simplified conversations about complicated topics has depended on various abstractions. Furthermore, as the IT environment becomes more complex, the need to understand the separations among various conversations becomes an increasingly important tool for dealing with such complexity.
It's also important to note that business people also deal with abstractions every day, even though they may not realize it. After all, business itself is an abstraction for the myriad activities that people undertake at work. Business processes are also abstractions consisting of sequences of such activities. All of these abstractions provide people with a frame of reference for conducting meaningful conversations where the participants have a good shot at understanding one another.
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 who 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 service orientation 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" itself:
1. Business context -- a service is a capability the business can draw upon to achieve its goals.
2. IT context -- a service is a contracted interface to software functionality and data that communicates via messages.
3. SO context -- a service is an abstract representation of an IT capability that the business can compose with other Services into applications that implement business processes.
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:
1. Business context -- need, decide, order, buy, pay, use, measure, support
2. IT context -- define, design, analyze, develop, code, test, deploy
3. SO context -- govern, model, save, render, create, publish, discover, compose
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. The third conversation, however, thinks about service creation as a set of model-driven, declarative operations that take place above the service abstraction: they don't deal with the code-centric issues of the IT perspective, while still providing services by leveraging IT capabilities.
Learning to speak service-oriented
Today's service-oriented architect is part evangelist, part visionary, part therapist, part coach, and part taskmaster. Among all these duties the SO architect has, let's add one more: language teacher. It is this architect who must work with both audiences to explain the new vocabulary of service orientation, and with it the new way of thinking about the relationship between business and IT.
The good news is, you architects out there don't have to worry about teaching technology to a business audience or teaching business to a technology audience any more. Those of you who have tried either of those Sisyphean endeavors know how often they amount to rolling a stone up a mountain. Instead, leverage your organization's progress with SOA to craft a new language for your organization, one that both constituencies can master. True, the third conversation will seem technical to the suits and "high level" (read: business-centric) to the geeks. But rest assured this new conversation is the key to successfully aligning the two camps.
The ZapThink take
Even though the goal still eludes us, we've definitely made a certain measure of progress aligning business and IT via previous efforts over the years. In fact, the entire vision of eBusiness in the 1990s was one of improved alignment. And while there's no question that the vision of eBusiness was successful in many ways -- when was the last time you traded a stock or bought a plane ticket without using the Internet? -- true alignment remained largely out of reach, in large part due to the human communication issues discussed above.
Just as eBusiness had only limited success in achieving true business/IT alignment, SOA will only have limited success as well unless both sides of the cubicle wall learn to speak the third conversation. It is only by learning to speak this third conversation that business and IT can finally come into alignment. The reason this goal has been so firmly out of reach up to this point is that people assumed the only way to achieve it was to either teach business people to speak tech, or to teach the techies to speak business -- but history has shown that such a goal is basically unrealistic. And yet, we propose that it is possible, and possibly even likely, that both business and IT people can learn to speak the third conversation. Only then will they truly be able to move forward in alignment, and only then will SOA live up to its potential.