Coherency Management

What is coherency management?

Coherency Management represents a significant point of evolution in the design and management of all enterprises. It is about using Enterprise Architecture (EA) and other disciplines to advance alignment, agility, and assurance in highly dynamic organizations that sometimes have chaotic operating environments or work in complex contexts. The essence of the concept is that all enterprises have a multitude of processes that document what the organization is doing, how it is doing it, and why. In addition, there are usually documents that say what changes are planned including short and long-term targets. All of these things can be considered an organization’s architecture and they need to (gradually) become consistent, structured, formalized, and used to attain coherency. The best way to do this is to adopt Enterprise Architecture as the ongoing, overarching method for describing, abstracting, analyzing, designing, and re-engineering new and existing enterprises – regardless of the market, industry, or government sector. When combined with ideas of Risk Management, Change Management, Strategic Planning, and others, it is about EA becoming pervasive and allowing us to explicitly manage the Coherency of an Enterprise instead of dealing in anecdotes and indicative measures.

Where did it start?

Coherency Management as a practice within EA originally started as an exploration of what we at first were calling EA 2.0. Like many around us, we knew EA had the capability to fundamentally shift from EA with an IT heritage to EA with a whole of business approach. As we explored the ways we saw it changing we realized some important things:

• There were distinctive (and classifiable) ways EA was being done. These became the three modes of EA.
• There was preexisting processes and process owners that were writing and maintaining artifacts that (if properly structured) could be integrated in to the holistic Enterprise Architecture.
• Once the key process owners joined in on the effort we could achieve alignment, agility and assurance. We could employ scientific principles to ensure we were doing things right and doing the right things and we could manage against a coherency objective.

The practices, tools and ideas found in coherency management that allow us to improve enterprise function are not invented by the new practice. The practice simply knits them together, makes certain objectives explicit and allows us to manage against them. So, one could say the ideas of Coherency Management started once people began to implement the ideas of Enterprise Architecture.

What in the enterprise has to be coherent?

The ultimate goal of Coherency Management (CoM) is to have an enterprise which functions coherently in everything it is doing. This means that management is being performed coherently but, more importantly, it also means that the policies, services, processes, solutions, reports, plans, and operations of the enterprise are coherent. Of course, this might sound like too immense a task to attempt so the Coherency Management Operation Framework within the CoM Practice describes how this can be introduced gradually without great expense. There is another, less discussed aspect of coherency and that is the external view. If you describe and analyze your customer base, partners, providers, etc with the same models and standards as you use internally you will have an improved ability to meet the needs of this external community. It allows you to deal better with things like Mergers & Acquisitions, collaborative efforts, shared tasking, etc. The book presents and elaborates the five dimensions of organizational coherence, which are: Organized, Consistent, Connected, Institutionalized and Designed; along with the guiding questions to assess the extent and nature of coherency.

Finally, with CoM being done internally and being leveraged externally you will also be able to answer questions like what capabilities do I have internally that can be leveraged to meet external needs. (e.g. exposing corporate services as client services.)

Why do this?

Most organizations have some degree of overlap in their programs, business lines and services. Coherency Management can help you find and correct these errors. As we say in the book:

If you:

• feel stifled by indecisiveness and consequent inaction;
• are tired of duplicate or wasted effort;
• feel you manage in a knowledge vacuum whilst being surrounded by information;
• can’t get your organization to respond to challenges quick enough;
• haven’t got enough time to process all your information; and
• would like to know you if are doing the right things and doing things right

… then this book is for you because incoherency may be the root cause of your problems. With Coherency Management we are beginning to understand that now, and we believe this is just the commencement. A named practice will bring together related work that will allow us (as a profession group) to advance to cause of EA and in particular CoM. The time is now for us to standardize and cooperate in the development of a practice.

Why must organizations be coherent? What happens if they are not? Aren’t you just coining new terms and phrases for future generations to accept to give yourselves lasting value? How is this different from what has been done before?

Coherence is the only way to manage complexity and lead change. Usually, the size of an organization is inversely proportional to its coherence. Coherent organizations will have, by definition, less waste and better service but you need a practice to ensure you actually manage it and to be certain that your coherency is real. The collection of the elements we discuss has not been done before and we also have a new way for describing some of the items because the practice introduces specific activities to help attain better results. There are easier ways to create a legacy than trying to change 30 years of direction within a discipline and asking autonomous business function to participate in standards, which causes them to lose some degree of power and control. We have taken this on because it was necessary, not simply a potential source of revenue. We’re asking for the community to collaborate on extending and amending the elements of the CoM because we believe there is something big here.

In some respects this is a collection of things that have been done before but they are assembled in together with additional ideas and concepts to give us something new. Some noticeable differences are:

1. This recognizes that for any enterprise the enterprise architecture has always existed and is being done by a lot of people not traditionally considered as contributors to the Enterprise’s Architecture. However, the artifacts being created do require a lot of work to become coherent.
2. It makes explicit the three modes of EA and allows us to develop discrete activities for advancing each mode.
3. It introduces a practice of continuous improvement to assure the level of coherency across the entire enterprise over time.
4. It introduces the idea that EBA for the sake of Foundation EA is different than EBA done for Extended EA. This distinction is critical for Coherency Management because it underlines that purpose matters when doing EA.

Coherency Management may sound like a buzzword but it is NOT a fad. Certain elements of EA and other parts of CoM have actually been in place for several years. With the release of the book, we intend to formalize it as an area of practice and management innovation. There are organizations which can be considered ‘coherent’, but that is more likely an outcome of outstanding leadership and management. Our intention is to define and provide the means for organizations to be coherent, so that there is structure and method to it.

Isn’t it just alignment?

Alignment is certainly a necessary element in coherency and, at first; we thought this might be the enough to explain the types of benefits we were seeing in our research. As we began to understand how EA was helping in terms of providing assurance to professionals like auditors and evaluators we say something more than alignment. We also saw examples of well-aligned organizations being unable to respond quickly to new circumstances or provide coherent information about them. It is akin to the idea that two service lines might be perfectly aligned (i.e. no gaps or overlaps) but because of basic design structure differences they would be unable to come together easily on a shared service because their service boundaries (inside their organizations) were different. So simply put, things can be aligned although not achieving the agility we consider when we talk about coherency. The enterprise design has to be complete and true to purpose as well as based on common descriptive/design constructs in order to be coherent.

Is this being done anywhere right now?

During our research we saw many elements being practiced in various enterprises, mostly within the EA discipline, and we’ve presented chapters to capture that sense of variety. However, we are proposing a named practice to knit these things together with a different focus and different model than we’ve been able to see before. It is fair to say that there is probably not a single organization doing all the things described in the book but certainly there are many organizations engaged in multiple aspects of CoM.

It sounds bigger than EA. Is it?

Not really, if you look at what EA could achieve, but if you mean EA from an IT-discipline perspective then CoM is indeed bigger. Our decision to name it as a practice within EA is due to our belief that EA can act as a service to all other aspects of the enterprise. In Chapter 20 we allude to the possibility that this could begin to prosper as a partner to EA, but that largely depends on how we roll it out, for example, within the measurement model we are developing there is this question whether we incorporate principles and practices from risk management or simply pursue changes with the risk management community to incorporate coherency risk. Depending on how questions like this gets resolved, CoM could easily remain a practice within EA, or evolve into a distinct discipline, but our preference is not to introduce CoM as a new overarching meta-framework for the enterprise, because EA should be in that position.

The definition of EA in the book does not have the word ‘technology’ in it. Is this too far-fetched given the current state of practice?

For long, EA has been an end in itself. The traditional approach has been to define the target architecture, and a series of projects (as a transition plan) to reach the target architecture. However, with this approach the EA community has had difficulty convincing the executive leadership of what their role actually is. Based on our own research we discovered that there is a general realization that EA has to play a much bigger role in the organization. A role where EA is viewed as a means to something more critical. We believe that if EA has to be the ‘architecture of the enterprise’ its role and influence has to go far beyond its traditional IT centric approach. While IT would continue to remain an important factor, we also see that business-IT alignment as the primary reason for EA will continue to fade. Some people believe that the greatest degree of misalignment does not occur between business and IT, but rather between different functions of the business. For e.g. misalignment between marketing and sales; finance and HR; marketing and HR; sales and operations etc.).

As stated earlier, the book represents a significant point of evolution in the design and management of all enterprises. The intention is not to capture the current state of practice in EA, but provide directions into the next generation of EA. We strongly believe that the definition of EA provided in the book, reflects how EA is going to evolve over the next five to ten years.

What is the contribution to EA?

The book gives shape and form to something many of us have talked about for some time, namely that EA can help the entire enterprise with their planning, design, operation, efficiency, etc. It is also a wide sample of cases and thoughts reflecting the variety within the EA discipline it self, thus helping define the scope of the EA BOK. Ultimately, the message is that we must ensure that enterprises are well architected. A major contribution to the advancement of EA is that we explicitly call out to the other management areas (e.g. Accounting, Financial Management, Human Resource Management, etc) to be very active participants in the creation and maintenance of the Enterprise’s Architecture. This also includes the standards which underpin the entire organization in terms of description and design.

What are the three modes of EA? Are they mutually exclusive?

EA is being practiced quite differently around the world or across the street. In our experience and research we’ve determined that there are three basic modes of EA.

• Foundation EA: The most common and classical form of EA is what we call Foundation Architecture. The EA (in this case) is to create an enterprise-wide technology design and (in more advanced cases) to create Enterprise Business Architecture to capture the business requirements precisely. Often, this form of EA can be seen as helping Business to IT alignment. Foundation Architecture can be seen in the most widely accepted definition of EA provided by Ross, Weill and Robertson where “EA is defined as the organizing logic for an organization’s core business processes and IT capabilities captured in a set of policies and technical choices, to achieve business standardization and integration requirements of the firm’s operating model”.
• Extended EA: Extended Enterprise Architecture came about in the late 1990’s and focused on engineering an entire enterprise from integrated strategy, business, and technology perspectives. To support this expanded view of EA, a number of approaches and tools were developed to provide standardized, repeatable methods for describing an enterprise in all dimensions – beyond just the IT perspective. Whereas Foundation Architecture used architecture methods and tools to capture business requirements in order to design better IT systems, in the extended approach, architecture methods and tools capture strategic goals and related business requirements in order to design the enterprise.
• Embedded EA: In the Foundation and Extended modes of EA, artifacts (various types of documentation) are created as the result of an EA process or method, somewhat extraneous to the functioning enterprise. But what if architecture tools, methods, and models became embedded in the normal (usually existing) processes of the day? We call this Embedded EA, where the architecture, rather than relying on processes and people extraneous to the business programs (and their processes), is produced by the processes themselves. In this way the architecture is organic and ever greened naturally.

Balanced Architecture is a term that we use to describe when an enterprise utilizes the best and the most appropriate characteristics of each of the three modes of EA. A perfectly balanced program is unlikely to exist as of yet but there is definitely activity in all three modes around the world.

The three modes are not mutually exclusive; neither do they represent stages of architecture evolution and maturity. In fact most organizations are likely to have an eclectic mix of all three modes, albeit to different levels of evolution and maturity. A fully coherent organization will have a balanced architecture.

In the ‘embedded mode’ chances are that most (if not all) architecture artifacts will be developed by line-managers and specialists themselves. Are we then relegating the role of the enterprise architect to a support function?

Not really. In reality, in the embedded mode the role the Architect elevates to that of an organization design leader and mentor. At the operational level, architecture artifacts are best produced by people who do the work. For instance, if the need to create business process models, it is best created by the respective process owners and process managers. In the embedded mode the role of the architect will be to develop policies, frameworks, methodologies, standards, ontologies, rules, structuring approaches and alignment mechanisms, so that the business process models produced are:

1. Designed using organization-wide rules, standards and notations;
2. Organized along the defined categories and groups;
3. Consistent by way of how they have been developed and communicated;
4. Connected to other architecture artifacts that are influenced by and influence the artifact in consideration; and
5. Institutionalized across the organization so that every part follows the same rules, standards and notations.

To summarise the role of the architect would be to ensure coherence across the organization using EA as a means to achieve the coherence.

Architecture must be done by a core group of architects (and not by everyone). What is your take on this?

In a small organization this might well work. In a large organization, this is a fading model. It is just not feasible for a core group of architects to conceptualize, develop and manage all of architecture and its concomitant artifacts. One of the primary reasons many EA programmes fail is because the attempt to repeat what has already been done in a different way. There is a very great possibility that this approach of ‘the-architect-doing-it-all’ will stamp on others foot, thereby creating unpleasant situations.

We strongly believe that the architect has to eventually operate from the perspective of being able to leverage on existing content and artifacts. The role of the architect will be to develop policies, frameworks, methodologies, standards, ontologies, rules, structuring approaches and alignment mechanisms, so that all existing and new architecture artifacts are coherent leading to organizational coherence.

Is EA morphing into an over-arching meta discipline that includes every important aspect of the organization?

Yes, we are starting to see this realization seep into the organizations. Most organizations have a plethora of programmes and practices running concurrently. Some key ones are Balanced Scorecard, Business Transformation, Six Sigma, Business Process Management, Knowledge Management, Service Oriented Architecture, Grid Computing, and Standardization among several others. Each has its own group of proponents and enthusiasts and often done by different groups of people. They often compete for resources and management attention. Done rightly, each has its benefits. However as a group of programmes which tend to have competing goals and objectives pulling the organization in different directions, the net result is often disappointing compared to the overall potential. This creates cynicism to any further intervention mechanisms. During our research we discovered, it is dawning upon organizations that EA has the potential to be over-arching meta discipline that connects all such individual programmes into a coherent whole.

EA is still not yet common parlance in the business community (e.g. MBA curriculums). Is this an attempt to do so? Aren’t there competing approaches / ways? Has there been any traction from the business community?

We agree that EA is still very technology centric and not yet common parlance in the business community. Having said that, we also see a few leading business schools in the world have included or are planning to include EA in their curriculums. There is still a long way to go, but the start is encouraging. Furthermore, as Governments have been playing a leading role EA adoption, public administration and public policy programmes are also starting to incorporate EA. Since Government EA is a critical success factor for E-Government programmes, senior and executive leadership from the Government / Public sector are becoming increasingly receptive to the idea of EA as a means to move towards connected government.

Is coherency management a product or a project? Can it be quantified and measured?

Coherency management is not a product. Although there are several legitimate EA products, they do not yet include explicit change to accommodate Coherency Management. Coherency Management itself is not a project per se. It is about continuous change, over time.  You can have a project to create the initial program office and operational model of Coherency management but you do not per se have a project that makes your enterprise ‘coherent’. That happens gradually, over time. This is reflected through the Coherency Management Assessment Levels provided in the book. As a continuous effort, organizations would usually traverse the following stages: Absent, Introduced, Encouraged; Instituted, Optimized and Innovating.

There is work underway to develop a model to measure and evaluate coherency within an enterprise (or across multiple). There are several key dependencies and challenges to resolve as part of the effort (e.g. what method for ensuring all investments are comparable – function points? Service (a la SOA), etc)

How do I get started? How can the ideas and concepts in the book be realised?

By reading the various ways the Enterprise Architecture is being applied you can form an opinion of what you think you need most in your organization. It would nice to have a simply one size fits all solution but the reality is that organizations can have widely different priorities, problems and environments.

For the CoM specialist there are, however, some basic places to start such as:

1. Get training in EA. There are plenty of good schools but not everyone is yet teaching the ideas of Coherency Management. The major difference is that schools still teach the idea of ‘doing the EA’ instead of ‘finding the EA’ which is being created by others and aligning it. Most schools also don’t teach the idea of a practice which focus on how coherently an organization is operating. Still the EA training is required so you can enter in to the conversation of coherency management as a practitioner.
2. Understand where your organization is in relation to the three modes of EA and develop your personal action plan.
3. Use the Coherency Assessment Framework Metamodel to establish a plan of attack for where you need to address coherency most urgently.
4. Use the Coherency Management Operation framework and adapt it to your context.

If you are a businessperson wanting to benefit from coherence your first step is different that the specialist that might be charged with implementing the ideas of Coherency management. You will need to do whatever you can to push the idea of standard approaches and the ability to have working artifacts that contribute to the creation of Architecture for the enterprise. This means getting to the CEO. It does not mean that the CIO cannot provide the service but the CEO must understand that it is a service being offered by the CIO without an IT bias. For example, the CIO can have a normative model based on outcome logic modeling for the sake of developing policy.

Is coherency a plausible goal for organizations new to EA as a practice? Does this make ‘coherency’ more difficult?

CoM without EA is a little like putting the cart before the horse at this time. You need to understand certain principles of EA before you can embark on CoM. Perhaps, this could change in future but at this time that would be difficult. So, it is a good idea to have some degree of expertise in EA as you begin.

Is coherency management an expensive endeavor?

If done properly and incrementally, we believe costs can be managed quite well. We are essentially borrowing ideas from several other disciplines that were in the mix before we introduced coherency management. Therefore the cost is not all ‘net new’. But there is a need for some of the incremental elements.

Where can I find experts in coherency management?

There are many experts in EA around the world. Refer to the authors of our chapters for a small sample of the expertise available in the various parts of Coherency management. Again, it is unlikely that you will find dedicated Coherency Management ‘experts’ for some time but you will gradually see it introduced more and more. Right now our focus in on co-creation. We need people to participate in the development of the ideas so that we achieve the most possible with this very new idea.

Are there any training programmes available that can help me get up to speed?

There is training available in the supporting disciplines of Coherency Management, most predominantly Enterprise Architecture. For good training in this regard, look for programs, which emphasize a broad range of application. This means that in addition to the normal training involving things like the Zachman Model, the specific EA Frameworks and EA Method also ensure you getting training on how EA is being used by non-technology managers to aid in their designs and decisions. Check our links page for training that we’ve seen or done that we think would be worthwhile. Training in the specific frameworks, models and tools of Coherency management discipline are still being created.

Is there any follow-up work coming along in the near future?

There are several follow-up activities already planned. The significant ones include:

• Collaborative Development: The book simply introduces the concept of Coherency Management. The frameworks presented are initial models based on our research and beliefs. This web site is a opportunity to help define where this goes. We will continue to develop these ideas and apply them in our endeavors but only with broad participation will we be sure we are on to something enduring.
• We’ve been contacted by a leading management consultancy firm to Development a 30-40 page executive précis, to be distributed to global business leaders, with the aim of delivering the message and its significance to non-IT people.
• Dissemination of the ideas contained in the book through conferences, seminars and other events relating to the book.
• Development of training programmes in North America, Europe and Asia-Pacific.
• Generation of adequate interest and discussions around the book, and perhaps culmination of those ideas as a trigger for a follow-up book. While this book serves the purpose of introducing the concept, the follow-up book is expected to focus on the idea of implementing coherency management using EA.
• Several other activities with other organizations and groups are underway and we’ll announce those as soon as is appropriate.