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.
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.