Tag Archives: EA Program

The Architecture Crystal Ball: Predictions for 2012

I have had the opportunity to read several documents containing estimations on what the chief architects and CIOs should expect of the concept of Enterprise Architecture in 2012.

As a result I have made some thoughts of my own, and my thoughts have been delimited to what could happen in Scandinavia. There are reasons for when or where the organization should develop.

Most of the articles that I have read in order to identify the potential development of Enterprise Architecture in 2012 were developed by American organizations and my assumption is that American organizations usually apply an American approach to dealing with problems at hand, and as a result my view might differ quite a bit from the trend analysis that organizations like IBM, Gartner Incorporated, The Open Group, Microsoft or other organizations might have articulated.

Below I have defined four areas that organizations will invest their resources into.

Frameworks and Models

  • CIOs, it-management and the chief architect have discovered that it is unlikely that they will gain a total overview of all systems available in the enterprise and they will focus on developing a few key models.

  • The chief architects will continue investing time and effort into deployment of frameworks, but the chief architects would still have to mix “best of breed” from the frameworks in order to implement the enterprise architecture program.

Investments Planning and Governance

  • Medium and major organizations will begin to add their IT investments to their Enterprise Architecture models, since it is presumable that this would add value to the decision platforms.

  • The investment planning will still be focused on the IT-spending and only to some degree on how information technology takes part of add value to the business.

Technology Foresight

  • The Enterprise Architecture programs will still be IT-centric; however the structured methodology for collecting data about the enterprise architecture will provide the chief architects with the opportunity to impact the IT – strategy, and as such they could have a chance to evolve the enterprise architecture program.

  • The Enterprise Architecture programs will be used in order to define strategic approaches to what sort of technologies that make sense to invest in. As such the chief architect can gain a leading role in articulating the it-strategy. In order to do so the chief architect would enable a platform where realistic scenarios for implementing technology in order to give the decision-makers a realistic insight on what they would have to deal with.

  • The debt and credit crisis will in 2012 impact the organizations in a way that increases the demand for a smarter usage of the information systems and technology platforms available. The smarter usage of information systems demands an approach to information governance and reliable information.

Principles, Standards and Methodology

  • Organizations will find out that without principles for how to deal with different perspectives of developing their IT architecture, they will not be able to enforce the desired behavior. As a result organizations will invest more time in articulating principles.

  • EA assurance for the IT architecture will be a hot topic during 2012, and the organizations will eventually initiate projects that will focus on the articulation of principles based upon criteria like when does the principle apply, when can the developers differ from the principles, when should the principle be updated and who is responsible for updating the standard?

  • Standardization will likewise become a dominant topic, and many organizations will initiate projects that supports the development of it-projects enhances customer experience (platform independent and mobile). Management of standards are vital in order to ensure the development of these projects since it it is vital to ensure the data export of data.


Due to the crisis most organizations tries to reduce costs and deliver a better value proposition to its customers. Most organizations can save money through standardization of the their IT-architecture; however the decision-makers would have to know how to deal with gaining information of how the IT-architecture works, how it can be simplified (enhancing speed of development) and how it can be closer aligned with the business processes.

For this, enterprise architecture is essential and that is how I see the usage of enterprise architecture in Scandinavia in year 2012.

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.



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.


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.


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.

The IGIA-Framework

During the summer of 2010 I worked with a literature review that basically dealt with how Enterprise Architecture (through Coherency Management) could be addressing the issue of rewiring the form of leadership which exists in the enterprise.

The IGIA-Framework is a form of synthesis of various theories within the field of corporate governance, IT strategy, IT governance, Workforce planning, Enterprise Architecture and Coherency Management.

The edition of the framework that is released with this blog post is advocating a big bang change approach which demands a lot of resources and a long term commitment. This will be altered with the next edition of the framework which I plan to release during 2011.

The IGIA-Framework needs to address the short turn achievements while using Enterprise Architecture and Coherency Management, and for that reason should the IGIA-Framework be evaluated and developed into a framework that can enable enterprises with gaining a better form of leadership, structure, architecture and not to forget a chance to achieve a sustainable competitive advantage.

With these words I publish “Integrated Governance: A Way to Achieve Competitive Advantage” the certified edition.

Download the literature review / IGIA – Framework 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.

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.


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.


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.

Extending and formalizing the framework for Information Systems Architecture

The Concept of the Framework

The framework can in some ways be compared to techniques such as the flowchart (that was introduced by John von Neumann back in 1945. The flowchart is fine for many different issues and a flowchart is good to illustrate algorithms and flow of goods and processes.

Entity – relationship diagrams are used to show entities among various objects, processes and databases.

The purpose of the framework is to show how everything fits together and how they interacts. There are 30 boxes that are organized in six columns. The 30 cells or boxes are indeed intended to subject matter which means it is possible for those identify the various artifacts and deal with them in each cell.

Overview of the Framework

The framework has several minor items that can be categorized or organized as:

  1. The Scope which is the first architectural sketch which is known as the bubble chart. In the ISA framework (Enterprise Architecture) it is equal to an executive summary.

  2. Enterprise or business model this is the professional drawing at an architect. In the ISA context then this is equal to the business model to the organization.

  3. System model which is equal to a list of specifications. In the ISA context this is equal to a system model designed. The model presents the information and the models that are linked to another.

  4. Technology model which is equal to a contractor that has to redraw the architect’s plan. The model serves as a way to constrain the technology. The technology model is dealing with the programming language, I/O devices or other technology.

  5. Components which in a architecture perspective deals with the sub-contractor work out a specific plans for the building a building. In an ISA context deals with the programmers or actors are aligned with a broader context so sub-optimization is handled in a proper way.

The Extended ISA Framework

Rules of the framework needs to be taken into consideration and dealt with to understand how the framework works:

  1. The columns have no order. Order would imply priority and since the cells are equally important.

  2. Each column has a basic model. It is important to understand that each model is representing a simplified version of the world. The focus is to ask what, how, where, who, when and why.

  3. The basic model of each column has to be unique. Zachman is of the opinion that the cell is unique.

  4. Each row represents a distinct and unique perspective.

  5. Each cell is unique. This means that the cells should be checked twice while the framework is applied to the current situation.

  6. The cell model are made of the perspective of the row.

  7. They logic is repetitive.

The EA Management Program: From the perspective of a Coherency Architect.

Why a Program and not a Project

Enterprise Architecture is dealing with configuring many different components of an organization (Bernard) and these components can rarely be configured properly through a big bang change as a project would usually be. A program can be defined as a series of projects that will change different components in a evolutionary approach.

Since Enterprise Architecture and Coherency Management is dealing with more than people then it the changes can’t be implemented with a big bang approach since it will either fail by the people will go back to the old way of doing things or they will be overworked in changes (of which John P. Kotter has written the book titled “Creating the Sense of Urgency”).

Therefore should the Coherency Architect work with establishing a so called Enterprise Architecture Program (EA Program) or more advanced a Coherency Architecture Program. The difference between the two types of programs are that organizations that works with the Coherency Architecture program can be identified as having an Enterprise Architecture titled as “Extended Architecture” and above.

The Enterprise Architecture

First of all the Coherency Architect needs to identify the AS – IS Enterprise Architecture to understand the enterprise architecture as it current is. When the Enterprise Architecture has been investigated and a significant overview has been created then the Coherency Architect should develop a transition plan. The transition plan that is known as the Enterprise Architecture Management Plan. The plan is foremost a documentation method.

The Enterprise Architecture Management Plan

The plan is the transition between from the ”AS IS” (the current state) to AS IS (the future state). This means that the organization needs to launch a series of projects that enables clarifies the business processes (business architecture, the information systems and data needs (the information architecture) and how the various technical platforms operates and interacts (technical architecture).

If the organization chooses to apply Bernard’s EA3 Cube as the preferable EA approach to document the “AS IS” state for the Enterprise Architecture then the Enterprise Architects have to investigate the five levels from a top down approach. The first level is the goals and initiatives, the second layer is products and services, the third layer deals with data and information, the fourth layer deals with systems and application and the fifth layer deals with network and infrastructure.

The EA3 Cube.
The EA3 Cube.

The documentation process is often costly and it takes time; however by investigating the Enterprise Architecture then the architects can aide the top management of the organization by identifying gaps and potentially inefficient processes and systems that needs to be replaced or upgraded. When the gaps have been identified and the top management has given its permission to initiate the the transformation then the EA program can be established.

The program can be defined as a set of projects that all have that in common that they deal with components of the Enterprise Architecture. For that it is necessary to understand how the EA related projects are to be defined.

The EA Related Projects

The projects are usually strategic and the outcome of the projects impacts either the business architecture, the information architecture, the application architecture and the technological architecture or all of them.

An example of such a project is the implementation of a new ERP software application or implementation of a new project management flow system.

The two mentioned projects have an impact on their respective architectures; however if they are implemented the proper way where the business processes are re-defined then they will impact all the architectures (for that principles needs to be articulated).

These projects needs to be evaluated to identify how they contribute to the transformation of the Enterprise Architecture. In this process it is notable that the projects shouldn’t entirely be evaluated on economic costs and benefits (TCO and ROI) but also on how the projects enable the organization to accomplish its visions.


The EA management plan needs to be taken into consideration when organization begins to achieve success so management is able to react to potential gaps there might be in the organization. In the same time there will be a need for the Enterprise Architecture Management Plan to obtain knowledge of ways to innovate the organization and enhance its ability to develop new products and services if not to mention compete for market share or resources.


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

Download this paper here.