Forrester’s Q2 2011 Global Current State Of Business Architecture Online Survey found that organizations are optimistic about the effort it takes to create a business architecture – overly optimistic. The prevailing view is that it will be significantly easier to create business architecture than it is to create enterprise technical architecture. A significant number of Forrester’s survey respondents – 63% – thought they would create the core business architecture in less than two years. They are clearly not taking into account the multitude of challenges that make building business architecture an arduous and time-consuming task.
I talk with business architects every day. Here are the types of challenges they tell me they are facing:
No standard tools or methodologies are available. Existing EA templates and approaches offer little value. Much of the BA’s work is exploration and innovation. It takes time to find the right path.
Business architecture has to be sold. The overwhelming majority of current business architecture efforts are not chartered by business executives. This means they must be promoted and sold. Additionally, business architecture is a complex product, and every sales professional knows that complex products have elongated sales cycles.
Multiple views are the norm. Business architecture artifacts are not one size fits all. There are many different viewpoints of business issues and opportunities, including strategy, capability, and process, among others. Business executives vary in their perspectives, so multiple views of each viewpoint will have to be tailored to fit the specific audience.
I am increasingly being asked the question: “What tools are business architects using?” My answer is short but not very helpful: “Microsoft Office.” In a recent Forrester survey of more than 250 organizations, 80% of the respondents said they used PowerPoint, Excel, or Visio. Thirty percent or less also use a variety of other tools, including the typical EA tool suites and process modeling tools.
My question to the business architecture community is: “What kind of business architecture tools do you want?”
Here are a few attributes to spur your thinking:
What business architecture elements do you want to manage: goals, strategy, capabilities, processes, services, organization, etc.?
How would you like to see the tool packaged: totally integrated (one tool does it all), separate components, integrable modules?
How important is it that your business architecture tool integrates with the more technically focused EA tools?
What kind of platform do you want your BA tools to run on: desktop, server, cloud?
How would you like the pricing structured: one-time purchase, lease, SaaS model?
In preparation for our next EA Forum, I have been doing a lot of reflecting lately about the state of EA and what it means as we move forward into business architecture. And frankly, I don’t like what I am seeing – or more accurately, I don’t like what I am thinking. It seems to me that we are stuck in an outdated – and I will go out on a limb here and say not very successful – paradigm. So what is a paradigm? In this case I am referring to our thinking paradigm – the model in our brains that structures the way we think about EA. Our paradigms represent the “box,” as in thinking inside the box. When we are thinking outside the box, we are essentially trying to create a new paradigm – or thinking model. Paradigms are very powerful. That is why it is so difficult to think out of the box for any extended period of time. Here are the six elements that I see very consistently in the thought patterns of EAs:
Governance – Mechanisms to approve EA designs and enforce adherence to the reference architecture at the project level.
Principles – Decision filters that both EA development and application decisions flow through.
Current state – A snapshot of current issues and technology baseline (often in significant detail).
Reference architecture – The body of work describing EA’s intent, organized in a framework, expressed in strategy, standards, patterns, guidelines, etc.
Target state – An idealized future state viewpoint describing how the organization desires to change the current state based on the current understanding of technology and architecture.
If you have an enterprise or business architecture marketing program or well-defined marketing methodology, Forrester would like to talk with you about a potential case study.
I am initiating a research project on marketing the enterprise architecture (EA) and business architecture (BA) practices. This research will examine how EA and BA practices are promoting their value to their IT and business constituents and explore the best ways to engage and influence architecture’s stakeholders. This research aims to illuminate best practices that can guide enterprise architects in designing a marketing program that can successfully engage the larger organization and develop support for EA and BA initiatives.
The questions this research will answer:
What are the factors to consider when developing a marketing initiative?
What are the typical goals of EA and BA marketing initiatives?
What marketing approaches work best?
What types of marketing artifacts resonate well with stakeholders?
Who are the best targets for a marketing campaign?
How do you know if your marketing efforts are paying off?
If you have a good story about your marketing practices, please contact Kim Naton at firstname.lastname@example.org.
Or - if you just have a good marketing idea, leave a comment.
I want to introduce you to a book that will change the way you manage meetings and make collaborative decisions: Six Thinking Hats by Edward de Bono. One of my CIO clients told me about this book, and I bought it used on Amazon for $0.01 (plus shipping and handling of course) – now that is a deal. Though I can’t see sitting in a room of business executives and saying “Now everyone put on your white thinking hat,” this book presents a very clear explanation of why our typical “everyone present their viewpoint” type of discussion is so dysfunctional. The problem is that people come from different perspectives, so we end up arguing apples and oranges. Six Thinking Hats lays out a process where everyone can get their position on the table in a way that encourages a more holistic look at the issue and results in fewer arguments and more discussion. Here is how it works:
During a problem-solving session, the facilitator solicits input from six different perspectives. The key is that while the group is thinking in a particular perspective, only comments that fit that perspective are allowed. The six perspectives are:
White hat – An objective look at the issue based entirely on facts and figures. This thinking type focuses on what we know or at least on the best information available. This type of thinking often dominates most IT discussions.
Red hat – Provides the emotional view. Data and reality don’t matter. Everyone gets to talk about how they feel about the issue. What I like about this perspective is that it legitimizes what people are feeling. They don’t have to defend their position with data. To me, this is the most often ignored perspective in IT discussions.
Black hat – This is the devil’s advocate viewpoint. The focus is on issues, challenges, roadblocks, and anything that can go wrong.
One of our client consultancies recently raised an issue about using the name “Enterprise Architect.” Many of their clients, particularly on the business side, didn’t understand the title unless a lot of context was included to help explain it. While I think most IT types have had enough exposure to EA to understand what it is all about, this isn’t true on the business side. Even though the name might be the industry standard and reflect (to some extent) what we do, if it takes explaining then maybe it isn’t the best name.
I do think it is the “architect” term that is the main problem, but “enterprise” anything has also left a bad impression with some companies – and really, what does “enterprise” mean anyway? Who else uses that term in their title? Finance and HR operate exactly the same way as EA – they have enterprise accountabilities – but don’t have enterprise in their titles – or at least I haven’t seen it yet.
Additionally, when I work with new EA programs, I frequently find that they are in their third, fourth, and sometimes fifth iteration of building an EA practice. Often there is a negative connotation around the EA term built up from past failures. These clients also would like to use a different label for enterprise architects.
Forrester sees EA as primarily a strategy function. It can be focused on business strategy, technology strategy, or both depending on the organizational approach. In a recent client session we brainstormed a number of different names for the enterprise architect including: IT Strategist, Business Technology Strategist, Enterprise Strategist, Corporate IT Strategist, Corporate Business Technology Strategist, Enterprise Alignment Consultants, and Enterprise Strategy Consultants. We also came up with a similar series of names replacing strategist with advisor.
I was introduced to the term “eat your own dog food” many years ago by a Microsoft project manager who pointed out that if you don't use your own products, maybe you should think about working for someone else (some of the best advice I ever got from Microsoft). Some years later I was teaching an EA leadership class in Sydney and used the “eat your own dog food” metaphor. A very indignant architect stood up and with great flair said: “Man, we are enterprise architects! We slurp our own caviar.” Well, whether it’s dog food or caviar, if you build it you should use it. The problem often isn’t that we don’t want to use our own products; it is that we are so busy trying to get everybody else to use them that we just don’t think about it.
I just published a report titled “Use Business Architecture Tools To Align EA With The CIO’s Agenda.” The genesis for this research was the realization that EA teams, along with many other organizations, don’t do a very good job figuring out what their bosses really need from them. And architects, unlike other organizations, have all the tools and skills they need at their disposal. So here are my four simple steps to better alignment with your CIO:
I recently led a workshop with 35 clients from a variety of industries to uncover the challenges they face in their business architecture efforts. Through brainstorming and breakout discussions, the group created more than 160 individual challenge statements. In subsequent analysis I was able to identify 14 unique challenges in three major categories: EA skill/capability, organization/culture, and support/resources.
Here are the challenges I identified:
Lack of business skills in the EA team
No proven BA methodology to follow
Low EA visibility/credibility in the business community
Poor business-IT goal alignment
Gatekeepers protect their business relationships
Business units plan and work in silos
A culture of change resistance
Tactical business focus
Lack of clearly articulated business strategy
Lack of executive sponsorship
BA’s value proposition hasn’t been established
Lack of funding for BA initiatives
Concern over impact to other initiatives
Management puts a low priority on BA
Fourteen challenges seem like a lot to deal with (and I am sure there are more). But as I looked at the list I realized that these are not unrelated issues that can be solved independently but in fact are clearly structurally related. For example: A lack of funding can only be solved when you have a compelling value proposition, which can only be created when you have demonstrated value in some way, which can only be done when you have the right skills and capabilities. A general model of the relationship is below. I know most of us would like to start with funding and executive sponsorship, but it just doesn’t work that way.
One of my current research projects is to define how EA teams capture and express business strategy. Early in the process I am finding a lot of variation in how organizations articulate strategy. In my preliminary interviews I have heard three basic definitions of strategy:
What is the key to effective enterprise architecture? In a word: influence. I rarely see an EA team that can’t build a reasonably good architecture, but I also rarely see an EA team that can successfully drive support for even the best of architectures. The most elegant architectures are worthless unless they are widely adopted and utilized. We don’t need more elegant architecture models; we need more eloquent architects.
Over the past few years I have asked hundreds of architects two simple questions. First: “What is more difficult - building architecture or implementing architecture?” Every single architect without exception tells me architecture is much harder to implement than to build. My second question is more telling: “Where do you spend the majority of your time?” Their answer: “Building architecture and my architectural skills.” Even though EAs clearly understand the problem, they don’t address it. Why is that? I think it is because deep down inside, they don’t want to.
Building organizational influence is long and difficult work. It requires an entirely different skill set than architecting. The focus is on people and relationships rather than technologies and concepts. Most architects don’t feel comfortable here. Instead of acknowledging reality and dealing with it, often architects try to avoid it by putting the problem on someone else’s back. “EA can’t succeed without executive sponsorship.” “Someone needs to give us more authority and control.” The fact is, very, very few EA teams actually get anything close to this. The majority don’t even get significant support from their CIO. And yet, somehow, many succeed. How? By building personal and organizational influence. The bottom line to EA success is organizational impact. How much are you having?