Category Archives: Organization

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.

Innovation in an Enterprise Architecture Context: Innovating the Business Processes, Technological Services and Corporate Strategies.

Innovation

This blog post deals with innovation in regards to the Enterprise Architecture program. I’ve been able to identify two different approaches to innovation. The first approach to innovation is what I define as incremental innovation. The second approach to innovation is radical innovation. In most cases incremental innovation is innovation in social systems where small improvements have been introduced to the social systems.

Likewise is radical innovations forms of innovations that fundamentally changes the social systems e.g. how they work or how they interact with one another.

Likewise is the concept of innovation extremely context dependable. For one social system a particular approach could be considered an innovation where the same concept could be considered old news. Innovation, could as before mentioned, be incremental saying that a new way to deal with the piece of technology or business activity. Likewise could the same situation be radical if the technology never had been used before.

When it comes to innovation and applying it in the context of the enterprise the question of adaption would have to be dealt with.

Adaption

Rogers speaks of how the innovations spreads to the various organizations, parts of the organizations and people. In this process there are five stages before the people of the enterprise would be able to fully apply any given form of innovation.

Innovation defused by that people observer other people who have success by applying the particular innovation in order to solve problems or to certain things in a new way that benefits them and their social structures.

Social systems shares a culture that is shared among the individuals who interact with the social systems. The purpose of the culture is to give the members of the enterprise a sense of security against the ever changing environment that the members of the enterprise is situated in. Culture is usually against changes and thereby against innovations. However there are also cases that suggests that culture can be used to enable the enterprise with innovation if the executives and middle management gives the employes the proper amount of trust.

In other words Enterprise Architecture has to be adapted to the enterprise that is about to invest in the program and as such the Enterprise Architecture program can be seen as an incremental innovation and a radical innovation depending on how the decision makers and the stakeholders sees the implementation process.

Innovation and EA

In regards to enterprise innovation the focus of Enterprise Architecture would be to deal with the processes in the enterprise. For enterprises the idea of incremental innovation would be dealing with the processes in small steps while radical innovations would be innovations that are “game changing” for the enterprise. In this particular light it is a necessity to see Enterprise Architecture as a form of continuous innovation for the enterprise and as such a container for future innovations and as such can the Enterprise Architecture program become a barrier for the innovativeness of the enterprise.

It easily become a fine act of balancing between the rules, standards and principles and the necessity to crystalize solutions for the various unplanned situations that the enterprise experience. Ciborra named this the concept of bricolage (or organizational hacking). In order to facilitate bricolage it is a necessity for the decision takers to empower the employees of the enterprise by allocating power and accountability to the middle managers or the employees. As such this should give the enterprise the necessary platform in order to make bricolage works.

Innovation in this context could be facilitated by the various stakeholders of the enterprise and through the Enterprise Architecture program the concept of innovation could empower the alignment and the agility of the enterprise.

Enterprise Architecture

So what is Enterprise Architecture all about? I’ve chosen to define Enterprise Architecture as a program that deals with the various projects that the enterprise works with in order to change its architecture. However this can not serve as a definition since it doesn’t include some of the most important elements of Enterprise Architecture. Enterprise Architecture as a concept includes an element of documentation of the current architecture of the enterprise (known as the AS – IS situation) and an element that deals with how the future architecture of the enterprise should be like (the To – Be situation). Different communities of practice within the ecosystem of Enterprise Architecture practitioners sees the concept of Enterprise Architecture differently e.g. some sees Enterprise Architecture as a set of processes that constantly ensures some alignment through the implementation of processes and others who sees Enterprise Architecture as a form of blueprinting that ensures that the enterprise develops in to a coherent entity. There are most likely different views of what Enterprise Architecture is all about in the various communities in the ecosystem, and it is almost certain that each book that have been published on Enterprise Architecture works with its own definition of the concept.

My definition of Enterprise Architecture is in this context that Enterprise Architecture (as a concept) consists of a program for documentation of the enterprise’s architecture, a program for identification, specification and development of projects that enable the enterprise to achieve its goals. Likewise does the concept of Enterprise Architecture include the development of standards and principles that are used to govern the enterprise on all levels. When this is said the last component that add to the definition of what Enterprise Architecture is all about is the concept of enterprise governance.

Enterprise governance has to ensure that the enterprise achieves its goals and the goals can only be achieved if there is some kind of innovation in the enterprise. Innovation should in this context be understood as an ability to alter the various parameters of the enterprise.

The Synthesis

I’ve with some inspiration from Leavitt (1965) and his diamond model defined my own model that shows what Enterprise Architecture is all about. Enterprise Architecture is the platform for how the organization executes the business objectives, business processes and technology services. As such the holistic approach to deal with the elements of tasks, business objectives and technology services will have an impact on what kind of employees that would be needed in order to ensure that the enterprise can produce products and services to its customers. Each of the elements impacts the other elements and as such the decision makers (executives, middle managers, team leaders or anarchies) have to deal with the problems through the Enterprise Architecture platform and program.

People are the key when it comes to the breakdown of the classical barriers in the organizational hierarchy and as such it becomes a necessity to deal with people in order to achieve a better and more mature enterprise architecture. It becomes a necessity to deal with the focus of who the enterprise have access to and how the various stakeholders of the enterprise can add to the innovativeness of the enterprise.

While the enterprise adds value through producing products and services to its customers. The various stakeholders in the enterprise do some kind of bricolage or organizational hacking. The concept of organizational hacking can’t be dealt with in any other way and as such most of this “hacking” helps the organization deal with the everyday crisis and as such the Enterprise Architecture program (principles, standards and security) has to take this into consideration and find the balance between hacking and standardization.

While implementing an Enterprise Architecture program the decision makers would have to ensure that incremental innovation isn’t neglected or for that matter locked due to the approach to standards and principles. Likewise should the decision makers work with the concept of bricolage in their assumptions of planning, and as such they should embrace that two, three or five year plans can’t lead to competitive advantages.

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.

 

Enterprise Architecture is more than IT

This blog post is based on the guest lecture that Chris Potts performed at the course B30 Enterprise Strategy, Business and Technology at the IT University of Copenhagen the 25th of October 2010.
It is growing sense around the world that Enterprise Architecture is dealing with more than IT; however since the concept’s origin from the world of IT has often been portrayed as an IT concept, and implemented as a rather IT centric tool.
Chris Potts asked the class at the lecture: “Can you recognize this architecture (this building – showing a picture of the insides of the Sydney opera house). This is a picture from the inside of the architecture. It proved to be the Sydney opera house but it is often hard to identify buildings (architectures) from the inside but it is rather easy to identify it from the outside”.
According to Potts is the biggest difference between an Enterprise Architect and a building’s architect, and that is “a building cannot change its own architecture” but an enterprise can, and Potts views on the definition of architects in enterprises deals mainly with that all the members in the enterprise in some way are architects. When it came to the role of Enterprise Architect is to change the world. Potts made use of the quotation below.
“According to Potts then Enterprise Architecture is about changing the world into something it probably wouldn’t otherwise have been.” – Chris Potts (2010b).
The question then becomes how to challenge the status quo, and the approach doesn’t always tells people what to do. So you may have an architecture but it doesn’t tell people what it is. According to Potts then sometimes the Enterprise Architect need to risk a lot as strategist and you would need to be ruthless.
Potts is of the opinion (an opinion he shares with Mintzberg and Ross & Weill) that strategy has to be embedded into the behavior of the actors within the enterprise. When it comes to behavior then there are two different forms that needs to be dealt with. The de facto behavior and the formalized behavior. The formalized approach to behavior deals with articulating the desired behavior in work structures through formalized descriptions of what is desired into the various artifacts.
When working with Enterprise Architecture then it might be a focus to use an argument as “Enhancing Enterprise Performance With Structural Innovations”. The hard part of this is the structural innovations part. The Enterprise Architect has to force himself to become innovative in using Enterprise Architecture and innovative in ways to improve the enterprise, and to create value for the enterprise as a whole.
“The whole is greater than the sum of its parts” – Aristole
Structural performance of the enterprise architecture is a principle that needs to be dealt with. Chris Potts mentioned that many investors work with analyzing the profits and costs of the enterprise but they usually fail with understanding or investigating if the enterprise is about to collapse from within due to bad architectural design.
There are many fundamental truths according to Potts. The first one is that the structural performance of an enterprise depends on its architecture, and the second one deals with an enterprise has an architecture regardless it is formalized or not.
The third truth that any enterprise architect should adapt is that the actual shape and structure of an enterprise’s architecture is the aggregated output of all its invests in change.
The fourth principle deals with the value of the structural innovation depends on the wider architectural context and last the enterprise architecture is about scenarios not certainties.
In this context the work with the core tactics is that the chief architect should bring both the explicit and implicit enterprise architects and make them work together.
Chris Potts introduced a new framework for change called the double e, double a journey.
Establish and explorer. These two steps are private to the chief architect and the activate and apply are public to the chief architect. It simply deals with taken over the enterprise through a guiding coalition which in principle can be related to the change framework that John P. Kotter who made the famous eight steps for change program (dating back to 1995).

The Scope of Enterprise Architecture was discussed and the class reached the following conclusions:
1. Activities and Processes.
2. Boundaries.
3. People.
4. Capabilities.
5. Resources.
6. Data.
7. Information.
8. Government and governance.
9. Environment.
10. Technology.
According to Potts markets do also have architectures and this approach leads to a fundamental focus on business architecture since the business architecture can’t stand alone to the market architecture. The market architecture contains the customer experience and from this perspective the architectures needs to be aligned to the market architecture to provide what the customers want. The business architecture in the other hand deals with the virtual organization (or more or less the virtual organization) and it is directly connected to the partners and suppliers that delivers materials and services to the enterprise.
According to Potts then structural performance is the key for measuring how well the enterprise is doing Enterprise Architecture. For this a cash-flow analysis based on the annual reports from the enterprise can be applied; however it is greatly encouraged to make use of other forms of analysis to come to this particular approach e.g., activity based costing. This approach might not give a correct view of status quo of the various lines of business and therefore other key performance indicators and methods needs to be applied.
Therefore should an Enterprise Architect make use of context specific strategies for each line of business. The example that Chris Potts made use of was a bit simplified in relation to measuring the different initiatives the enterprise works with; however it is a needed technology.
Chris Potts emphasize that the politics of management and the politics of organization is of great importance when it comes to Enterprise Architecture, and if the chief architect doesn’t understand the dialectic struggle within the enterprise then it certainly will become a problem for implementing Enterprise Architecture, and according to Potts the political aspect of governance is rather often worse in the public sector than it the private sector.
The interesting part about the approach that Potts makes use of is that he actively tries to describe how a chief enterprise architect has to be able to play many roles and he has to be able to facilitate innovation and development issues within both the lines of business and enable the top management of the enterprise to govern the various lines of business. In other words he has to be able to facilitate innovation while tightening control which usually is a contradiction.

Challenges of Enterprise Architecture: A Focus on the Transformation!

Barriers for Enterprise Architecture

When working with adaption of concepts and technology then the enterprises will face issues with to identify the proper solutions in the proper pace and adapt the solutions to the context that the enterprise is within. Likewise will the enterprise face the challenge of adoption. The adoption of the concept or technology.

The first outwards part (identification of potential technology or concepts) has to be diffused by networks that the enterprise linked to. This can be either through so called social networks or through meta-organizations that acts on behalf of many different organizations and sent out information to the different actors within their network. In many cases is the technology or for that matter the concept in some form generic, and the enterprise needs to alter it to make it work in their context. The adoption process (Rogers 2005) as it is called will have to impact various activities, processes and structures within the enterprise, and that will take time.

Usually semi-mature enterprises will be working with an assumption that they will have to make use of project and program management to implement the new concepts or technology. However it is quite clear that the transformation itself will not happen as a result of project management, but only as a result of organizational transformation. It is rather common that the various lines of businesses don’t adapt and incorporate the various projects right away which leads to the realization of the investments isn’t crystallized right away.

It can be concluded that it is the adaption process that fails when enterprises aren’t able to incorporate the projects into their activities.

The question then becomes if the concept of project or for that matter program management will be a particular good way of adapting the enterprise to change when the real focus should be on how to adapt to the organizational transformation, and thereby working with change management instead of project management.

Change management is usually a rather difficult discipline to work with, and many enterprises underestimate the resources needed to implement the resources. When working with adaption of concepts and technology, then the enterprises will face issues with identifying the proper solutions in the proper pace and adapt the solutions to the context that the enterprise is within. Likewise will the enterprise face the challenge of adoption the concept or technology.

The part is the outwards of the organizational barrier (identification of potential technology or concepts) has to be diffused by networks the enterprise is linked with either through so called social networks or through meta-organizations that acts on behalf of many different organizations and sent information to the different enterprises within their network. In many cases it is the technology or for that matter the concept in some form generic, and the enterprise needs to alter it to make it work in context of the enterprise. The adoption process as it is called will have to impact various activities, processes and structures within the enterprise, and that will take time.

Usually semi-mature enterprises will be working with an assumption that they will have to make use of project and program management to implement the new concepts or technologies. However it is quite clear that the transformation itself will not happen as a result of project management but only as a result of organizational transformation. It is rather common that the various lines of businesses don’t adapt and incorporate the various projects right away which leads to the realization of the investments isn’t crystallized right away.

It can be concluded that it is the adaption process that fails when enterprises aren’t able to incorporate the projects into their activities.

The question then becomes if the concept of project or for that matter program management will be a particular good way of adapting the enterprise to change when the real focus should be on how to adapt to the organizational transformation, and thereby working with change management instead of project management.

Change management is usually a rather difficult discipline to work with, and many enterprises underestimate the resources needed to implement the resources.

Win Over The Opposition

In most literature that has been written about how change management works with the assumption that an enterprise can be unfreezed, moved and freezed. The initial idea was proposed shortly after the second world war by Kurt Lewin. The assumption was based on that the organization was a tightly coupled social system where the actors thought and acted alike. However this might not be the case for most enterprises if they are slightly more complex than the average entrepreneurial organization. For this Karl Weick introduced the loosely coupled social system. In the paper Weick wrote together with Orton in 1990 they state that there are eight forms of loosely coupling among the various components of the enterprise:

  1. Individuals.

  2. Subunits.

  3. Organizations.

  4. Hierarchies.

  5. Organizations and Environments.

  6. Activities.

  7. Ideas.

  8. Intentions.

This means that it isn’t as easy as Kurt Lewin proposed it was to change enterprises. It is a rather complex processes where the influences of the various connections and couplings with the components of the enterprise. It is very likely that the various components will be influenced by their contexts and thereby by their domains.

It is notable that in every organization there will be different forms of coupling among the various components and some will be more tightly integrated than other. Therefore should the eight forms of coupling be understood as a stereotyped view that needs to be customized. In his book “managing the unexpected” that burning platforms aren’t the way forward if the enterprise has to transform for the better, since it is already to late when the burning platform is present.

The Burning Platform?

Therefore should the burning platform be a last solution. The concept of the burning platform was originally published in the Kotter’s (1995) article dealing with managing change. The first part of working this particular change approach is creating the burning platform and for that the executives needs to create a crisis so it is apparent that the enterprise needs to change or extinct.

When the burning platform has been established then Kotter works with a framework that contains eight steps that needs to be followed to implement change. All of the steps are useful but the primary problem is that the approach to change is based on Lewin’s eight steps for change.

It might make the framework for change useless but the rest of eight steps might be useful if it is combined with social networks theory and defining how to approach the loosely coupled systems. Likewise does the enterprise need to institutionalize a culture that accepts when the managers and employees makes mistakes and support them when they report when the mistakes happen so the damage of the mistakes are coped with.

In conclusion it is a necessity to handle the change approach by blending it with the views of Rogers, the views of Weick and the view of Kotter. As it is with all generic frameworks it has to be adapted to the individual enterprise otherwise will the benefits not be realized by the enterprise.

Enterprise Architecture and Organizational Transformation

It is needless to say when implementing an Enterprise Architecture program then it will lead to a need for change in the organization and it handles a lot of its activities for working with documentation, communicating and not to forget how to prioritize projects and organize them into programs. The changes in tasks will impact the organization structure, the people who have been employed, and the technology that has been implemented.

If the enterprise already has implemented a functional Enterprise Architecture program then it is likely that the enterprise will have to identify that the various problems that the Enterprise Architecture program has identified and the transformation phase of the critical business processes. The Enterprise Architecture program will lead to further change through iterations and eventually the program will have matured the Enterprise Architecture. When the Enterprise Architecture has matured then a lot of other elements of the enterprise will be influenced by the concept of Enterprise Architecture program.

Projects Don’t Transform the Enterprise

Projects alone aren’t contributing to change within the enterprise. Usually projects are groups that are established with members from the Line of Business or the Lines of Businesses and when the project has been delivered the project team is usually dissolved and the project is handled over to the line of business. It is in the line of business that the change needs to occur if the business processes have to be changed. Therefore it is the Lines of Business and their ability to adopt the project deliveries that is the key to a more agile enterprise.

Sources

Kotter, J.P., 1995. Leading Change: Why Transformation Efforts Fail. Harvard Business Review, (March – April 1995), 9.

Orton & Weick, 1990, Loosely Coupled Systems: A Reconceptulation.

Rogers, E.M., 2003. Diffusion of Innovations 5th ed., Simon & Schuster International.

Weick, K.E. & Sutcliffe, K.M., 2007. Managing the Unexpected: Resilient Performance in an Age of Uncertainty 2nd ed., Jossey Bass.

Loosely Coupled Systems: A Reconceptulation.

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

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.

The OIO-Framework: The EA Framework Designed for the Danish Public Sector.

The Public Sector has to take Charge of its IT Architecture

The public sector has had a sector wide view on IT investments (that includes investments in information systems and architecture) that they should focus on purchasing the cheapest and most relevant solution.

The cheapest solution has often led to that the solution has been developed with in a narrow scope. This has had an impact on the IT architecture since it has been optimized for the local department or unit. The result of this is in general not desirable since the government in 2003 articulated goals for that the architecture should be scalable and reusable.

The suppliers to the IT architecture are still in charge of developing components and implement the business logic. The public sector then have to demand a common set of standards to enhance interoperability.

The reason for the public sector should promote these demands are that the level of competition will become more intense which will be an advantage for the public sector.

The public sector has to realize that if it wants to be ahead of the suppliers and thereby gaining a competitive advantage then it should focus on developing its employees in the skills of Enterprise Architecture or IT Architecture Management.

According to John Goetze the reason for why the public sector (the ministry of Research and Science) chose to name the concept IT Architecture due to the secretary of Research and Science preferred the name “IT architecture” compared to the title “Enterprise Architecture”.

A common IT Architecture Framework

The framework focuses on coordination, a common set of methods, a common choice of methods, systems and principles, and common tools.

The common coordination deals with that the public sector should establish a committee that create the common IT architecture that public sector should mature and develop. The common frame of method is a common standard of processes, concepts and processes. The common choice of systems and principles deals with the public sector should deal with standards and infrastructure that should led to a reference profile and a Service Orientated Architecture.

The common set of tools deals with establishing common databases, libraries, contracts, description of processes, definition of data, software components including descriptions of infrastructure solutions.

Consequences

To promote the usage of IT and the be able to scale the systems across several departments, ministries, counties, communes and other public administrative sectors and institutions can make use of the stored data.

The public sector will experience that the costs for developing the IT architecture and the costs of the processes will also diminish over time.

However when the organizations within the public sector in one way or the other invests in a new information system then the specific organization has to apply specific controls and methods to ensure that the systems are designed and optimized for the specific processes (of course build the reference public reference profile).

The new repository and framework will give the public sector the benefits of organizational change and the understand of systems changes as well since they are build around the same systems and principles of management and Service Orientated Architecture. It is notable that the implementation of the IT architecture will be a hugh investment and the investment can result in big benefits and opportunities as well.

The Background for the OIO-framework

The reason and background for the development of the public IT architecture (and the OIO-framework) is to establish a foundation for Enterprise Architecture to ensure maturity in the common enterprise architecture to enhance and develop public services to citizens and customers.

The government has established a vision for what is known as digital governance & management. The vision is based on four goals (principles) that needs to be taken into consideration:

  1. The digital governance & management has to empower the citizens and corporations to the network society.

  2. The public sector has to work and communicate digitally.

  3. The public sector has to provide coherent services and products to the citizens and the corporations.

  4. The tasks in the public sector has to executed where the tasks can generate the largest benefits.

The above mentioned goals have to be translated into processes and these will be implementing over several years and with different development logic.

  1. Goal two to four deals with that the IT architecture should better public support through higher quality in the IT foundation.

  2. Support the development of innovative cross governance processes through greater coherence in the informations.

  3. Achieve a more effective governance through larger efficiency in IT usage.

  4. Gain access to rapid support of new or changed governance processes and organization changes through tested infrastructure solutions.

  5. Give access to public information through open to citizens, corporations and public institutions and authorities.

  6. Give sufficient protection of public information through secure solutions to manage and communicate data.

  7. To create more successful IT solutions through larger predictability of the results of IT investments.

  8. Give the public sector access to stabile IT systems with sufficient capacity.

Experiences that can be Crystalized from the OIO-framework

There are several other countries that have made an effort to implement IT architecture (Enterprise Architecture) and these countries have gained some experiences.

These experiences are as follows:

  1. Commitment has to be on government level.

  2. A cross government institutions and departments collaboration is needed.

  3. Standardization of data structure and functional data interfaces has to be implemented.

  4. Choice of technical standards are needed.

  5. A common infrastructural platform has to be implemented.

  6. Anchoring the knowledge and change through certifications and common shares of practice have to be implemented.

Guiding principles

The OIO-framework emphasizes 10 principles that the Coherency Architect has to take into consideration when the government of one reason or the other implements a new IT architecture:

  1. The Service Orientated Architecture is a paradigm of which the government has to invest its resources so a coherent digital governance can be applied.

  2. The prospect is that the government will take an active role in the service orientated architecture.

  3. The national common IT architecture has to be the lowest common standard that in the same time enables the ability to add to it (a kind of dogma architecture).

  4. The IT architecture should reflect the vision of the business side and there should be a consensus regarding the choices the business side has committed itself to.

  5. The national IT architecture should be applied in those cases where there is a business needs and business analysis should support the usage of the usage of the IT architecture.

  6. Legacy systems shouldn’t be scraped or for that matter be converted to run on the same platform. In the other hand none of the legacy systems should be spared in advance of the implementation.

  7. The implementation should focus pragmatic assumptions and the implementation should be done in iterations.

  8. The IT Architecture should be based on the lowest possible political foundation to ensure that those persons who know about the situation locally can take the proper responsibility and accountability for the situation and implementation.

  9. Denmark is not the only country on this planet and therefore should the work with the architecture be coordinated with international players.

  10. The work with the IT architecture and the standards should be published on a public website http://www.oio.dk.

The IT Architecture Process

The white book is based on two cycle processes that enriches each other while they are executing. The two processes are iterative which means that these have to be executed continuously.

Since the public sector is rather decentralized and therefore is the principles and concepts discussed in the white book based on the idea that these can be dragged down onto the various self-governing institutions and their contexts.

Strategy Process.
Strategy Development Process.

It is worth to mention that the upper circle is the strategic process and the lower circle is the implementation process.

  1. Vision and goals describes the strategic business goals and that will be with a special focus on those that are related to Information Technology. It is a necessity to keep a dialog with the top management of the enterprise and the political side of the business is a necessity as well.

  2. The Business Architecture describes those processes the IT system has to support both when it comes to functionality and procurement. This state is a result of an analysis and an optimization of existing work related processes.

  3. The Information Architecture describes the business strategy and its demands to the organization of information. This contains both the high level description and low level technical description.

  4. The Technical Architecture is based a common shared systemic description of the demands which can be categorized with the high level part of the systems and modules and the low level description of each of the modules.

  5. The Conceptual Architecture Principles is a rule set that handles the initiation of the IT solutions so these are within the demands presented in the “Conceptual Architecture Principles and former mentioned architectures”.

Besides the strategical architecture process the practical implementation process will be executed.

  1. Document the existing situation (AS – IS).

  2. The Gap analysis deals with identifying the identifying what legacy systems that fit into the conceptual architecture principles.

  3. Prioritization and planning. This phase deals with the planning the technical change that is needed to bring the “AS IS” to the desired state “TO BE”.

  4. Implementation projects deals with implementing the changes through a series of projects.

The Three Layer Model

The three layer model can be utilized and linked directly to the architecture model.

  1. The user interface layer (3-layer) that is directly linked to API & Services and Presentation.

  2. Business Logic Layer (3-layer) that is directly linked to application server, integration server and database sever.

  3. Storage Layer (3-layer) that is linked directly to server hardware and operating system, data layer, and network.

When the public sector starts the redefinition of its “Enterprise Architecture” (IT Architecture) then it should focus on to break down the known barriers and not just enabling old government procedures or processes. This means that the old processes should be supported with new technology since they often just led to the same result as the old processes and these rarely enables the true potential of the technology.

Principles

The foundation of work with IT Architecture (Enterprise Architecture) is based on the principles developed by the chief architect and the EA team.

On the lowest level of principles we find the principles that are focused on a specific system where we in the highest level is based on the idea that the entire enterprise should align their decision making with.

The principles should be build upon:

  1. Interoperability is a necessity to enable the usage of and recycle the data. However interoperability can also be viewed as a way to create coherence in new ways.

  2. Security is a paradigm and an imperative. If the system is not based on the

  3. Openness is based on the idea that the interfaces have to be open so the can ensure communication and interoperability among the systems components.

  4. Flexibility is based on the idea that the system has to be build so it would be easy to modify to the system (enterprise architecture will be suited to its surroundings).

  5. Scalability deals with how the system will be working when there is a greater demand for its features and usage.

Sources

Gotze et al, 2003, Hvidbog om IT-arkitektur, Copenhagen.

Download the blog post from here.