Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

Does IT know what our business is?

Vitruvius.jpgBy:  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:  

  1. align business strategy with IT strategy and then with IT operations;
  2. align business strategy with business operations and then with IT operations; or
  3. 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:

  1. do business architects understand the business logic, and
  2. 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.

 

 

References:

*   John C. Henderson, N. Venkatraman: Strategic Alignment: Leveraging Information Technology for    Transforming Organizations. IBM Systems Journal Volume 32, p 4-16 (1993)

 

Related links:

 

About the author

 

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

Comments
leroymason | ‎03-07-2013 09:48 PM

Harry, thank you for a very entertaining and informative article. It is important for contemporary practitioners to realises the heritage of the problems we are still dealing with. As you indicate, this problem was defined back in 1993.

 

In many ways the difference between business and IT reminds me of the difference between phyics, chemistry and biology. Physicists assert the true of the second law of thermodynamics but this means the subject matter of biology should not exist. That is, organisms continually subvert entropy.

 

What we need is a theory that encapsulates them both. Recently I've been looking at Prof Steven Alter's Work Systems Theory and while not complete I consider it the best ontology I've seen so far. I would be interested in your thoughts.

Hendrickx(anon) | ‎03-08-2013 08:53 AM

Hi Leroy,

 

Thank you for your comment. You triggered me and I just had a look at one of Steven Alter's articles on the chasm between socio-technical and technical systems, and his approach to modeling working systems. Indeed this comes close to what I believe is necessary to develop sound systems: capture, understand and communicate the relation between intentions, structure and resources.

 

Although I need to dive into this are some more, my first comment would be not to consider the technique only, but also develop a role and way of working how to apply it in practice. Hence the focus of my BLOG on socializing, controlled language, communication and managing the stakeholder involvement.

 

Harry

Roy Woodhead(anon) | ‎03-13-2013 05:02 PM

Hi Harry,

 

Like your diatribe (This is how pre-Socratic philosophy was carried out (;-)).

 

The assumption I would also question is, "Does the client know their own Business?" In my consulting experience client organisations are also trying to make sense of the highly dynamic market-environments and so it is a lot more ambiguous than many people imagine.

 

Vitruvius is a name that was found on a pattern book from which classical architecture sprang; not sure if much else is known about him and so for me he is not such an interesting character in your mini-play.

 

Socrates on the other hand is. He encouraged 'dialogue' a form of purposeful enquiry with the sole intent of building deeper understanding. Now this approach could help IT if both IT and the Customer suspended the usual 'selling' and 'buying' postures and actually had an 'enquiring' conversation about how IT could give the client a competitive advantage (i.e. outcome focused).

 

Such would close the gap you point to. So for me, it is a question of organisational-attitude, willingness to listen and learn and willingness for both clients and IT to create value without trying to takew advantage of each other (Think Nash Equilibriums to see the sense it makes). 

 

Guess new attitudes is easier to call for than to change (;-)

 

Great though provoking Harry !!!

 

Best wishes

 

Roy

 

Harry Hendrickx(anon) | ‎03-14-2013 09:44 AM

Hi Roy,

 

Thank you for your comment on this blog. I fully agree with your observations. If we would proceed this conversation I would emphasize that the dialogue between business and IT is the playing ground of the business architect.

 

As you indicated it is a real challenge to organize or trigger that dialogue. With the approach of the business architect I had very positive experiences over the past 15 years. Hence I like to state that the business architect has the potential to "bridge and drive the business IT dialogue". His profession is to capture business strategy and identify in a systemic way the implications for business operations. Thus, he often adds value to stakeholder's own understanding of their business, and in a more holistic way.

 

It might be valuable for HP to pay more attention to this space in the business development lifecycle. Especially in the mobilization of large enterprise transformations the business architect discipline is quite valuable.

 

HP's challenge is how to integrate this in their business.

 

Harry

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation