By: Harry Hendrickx, CTO / Enterprise (Business) Architect, Hewlett Packard Company
At the 12th annual LAC architecture conference in the Netherlands, several presentations and workshops focused on business architecture. Debate around “Business versus IT”, “Is information part of the business?” and such were discussed by a thought leadership panel. One panelist posed a question that is spot on in regard to one of the biggest problems facing enterprises when transformations are being shaped: “Does IT know what our business is?” I really liked this question but unfortunately not much attention was paid to it.
What better way to correct that oversight than through a blog that traverses the space-time continuum? We have transported Vitruvius and Socrates to the year 2013 and listen in as they discuss this topic. (Note: For those who have misplaced their college notebook on the Roman Empire, Vitruvius was a Roman writer, architect and engineer born circa 70 BC. Socrates, of course, was the famous Greek philosopher born about 400 years earlier.)
Vitruvius starts with his response to the question that the LAC panel in the Netherlands overlooked . . .
Vitruvius (VIT): Does IT need to understand the business?: I do not believe there is a need. The IT industry has created its own problem by creating an “us-versus-them” relationship with business. IT has created its own gap.
Socrates (SOC): That gap indeed arose during the late eighties and early nineties, and was established by Venkatraman and Henderson in their article on business and IT alignment. However, if such a gap is unnecessary, what would then be the real problem when aligning business and IT? *
VIT: Although Venkatraman’s and Henderson’s intentions were quite valuable they did not resolve the alignment problem. In hindsight, they worsened the problem by creating an over-simplified picture of the alignment between Business/ IT, and Strategy/Operations. Both gaps became empty spaces that nobody knew how to bridge.
SOC: Well, there are several ways to bridge these gaps:
- align business strategy with IT strategy and then with IT operations;
- align business strategy with business operations and then with IT operations; or
- align business strategy with immediate solutions.
VIT: Let’s take a closer look at what you’ve suggested. Your first approach of alignment would require a lot of magic that resembles more art than profession. This often happens when business strategy is translated into IT strategy. Your second approach would be to adopt a machine view of operations, technically derive information objects and models, and then develop applications and supporting IT operations. Unfortunately, traceability to the business strategy is not the strongest attribute of experts in that field. Statements of strategic nature are usually captured and modeled around objectives and critical success factors. However, the real business logic behind this approach is difficult to reproduce or articulate. Your third approach can work in the short run, but usually falls short by failing to meet several business requirements. This results in costly repairs and rework.
SOC: Okay, I see your point. The machine view works quite well technically to identify how IT and business need to be shaped. Only it is too time consuming, too costly and success is too uncertain. Its weakest point is the way strategy is aligned with internal context (approach #2). A similar weakness also appears in the art approach. This is good thinking, but results are difficult to communicate and understand without having been involved. The IT sector responded to this issue with a more disciplined and systemic approach: the architecture approach.
VIT: Yes, but that approach does not accomplish its promise either. The enterprise architect enables better alignment, but cannot fully resolve the alignment problem. It has too much of a technology perspective. A common complaint is that enterprise architects do not sufficiently understand the business. They cannot create a dialogue between business and IT that will uncover the real business logic and thus prevent unexpected issues. The enterprise architects ultimately deliver a light weight business vision and strategy.
SOC: Wait, why do you say their business vision and strategy is light weight?
VIT: Well, the individuals using an enterprise architecture approach come from the technology and engineering field and thus have a machine view (meaning that if all components are in place, it will work when energy is added). Other professional roles include a light weight approach because none of them have yet developed a mature, systemic approach for alignment. Business consultants are biased to the industry aspects, enterprise architects are biased to the technology, business process are biased to the people and activity aspect and business analyst are biased to the solution requirements derived from operations. What is lacking is a holistic approach that aligns all these perspectives.
SOC: So why doesn’t a machine view resolve the problem? All components have to be in place and that is what architects do.
VIT: It is one thing to have them all defined, but another to have them working according to expectations. Requirements have to travel from top level executives to designers and implementers. That is a process carried out by people, who believe it or not, don’t always communicate objectively or completely. They have different perspectives, different interests, and don’t always trust each other. Alignment is over-simplified when the social process and language control during the early phases of enterprise transformations are restrained.
SOC: Are you sure about that? Haven’t some consulting firms been practicing the social perspective for a while?
VIT: Yes and no. A few consulting firms did pay attention to the social process when working on business process re-engineering and large transformations. But while there was awareness of the concept of a social process, there weren’t any methods or processes to implement them. A gap still existed between the business consultants, enterprise architects and engineers. (And the industry will still wrestle with it as highlighted by Venkatraman 15 years after the referenced article was published.*)
SOC: Ah, apparently we need a role that captures the finesse of a business strategy, understands its implications for the internal context and communicates its needs to designers and other stakeholders in a controlled manner. In other words, we need a translator.
VIT: Correct. However, that is not easy. We need staff that is bi-lingual. They must speak the language of both business consultants and enterprise architects. In short, the gap still exists between business/ IT and strategy/operations. The problem is not resolved by just a socializing approach or just the enterprise architecture approach. The communication of business insights, business needs and solution requirements between different stakeholders needs socializing, language control as well as a mechanical approach.
So back to the original question: does IT need to understand the business? The answer is: no. IT needs to determine what solution requirements will fulfill the business needs. However, business needs are preferably communicated by business managers and this is not easy because too many managers are usually involved. Hence the business architect role arose to capture and communicate how business needs are related. This “broker” role seems justified. With it, and a more socializing process, the artificial gap created earlier can now be bridged. Since there was no stable, consistent language at that time, a formalized common language had to be developed to capture the business logic and business needs. This then enabled the ability to develop and communicate a comprehensive view of the implications of the strategic intent for business operations. The business architects have been developing this as part of their profession, and now they can declare they are ready for it.
SOC: Your logic is sound. Care to join me for ouzo and some nice kalamata olives? I’m fresh out of hemlock.
Let’s summarize as we bid Vitruvius and Socrates adieu. Alignment is a need since information technology arose. An enterprise architect is needed to investigate implications from the technology perspective. A business architect on the other hand is needed to assess the implications of the strategic intent for business operations. The business and enterprise architect talk the same methodological language and play a vital role when aligning business and IT in large transformation projects.
Here are the two litmus test questions when launching these projects:
- do business architects understand the business logic, and
- do your designers understand the input of the architects?
Positive answers to these questions will demonstrate the value of a common way of thinking and for using a common formalized language that the architecture approach provides.
The business architecture approach was the last missing piece for succcessful enterprise transformations. When all these elements are in place, the transformation capability can advance to the next level of maturity based on a standardized approach.
- HP Applications Transformation Solutions (website)
About the author
Harry Hendrickx, CTO / Enterprise (Business) Architect, Hewlett Packard Company
Harry is a recognized expert in the strategic planning of large enterprise transformations and governance. During his 26 years in the IT industry, Harry has held leadership roles focused on IT technology adoption, aligning IT with business operations, and business architecture and standardization. He is the author of articles and books on these topics and has presented his work at many international conferences. Harry has a Masters in Economics and a PhD from Tilburg University.