Developing Frameworks: Five Things To Do and Five Things To Avoid.

The Essentials

While working with the concept of Enterprise Architecture it usually becomes a necessity to chose and implement a framework. As such the chief architect can either implement a standard framework, and as such commence the project of documenting the AS – IS situation1. It is an option to adapt the standard framework in order to make it suitable for the enterprise as such make it work better in the implementation process. An alternative to deal with a standard framework the chief architect could develop his or her own framework that from the start has been developed in mind to the specific enterprise. This specific paper is dealing with some pitfalls that I have identified while I have been working with developing a framework by myself.

I will first and foremost outline my definition of what a framework is, then I will deal with which five problems I have encountered and how these problems can be avoided. As such this will become a list of dos and don’ts. Finally I will summarize my findings in a conclusion.

What is a Framework

There are several reasons to apply a framework e.g. the potential of increasing the success rate of the implementation of the Enterprise Architecture program, and as such I have chosen to go in depth with a definition of what I think a framework is about.
I have defined the concept of the Enterprise Architecture framework as essentially a document that outlines which artifacts the chief architect and the Enterprise Architecture group should be identifying, describing and organizing into a repository. Thereto does the framework defines which roles that are supposed to be in the Enterprise Architecture group and how the AS-IS state should be documented. Likewise does the framework details how the scenarios deals with the process of change from the AS – IS situation to a desired TO-BE situation. In between these two it usually a good idea to have a transition plan (Bernard 2005, p. 33).

I have now defined how I understand the concept of the framework. The framework is a key element in order to implement an organized documented overview of the AS – IS situation of the enterprise.

Problems and Solutions

The chief architect should include stakeholders for its internal environment in order to gain an understanding of how they understand the enterprise’s social systems, business systems and information systems. As such the chief architect would have to gain an understanding of how each of the parts of the enterprise works and how these systems interact with one another.

The framework should reflect the organization since it would have to reflect the current conditions yet the framework would have to be used as common reference model for the Enterprise Architecture group. Eventually should the framework be adaptable to filters in order to give the various stakeholders the information that they would need in order to ensure buy-in and support for the changes needed in order to transform the enterprise to the desired state.

While developing the framework the chief architect shouldn’t make the framework too complex in order to the level of details and the language used. Likewise should the chief architect be aware of that the repositories that he choses should be dynamic due to the possible rapid changes in the architecture of the enterprise while the organizational changes are occurring. I am of the opinion that organizations changes more rapidly than the decision makers realizes since people changes habits and their ways to deal with certain tasks due to the changes in their (and thereby the enterprise’s environment). I have come this particular opinion due to an article I have read by Orton and Weick (1990) where Orton & Weick argues that there are several voices of loosely coupling, and one of these voices (the voice of typology) deals with the fragmented environment impacts the possibility to enforce change onto the social systems (Orton & Weick 1990, pp. 207-210) due to connections and impacts of the internal and external environments will in some points stop a centrally planned change.
It is a necessity to avoid rigidity and too much bureaucracy so to say the chief architect would have to avoid creating a paper tiger. It is one of the major problems with Enterprise Architecture , and Wagter et al. (2005, p. 178) discusses in their book titled “Dynamic Enterprise Architecture”. Likewise does Wagter et al. discusses the concept of implementing Enterprise Architecture in small steps and small sections due to the unnecessary usage of the enterprise’s resources in implementing a system in a world where all resources should be contributing to the enterprise’s competitive advantage.

Dos and Don’ts

In order to give the various chief architects or other individuals in the Enterprise Architecture groups in the enterprises out in the industries, I have articulated five things to do order to develop a good framework. Likewise have I articulated a list of five pitfalls that the chief architect or others in the Enterprise Architecture group should avoid in order to implement a successful framework.

Dos

Don’ts

1) Do include stakeholders in the development of the framework.

1) Don’t focus too much on the technical architecture while you develop your framework.

2) Do work with both social systems, business processes and IT.

2) Don’t assume that the framework can be used for a total codification of knowledge in the enterprise.

3) Do work with the business architecture. After all it is the enterprise’s business systems that generates value.

3) Don’t assume that the framework is perfect after you have designed it at the desk. The framework has to be improved during the implementation and after the implementation since new stuff and perspectives will occur.

4) Do work with an approach to keep the framework simple.

4) Don’t assume that people align themselves with a centrally planned strategy. Assume that the organization consists of many different entities that can be impacted by elements outside the organization’s boundary.

5) Do work with the stakeholders understanding of what the framework is and why it is important.

5) Don’t develop a “paper tiger” it makes no sense to develop at lot documents that nobody reads or acts according to.

Which leads to the conclusion of this paper.

Conclusions

A framework is a fundamental element that the chief architect and the decision makers of the enterprise have to be involved with in order to ensure that the Enterprise Architecture program can be implemented in the enterprise. As such there are five things that the chief architect should take into consideration while developing his action plan e.g. Include the stakeholders in the development of the framework, the inclusion of business and IT, the business architecture is the primary architecture, keep the framework simple and ensure that the stakeholders understand what the framework is about and why it is important. Likewise are there five pitfalls that the chief architect has to take into consideration while he develops on the framework e.g. avoid to focus too much on the technical architecture, he shouldn’t assume that the framework is a Swiss army knife in regards to knowledge sharing, he shouldn’t think that the framework is perfect, especially pre-implementation, he shouldn’t believe that people just align themselves with planes developed by a central administration and last but certainly not least. The chief architect shouldn’t develop a paper tiger.

The keyword to framework development is simplicity, prototyping and iterative change.

Bibliography

Bernard, S., A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.
J. D Orton and K. E Weick, “Loosely coupled systems: A reconceptualization,” The Academy of Management Review 15, no. 2 (1990): 203–223.

Roel Wagter et al., Dynamic Enterprise Architecture: How to Make It Work, 1st ed. (Wiley, 2005).

1The situation as it is in the current moment.

Schools of Enterprise Architecture: Ideas of Architecting the Business, the Organization and the Technology

Introduction

Enterprise Architecture as a concept can be defined as many different things, shapes and practices. Through my studies of the concept of Enterprise Architecture, I have discovered that there are as many definitions of Enterprise Architecture as there are frameworks, books and articles on the matter.

Most frameworks agrees on that the concept deals with developing a set of standards, principles and documentation. These three elements are used in context of documenting and dealing with the usage of information technology in the organization.

From that on there are differences among the definitions of Enterprise Architecture like how to implement Enterprise Architecture program. A rather simple estimation there can be defined three different schools for Enterprise Architecture practice.

Schools of Enterprise Architecture Practitioners

The first school this blog post will address is the process school. The second school is the enterprise engineering school. The third school is a school in between the two former, which I will name the hybrid school. The practitioners works with an ideal that Enterprise Architecture isn’t solely a project / program process or a blue printing process.

The Process School

The process school and its practitioners are usually working with TOGAF, OIO EA or other framework (approach) that emphasize a program management and a project management methodology on adapting projects to support the Enterprise Architecture program.

It is needless to say that the process of adapting the projects to align with the principles of the Enterprise Architecture program is based on a set of continuous processes. These usually contains a set of strategy development, communication and execution. Likewise does most frameworks have an implicit form of evaluation before the process starts again.

The Enterprise Engineering School

The enterprise engineering school and its practitioners work with an idea that the enterprise can be build upon models or what can be defined as blue prints. The focus is to develop blueprints that can ensure the enterprise’s abilities to obtain models of governance, social systems and technology. The focus is to enforce a change program through a program management approach, but opposite the process school the enterprise engineering school doesn’t go into detail with the program or project management methodology.

In this case blueprinting is dealing with developing meta-models that interconnect the various approaches to governance.

The school of enterprise engineering and the process school are in contrast and in somehow conflict with one another in their approaches to Enterprise Architecture. In my opinion both schools can be of interest since both schools have some advantages that can be used in context of the enterprise.

With this in mind I will discuss the hybrid school.

Enterprise Architecture for the Hybrid School

In lack of better words I have chosen to name this school for hybrid school since the practitioners within this school don’t see the two former schools as pragmatic in their quests for practicing Enterprise Architecture and they combine both the process oriented methodology and the benefits of blueprinting.

As earlier mentioned the focus of the blueprinting is to create valid meta-models that can be used to communicate the current situation and the desired situation for the enterprise. The models are usually developed through a process of communication with the stakeholders and through the expertise of the chief architect and the enterprise architects. The enterprise architects applies a framework of which they identifies through a framework that has been selected or developed by the chief architect.

The process school deals with applying a program and project management methodology in order to establish a continuous process that enables that the enterprise’s corporate strategy can be crystallized.

The practitioners and the academics working with Enterprise Architecture establish a process for implementing the blue prints of the enterprise architecture.

The Hybrid school is of my opinion a suitable foundation for establishing an Enterprise Architecture program in almost any enterprises due to any Enterprise Architecture program have to be modified to deal with the individual situation for the individual enterprise. I believe that all enterprises are unique due to their employees, managers, executives and the story for how the enterprise has developed, and all of these elements have an impact on how the enterprise is able to deal with the competition. The degree of competition has a intern a significant impact on how many resources that the enterprise is able to adapt new technologies, processes and people in order to gain advantages that might or might not lead to competitive advantages.

The stakeholders in each of the enterprises sees the world differently and it can’t be an advantage to lock the Enterprise Architecture approach to one particular approach if what is needed is an approach that can deal with both project methodology and blueprinting.

The Future of Enterprise Architecture: Approaching the Next Generation Enterprise Architecture.

What Enterprise Architecture is Today

Enterprise Architecture origins from the Information Systems world as a form of documentation. The initial idea was known as Enterprise Information Architecture and was presented by John Zachman as way to make a blueprint of the IT usage in an enterprise. He claimed when working with a blueprint then it would be easier to make some form of coherent decisions.

This particular approach developed from what was seen as the Zachman checklist (typically a jargon applied by theorists within the TOGAF-framework.

What Enterprise Architecture Should Become

The question then becomes what Enterprise Architecture should become. There is potential in working with integrated governance. This means that enterprise architecture needs to evolve from being an IT centric approach to articulate and initiate projects that create alignment between IT and the business.

The most widely used generic framework is TOGAF that is developed and maintained by the OpenGroup, and it is only recently in version nine of the TOGAF-framework that the element of organization was added. This is a clear indicator that slowly but surely the concept of Enterprise Architecture starts to address other parts of the enterprise than IT.

In other words Enterprise Architecture should emphasize more on integrated governance that ensures that the enterprise is able to execute the strategy that has been articulated. The execution process will have to entail components of the enterprise like corporate capital planning, workforce planning,, security planning, IT planning & governance, supply chain management and innovation management. During the process of developing Enterprise Architecture there will probably come new issues the organizational aspect while the change is taking place, and therefore will have to become an evolutionary process that develops over time. This particular topic will be dealt with in the next section, and since it is a focus on persons, then it is very likely that the community that practice Enterprise Architecture would have to adjust and change their idea.

When speaking of organizational aspect and then the next generation of Enterprise Architecture has to address managing of virtual enterprises as well as the concept of Enterprise 2.0 .

How Enterprise Architecture Becomes Holistic

To enable enterprise architecture to move away from the IT-centric to become a holistic approach to integrated governance, then the progress will deal with embed management, organization and strategic approach into the enterprise architecture frameworks.

My definition of framework is a method that leads to integrated governance. The progress towards integrated governance is dealt with through enabling a holistic understanding of how the enterprise adapts to the understanding of how the enterprise works. The understanding can only be achieved if the enterprise organizes its findings in an enterprise wide repository that is visible for all actors in the enterprise.

The holistic management approach needs to address something that is classically been associated with change management and it is in many ways dealing with feelings and attitudes on collaboration among the various factors in the enterprise.

Enterprise Architecture is performed through a community of Enterprise professionals (in major complex enterprises), consultants who are loosely mingle with many different clients and not to forget academics and students who study and develops on enterprise architecture, and it is essentially these people who have to change their mindsets to address Enterprise Architecture in new ways and thereby develop the concept of Enterprise Architecture. As it is with science and theory so it is with diffusion of science and technology so it is with the diffusion of Enterprise Architecture. It rarely comes in revolutions and therefore it most likely will become an evolutionary process where case studies needs to be done and communicated.

Conclusion

In conclusion it is a necessity to go from IT centric designs as the primary approach has to be dealt with since it doesn’t lead to a particular competitive advantage, and since most problems the enterprise faces are systemic and not particular within the field of IT. Enterprise Architecture as a concept is compatible with thinking in systems and sense making and therefore is it likely that the future of Enterprise Architecture will be working with sense making and enterprise wide problems in the corporate strategy.

The transformation process is a hugh process with many obstacles, and it is for sure it will take time to handle the problems of change since it is an entire community that changes its mindset. The way to make the community change its mindset is through the various educational programs and through changes the ideas within the networks for Enterprise Architecture.

The primary problem will be changing the culture and the mindset of the practitioners of Enterprise Architecture, but the challenge is not impossible to cope with.

Appendix

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

Mcafee, A., 2009. Enterprise 2.0: New Collaborative Tools for Your Organization’s Toughest Challenges, Harvard Business School Press.

Pasternack, B.A. & Viscio, A.J., 1998. The Centerless Corporation: Transforming Your Organization for Growth and Prosperity in the New Millennium, Simon & Schuster Ltd.

The Foundation for Coherency Management: A Framework for Change.

A Framework for Organization to Embrace Coherency Management

When an organization choses to pursuit the implementation of Coherency Management then it the organization have to focus on organizational change. The idea of the organizational change is when the managers, middle managers and the employees will have to work in a different way and humans and organization culture have a tendency to be conservative and react hostile against change.

For this the Coherency Architect should focus on how create the proper form of change within the organization.

A Quick Summary of Coherency Management

Coherency Management deals with how to achieve alignment, agility and assurance through maturing the enterprise’s Enterprise Architecture. According to Doucet et al (2009) then there are three stages for an Enterprise Architecture. The first one is the form that is called the Foundation Architecture which is typically led by the IT department and sponsored through the CIO. The second stage is the so called extended enterprise architecture where both the business side and the IT-organization have adopted and applied Enterprise Architecture to expose the current situation (AS IS architecture) and is used to manage the enterprise’s strategic, business and technology elements.

The third and last stage is called the Embedded Architecture. This particular form of architecture is defined by the most employees in some way or the other work with the Enterprise Architecture. However there are two forms of Enterprise Architects. The first form is the explicit of architect of which there can be defined to dominant forms. The mature and advanced form of Enterprise Architects that are working with an established architecture office that handles the various forms of strategies to create a so called coherent overview. The other form of explicit architect are working with various sub architectures such as the business architecture, technology architecture or the solution architecture.

It is worth to mention that these three stages of architectures are supported by Herzum in his 2003 paper on the topic.

The Framework

When dealing with organizational change then the Coherency Architect needs to work with developing and internal pressure for enabling change. The question can be if the organization is loosely coupled or not. In this particular framework the assumption is that the organization (enterprise) isn’t loosely coupled.

When the organization (enterprise) isn’t a public given monopoly such as the Danish postal services then it will face competition. The competition deals with that the competitors will work for gaining market share this is done through various strategies and those enterprises that sees that they can’t make money in a particular market focuses on differentiating their products or services.

The various moments the competing enterprises makes are in a way a path to more innovation (since it emphasis the development of new products or differentiating the products e.g., make products of a better quality), and this can be defined as a part of the external pressure. It is worth mentionable that not only does the competitors add to the external pressure e.g., the government, press or other external entity. The external pressure can be an enabler for an internal pressure of which is needed to create the urge for change. Change or initiatives for change can be limited through the persistence of organizational culture (as before mentioned organizational culture tends to be rather conservative) and urge is a feeling among the actors within the organization to approve the change initiatives.

It is a preferable situation for the enterprise and the Coherency Architect would be if there can be created a synergy between the external pressure and the internal pressure. This particular synergy would be the burning platform.

When the external pressure e.g., competition, law (regulation) or other element changes in the enterprise’s domino then the Coherency Architect should work with influencing the various groups within the organization that holds some form of power. For this the Coherency Architect needs to produce valid arguments for the need for change and arguments on what to do. For this an elevator pitch can be necessary. According to Bernard (Bernard 2005) then the concept of Enterprise Architecture embraces strategy, business and technology so all of them can be aligned.

The elevator pitch could therefore be something like this “Enterprise Architecture assists in creating a coherent overview of business, strategy and technology”. The elevator pitch has to be supported through an economic and strategical estimation of the benefits that Enterprise Architecture and Coherency Management can add to the enterprise.

When done so then the Coherency Architect should establish an Enterprise Architecture group where he or another person should be appointed the Chief Architect and this person should be granted the resources, responsibilities and power needed to implement an Enterprise Architecture program. Before Coherency Management can be implemented then the organization needs to implement an Enterprise Architecture program and through the principles of Coherency Management evolve the Enterprise Architecture to more than just the “Foundation Architecture”. When establishing the Enterprise Architecture program a suitable Enterprise Architecture framework should be applied e.g., Bernard’s EA 3 Cube framework. The framework should as a documentation form and as a management form ensure that the enterprise’s current projects are investigated and if possible aligned with the strategy, business and technology goals for the Enterprise.

While the Enterprise Architecture program is established then the Coherency Architect should communicate with the sponsors

When the alignment has been established then the Coherency Management framework CoMOF framework should be adapted to the needs of the organization e.g., should issues like repositories be dealt with which leads to the example of the Modular (modular repositories) Coherency Management Framework (needless to say that the framework is based on Doucet et al. basic suggestions for a framework). When the maturing process for the Enterprise Architecture has been matured then it is important for the Coherency Management to verify and moderate the feedback channels that is the foundation of the renewing the Coherency Management and Enterprise Architecture programs and eventually the need for changes have to be implemented along side a new burning platform.

Key Issues

An Enterprise Architecture program should be enterprise – wide and therefore the Coherency Architect will have to deal with resistance to change and for that communication is vital for all the necessary stakeholders. Therefore a communication plan is needed and it has to focus on three particular issues. 1) The stakeholders don’t think like the Coherency Architect. 2) The various stakeholders needs different kinds of information. 3) The need for urgency needs to be enabled through communication and therefore should the Coherency Architect communicate the victories and the victories needs to be sequenced over the period of time one iteration takes and the communication needs to be done in a way that appeal to the feelings of the stakeholders.

Conclusion

When an Enterprise Architecture program and a Coherency Management program is about to be established then it is vital for the success of the program, that the Coherency Architect deals with the issues of pressure to establish a burning platform and then anchor an EA office or for that matter a coherency management office to the power bases in the organization. When done so communication about victories has to be prioritized and sequenced to so the stakeholders continue with their support for both the Enterprise Architecture and Coherency Management program. Since Coherency Management is based on the foundation of Enterprise Architecture then it is a necessity that the EA program is anchored first and for that the proper approach is to apply an EA framework e.g., Bernard’s Enterprise Architecture 3 Cube Framework and use the EA program to align the business and IT projects of the organization to support new or improved business processes (TO BE architecture) that are dictated by the corporate strategy.

When the EA program has been established then the usage of a Coherency Management framework needs to be implemented and the framework needs to be modified to the needs of the particular enterprise e.g., by adding multiple repositories.

When both the EA program and Coherency Management program has been established then it is vital that the Coherency Architect ensures improvement and that can be done by established and routinized channels for verification and feedback.

The need for adaption to the domain of the organization will lead to a continued demand for the establishment of a burning platform.

Sources

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

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

Herzum, P., 2003. Applying Enterprise Architecture. Cutter Consortium Executive Report, 6(3), 36.

Kotter, J.P., 2008. A Sense of Urgency, Harvard Business School Press.

Download the paper 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.

Implementing Enterprise Architecture: From a Coherency Architect’s Point of View!

Organizational Change

In most organization it has been the IT department and the Chief Information Officer (CIO) that has initiated the Enterprise Architecture program with an IT department’s focus. The IT department’s focus is often based on that the IT department wants to clarify how the organization operates (operation model) and makes use of the artifacts that it has collected through the initiating of the Enterprise Architecture program. This often leads to a business to IT alignment process where the

The Change of Focus

The IT focus can in many ways be a good approach to start with; however the IT approach only gives the organization limited possibilities with working with Enterprise Architecture since the rest of the executive team often aren’t responsible or even evaluated on how well the Enterprise Architecture program is performing. This means that they rarely will take the EA program into consideration or assist in making the EA program more successful for the organization. Therefore it can be necessary to force a change of focus.

Replacing the CIO

The necessary change might come through that the organization chooses to replace their current (and often technically minded) CIO with a new CIO that has been engaged with the business side of the organization. This often eases the communication with the executive team and not to mention the Chief Executive Officer. This will eventually bring another perspective to the Enterprise Architecture program. The EA program will go from being IT minded to be organizational minded. This will in time evolve and mature the architecture from being the foundation architecture to become the extended architecture (Doucet et al. 2009).

However then replacement of the CIO is not enough to create the new focus. The focus has to be implemented along side an organizational change program that has to focus on how achieve desired changes in order to gain a competitive advantage or advantages such as agility, assurance and alignment with the goals of the organization. Since there can be a lot of bad will (Bjorn – Andersen & Marcus 1987) towards the IT department within the organization then it is a necessity to alter the organization culture and that can often only be achieved through organizational change programs. To initiate the organizational change program then the EA board, the Coherency Architect and the Chief Architect should address the various stakeholders in the executive group where the primary focus should be to communicate the value (including strategic value) of Enterprise Architecture to them.

The Extended Architecture

The Extended Architecture is characterized by being the advanced step of Enterprise Architecture and by maturing the architecture then the organization will be able to achieve results through that through working with Enterprise Architecture in both an IT context and a business context will make the organization able to know more about its architecture (the way the organization is designed and works (operation model), When doing so then the organization will be able to commit to better governance and decision making.

The assurance through knowing the business processes and the technological platform ensures that the organization will have a chance of applying new business processes that will enable the organization to achieve a strategic advantage.

Forms of Architectures

Forms of Architectures.

Conclusion

The Coherency Architect and the EA board should communicate the value of Enterprise Architecture to the executive team. The Executive team should be working with identifying the need for change to achieve to mature the enterprise architecture from the foundation architecture to the extended architecture and communicate the ideas (and benefit of changing) to the executive team. Eventually if the CIO hasn’t been able to communicate and influence the executive team to buy in to the Enterprise Architecture program then the CIO should be replaced. The successor should be a person from the business side so the Enterprise Architecture program is able to change focus.

Sources

Markus, M.L. & Bjørn-Andersen, N., 1987. Power over users: its exercise by system professionals. Commun. ACM, 30(6), 498-504. Available at: http://portal.acm.org.esc-web.lib.cbs.dk/citation.cfm?id=214762.214764&coll=portal&dl=ACM&CFID=22716975&CFTOKEN=73079095 [Accessed February 20, 2010].

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

Download the blog post here.

An Introduction to Coherency Management: A keynote with Gary Doucet @ ITU 2009.

The Basics of Coherency Management

Enterprise Architecture is a discipline is about 30 years old. Based on a paper by John Zachman who worked at IBM at the time. Enterprise Architecture is evolving over time and currently it is improving the coherence of enterprises to bridge gaps in organizations and enterprises. Coherency Management is for using Enterprise Architecture to advance the alignment, agility and assurance. It might lead to that IT will help the enterprise in doing its business. To explicitly manage coherency which is a new perspective within this discipline. Coherency Management as a concept is not about if the company is a success or not but a way to investigate the enterprise to find factors that enables the organization is coherent with its goal and processes.

The explicit architecture will assist the management on future development of the organization, its processes and its way to function as an organism.

People is the key in relation to rapid change (and a barrier). This perspective is supported by the view that Chris Potts introduces in his “fruITion strategy”.

Enterprise Architecture is about people” – Chris Potts, IT University of Copenhagen 2010.

Enterprise Architecture is often a Chief Information Office lead project. The main purpose of the Enterprise Architecture is building good IT systems and the Enterprise Architecture project is disconnected from the rest of the organization. Every organization has an architecture. The purpose of the Enterprise Architecture is to make the architecture better.

Ross and Weill (2005) fell into a trap with their definition of Enterprise Architecture since it is way to technology orientated. It should be on how to improve the way the organization does its business.” – Gary Doucet, IT University of Copenhagen 20091.

In general there are four forms of architectures. The first is formalized architecture and the second the un-formalized architecture. There are however three modes of Enterprise Architecture where the more advanced form is called foundation (the extended mode of Enterprise Architecture) where the architects is focusing on understanding the business. The most advanced form is called embedded Enterprise Architecture where you find the process owner and make them modifying the processes.

An example of harvesting artifacts is the government of Canada where the chief of treasure wanted to know about the services they provided for the aboriginal community (first nations) and he therefore asked the best analysts in his administration to find the information; however it took about six months before they finished the process to understand what happened.

Enterprise Architecture is the inherent (existing as permanent and separate) design and management (management and control) approach (you need an approach that works for your organization) essential for organizational coherence leading to alignment (aligning the components of the organization with one another), agility (the ability to change quickly) and assurance (to check up that the products and services and administration is done correctly and accordingly to the corporate strategy).

People always focus on projects but the steady state should be the focus. The Enterprise Architecture is a continuous improvement model. If the organization gets a coherent view then the management and the employees eventually do better decisions. Coherency Management is a new concept but it incorporates existing elements, applications and objectives of Enterprise Architecture but in particular new aspects in particular:

  • Incorporating other process owners.

  • Managing coherency explicitly.

  • Enterprise Architecture as a continuous improvement agent, not simple “AS IS”, “TO BE” and the way to get there.

  • The coherency planning office should be in charge of the coherency project(s).

It is not a new name for Enterprise Architecture. It should be considered a practice within Enterprise Architecture. It is not a project. It is not a demotion for chief architects. It is not an attempt to control all management functions. It is not a quick fix. It is not something that only pays back in 15 to 20 years.

The next thing which has to be implemented in Coherency Management is a measuring model and the involvement with consultancy community.

1The 18th of September 2009 a Keynote at the E-business Association at the IT University of Copenhagen.

Download the paper here.

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!$

Architecture Maturity

Coherency Management is about gaining agility, assurance and alignment and these gains are closely linked to the maturity state of the architecture of the organization. All organizations have an architecture the question is how matured it is.

It is therefore desirable for most organizations to one way or the other to identify, mature and monitor the process. Before the identification takes place then the various characteristics of the architectures have to be dealt with.

The Architectures

In this section I will shortly deal with the architectures that are presented by Doucet et al. (Doucet et al. 2009)

The architecture that hasn’t been exposed to Enterprise Architecture and as a result of this the management or other actors in the organization are not aware of how the organization, its processes and its various layers are designed and interacts. This includes that the organizations isn’t aware of how their IT is used to support the various business processes.

The Foundation Architecture is an architecture that has been exposed to Enterprise Architecture; however this has only been applied for the IT side of the organization to bridge the gap between business processes and IT. In this state the Chief Information Officer (CIO) and the IT department has a great influence on how the Coherency Management tools are applied though this a downside and that is that the rest of the organization rarely understands the idea of Enterprise Architecture.

The Extended Architecture is bit more mature in the context of applying Enterprise Architecture. In context this means that other departments in the organization have identified that Enterprise Architecture tools can be made use of to improve the ability of the organization. In relation to who is in charge for the Coherency Management implementation then it is likely that this has passed from the CIO.

The Embedded Architecture is the so far the most mature level an organization can reach by applying Enterprise Architecture tools and change management. This means that the entire organization make use of Enterprise Architecture tools identify, initiate and implement new processes. This means that the organization has enforced a framework that has to be taken into consideration when new processes have been applied.

In addition to the above mentioned architectures the Balanced Architecture (Doucet et al 2009 p. 224) can be added. This is a future state within the Coherency Management concept.

I will therefore discuss the tools that can be applied.

Why Should Architectures be Matured?

When an architecture matures then the organizations that make use of them also become more agile and better in the sense that the organization easily can implement new processes, flows, systems etc.

This means that the organization can gain value for its stakeholders if the organization apply Enterprise Architecture tools to mature its architecture.

The Tools

There are several tools that can be applied to identify and monitor the state of the organization architecture. I have chosen to make use of Barnard & Grasso (Doucet et al. 2009) that have written a chapter which deals with how Enterprise Architecture can be matured.

According to Barnard & Grasso then these factors are useful to measure:

  • Enterprise Budget & Procurement Strategy.

  • Strategic Governance.

  • Extended Enterprise Architecture Architecture Results.

  • Extended Enterprise Architecture Developments.

  • Extended Architecture Program Office.

  • Business Units Involvement.

  • Executive Management Involvement.

  • Extended Enterprise Involvement.

  • Business & Technology Strategy Alignment.

The above mentioned indicators can be used to identify on what state the organization is on. If the organization is pre-dominantly in the un-mature part of the scale e.g., that the organization has an un-mature architecture. If the organization in any way has indicators that indicates that the organization is on a better level than the sublevel then the Coherency Architect should assume that the organization is maturing its architecture (perhaps implicitly).

There are methods that can be used to mature the architecture. For this the EAAM approach can made use of. The EAMM approach deals with how the Coherency Architect can measure and audit the architecture of the organization.

Control

As with all plans then it is a necessity to work with auditing and control which deals with controlling if the various goals used in the EA programs have been realized. This process is mandatory for every Enterprise Architecture project as it is for every strategic approach.

For this an Enterprise Architecture Audit Program should be established. According to Barnard & Grasso there are to forms for such a program. The first form is the light edition that consist of one to two persons who audit the EA programs in the organization. The analysis of the organization is build upon a superficial (high impact) analysis. The other is the advanced program where two to five persons go through a complete analysis of the EA program.

Coherency Maturity MindMap

Coherency Maturity MindMaps

Sources

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

Further Reading

Extended Enterprise Architecture Model (E2AMM v.2.0) (www.enterprise-architecture.info)