Day: February 12, 2013

My last posts have been very much focused and following a red line, so now I am trying to pick up some loose ends. There is one thing which bugs me quite often when I am doing Enterprise Architecture work. There is way to much focus on talking about Enterprise Architecture. Something which is also reflected by following twitter post:

I suspect that the primary job role of Enterprise Architects is to argue with other EAs about what #entarch is. Prove me wrong, people.
— Kevin Brennan (@bakevin) 7. Februar 2013

My personal observation is that Architects actually discuss about Enterprise Architecture, but do in most cases not argue. This is a differentiation I find very important, because an argumentation chain would at least provide a red line why one approach is chosen over the other. By looking at the pure amount of frameworks and tools in the market and the amount of new players entering that space it is quite obvious that Enterprise Architecture is at the moment in a hype or fever situation. This can easily lead to total irrational decisions. On this topic I recommend to take a closer look at the Tulip Mania, some of the behaviours might also be seen in more recent crises.

Here (as mentioned before) I use GLUE as mapping tool for me. The real most interesting (and relevant) question for me always is: Where is a person stuck in the GLUE circulatory system.

And then I try to go into that position, placing myself onto the seat of that particular person to understand where the missing links are. If I manage to understand a portion of it I try to show the traces by using whatever terminology is approbiate for that particular person. Not GLUE, not a specific framework, but whatever language element helps. Sometimes indirect communication by others is the only way to succeed, sometimes I need to play over time. Invest today, harvest in a couple of month when a small trigger has grown into something powerful.

In most cases showing the connections to other information streams (in the circulatory system) allows the person at hand to see some possible answers to concrete problems which have not been solveable before. And there is one thing I know, then it is that I do not know anything, but what I know is that I am an Enterprise Architect. So in most cases I have literally no chance to give a correct concrete answer even though I am fairly often asked to give one, but I am able to help the information flow, to unblock the thinking, to link elements. There is my focus and that enables others to bring their great knowledge to the game and solve problems I would not have dreamt of being solved.

A key ingredient to achieving Business and IT alignment is the development of a common lexicon that all parties can use to describe and manage change.  This sounds like a fairly simple requirement, but in practice it can often prove to be difficult.  Your enterprise has this problem if you hear comments like these:

• “We aren’t all on the same page in describing the business and its needs.”
• “We have difficultly having fact based conversations about priorities.”

I’m reminded of the quote from “Cool Hand Luke” in which the Captain says to Luke “What we’ve got here is … failure to communicate.”  We do have a failure and if we can’t overcome it then all our efforts are going to be for naught.

Why do we have this problem?   Many times those of us in IT exhibit too much “inside out thinking”.  We speak of services we deliver to the business.  We speak about applications or technologies or architectural domains.  This terminology is ours and it is effective when we speak amongst ourselves, but it is ineffective when we need to communicate to business leaders.  Our customers are not going to change so in this case we are going to have to “go to the mountain” because the mountain is not going to come to us.

So what language do business leaders understand?  At Troux we have found that having a discussion with the business about “portfolios” is much more productive simply because it uses business language.  To that end we find that describing the enterprise as a set of interconnected portfolios greatly facilitates business conversations.  In fact, an “enterprise portfolio management” approach has direct analogies in to classical investment portfolio management.  Investment portfolio Management is defined as “The art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk against performance.” ¹ Likewise, at the end of the day, managing the enterprise is also about making investment decisions to manage risk and improve performance. 

Simply put business stakeholders understand what the business does and what the business does can be described in Business Capabilities.   Don’t confuse business capabilities with business processes, which are a description of “how” things are done.   And don’t think that you are speaking the language of the business when you only speak of organization structure.   Organization structure is important but as we all know it is subject to change fairly often whereas business capabilities remain a fairly stable, albeit abstract, description that establishes a commonly understood business context.  It’s worth noting that Forrester Research speaks of them as “The Rosetta Stone.” ²

Let’s consider an example — in this case we know for a fact that a set of applications need to modernized as they are implemented on obsolete, unsupported technology and have security risks.  One approach would be to propose a project to improve our technology architecture domain that will result in improved business services.  Depending on whether or not our customer understands what we said, that project may or may not easily get approved.  Now consider a different proposal: “Our business capability for customer provisioning is at risk because we have under invested in our technology portfolio.   We propose adding this project to our investment portfolio to reduce risk and improve performance of this key capability.”   This is the same proposal but will very likely yield different results, because we changed the nature of the conversation.

In practice, business capabilities can make the complex simple and enable what we at Troux call “fact based conversations.”  For a discussion of practical applications of business capabilities, attend our upcoming webinar “Speaking the Language Of The Business”.  You can register here.

[1] http://www.investopedia.com/terms/p/portfoliomanagement.asp#axzz2Jacaoaej

[1] “Business Capabilities Provide The Rosetta Stone For Business-IT Alignment”,  July 06, 2009, By Jeff Scott with Alex Cullen, Mimi An