Category Archives: Methods

Icons for the Capability Map

The Capability Map: Identifying Strategic Initiatives Through Enterprise Architecture.

Capabilities

Many enterprises experience a more intense form of competition and for that matter a more intense form of pressure from the outside the enterprise e.g. through financial institutions, government agencies and customers that demand more and better products for less money.

In such situations there are several perspectives that the enterprise’s decision makers would have to take into consideration when it comes to how the enterprise should develop in order to achieve the goals and objectives that have been defined by the various groups of stakeholders within the enterprise.

In regard to this I have to confess, that I work in a Scandinavian environment where other stakeholders than the executives can have a significant influence on where the enterprise is heading and with what measures it have to be done with, and that has an impact on my view on how to deal with the process of defining capabilities and how to execute strategies.

When I speak of capability then I am defining it as how the enterprise is able to execute activities or processes that are related to realistic strategic initiatives.

Activities and resources can be defined as those who deals with something in a specific way in order to complete a particular task or for that matter reach a particular objective. Activities can to some extend be defined as processes if they are grouped as such by the enterprise that is investigated.

Resources deals with the people, machinery, structures and systems there are at hand. When mentioning structures and systems then it is possible to deal with how people interact with one another in order to handle the activities or processes. Structures are in this regard how various hierarchies work and how the distribution of people within departments do things in various ways. Systems can in this case be a bit bogus. The first way I have chosen to understand and later on defining a system is through a hypothesis that it can be a social system where people interact in a formal and for that matter an informal way, and the concept of a system can be a set of coupled information systems transforms data (input) into information. Information systems are combined with structures in order to develop the information needed for the decision makers. As earlier mentioned there can be several layers in the decision-making platform in Scandinavian companies, and as a result there are several different needs in order to deal with the information available.

An Enterprise Architecture program is about taking charge of the people, the activities, the structures, the systems and synergies that exists in the enterprise and transform relatively complex information into useable information for the decision-makers.

The question is to find information that has been validated and that can be trusted. The information should provide the decision-makers with a set of scenarios and opportunities that summaries the capabilities of the enterprise.

The Maps

So how do you map the capabilities of the enterprise?

First and foremost you will never be able to map all the capabilities or for that matter simulate all the scenarios. First of all why would you? The enterprise you work for has limited resources available for the doing so in the first place and secondly you would probably have a lot of other things to do as Enterprise Architect in your enterprise e.g. continuing to convince stakeholders to commit their support for the Enterprise Architecture program.

So the question becomes, how do you transform the information you got organized in your Enterprise Architecture repository into capabilities?

The first and foremost action to take is to consult the various specialists, middle managers and people who have the first hand experience with working with the activities and processes in order to gain an insight in how the enterprise is working and how the various parties perceives the problems at hand and what barriers and obstacles that the enterprise would have to cope with in order to achieve an objective.

The second action to take would be dealing with organizing the impressions and validate each one of the impressions in order to identify ways to do things in a smarter way and identify issues that could be dealt with in easy ways and issues that seems systemic of nature. This process is a rather subjective one and it is very likely that a great deal of the stakeholders will disapprove of the particular prioritization of the issues, barriers and capabilities. The reason for this might that they assume that their problems or issues with the current architecture are way more important than those of the rest of the enterprise.

In other words don’t expect to become popular with all people in the enterprise while you prioritize and develop the capability map, but you can do a lot of things in order to convince the various stakeholders the necessity to deal with the problems at hand.

The third action to take would be dealing with organizing the feedback and validating the first set of impressions from the various forms of the issues dealing with capabilities, barriers and problems.

The fourth action to take would be to create the map presented to the decision-makers in the enterprise. The capabilities map should in turn be combined with scenarios due to the problems the enterprise will face with the increasing competition and availability of resources.

The Capability Map

The way I see it, the capability map shares a lot of features with the rich picture (as described by Checkland and Mathiassen, in each of the two separate books on information systems development), the user can apply a lot of different notation forms in order to illustrate the situation the enterprise would be dealing with if a particular scenario would be realized. Though I have found that some icons or pictograms to be more useful than others e.g.:

Icons for the Capability Map
Icons for the Capability Map

And for that matter can a grid be applied in order to give the decision-makers a good insight to when it could be a necessity to deal with the capabilities in the enterprise. I make use of a 3 x 3 grid where the vertical axis is strategic importance and the horizontal axis is time.

9 x 9 Grid
3 x 3 Grid

So what is the capability map good for?

It is good for illustrating how the enterprise can achieve its objectives by (re)organizing and execute strategies through informed governance. One way of achieving informed governance is through an Enterprise Architecture program.

Furthermore, the capabilities map is good for dealing with communication with stakeholders within the enterprise and convincing decision-makers to initiate specific strategic plans.

Drifting the Enterprise: Ensuring Solutions for the Enterprise.

Markets and Drifting

Most organizations operates within an environment that develops constant changes, that enforce the need for innovation and change within the enterprise. The market usually ensures that the enterprise has to re-structure, re-organize and adapt to the situation at hand.

Drifting is the industry paradigm, and there is nothing to do about it if the enterprise wants to develop and keep innovating.

The organization has to adapt, and that leads to the situation where the organization should have to be able to adjust to its enterprise architecture and its information systems in order to ensure that the problems at hand are solved. Since globalization has increased the degree of competition from easy to intense from competitors that can mobilize resources from various countries (markets) and transfer the resources to the markets that they want to gain a market share in.

Many small and medium sized enterprises would have to “hack” their enterprise in order to find processes, technology and organizational structures that can lead to synergies that in turn can lead to a competitive advantage. By acknowledging this the chief architect has to recognize that the Enterprise Architect program can’t be designed for a stabile environment or for idealistic conditions. The Enterprise Architecture program has to be designed upon an idea that the entire model and process has to be easy to change in order to achieve the crystallization of short term wins.

Competitive Advantages

In order to gain competitive advantages the enterprise has to organize and enable as many processes as possible to empower the organization to do something that it can provide better, cheaper or faster than any of its competitors.

These processes would have to be enabled through planning, skills and the ability adapt to the situation at hand. Drifting within the enterprise is in other words an imperative that the executives, the chief architect and the enterprise architects would have to deal with in their establishment of the enterprise architecture program.

The competitive advantages are realized through the members of the enterprise are able to identify solutions that can overcome the problems that they face in their own segment of the enterprise and this first hand knowledge can lead to a greater understanding of how they can optimize their ability to produce. However the ad hoc solutions that Ciborra’s idea of bricolage and hacking can lead to sub-optimization of the enterprise and eventually it would lead to silos.

In order to cope with the problems of the drifting and in the same time enabling the benefits of drifting for the enterprise.

The Enterprise Architecture Program

I define the concept of Enterprise Architecture as a process of adapting the standards, principles and objectives for the enterprise. This process is also a form of blue printing for how the enterprise’s architecture should develop and that enables a form of enterprise engineering as well.

Enterprise Architecture is both a form of enterprise engineering and a project-governance process. Enterprise Architecture is a program since EA is a continuous process that consist of a portfolio of projects that step by step alters and develops the enterprise from its current situation (AS-IS) to a future desired state. This is known as the to-be situation.

The principal idea with the program is that the change will take place over time in small steps and that would in principle ensure that the big bang changes wouldn’t allocate too many resources and it would in the same time ensure that the changes would alter too much at the same time and thereby make the changes manageable. The manageable size minimizes the risks for the enormous project will fail to realize the benefits promised before the project was initiated.

Drifting leads to a need to deal with the problem of inconsistent technologies and solutions, that in turn would make it very expensive and difficult to manage. In order to deal with the negative impact of the tendencies of bricolage and hacking, it becomes clear that the enforcement of certain principles, standards, methodologies and approaches should be enforced and that the concept of Enterprise Architecture is capable to deal with. Enterprise Architecture has to be enforced through the culture of the various segments of the enterprise. However a too tough enforcement of the principles dealt with in the Enterprise Architecture program will eventually lead to a problem with enablement of innovation (process innovation and product innovation) for the enterprise.

The chief architect has to try to deal with informing the various creative elements within the enterprise in order to make them understand how they can apply the various applications and solutions to deal with the problems that their segment faces, but they would have to deal with the standards and principles defined in the Enterprise Architecture program in order to ensure alignment, agility and assurance.

The chief architect has to deal with this delicate issue, and it can only be dealt with in a continuous process from the day that the Enterprise Architecture program is initiated until the end of the enterprise.

 

Making Sense: One of the Components of Achieving Holistic Management.

Can You Make Sense of the Enterprise

One of many reasons for why many enterprises experiences that organizational change projects fail and their respective leaders and managers only discovers that there are significant problems with the way the members of the enterprise activities.

The Sense Making Process

In the sense making process it is rather likely that the preferred departments of the enterprise would be the IT department since the IT department is properly that department that has a lot of contact with the rest of the enterprise, and the rest of the enterprise contacts and require that the IT department uncovers their needs to develop information systems that supports their business processes.

However in many enterprises a lot of the other departments have hostile feelings towards the IT department. This means that the IT department and its representatives will be viewed with skepticism, and the concept of sense making is therefore undermined.

In relation to the writings of Doucet et al (Doucet et al 2009) then the ideal situation would be when the enterprise when the Chief Operations Officer that is in charge of the sense making and Enterprise Architecture approach but usually it needs a maturation period where the knowledge and responsibility has been handed over from the Chief Information Officer. From this perspective then it is likely that Doucet et al argues for a paradigm shift within the enterprise. When addressing the view of the enterprise then the focus has to address the mechanistic and the organic perspective also. Is the enterprise a social system that functions like a machine that can be optimized or is a kind of organic entity that can be impacted through facilitation.

The thoughts that Doucet et al presents deals with how the enterprise will obtain a higher degree of assurance, alignment and agility when the enterprise goes through a process of uncovering and adapting the Enterprise Architecture program. When fully adapted then the enterprise will be able to reach out and re-design its enterprise. The only way to achieve this is by an enabling of sense making at all levels of the enterprise.

Karl Weick (Weick 2000, p. 244) works with a concept that deals with how the enterprise in one way or the other scans its environment and how this impacts how the enterprise creates an understanding for how the strategy process can be articulated.

In this perspective the focus of sense making is in an external context where there are three phases. 1) Scanning the environment, 2) Interpretation and 3) Learning. The learning phase is dealing with how the enterprise learns and that is done through practice. The interpretation deals with how the enterprise understands its environment and how it starts to acquire the model it needs to create an understanding of its environment and its options.

I am of the opinion that the scanning process can be used inside of the enterprise as well and especially the second step has to be investigated into detail by the chief architect and for that matter the coherency architect. If the enterprise doesn’t take reality into consideration when it articulates the corporate strategy then it is very likely that the rest of the strategies that have been articulated aren’t able to cope with the real life situations within the enterprise. When addressing this it is very important to understand that if the enterprise doesn’t base their plans on their contextual reality then it the plans will at best give hope to the members of the enterprise.

When I talk of contextual reality then it is the combination of feelings, experiences, observations and not to forget hard fact. Hard facts are usually numbers and for that matter artifacts that can be understood in a narrow way by the individuals who have to relate to it and not forget how the social system that receives the analysis sees the world e.g., it would be very likely if the receivers would reject the analysis if it contradicts their own behavioral pattern and for that matter world view.

An example could be that a chief architect delivers a plan for the enterprise that is based on the organic1 view of the organization and the receivers have a view that is predominately mechanistic2. In someways can this situation be compared to the changes that happens in science when a particular community of scientists have been challenged a different community of scientists who has another view on how a particular problem (world view or paradigm) has to be applied. It takes a lot of energy and a lot of resources in change effort of seeing validating and accepting the other point of view.

It is therefore very likely that the chief architect or for that matter the coherency architect who has to address the problems in the enterprise through a change program that would have to engage in a dialogue on what the enterprise is, how management should be working, how the various elements of the enterprise should interact and not to forget how the members of the enterprise produce value for the enterprise. When speaking of value then I address how the individual member of the enterprise contributes to the goals that have been articulated by the strategy team (usually the executives of the enterprise).

In this dialogue the coherency architect would have to think of it as a process where the various stakeholders would have to adapt to the new views of the enterprise, management, approaches and not to forget one another. The process might not be able to produce the desired results right away but it is a dialogue or struggle that the coherency architect would have to take in order to force the executives of the enterprise to facilitate change.

The Resilient Organization

The difference between the conventional approach to change and ideas, and the resilient organization is that the resilient organization is an organizational system that identifies the exceptions in the operations, and acts pro-actively to correct the changes before exceptions escalates to the extend of a burning platform.

However the members of a resilient organization by themselves understand that they have to inform the other members of the enterprise about how or what is about to happen in the various sections of the enterprise, and the members of the enterprise have been trained to act to adapt to the environment that the organizations interact with. In the same time the members of the enterprise adapts to one another by informing one another on the conditions of the enterprise’s work systems. It is the self-correcting attitude that the members of the enterprise show while they are working that enables them to make the enterprise resilient to the changes.

The members of the enterprise needs to be able to share information local, regional and for that matter on a global plan and for that the Enterprise Architecture program and repository be a great enabler.

With this in mind then the concept of holistic management will be dealt with in the next paragraph.

Holistic Management

Bernard and Doucet et al argues that the enterprise needs holistic management and through that they would be able to achieve competitive advantages when achieving holistic management. But what is holistic management? And is holistic management even achievable.

A holistic form of management is according to Hoogervorst achievable if the enterprise works with the organic way interpret and embody the actions of the enterprise.

Holistic Management deals that the enterprise can achieve some form of coherent and informed governance by applying Enterprise Architecture to uncover the entire enterprise and thereby its whole architecture.

Enterprise Architecture is a way to lay the foundation for Holistic Management. When speaking of Holistic Management the concept needs to be defined. The concept of Holistic Management is dealing with how the executives, managers, workers and other stakeholders (usually these are connected to the enterprise like banks, suppliers and increasingly advisors and consultants) gains an overview of how the various elements of the enterprise (and thereby its architecture) works. This overview can then be operationalized into a form governance where the various executives, managers and workers contribute to the decision process and by that the right actions can be taken for the right purposes.

When the foundation has been established then the focus has to be turned to trust and motivation among the various stakeholders to support and maintain the foundation for the Holistic Management. I am of the opinion that most enterprises are results of coincidence and as such the entire enterprise is somehow a product of randomly selected individuals, purposes, resources and work flow. Likewise are there many different reasons for why the enterprise has developed into what it is. By writing this I commit myself and my view on the enterprise holistic management through the eyes of the organismic approach to organizational management where the idea is that the enterprise isn’t a machine but a form of organism that can eventually be cultured and evolved into something smarter and better.

This leads to some of the reflections on what Enterprise Architecture and Holistic Management.

Reflections

When working with Enterprise Architecture is dealing with how the enterprise can achieve alignment among the various elements of the enterprise e.g., between the business units (lines of business) and the their usage of information technology. However is it possible to achieve a form of holistic management for enterprises? Is it possible to achieve a form of enterprise governance that is able to impact practices of the enterprise on all levels in order to enable the executives to tune or grow the enterprise into a desired state? In my opinion it is possible to either tune or grow the enterprise but it isn’t possible to achieve governance without friction in some form within the enterprise. But it is of great importance for the enterprise to undermine the barriers that in one way or the other limits the ability of the enterprise to adapt, innovate and align its various components in order to achieve competitive advantages.

The first step in achieving holistic management is through initiating a scanning process of the external environment as well as initiating a scanning of the internal environment. The scanning process can achieve some ideas on how the enterprise works. Given the information on how the environments that the enterprise operates with the executives can operationalize into better and more efficient decision making. In my opinion the scanning process is vital for achieving Holistic Management or something close too. Nonetheless Enterprise Architecture and for that matter Coherency Management is of great importance to enable Holistic Management and these programs needs to be taken seriously by the executives and middle management.

The resilient enterprise is in my opinion a result of an Enterprise Architecture program that goes beyond of the foundation architecture (going beyond the IT centric approach).

When Enterprise Architecture is applied in the right situation then it is possible that the enterprise can advance towards a resilient organization; however Enterprise Architecture is only one of the factors that will enable a resilient organization, but Enterprise Architecture can both become an enabler and a driver towards.

Conclusion

Sense making is a process of which the stakeholders can gain knowledge on how the enterprise is doing compared to its customers, suppliers and competitors. This has to be taken into consideration of how the enterprise works and how the system needs to be adapted to achieve competitive advantages.

Enterprise Architecture is a combination of a toolset, method and process that can give the stakeholders an overview of the enterprise works. In the same way the enterprise is able to initiate the processes needed to undermine barriers for agility, innovation and adaptability and establishing the platforms that are needed to achieve a continuous tuning or growth of the enterprise.

The resilient organization is probably the most likely candidate for achieving the ability of Holistic Management and only organizational knowledge and culture can enable the organization to achieve the change and the platforms.

Bibliography

Doucet, G. et al., 2009. Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance, International Enterprise Architecture Institute.

Hoogervorst, J.A.P., 2009. Enterprise Governance and Enterprise Engineering, Springer.

Karl E. Weick and Kathleen M. Sutcliffe, Managing the Unexpected: Resilient Performance in an Age of Uncertainty, 2nd ed. (Jossey Bass, 2007).

Karl E. Weick, Making Sense of the Organization (WileyBlackwell, 2000).

 

1As Hoogervorst articulated it in his book from 2009 (Enterprise Governance and Enterprise Engineering),

2An older paradigm than the organic paradigm. The organization is seen as a kind of machine.

Download the paper here

 

Integrated Governance

Is an approach to make your organization work better by creating a form of management that supports the various forms of governance and forms of planning. The literature review that you will be able to read by downloading the document from the provided link, deals with how Enterprise Architecture can enable an enterprise to achieve the vision of holistic management. Enterprise Architecture is therefore one of the major components of the paper and likewise is Coherency Management. The initial assumption is that by using Enterprise Architecture and Coherency Management that the enterprise is able to achieve competitive advantage since the executives, middle managers and employees will be able to get a better understanding of how the organization works and what it can do to align processes, resources and intelligence to achieve a sustainable competitive advantage.

The paper defines integrated governance, and introduces a framework that most enterprises will be able to make use of to implement integrated governance. It is obvious that more forms of governance can be incorporated into the framework; however since it has been an academic study, I had to delimitate what forms of governance I had to deal with (otherwise it could be a rather long paper on various forms of governance that would be more or less relevant to include).

It is notable that the enterprise needs to adapt the framework for its specific context; otherwise it is very likely that the enterprise will not be able to gain any of the benefits that integrated governance as a concept can provide the enterprise with.

One of the most important aspects of the framework is the quality assurance feedback channels that needs to be established, since this is the only official approach to collecting the data needed to understand how the changes influences the enterprise.

The findings of the paper and the paper itself is published under Creative Commons version 3 SA BY U.S. Edition. This means that you are able to make use of the paper in a commercial context and you are welcome to make derivatives as long you stay loyal to the license and you credit me (Peter Flemming Teunissen Sjoelin) as the author of the original paper.

Download the paper here

A Compendium for Understanding Enterprise Architecture.

I hereby publish the notes I have taken during the course in Enterprise Architecture that I have attended at the IT University of Copenhagen in the spring of 2010. The compendium is published under creative commons SA, BY, NC which means that it can be used for most purposes; however the purposes have to be non-commercial.

The notes are centered on Bernard’s EA Cube and the statement “EA = Business + Strategy+ Technology” and that has been the key organizer for how the notes are presented in the compendium.

You can download the compendium here.

Bushido of the Coherency Architect: The Ways of the Coherency Architect to Efficiently Apply Suitable Solutions!

The Path to Improvement

The focus is to combine lean, Toyota Production System, Enterprise Architect and Coherency Management into a guide line like the Bushido: The ways of the warrior.

The main principle of Coherency Management is to implement a holistic management approach that enables the management to achieve alignment, assurance and agility.

Enterprise Architecture is the foundation of achieving Coherency Management and it is possible to combine that with efficiency to achieve an enterprise that have a lesser amount of slack and adds more value to its share holders and customers.

First of all an Enterprise Architecture program has to be established.

Second of all an economic analysis of the activities that the organization performs to get income.

Third of all communication of change needs to be performed. That means that the Chief Enterprise Architecture needs to communicate to various stakeholders. The various forms of stakeholders needs to be dealt with in different ways. The various stakeholders needs different kind of information.

Third of all the Enterprise Architect has to work with various applying a framework e.g., the EA3 Framework, TOGAF, OIO or other framework.

Forth of all the Chief Architect needs to demonstrate the value of the Enterprise Architecture. The Enterprise Architect should apply the evaluation models that give the information that the stakeholders needs to make their mind (approve or disapprove) the Enterprise Architecture program. It is necessary to apply the evaluation model for the business processes and IT processes before the EA program has been established. This is needed to compare the before and after approach.

Fifth of all the Enterprise Architect has to make use of his or her talent to deal with the persons who have to change their way of working after the Enterprise Architecture program has been established. According to Doucet et al. (Doucet et al 2009) then the organization then there are three forms of applied Enterprise Architecture. The first form is known as Foundation Architecture. The Foundation Architecture is when the organization has applied Enterprise Architecture in the IT department. The IT department has been the driver of the Enterprise Architecture and made use of it to uncover the the operational model of the Enterprise Architecture. When the organization mature the Enterprise Architecture then it should over time come to the Extended Enterprise Architecture where both the business side of the enterprise and the IT side. The IT side and the business side works uncovering the business and its processes. There are several forms of architects who have various functions and responsibilities. There will be a centralized office for Enterprise Architecture and there will be a commitment from the Executive Group1 to enhance and use Enterprise Architecture to govern the enterprise. There are business architects, process architects, technology architects information architects and the Enterprise Architects. The Enterprise Architects will be dealing with handling the overall aspects of Enterprise Architecture. The Enterprise Architects will be dealing with keeping the other architects in line with the Enterprise Architecture program.

After the Extended Enterprise Architecture level then the organization will be moving toward the Embedded Enterprise Architecture. The form of architecture is so far a kind of utopia where every employee in some way acts as an architect which leads to that there are explicit and implicit architects. Theres is a focus on a central EA department that consist of the best Enterprise Architects who works with the overall Enterprise Architecture framework and enabling the other architects with their work through empowering the framework and governance of the Enterprise Architecture.

Sixth of all the Chief Architect has to implement a Coherency Management framework so far there is only one kind of a kind. That means the CoMOF framework has to be adapted. As it is with all other frameworks then the CoMOF framework is a generic framework and it has to be modified for the particular organization. While applying the modified CoMOF framework in the organization then Coherency Architect (or Chief Architect) has to make use of the efficiency theories such as LEAN, Six Sigma or Toyota Production System. This is a necessity to improve the organization’s enterprise.

Seventh of all the Coherency Architect has to ensure that executive group continues supporting the Enterprise Architecture program and Coherency Management program. This have to be done through emphasizing the support for Enterprise Architecture by using external pressure to enable the internal pressure(groups with power) to invest resources into renewing the program. If the Enterprise Architecture program isn’t renewed then the value of the Enterprise Architecture program will lose value. The same is the case for the Coherency Management program.

Eight of all the Chief Enterprise Architect should be working for improving the channels of how the Enterprise Architecture is transforming.

The Code

The Coherency Architect should be therefore be working with being efficient, effective and use his or her experience to develop develop efficient enterprises through Enterprise Architecture.

  1. Focus has to be on efficiency and effectiveness. The ideal is that the Coherency Architect should be thinking in systems where to much slack is minimized; however enough slack to harvest the benefits of innovation.

  2. The vision of Enterprise Architecture has to be communicated to the stakeholders . The people skills and abilities to communicate fluently with people are virtues.

  3. Improving the Enterprises and their Enterprise Architectures then the Coherency Architect have to focus on influencing the organization cultures to institutionalize improvement through Enterprise Architecture.

Applying the Code

The Bushido Framework
The Bushido Framework.

The code can be applied through the model dealt with above . The path to improvement is designed around the stones n the circle. The circle represents continuity. Bernard’s EA 3 framework is located in the bottom is matured a long side the principles of the CoMOF-framework. The lines with arrows are symbolizing the maturing process and a part of the continues process.

1Top managers including CEO, CIO, CFO and COO etc.

Download the paper here.

Enterprise Architecture Frameworks: A comparison of EA 3, OIO and Zachman.

Framework and Methodology

According to Bernard (Bernard 2004) then a Chief Enterprise Architect or what equals to an Enterprise Architecture program manager is selected then the definition of the EA framework and the EA methodology becomes a necessity.

The Definition of the EA Framework

An EA framework is dealing with what the EA program will document.

The Definition of the EA Methodology

The EA methodology deals with how the Enterprise Architecture documentation is articulated and used.

The EA Cube and its Construction

The simple edition of the EA cube that explains the various components, and layers within the framework.

The EA3 Cube.
The EA3 Cube.

The Documentation Process

There are six steps that needs to be gone through according to Bernard (Bernard 2005, p. 97):

  • The process includes a framework.

  • The process includes the components.

  • The process includes the current architectural views.

  • The process includes future architectural views.

  • The process deals with the transition plan for going from “TO BE” and the “AS IS” architecture.

  • The process deals with threads that influence the enterprise architecture on all levels.

A Comparison of EA Frameworks

Zachman’s Framework

The foundation of the EA Framework is John Zachman’s Framework. It was originally based on an approach that it could be explained and dealt with as if you had to build an airplane or a house. The blueprint analogy was used to articulate the framework.

Zachman's Framework (According to Bernard)
Zachman's Framework (According to Bernard)

In general there is one single mistake that the Enterprise Architect can do when working with the Zachman framework and that is to focus too much on documentation. This is known as the “Zachman Trap”.

OIO IT Architecture Framework

The OIO framework (based on the white book on IT architecture) was developed for the Danish Ministry of Science. Its focus is on the Danish Public sector. The intention was to implement Enterprise Architecture to give the decision makers in the Public Sector a better foundation for how the single organizational entities operates.

From a management perspective the idea was to enable the public sector to standardize and centralize processes and decision making.

The OIO framework is based on the same paradigm as the EA 3 Cube by John Zachman.

Strategy Process.
The OIO-Framwork (The Two Main Processes).

As the illustrated above then there can be defined a governance process and a documentation process.

The two circles represent activities used to deal with updating and developing the architecture. The circle located in the bottom of the third illustration deals with the process of the “AS IS” and this is connected to the process of creating a vision, a business architecture, information architecture and the technical architecture.

The OIO-framework is often criticized for being to comprehensive and often the Enterprise Architects have to invest too much of their time to identify artifacts on various levels and organizing the artifacts according to the OIO-framework. Secondly it has been some time since the last edition of the framework was revised which might be an indicator for that the Danish Public sector is either static in its development or that the state plans to release a new edition of the framework or an entirely new framework. In the other hand the OIO-framework has an entire section dealing with defining and identifying architects which in my opinion is a strength by using the OIO-framework since it enables the Chief Enterprise Architect to communicate to the stakeholders who have what abilities, responsibilities and not to mention accountability during the Enterprise Architecture process.

The EA 3 Cube

The EA 3 Cube was developed in 2004. The Framework is designed as a cube and it is build upon the idea that hierarchies are needed to avoid sub-architectures (Bernard 2004, pp. 104 – 105).

According to Bernard then the business goals are the drivers of how the Enterprise Architecture is designed.

The EA 3 Cube is based on the primary function of organize and planning IT resources and documentation of the Enterprise Architecture. (Bernard 2004, p. 105).

The framework is build upon five levels and as before mentioned these are hierarchical to avoid sub-architectures.

The Five Layers of the EA 3 Cube

  1. Goals and Initiatives is as before mentioned the driving force of the Enterprise Architecture and therefore are these located in the top of the cube (as the first and primary layer).

  2. Products and services shows how Information Technology impacts the various products and services.

  3. Data and Information is used to document how the Enterprise makes use of information “AS IS” and how the information flow should be designed for future situations “TO BE”.

  4. Systems and Applications is used to organize and group the various information systems that give the organization its IS capabilities.

  5. Networks and Infrastructure deals with the so called backbone of the Enterprise Architecture and it includes how the networks interact and how various technologies interact such as VOIP and LAN, WAN etc.

The EA3 Cube.
The EA3 Cube.

Lines of Business (LOBs) that can be considered as a specific activity within the organization and all the have all the five layers of the architecture. The LOBs are named “Vertical Mission Areas”. The LOBs can have their own administration and functions that can be considered divisions within the divisionalized organization.

Crosscutting Components are established so the LOBs don’t create redundant features e.g., e-mail hosting and IT services.

Threads are defined as security, standards and workforce. These three threads go through each level of the framework.

Conclusion

These three frameworks are all located within the same paradigm and are therefore compatible with one another; however in some situations it will be better to choose the one of the frameworks over the other e.g., if analyzing an Enterprise Architecture for a public institution in Denmark then it recommendable to make use of the OIO-framework.

The frameworks have their strengthens and their weaknesses such as the Zachman framework that focus too much on documentation instead of changing the Enterprise Architecture from the “AS IS” stage to the “TO BE” stage. Likewise does the EA3 framework and the EA 3 Cube some benefits and advantages. E.g., is the EA3 Cube a rather simple framework and is therefore easily applied to small and medium sized organizations. In the other hand it tends to be a bit simple and generic which can end up being a disadvantage.

The Coherency Architect should therefore emphasize on choosing the right framework for the right situation and the right type of organization by using a SWOT – matrix or other form of matrix that can assist him or her with making the right choice.

Sources

Bernard, S.A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.

The Enterprise Architecture Framework

The Steps of the EA approach

There are defined 20 steps to establish the EA program according to the EA 3 Cube framework (Bernard 2005). The 20 steps have different importance in the four different phases which needs to be taken into consideration.

The first and thereby primary step is the establishment of the EA program. If the EA program isn’t established the organization will experience difficulties with improving its Enterprise Architecture.

The second phase deals with how the organization should define an methodology and the tools that are compatible with the EA approach (framework). If that is not in order then the EA program will not aggregate a proper view “AS IS” perspective.

The third phase deals with how the execution of the EA documentation program.

The fourth phase deals with how the EA program should be linked to the management and other kinds of management processes so the organization can generate the full advantage of the investment in the program.

Phase 1: Establishment of the EA Program

  1. Establishment of the EA Program and identifying the EA Chief Architect.

  2. Establish of the EA Methodology.

  3. Establish EA Governance and links to other management processes.

  4. Develop an EA communication plan to ensure EA stakeholder buy in.

The EA Program needs a person in charge to apply the right framework and the right tools and the person needs to be hold responsible and accountable. This means that the top management and management of the organization needs to buy in (#4). If they don’t buy in then the EA program will easily be detoured.

The EA program needs to be linked to other management processes so they can be coordinated and when they are coordinated they can become a greater asset for the organization. When the coordination has been established and the coordination has been applied then it might turn into a competitive advantage.

Phase 2: EA Framework and Tool Selection

  1. Select an EA documentation framework.

  2. Identify the EA lines of business (LOB) and cross cuts and the order of the documentation.

  3. Identify the EA components to be documented framework – wide.

  4. Select documentation methods appropriate to the EA framework.

  5. Select the software applications or tools to support the automated Enterprise Architecture documentation.

  6. Select and establish an online EA repository for documentation and analysis.

The documentation framework is frame for how the various elements have to be put into to create a systemic analysis. The analysis have to be focusing on identifying symptoms and finding the cure for the right problems within the organization.

The Enterprise Architecture should be documented so an “AS IS” is produced and used as a blueprint so management and the EA program chief architect can articulate a transition plan that can enable the organization to achieve its goals and thereby create the “TO BE” situation for the enterprise architecture.

Phase 3: Documentation of the Enterprise Architecture

  1. Evaluate existing business and technology documentation for the use in the Enterprise Architecture.

  2. Document the current views (AS IS) of the existing components in all frameworks areas (levels). Organize and store the artifacts in an online repository.

  3. Develop future business / technology operating scenarios.

  4. Identify future planning assumptions for each future scenario.

  5. Use the scenarios and other program / staff input to drive the documentation of future EA components in all EA framework areas. Store artifacts in the online repository.

  6. Develop an EA management plan to sequence the planned changes in the Enterprise Architecture.

The business and technology documentation is needed to create the “AS IS” since the EA consist of Business, strategy and technology and acts as a kind of governance tool for the organization.

The scenarios needs to deal with a positive scenario where everything stays the same and a scenario where things change and a scenario where everything goes down the drain (worst case scenario).

Involve the the staff to assist in making the documentation since many of them probably act as SMEs (Subject Matters Experts).

The EA management program needs to be the blueprint for changes that needs to be implemented in the enterprise architecture. This means that the program will have to be broken down to projects that can change the various components (and other elements of the enterprise architecture).

Phase 4: Use and Maintain the Enterprise Architecture

  1. Use EA – documentation to support planning making.

  2. Regularly updates current and future views of the EA components, and link information in the EA repository to create high – level and detailed perspectives of Enterprise Activities and resources in the current and in the future operating environment.

  3. Maintain EA repository and related EA modeling and analysis capabilities.

  4. Release annual updates to the EA management plan.

When working with the EA framework then it should be used to assist in the planning making (the transition plan) and not to mention that the methodology needs to be in place for the transition plan.

The EA repository needs to be maintained so every stakeholder in the organization can relate to the objects and terminology in the same way.

The EA management plan needs to be updated so it is matches the changes in the domain.

Sources

Bernard, S.A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse. 

The IT Strategy: An Articulation of the IT Strategy from a Coherency Architect’s Point of View.

Articulation of the IT Strategy

The Coherency Architect needs to be able to deal with the IT strategy otherwise he or she will not be able to drive any value from the Enterprise Architecture. There are many approaches to how an IT strategy can be articulated and what the primary focus should be.

This blog post will deal with the approach Chris Potts have proposed in his book titled “FruITion”. Chriss Potts have proposed a bit controversial approach to IT strategy e.g., he focuses on other models and claim that when the organization manages its investments then the right portfolio of technology will be selected, likewise does he propose that the role of the CIO isn’t an imperative. In the novel Chris Potts suggest the title “CIIO” for Chief Internal Investment Officer.

The Coherency Architect can make use of the approach to challenge his or her own view on the strategy and thereby be able to produce better strategy.

It is notable that the book is organized around a novel that deals with a CIO that faces a situation where he can’t pin point what kind of value the IT department brings value to the organization.
Potts then write emphasize some observations that can be made on each of the chapters in the book.

The Strategy Articulation Process

This section is based on the definitions that Potts describes in his work “FruITion” (Potts 2008, p. 13):

  1. Most robust strategies emphasize high value on its environmental feedback.

  2. Make sure the strategy is meaningful to the stakeholders of the strategy.

  3. Distinguish between the strategic level and the operational level thinking.

  4. Disinterest should never be understood as trust.

The following four statements are based on Potts’s “fruITion” (Potts 2008, p. 25):

  1. A document that contains the strategy is not the strategy.

  2. The language used to articulate a strategy shows the mindset of which the person who articulated made use of (or has).

  3. If the host organization (enterprise) has an IT strategy then it is necessary to include all of the Information Technology the organization (enterprise) makes use of.

  4. It is an imperative that the IT strategy has to summarized in one meaningful sentence; otherwise the strategy needs to be reworked.

  5. If the organization (enterprise) has an IT roadmap then it is imperative that the driver of the roadmap isn’t the suppliers but the tactical goals and strategies of the organization.

  6. If the CIO runs the IT department as an external business (weak links to the enterprise) then the enterprise will threat the IT department as such.

The following four statements are based on Potts’s “fruITion” (Potts 2008, p. 54):

  1. Shape the strategy by exploring why the company isn’t already fulfilling its promise.

  2. The CIO should validate who the promise is “talking about”.

  3. Build the strategy on a model that emphasize the customer and supplier perspective and never the “Business and IT” perspective. The over all reason for this is that the organization and IT department is one and the same.

The following four statements are based on Potts’s “fruITion” (Potts 2008, p. 204):

  1. If the organization manages its investments well then it is likely that the most appropriate technology will be selected.

  2. The organization should assign an executive accountability for maximizing the total value the company creates by its internal investments in change.

This leads to the Alignment phase.

The Alignment Phase

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.34):

  1. Never under estimate the pace (of change) of the Corporate Strategy.

  2. The strategy has to be compatible that stakeholders change their minds.

  3. Build the IT strategy on a promise and not on aims.

  4. If the IT strategy is organized around solving a particular problem, then it is a necessity that the IT strategy solves the problem.

  5. Are the persons who develops and articulates the strategy (strategists) game players?

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p. 44):

  1. If the business side of the organization perceives the IT department as an external supplier then it is likely that the IT department and the CIO can’t influence the corporate strategy.

  2. Different kinds of strategies needs different kinds of strategists.

  3. The CIO should know his relative strengths and weaknesses when it comes to analysis and synthesis. In a strategy it is the synthesis part that is the most important thing to handle.

  4. If the IT department or organization (enterprise) have issues with identifying what value the IT brings to the organization then it is likely that the organization (enterprise) experience wider business related problems.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p. 61):

  1. A corporate strategy that is focused on exploiting IT is focused on value, money and organization. The corporate strategy is not focusing on technology.

  2. The directors of a company is an independent community that adds value to the company.

  3. Value is defined as a portfolio of measures and types.

  4. The “business side” of an organization will in many cases assume the money the enterprise is spending on IT is a random number.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.124):

  1. Each stakeholder in a strategy has something distinctive to offer.

  2. Language and communications are critical to a strategies success.

  3. The concept of theoretical, practical and abstraction depends on the audience. The strategy should be articulated and aligned to the audience.

  4. People in organizations develops the projects rather fine but they tend not to make the most out of the projects when the projects have been implemented.

This leads to the value adding phase.

The Value Adding Phase

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p. 70):

  1. Many relationships are based on perceptions and high profile characteristics.

  2. The business side of the organization expects service and therefore should service levels between the IT department as a supplier and the customers be negotiated and incorporated into the strategy.

  3. The corporate strategy is about numbers. The focus of the IT strategy should be the same.

  4. Often there is a gap between those in the enterprise who adds value and those who spends the value. Is that also the case for the IT strategy?

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p. 159):

  1. The CIO (or the Coherency Architect) should make use of color coding to distinguish the business investments from the IT investments.

  2. The CIO (or the Coherency Architect) should prove that looking and managing the IT investment as something apart from the business investment isn’t sufficient.

  3. The CIO (or the Coherency Architect) should show that the strategic projects aren’t necessary those projects that aggregate the highest ROI.

  4. Explorer the cause and effect with of IT investments and business investements.

This leads to the change management phase.

The Change Management Phase

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.72):

  1. When changes occur (as it will with the implementation of a new strategy) then the change process will also impact the employees (and managers) personal life.

  2. Numbers is a dispassionate way to analyze the strategic landscape with. It should include what the CIO and the enterprise knows and doesn’t know.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.81):

  1. The IT strategy has to be articulated in an iterative approach.

  2. Look at the numbers in the budget and evaluate if they speak for themselves.

  3. The CIO (or the Coherency Architect) has to explore how the company budgets , manages, and measures business change that comes through IT related projects.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.175):

  1. The CIO (or Coherency Architect) has to cause other people to change.

  2. The CIO should know what he would die in the ditch for.

  3. The business side of the organization often experience the IT side of the organization as being “promising a lot and never keeps the promises and it doesn’t care about the business side”.

  4. 100% alignment among strategies can be dangerous and it occurs rarely that the strategies are 100% aligned.

  5. The future role of the CIO is not assured.

  6. The CIO or Coherency Architect has to understand that there are competencies else where in the enterprise that is in duplication of the those competencies that are in the IT department.

  7. The new strategy for IT demands a new operation model.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.180):

  1. Strategists deal only in success and so should the CIO and the Coherency Architect.

  2. It can be hard for the CIO and the Coherency Architect to challenge the orthodoxies of the organization.

  3. If the CIO will not cross the bridge then let someone else take care of the investments.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.182):

  1. Leading strategy can be a lonely job.

  2. The over all focus of a strategy is about winning. If the CIO or the Coherency Architect is not committed 100% to achieving the strategy then it is not really a strategy.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.191):

  1. Set down your Promise, Principles and Tactics for the key stakeholders to explore and ratify.

  2. The stakeholders wants to see the combination of ideas in relation to the organizational system.

  3. The strategy can look like the obvious but it is important that the CIO or Coherency Architect emphasize that the strategy isn’t applied.

  4. The CIO or Coherency Architect should test the best practice of the industry.

  5. The strategy is what the CIO or Coherency Architect does (de facto strategy).

This leads to the implementation phase.

The Implementation Phase

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.96):

  1. Use the “Promise, Principles and Tactics” framework while the strategy is in the articulation process and when it is about to become executed.

  2. The “Promise and Principles are the stabile core of the strategy. Tactics are more fluent or adaptable when it comes to events.

  3. Address each of the stakeholders individually (preferable personally) before the stakeholders are addressed as a group.

  4. Lead the execution of a strategy don’t manage it.

  5. When it comes to the investigation of IT investments then start with identifying value and then work backwards. When using a spreadsheet then the focus should be on columns and not on rows. This should help create the overview that is needed (according to Potts).

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.103):

  1. The strategist (CIO) is the embodiment of the strategy.

  2. Organize the collaboration around one set of numbers and strategic themes; however each person who works with the strategy should be given the opportunity to have an influence on that part of the strategy that they work with.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.115):

  1. A relationship is owned by two people.

  2. Experimenting with the numbers (in the budget) can uncover a new understanding of the problem.

  3. The CIO (or Coherency Architect) should make use of a bottom up value portfolio.

  4. The CIO (or the Coherency Architect) should evaluate the investment strategy to sparkle a discussion on what priorities the organization (enterprise) has.

  5. The Coherency Architect should be focusing on the exposing the scenarios for what will happen if the investment strategy is changed.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.134):

  1. Strategy is essential about options and opportunities and it is not about being right.

  2. Take the lessons for what didn’t work as expected.

  3. The relationships that people builds are influenced of previous events and relationships.

  4. Look for the subtleties in the responses of the stakeholders.

Types of Managers

Potts presents the model (illustration 1) that serves as a compass for characterizing managers within the organization. Note it is a compass and most managers aren’t purely technical, purely operational, purely environmental or for that matter purely organizational.

Pott's View on Managers
Potts's View on Managers.

The operational manager focuses on execution and internal processes.

The environmental manager focuses on how the strategy’s external context.

The technical manager focuses on specifications, technologies and products/services etc.

The organizational manager focuses on organization models, cultures, structure, internal politics and sourcing.

That leads to the conclusion.

Conclusion

The Coherency Architect should be aware of that there are various ways to develop and articulate an IT strategy. Potts approach is rather clear and can in many ways be considered as a practical approach to articulate an IT strategy. Potts approach can be considered an alternative approach to IT strategy and it can be used to challenge the “industry orthodoxies” which in itself can create a competitive advantage.

The Coherency Architect has to understand how an IT strategy is and how the artifact can be produced if it doesn’t exist in an enterprise already and that makes the concept of the IUT strategy rather important to understand and challenge.

Sources

Potts, C., 2008. fruITion: Creating the Ultimate Corporate Strategy for Information Technology illustrated edition., Technics Publications, LLC.

Download the paper her (articulation_of_the_IT_strateg.).

The New Age of Management: The Focus on Coherency Management!

The Development of the Organizations:

As you know that the organizations have evolved over time from once in the 19th century where the organizations (companies etc.) where small and insufficient. The organizations in the United States were of the size of 1 – 4 employees who were not selected on their ability but through their social network.

The 20th century formed organizations and created tendencies and pressures in the market that demanded that the organizations had to adapt to create the goods of a high quality for a low price so new markets could be reached. The 20th century introduced a scientific approach to management which was introduced by Frederick W. Taylor. This approach led to the creation of Taylorism and the core principle of Taylorism was to eliminate ineffective work processes.

This led to the construction of a management paradigm which has led to the foundation of the current management approach for the organizations.

Today we see organizations that are multinational or global and these have thousands if not hundreds of thousands of employees e.g., International Business Machines, Ford Motors, Microsoft, Google etc.

All of these works with a specific organizational design typically these have been hierarchical and this has led to specialization, productions increase, profit maximization etc.; however since the end of the production economy by this I mean the economy which was dominated by companies that produced physical products e.g., Cars (Ford). The Western economies evolved from focusing on physical products into providing services and later to focus on how to produce knowledge. The knowledge economy is characterized by the employees are those who are the asset. Their knowledge is the asset which is used to create products and services; however the products and the services are normally produced or provided by a different company in the third world e.g., India, China, Vietnam or Indonesia. Since the employees are the most valued asset then the goal is to make sure that the employees don’t leave the organization and enable them to create more creative and sustainable solutions of which the organization will be able to capitalize on.

This leads us to the evolution of the concept of management.

The Evolution of Management:

Management is defined as:

“Management is the art to getting things done through people” – Mary Parker Follet (Barret 2003, p. 51).

Management has evolved over time like the organizations. There have been several views on how to manage organizations; however this blog post will only deal with what a Coherency Architect should conclude to be relevant.

As mentioned before then there are the first form of structured management is the Taylorism (as mentioned under Scientific Management). This form of management insufficient in the knowledge economy since knowledge workers needs other forms of stimulation than monetary incentives and written orders to perform.

Naturally there was a reaction to the Taylorist approach. This happened when the Japanese companies introduced cheaper products and of superior qualitative which meant that the Western companies had evaluate the way they managed and motivated their employees.

Since the 1970s have the Western companies in one way or the other tried to imitate Japanese companies by developing management and quality systems like Six Sigma, LEAN and Toyota Production System. The reason for why the Western companies haven’t been successful is that they so far have simplified the systemic approach the Japanese makes use of.

The Japanese have a very different approach than Western companies when it comes to management and motivation. First of all the Japanese companies make use of a bottom up approach when it comes to how the organization articulate and implement their strategies. Second of all the Japanese companies have been known for motivating their employees by making them proud of their work and putting an honor in quality. Third of all the Japanese companies are known for lifetime employment which means that they commit themselves to keep the employees employed and as a result of this they expect a higher degree of loyalty and commitment.

The IT waves in the 90s and early 2000s led to leadership and motivation; however to many organizations (typically IT related organizations) didn’t realize how to enable more productivity or for that matter crystallize better products by applying the new forms of leadership. As a result of that many of the organizations failed to survive the IT bobble which proved that to many organizations didn’t have the appeal of the market to survive or they simply didn’t understand their Enterprise Architecture. If these organizations had understood their Enterprise Architecture then a lot of them would have been able to scale the need of their consumption of resources and as result they would have survived.

The new paradigm is that the employees are the asset of the organizations and these should be encouraged to enable them to develop their own products.

Coherency Management:

All organizations have an architecture regardless if members of the organizations are aware of it or not (Doucet et al.).

Coherency Management then deals with how the organization can gain advantages by using Enterprise Architecture. This is done by maturing the organization by diffusing the knowledge of Coherency Management and the by applying the tools from Enterprise Architecture to other parts of the organization. This diffusion needs to be build upon the idea that these have to be embedded in the business processes and continuously be applied with the maturity of the Enterprise Architecture.

In many ways the concept of Enterprise Architecture is based on the same paradigm as the management systems of the 20th century which is defined as structuralism and according to Doucet (Doucet et al., 2009) Coherency Management and the underlying tools such as Enterprise Architecture are typically defused by the IT department to the rest of the organization. This is typically done by the Chief Information Officer who anchor the paradigm in the middle and top management of the organization and gives the members of the IT department the “necessary protection” to enable change within the organization.

Therefore it is safe to assume that the Coherency Management approach will lead to a top down approach as it was the case for many other Western styled organizations. This might lead to the conclusion that Coherency Management in some way will be in a different paradigm than those tools which are suggested by Gary Hamel. However Coherency Management do also have elements which needs to be diffused via the bottom up approach and it has to be embedded into the organizational culture and employees with many different backgrounds have to apply their own views onto the concepts of Enterprise Architecture.

When this come to the consideration of Coherency Management then the drive to implement the concepts of Coherency Management and Enterprise Architecture is defining what paradigm to make use of. If Coherency Management is build upon the idea that the employees should help define the framework and tools the Coherency Management Office will apply in the various processes in the organization. In the other hand quite a few people are scared of change and change anchored in the hands of employees won’t necessary led to change or innovation like Henry Ford mentions in relation the innovation of the mass produced car: “If I had asked them then they would have asked for faster horses”. Therefore should the Coherency Architect keep in mind that the only way to enable change in an organization is to influence the organization culture. The culture can be changed in many ways by the tools of many different paradigms.

In this article I will however only deal with a few frameworks for change.

The first framework is the structuralist approach which where Kotter’s framework will fit into. John P. Kotter presents in his article “Why Change Fails” and this could be supplemented by Kurt Lewin’s unfreeze, move and freeze approach.

The second framework is the interpretive paradigm where the organization constructs some form of “internal” economy where the members of the organization can influence the projects which the organizations initiates. This is done by establishing a form of stock exchange where all the members can invest a fictional amount of company-money to found the projects.

The organizations that adapt this framework needs a strong Enterprise Architecture and move towards Coherency Management; otherwise will the entire change effort be in wane.

The third framework is based on the idea that the employees themselves should be able to choose their leaders and regulate their own production schedules etc.. This kind of coordination needs like the second framework a strong focus on their Enterprise Architecture and thereby also on Coherency Management to assist the employees and the management with keeping the organization on track.

The New Age of Management: A Focus on Coherency Management!$