THE ANSWER IS 44 (warning: Strategy and Enterprise Architecture used in the same sentence)

It used to be 90. Then, 70. A year ago, it was established at 44. While this is not the answer to the Ultimate Question of Life, The Universe, and Everything, it’s still an important one: What percentage of business strategies fail?

A multitude of reasons and factors explain why strategies or transformational initiatives fail. For example, a long time ago Dr. Kotter found that shortcomings in defining and communicating a compelling vision, and mobilizing around the planning and implementation result in failure. More recently, Dr. Kaplan and Dr. Norton in their book Execution Premium, found that roughly 2/3 fail because a formal strategy execution process is missing. An Economist Intelligence Unit & PMI report from 2013 says the biggest barriers to successful strategy implementation are: The organization lacks change management skills, initiatives are poorly resourced, and the organization lacks project management skills. (They also found out it’s “44”.)

The recommendations from these studies urge  you to embrace a smarter and a more wholesome approach to the execution of strategy. Yet something is missing: a methodology that supports the connecting of strategy to the components of the execution. Let’s summarize from the learnings above and add the missing, connecting piece:

1. Adopt best practises. All of the proposed best practices and improvements are needed. Ensure your team cherishes competences and methods for communications and change management. No excuses allowed!

2. Get organized. For execution, a program office is needed as a mechanism of prioritization and implementation of projects. Also needed is a guiding process that integrates the typically separate corporate activities. This process should be clear to all parties from formulation to implementation.

3. Get systematic. A comprehensive approach needs to be supported by a methodology where things can be connected in a meaningful way: Enterprise Architecture. Yes, that thing that’s based on ancient cults of Zachman and TOGAF, and that uses a clandestine language of ArchiMate to explain, with a holy metamodel, how all things necessary in IT, business, and universe are connected. The novelty in EA is how you use it in a business outcome driven way. EA forces you to define strategy, and its goals with concrete targets. It can also provide transparency – an improved understanding of what can be achieved. Taking advantage of new technology can be enabled by using EA, and it also helps in closing the feedback loop on execution.

With these actions, I believe THE ANSWER will be improved. As my favorite aphorism goes: Current ways of working equal current results; New ways of working equal improved results.

Please comment: Did you already try it – what are your key learnings? What is you way of ensuring the implementation plans are aligned?

PS. Thanks to Gail Severini and others in Balanced Scorecard /Strategy Office Executives Linkedin group for throughly clarifying the topic.

Sami Lotvonen

• fi.linkedin.com/in/samilotvonen/

IRM UK EA/BPM conference - Achieving business outcomes with enterprise architecture a major theme in the event

Last week QPR sponsored IRM UK EA/BPM conference that took place on 16-18 of June 2014 in London. QPR’s UK reseller Performance Analytics joined QPR in the event to promote QPR’s comprehensive and innovative enterprise architecture (EA) offering. The event brought together both EA and BPM experts from several countries and provided a venue for excellent discussions and presentations.

QPR team in full action at the stand

A clear theme in the EA area was that EA should focus on delivering concrete business outcomes and provide value to the key stakeholders of an organization. This theme was strongly emphasized in the event key note speech “Who Cares?: Getting a Grip on your Stakeholders’ Needs and Expectations” presented by Roger Burlton from BPTrends Associates. Burlton highlighted that the starting point for EA and BPM efforts should be to look at the needs of the main stakeholders’ of the organization – such as customers, owners etc. – and focus the efforts on delivering value to them. Burlton also emphasized the importance of performance measurement as part of EA work to demonstrate the results to the management and highlight the results with visually appealing dashboards and reports. Other dominating EA topics in the event were the significant role of EA in business transformation and strategy execution, as well as business architecture, which had its own track in the conference agenda.

As usual, the discussions at the expo floor proved to be very interesting and QPR’s comprehensive and innovative EA offering created a lot of interest.  Notably, the QPR business driven approach to EA received a lot of interest among EA and BPM practitioners. This was a really positive sign, as typically the ideas of the methodology gurus presented in conferences are ahead of the actual, real-life practices in organizations. But this year’s IRM UK event indicates that the gap between business outcome driven EA and traditional IT oriented EA is narrowing, as practitioners also seem to be keen to adopt this new approach. Or is there still a clear gap? Thoughts?  

Tero Aspinen

Director, Partner Management

fi.linkedin.com/pub/tero-aspinen/2a/592/344/

How to get started with Enterprise Architecture? The topic of having common language and information. Part 2/4

One of the key things I have found most important when starting discussions around enterprise architecture (EA) matters is to communicate and understand people by using their own everyday language. Even if speaking the same language (e.g. English), it doesn’t necessarily mean people understand things the same way. One word written and spelled the same way can have different contextual meanings for different persons (for example, term ‘product’ might mean to a retailer the combination of the sales package and the stuff inside the box but for the manufacturer it might mean that the sales package is just the material part and the thing inside the package is the actual product). Therefore, you need to be able to define and explain a meaning of a word or a phrase using other words than the word or phrase itself.

Terminology can change depending participants of discussions. When asking ‘what do you mean with that thing’ or ‘what is your definition for that term’, I have found that there are no stupid questions when driving for common understanding between people. Therefore, when starting any kind of enterprise architecture related discussions or work, start it by creating a glossary of concepts and terms first, and also try to understand how different terms relate to each other.

After making that vital glossary of key business terms (data about terms and their definitions), create also a conceptual information model showing how terms relate to each other. Understanding the context how different kinds of terms and words are used in business and how they relate to each other is also the basis for the information architecture creation which is very important part of your enterprise architecture deliverables.

Since EA’s purpose is to create a systematic big picture of all matters related to an organization, using the language of the organization makes your enterprise architecture more understandable for everyone. When discussing with Enterprise Architects about enterprise architecture, there is a good chance we are already using a common vocabulary of EA methodologies, especially if architects are familiar with e.g. TOGAF or some other EA frameworks. But do not expect any other person than another Enterprise Architect to understand that EA jargon. Therefore, it is crucial to speak the language of the business.

So, if you are an Enterprise Architect, as a first thing you need to create a glossary of the business, learn the terms and adopt them by creating a conceptual information model of the key concepts and their relationships. That is also one of the most valuable enterprise architecture deliverables you’ll make and keep up to date. If you are a business stakeholder, help those persons trying to construct a business glossary since you’ll find it a very useful tool later on in your own work when discussing with people about your business.

Ari Anturaniemi

Chief Consultant, Enterprise Architecture

fi.linkedin.com/pub/ari-anturaniemi/3/572/a51/

How to get started with Enterprise Architecture? Part 1/4: Business

Enterprise architecture (EA) is a hot topic both in public and private sector organizations. One of the reasons why interest for enterprise architecture is rising, is that world has become quite a complex place. Complexity costs, especially unplanned complexity, and therefore many organizations are seeking holistic, and systematic thinking approaches to clarify and simplify things. The promise and essence of enterprise architecture is to provide that kind of thinking and a tool for business planning and management.

A problem many organizations face when starting enterprise architecture work is where to start, and how to get started? Here is my simple three-point starting list how to begin your EA work regardless of your role in that work:

1. Understand. Start to understand your organization’s business. Read annual reports, investigate operating plans and have a look at your organization’s strategy and goals: what value and mission does your organization drive for? Ask, discuss, and look for more information about how your organization does its business.

2. Communicate. Have a dialogue with business and supporting units. When discussing about business, use common business language. If you are not familiar with business language, you need to learn the basic terms related to your business. Discuss with business people what are their thoughts, concerns and worries about running the business.

3. Network. Discuss and share thoughts with people in your organization who are the customers and suppliers of your organization, and find out if there are other interest groups your organization is collaborating with. Analyze the value network of your organization. If you don’t know something, ask people who knows. People in your organization are surely willing to answer if you just ask.

No matter if you are CEO, CIO, Enterprise architect, IT manager or a line worker in your organization; the same list applies to you all. If you are a consultant trying to help other organizations, again, the same list applies. Capture all your learnings, and you have a good starting point to create your first EA deliverable called Business Architecture. So, start your EA work from the things that really matter, that is, business.
 
Ari Anturaniemi
Chief Consultant, Enterprise Architecture

fi.linkedin.com/pub/ari-anturaniemi/3/572/a51/

Who stole Enterprise Architecture?

Dear friends,

The term Enterprise Architecture (EA) appeared in the literature for the first time some 25 years ago. Enterprise architecture pioneers like John Zachman and Stephen Spewak linked the concept with a multidimensional and layered structuring of an enterprise, intended to satisfy the needs of the business. Since then, various frameworks have been introduced by different individuals and organizations, ranging from military and government to private sector. Practically all of them contain the basic elements in some shape or form: business drivers and requirements, information architecture, process architecture, application architecture, and technical architecture. The practitioners and standardization bodies are in violent agreement that these are all in the heart of enterprise architecture.

Given the above, one would assume that the concept and the term Enterprise Architecture would  be a stable part of common knowledge. I wish this was true, but the EA culture is suffering from unnecessary turbulence. There are individuals and organizations, acting out of ignorance or commercial interest, trying to introduce definitions and interpetations that are not adding value but rather distorting the picture and confusing those that are new to the topic. For example, some companies having a significant interest in the technology side of IT have advertised enterprise architecture as a big IT architecture. Having strong marketing muscles and excellent access to enterprises through their IT departments, they have created the confusion among their customers that EA is about IT only. If this is the first message that the CEO hears from the CIO about EA, the damage has been done and is difficult to repair.

The above is an example of twisting the meaning of an existing term. Another type of confusion arises from inventing completely new terms. This has been the core competence of marketing departments throughout the history. Marketing is seeking novelty, defining niches which then can be occupied, claiming to be the first or biggest in the recently invented niche. You can always define your own terms and concepts, and distract your customers from the competition. There is no need to have true novelty in your products or services, playing with words is enough. This is an old strategy: if you can't win on a level playground, try tilting the playground. Who cares if you do damage to your customers and to the enterprise architecture community.

Education, science, and language are part of our culture. As such, they are subject to the natural laws governing the eternal evolution of culture. Despite of this unavoidable evolution, we need to keep in mind that it is not random but is influenced by people. It does matter, where the evolution takes us and that we do influence it, when it matters. Concepts like business capability and enterprise architecture are purely abstract and artifical, but they are serving an important purpose for the enterprise management and should be engineered to serve that purpose effectively. Whether we can or cannot, is determined by the strength of the global community of scientists and practitioners driving the ontological process for enterprise architecture. New terms and concepts should be introduced cautiously, weighing their value and linkage to existing ones. New knowledge has value only if it can be put in the context of some existing knowledge. This way we can make sure that climbing the stairs of knowledge is not followed by falling down on our noses.

Enterprise architecture is not something completely new and isolated from other parts of management science. It derives from systems thinking for its philosophical part, and from systems engineering and economics for the methodological part. We need to protect it as the broad conceptual framework and foundation for defining, scoping, and positioning other disciplines like Business Modeling (BM), Operational Development (OD), Business Process Analysis (BPA), Business Process Management (BPM), Enterprise Business Process Management (EBPM), Capability Maturity Model (CMM), Six Sigma, Business Intelligence (BI), and Corporate Performance Management (CPM). None of these disciplines has the richness of semantics and structure to be used as a reference framework for the others. Enterprise architecture as a concept and discipline has these properties for the most part, and as for the remaining properties, let's make sure EA evolves to cover them as well. Starting from the scratch, with a completely new term and concept, is not feasible nor necessary.

Together we can catch and stop the term thieves!

Jaakko Riihinen
Senior Vice President
Products and Technology
QPR Software Plc

fi.linkedin.com/in/jaakkoriihinen/