Category Archives: Strategic Management

2012-04-05 18.07.48

Summer School (Week 31, 2012)

I have been fortunate to participate in the Enterprise Architecture summer school that took place in week 31 in year 2012 at the IT University of Copenhagen. There where a lot of interesting presenters, academics and practitioners. One of the more notable presenters where Martin van den Berg who happens to be one of the authors to the book “Dynamic Architecture: How to make it work” and “Establishing an enterprise architecture practice”.

Furthermore came a lot of presenters from Finland who had researched the concept of Enterprise Architecture and a chief architect from a major Finnish/German Corporation.

This particular blog post was written in order to give you some insight in what happened with one of the presentations and I plan to release more blog posts dealing with the thoughts I have had during and after the summer school.

Innovation for Enterprise Architecture

The presenter, Mr. Kim Peiter Joergensen, argued that the enterprise architecture program has had little impact on the business. One of the reasons for this was the way that the enterprise architects usually developed their business artifacts. That triggered reactions from most of the practitioners who attended the summer school and as a consequence the keynote turned from being a presentation to a debate.

I was not particular impressed by the rather true, but rather stereotypical ideas of how enterprise architecture has impacted the organizations ability to invent and produce new products. From my perspective it really depends on how the organization and the chief architect approaches the concept of innovation and for that matter the concept of inventing.  Mr. Kim Peiter Joergensen should have worked with his preliminary (definitions and principles) for what invention and innovation is in an enterprise architecture context and that could have improved his presentation quite dramatically.

I believe that innovation is about identifying inventions (e.g. software, concepts, methodologies etc.) and identifying their fitness for adaption in the enterprise and its business, application and technological architecture. One example of this could be an enterprise architecture function that handles and develops the technology strategy.

In despite of the rather alternative way of defining enterprise architecture and invention or innovation, Mr. Kim Peiter Joergensen’s presentation did develop some ideas of how to approach this particular issue. First of all an exploration of the topic would have to be dealt with through defining the perspectives and how innovation and the concept of inventing.

Observations

The Enterprise Architecture function can enable the time to implementation (and essentially market) by developing and maintaining a technology strategy where the architects identifies new technologies and concepts that can be implemented in the organization.

The Enterprise Architecture function can enable standardization that makes it possible for the various applications to communicate with one another and as a consequence ensure a faster implementation rate of processes, software and concepts.

The Enterprise Architecture function can identify needs for reengineering of the structure of the organization’s structure.

Dealing with Systemic Problems Through the Enterprise Architecture Program

There are many problems the chief architect, enterprise architects, CIOs, executives and decision-makers on all levels will be facing while handling the day to day operations. Quite a few problems that they will be dealing with are symptoms of larger more complex problems or what I have chosen to define as “systemic problems”.

Systemic problems are the roots of why processes do not seem to connect resources, parts of the products that are to be delivered to the customers are bulked up or simply not arriving at the right place at the right time, information that isn’t shared across several different parts of the enterprise. Such symptoms can usually be dealt with rather easily e.g. a systems architect would say that an information system can be constructed in order to create an overview of the information and share the information among the stakeholders, and so the stakeholders believe the problem has been solved; however quite often will the problem not be solved e.g. the information that the system has to make use of in order to create forecast and delivery dates can’t produce any useful information if no one provides information to the system and likewise will the system not deliver any kind of value if those who are supposed to react upon the information delivered don’t do so.

So what can the chief architect and the enterprise architects do in order to find out if there is a systemic problem, and how to gain an overview of the problem(s) in order to find out more about the systemic problem and identify solutions for how to deal with the problems.

As I see it most systemic problems share similarities with “wicked problems”. Wicked problems are defined as problems that are defying logic, they includes various perspective, they are connected through different problems that occur and they can’t bet solved the regular linear way. All in all the chief architect would be in a problem where he and the other members of the enterprise architecture team would have to share their knowledge in order to find out how important the problems associated with the symptoms are, and how the enterprise architecture team can contribute to solving the problems.

One of the great problems applying resources to deal with systemic problems is that the problems involve many different segments of the enterprise and as such all the stakeholders that have something to say would have to be involved. The problems could potentially prove to be hard to solve due to the situation where the enterprise would have to allocated resources to deal with the problem, that is hard to define and where it is hard to identify which of the segments that would have to contribute what. Politics can’t be avoided in order to solve the problem and that means that the decision-makers on various levels in the enterprise would have to be involved and the scenarios for solving the systemic problem would have be changed in order to gain the trust of the important decision-makers.

Besides politics and the allocation of resources there several other barriers that the chief architect and the enterprise architecture group will be facing e.g.:

  • Furthermore does time means money.
  • Opportunity cost can be hard to estimate.
  • Mental models that are frozen.
  • Organization cultures that are notorious hard to change.
  • Power issues and accountability for changing the status quo.

Each of the barriers above would be hard to deal with in the short or for that matter in the long run; however the role of the enterprise architecture program would be to identify the capabilities that the enterprise possess and how they can be made use of in order to gain the insight.

The question becomes how can enterprise architecture program assist the enterprise with solving the systemic (wicked problems).

The way I see possibilities of using the enterprise architecture program is through combining the documentation process with the process of questioning the various stakeholders in the various segments and through that feedback the enterprise architects are able to define a view of the situation that can be used to facilitate workshops where the stakeholders can comment and ask for changes. When this process has been taken care of the enterprise architects would bring back the knowledge they have collected and draw a map dealing with the problems they have been able to identify and from that they would prioritize the problems. The map could be build upon the concept of a rich picture with more layers. This model could with some benefit be mapped in the modeling tool. The chief architect could present the findings to the various decision-makers in the enterprise in order to create a pattern for how the enterprise can get over the systemic problem.

The decision-makers can from that information get a significant better overview of the situation (in any case it is better than having no information what so ever) and decide what to do in order to improve the situation. As I have earlier mentioned then there are no quick fixes to wicked problems and likewise are there few, if none, of the solutions that can be proclaimed the right solution for the problems the enterprise faces. The solutions are to be defined only on if the solutions improve or demote the situation for the enterprise.

Five Things to do in order to deal with KPIs for Enterprise Architecture Processes

Measuring Enterprise Architecture Processes

In most enterprises that applies Enterprise Architecture will there be a need to measure how the enterprise is progressing from adapting the Enterprise Architecture Program and there will be some stakeholders who would like to know what value or benefits they gain by investing (and keep financing) the Enterprise Architecture Program.

Enterprise Architecture Processes

Implementing Enterprise Architecture principles, standards, systems and strategies would need some changes, processes and scoping. In this particular paper the idea of Enterprise Architecture processes deals with the concept that a chief architect sets a set of tasks in motion in order to uncover systems, social networks and business processes. The Enterprise Architecture processes differs from business processes by the architectural processes changes systems, business processes, information systems, IT, technology and social systems. Business processes deals only with optimizing the flow of production and goods.

The Enterprise Architecture Processes deals with implementing the structured approach to Enterprise Architecture and to keep maintaining and maturing it. It is quite right that the Enterprise Architecture program would have to be maintained in order to ensure its functional in the long run.

If you can’t measure it, you can’t manage it
– W. Edwards Deming.

Measuring

The chief architect would have to develop some KPIs in order to measure the processes that are a part of the Enterprise Architecture Program. In order to gain an overview of the processes it becomes a necessity to measure the processes before the initiatives have been initiated in the Enterprise Architecture Program. In the ideal situation the chief architect would have to investigate how the business performed before the Enterprise Architecture Program was initiated. The measurement should be used in order to improve the decision makers abilities to make the right decisions. In order to investigate if the proposed changes that have been implemented with the Enterprise Architecture Program have improved the situation for the enterprise, the chief architect would have to measure the “as-is” situation for the processes and “to-be” would have to be like. After the processes have been implemented the ideas would have to give the decision-makers an idea of or if the enterprise has moved closer to a desired state. For this key performance indicators can be a rather good tool for measuring.
The next section of the paper deals with the concept of key performance indicators.

Key Performance Indicators

In this paper a key performance indicator is defined as a number (simple indicator) indicating how a process or segment of an enterprise works. Key performance indicator is a simple tool that gives the various stakeholders data for interpretation and as such the KPI can’t stand alone it has to be accompanied with in-depth analysis documents.

Key performance indicators (KPIs) are suitable situations when the decision-makers would have to a quick overview of how the enterprise works (processes, segments and systems).

The KPIs would have enable the chief architect and the various other profiles that are a part of the Enterprise Architecture group with the appropriate data from the various systems.

KPIs have a significant factor within the concept of the Enterprise Architecture Program due to the various elements of the enterprise’s architecture works.

The KPI is needed is used as by the decision-makers in order to find out if there are any particular problems in the day to day management. Each of the KPIs can guide the decision-makers and it would be able to misguide the decision-makers. In order to find out if the KPI is adding the right value to the the overview that the decision-makers understand the KPI and how it should be used. Likewise does it become a necessity to deal with the KPI in order to understand if the KPI can be used in order to gain the overview in the in the enterprise. KPIs are by all means simplified and it becomes a necessity for the chief architect and for that matter the enterprise architects investigates if the KPI is too simplified and if the KPI can be implemented in the enterprise at hand.

Validating the KPIs

In order to validate the KPIs the chief architect would have to go into the situation of the various groups in the enterprise e.g. do the various actors understand what is to be measured and how they are measured. It is a necessity to challenge each of the KPIs and their stakeholders in order to find the best possible way to ensure that the KPIs measures contributes with value.

Five Things to do in KPI – EA Development

As promised I will hereby present five things that the chief architect could do in order to develop usable KPIs:

1) Identify what KPIs are relevant for the enterprise from a business point of view. Associate other KPIs when the business KPIs have been identified.

2) Probe the views of the enterprise’s decision-makers and those who would make use of the KPIs. Ensure that the business-stakeholders understands why the KPIs have been chosen and what they represent.

3) Articulate a draft for the KPIs and simulate how they impact the decision-makers and if they give the right kind of indication to the decision-makers. Ensure that you incorporate business-politics in your plan for implementing the KPIs.

4) Refine the KPIs and educate the various stakeholders and decision-makers in how the make use of the KPIs and when not to make use of them.

5) Build in the KPIs for the Enterprise Architecture program and ensure that the KPIs are visible in all the various forms of governance structure that are directly related to the Enterprise Architecture program.

Holistic Management in a Context of Enterprise IT Management and Organizational Leadership

An Approach to Sense Making and Intelligent Business

There are probably many different ways to gain sense in each of the many different enterprises and organizations across the planet. This particular paper investigates one particular approach question the validity of the data and the selected approaches to articulate strategies and plans. This should give you (the reader) an idea on how to develop better plans that in turn would give the enterprise a better system.

In order to make proper decisions on how to develop the enterprise it becomes a necessity for the enterprise to deal with the question of sense making. How does the specialists and systems that have been applied in order to analyze data from the enterprise’s environment? How does the systems adapt to the trends the data indicates might be developing? How do the specialists question and tests the data they have collected and analyzed?

The three step approach to organizational learning and data collection is in its origin based on Weick’s approach, though I’ve taken some liberty in order to create a synthesis in order to specify the ideas that Weick presented in his book (Making Sense of the Organization, 2000) to an Enterprise Architecture approach in order to enable enterprises with crystallizing competitive advantages. By crystallizing competitive advantages the enterprises could avoid situations that in other cases would have forced out of business. This leads to the first part of the process that Karl Weick introduced in his book.

Scanning for Data

It is of importance of all enterprises to scan its environment in order to gain an understanding of how the stakeholders (competitors, suppliers, government etc.) will be acting in potential future scenario. This is usually a rather good component in articulating a corporate strategy and all of the subsequent strategies like the IT strategy, financial strategy, organization planning etc.

The scanning process includes the situation for the internal environment and for the external environment. The internal environment consists of an other set of stakeholders than with the external environment, but these are just as important. Likewise is the internal environment connected to the the external environment.

The data is usually based on several different sources and as such the data that the specialists and systems collects are of different qualities and as such the data and their sources have to be questioned. The questioning is in a way a process to ensure that the specialists who collects the data should question the ways they identify the data and how to be able to deal with the way the data is analyzed. This is discussed in detail in the interpretation.

Interpretation

While analyzing the data the specialists works with a validation technique that in turn tries to investigate how or if the enterprise can make use of the data. The interpretation is likewise a fundamental element in the way the data is applied in the strategy development process.

The interpretation can be used to ensure that the strategies could be easier to implement, and as such the strategies could lead to the desired state of the enterprise. As such the focus of the planning would have to avoid what Mintzberg (Mintzbegr 2009) defines as the planning school, that is characterized by applying a lot of resources to the articulation of planning but as such it usually emphasize planning too much and implementation too little.

Learning

The specialists and the systems would have to learn from the articulated strategies, otherwise will they fail in adapting to the new situations of the environment that they analyze.

The learning process is likely the most important step of the entire process since the enterprise’s specialists would have to adapt their analytical models to understand how the environment.

The result of the learning phase is in itself a form of knowledge sharing and it impacts the framework of how the enterprise operates.

Learning and knowledge sharing are two sides of the same issue and as such the specialists and decision makers have to think in how to transfer the knowledge to one another. For this a specialized repository can be applied. In order to share knowledge across the enterprise the individuals would have to a common understanding of what knowledge is about and who to interact within in order to gain access to the information and knowledge that they assume they would need in order to make better decisions and better plans for how the enterprise can gain competitive advantages.

In order to gan a further understanding of how the enterprise can create value through planning it becomes a necessity that the cycle is documented and the cycle is transparent for all of the stakeholders that interacts with top level planning.

The Cycle

The process is cyclic and that is essential that it is build upon a cyclic structure in order to the specialists to make their predictions more reliable. More reliable plans can be used by the decision makers to enable the enterprise to achieve its goals.

Furthermore can cycle be enhanced with the enterprise, if an Enterprise Architecture Program is established and that the decision makers makes use of the data that the Enterprise Architecture program has been able to produce.

The illustration below shows how the enterprises can make use of the sense making process to achieve a more coherent, better aligned and more agile enterprise. As it is illustrated the Enterprise Architecture Program is used to enable the decision makers to align the various conceptual sections of the enterprise. In the diagram below there are three conceptual sections of the enterprise. The decision makers articulate a strategy.

The experienced reader would note that the definition of what Enterprise Architecture impacts is derived form the EA3 Cube framework that Bernard (2005) proposed. The approach is based on the concept of Enterprise Engineering (Sjoelin 2011a) and as such it is the opinion of the author that the focus of the .

Assessing the Business Processes

The chief architect should evaluate the business processes, and it is a necessity to evaluate the primary business processes, business model/operating model (Ross & Weil 2009, Ross et al. 2006, Ross & Weill 2004, Finkelstein 2006) and support processes (Porter 1985).

In this particular paper the concept of primary processes is defined on what processes that are essential in order for the enterprise to deliver value to its customers. The chief architect should naturally apply a multi perspective analysis method to understand the underlying principles of the enterprise and its social systems. For this the chief architect and his associates (the enterprise architects, solution architects, business architects) should investigate the operating model and business model of the enterprise in order to gain an understanding of how the enterprise’s internal environment will change in the near future. The scanning of the internal environment should uncover the processes that aren’t fully supported by IT and the processes of which the enterprise would be able to identify a series of projects that could change the enterprise to a desired and more competitive enterprise.

The chief architect or one of his or her associates have identified which of the business processes that do support the business in achieving its goals. He or she would have to go into a process of identifying those processes that would have to be obliterated (Hammer 2000) (re-designed completely). In the process the chief architect and associates would have to re-thing the support processes in order to avoid the pitfalls of an unstructured and incoherent enterprise architecture.

The chief architect and his associates would have investigate how the various processes could be grouped and how the various projects can be implemented in order for the enterprise to harvest synergy. The primary business processes should be organized into “clusters” along side the support processes that clearly can be associated with each of the primary processes and as it has been mentioned earlier in this paper it is a necessity to organize the various business relates activities and processes in order to maximize the potential synergies. However there are some pitfalls that the chief architect and his associates might fall into for example is complexity a factor that can’t be ignored. The more complex a particular segment or domain of the enterprise is the more likely it is that the particular system in the enterprise can’t be generalized into an “Enterprise-Wide” platform, or rather the meaning of doing so is lesser relevant in the sense of information systems design.

Connect the Business Processes and the Information Systems

The chief architect and his associated would have to apply a structured methodology in order to ensure that the enterprise is able to establish and understand how the enterprise and its underlying architecture works. In this paper the author assume that this can be done through the establishment of a formal group that is in charge of investigating and defining the enterprise’s architecture. The method can be based on formal Enterprise Architecture framework and as such be a part of the structured methodology that the decision takers decides to apply.

The author’s definition of Enterprise Architecture is:

Enterprise Architecture is a set of principles, standards and methods for achieving informed governance. The models derived from the standards and methods have an impact on how the enterprise is able to align each of the elements of the enterprise with one another. The alignment will enable enterprise governance and agility for adaption and assurance.” – Peter F. T. Sjoelin (2011a)

It is the author’s opinion that the framework is the set of standards that dictates how the various artifacts that would be documented and stored in the repository are to be defined. In other words the framework is alpha – omega in order lay the foundation for an enterprise ontology (Dietz 2006, Bernard 2005, Hoogervorst 2009).

The framework could eventually give the chief architect the advantage of winning over stakeholders that are skeptical towards the concept of Enterprise Architecture, and likewise does the author assume that the framework would have a significant impact on the value of the repository that contains the descriptions of the artifacts. The value is derived from how well the various stakeholders in the enterprise are able to connect to the repository and understand the value of these.

As earlier mentioned the author expressed his views on that business processes and IT rarely generates synergies due to the lack of obliteration of processes that were designed for the pre-computer and Internet age. It is necessity for the chief architect and his associates to investigate the enterprise’s current usage of information technology and information systems. The chief architect and his associates should be working with a methodology that documents the various information systems, platforms, applications, devices that the enterprise applies in order to provide the various stakeholders (executives, middle managers and employees) the proper information in order to make them understand how the social system works. The chief architect would have to make sure that the business processes and the information systems are evaluated before and after the change process has been initiated in order to give the decision makers the best possible overview of how the enterprise has changed after the implementation of the new approach to business processes and information systems.

It is the opinion of the author that in order to ensure that the enterprise would be able to gain an advantage in governance by focusing on the enterprise’s approach to investing in its technology, assets, people and systems (Potts 2008). The investment process is essentially the embodiment of both the corporate strategy, the IT strategy, the financial strategy etc. After the chief architect and his associates have worked with their analysis of the enterprise’s corporate strategy it is almost certain that a road map should be articulated so the focus could be shared among the members of the Enterprise Architecture group and later on among the various decision makers in the particular enterprise.

It is the author’s opinion that the investment approach would have to be connected with the the enterprise’s program management. It will become a necessity for the enterprise to deal with its approach to enterprise investments and program management since it is the decision makers who are responsible for the allocation of resources to the projects and systems that the enterprise are able to invest in the projects that will change the enterprise. According to Bernard the the enterprise would have to change by the many different projects alter and mature the architecture of the enterprise.

The author is of the opinion that the desired architecture (TO – BE) should be described in a transition plan that should be used as a document to communicate with the stakeholders and the decision makers in order to communicate and evaluate the each of the projects that would have to be allocated resources to and implementation of projects. Likewise is it the author’s opinion that the transition itself has to be guided by the principles that the chief architect and the decision makers have articulated.

As the author has mentioned earlier in this paper the complexity is a barrier that can’t be ignored if the synergies of enterprise architecture and enterprise governance should be harvested.

Group the Business Processes and the Information Systems

The social systems have to be identified and as such it becomes a necessity to group the systems into various domains of specialisms. Each of these domains would have to generate synergy among the social systems and the information systems in order to justify their existence. The domains are a necessity in order to cope with the question of complexity.

Complex organizations can very well own processes and departments that are specialized to the degree that it constitutes a silo. In those cases, the silos can’t be viewed as negative issue, as long as the employees, middle managers and executives in charge of the various processes communicate and interact with one another on regular basis.

In order to ensure that the changes by grouping the various information systems and social systems, the managers would have to allocated resources in order to facilitate communities of practices that would enable the stakeholders in the enterprise with understanding and adapting to the new situation in the enterprise. It is pivotal that the decision makers allows the various members of the enterprise to make use of their time at work and in the change process to form such social networks.

A community of practice is defined by Wenger (1999, p. 47) as Such a concept of practice includes both the explicit and the tacit. It includes what is said and what is left unsaid; what is represented and what is assumed. It includes the language, tools, documents, images, symbols well-defined roles, specified criteria, codified procedures, regulations, and contracts that various practices make explicit for a variety of purposes.

It is likewise a necessity to make use of the social networks to create an understanding of how the enterprise works since that would add value to the ontology of the enterprise.

The social networks are likewise pivotal in order to enable the change process that occurs within the enterprise, and as such the chief architect and the decision takers who are in charge of the enterprise have to identify change agents and motivate the various social networks to adapt to the changes and work alongside the goals that the decision takers have articulated for the enterprise. In this light the decision takers would have to trust that the members of the enterprise works for the best of the enterprise and to some extend allow the employees to self-organize and prioritize the various tasks at hand.

I would recommend a form of hybrid of a top down (Kotter 1995) and bottom up approach (Hamel 2007) to solve the problems with anchoring the changes in the enterprise. The approach is dealt with in detail in table 1: The suggested approach to change management.

Step

Description

Impact

1

Establishment of the an active network within the executive group.

The executive group and middle managers (who aspire to become executives).

2

Identification of change agents in the enterprise that would stay among middle managers and employees.

The entire enterprise and on all levels of the enterprise. There should be found agents as many places as possible.

3

Establishment of an office or department for internal communication in the enterprise. This office has to be located close to the change leader and his position so it is clear that what is sent to the employees in the organization is the words and intentions of the leading coalition.

The upper end of the middle management. Eventually it will impact the rest of the enterprise since the communication from this office should be directed to all parts of the enterprise.

4

Establishment of scope, goals and mission clearance. Stakeholder alignment is a necessity to create the proper dynamics.

The change coalition (all agents on all levels of the enterprise should be involved in this).

5

The change leader should make sure to attend meetings and conferences with the other managers on how the change effort is planned to impact the enterprise.

Executive group and middle management.

6

Plan workshops with employees that focus on identifying issues that needs to be dealt with in the particular devisions, departments, processes and projects.

All members of the enterprise.

7

Enable feedback channels where the executives, managers, and employees can report if departments or processes don’t work as intended. In this case IT / IS is a part of the concept of processes.

It will impact all levels of the enterprise in order to achieve that all members of the enterprise are able to add information to what needs to be re-configured.

9

Initiate the implementation process.

All members of the enterprise will be impacted as a result of the change program.

10

Keep on changing the architecture in order to achieve agility and adaption the changing environment of the enterprise.

In the long run it will impact all members of the enterprise on all levels. In the short run small sections of the enterprise will be changed.

Table 1: The suggested approach to change management.

The managers needs the information that they can gain access to in the social networks through their insight to the networks. When it comes to the diffusion of knowledge it is very likely that the segments of the enterprise that are too complex. If the knowledge is too complex it is evident to investigate if the particular domain can be handled by enterprise-wide systems or for that matter enterprise-wide business approaches. Nonetheless the most important thing is that the any new employees, managers or executives can be introduced to the persons who have some idea on how to deal with the problems, tasks, activities and processes in each of the domains that are likely to be too complex. What is important for the enterprise is that the executives, middle managers and not to forget the employees support a culture of knowledge and information sharing. The IT systems should be developed to support their particular processes. These information systems could eventually be connected, but there is as such no need for enterprise-wide information systems that standardize the workflows. Knowledge can be hard to standardize and as such the various stakeholders of the enterprise can’t be expected to know everything about the same topic. In other words it is very likely that the chief architect and the decision takers would have to challenge their assumption on process standardization.

Create Value Through Grouping of IS and Business Processes

The chief architect and his associates would have to investigate how the enterprise can generate value through grouping the social systems and information systems.

The approach that the chief architect and his associates should work with a projects that will enable change for the various projects that would change the enterprise.

The progress for each of the projects will be impacting the enterprise’s architecture and thereby transform the architecture from the AS – IS situation (Bernard 2005)which is the current state for the enterprise’s architecture to the desired state which Bernard names the “TO-BE” state. The transition plan is the document that communicates what kind of projects that would have to be initiated and implemented in order to mature the enterprise’s architecture and through that enable the enterprise to reach its goals. The transition plan also works as a kind of plan that can be communicated to the various stakeholders who would have to back the enterprise in the maturation of the particular situation. The maturation process has to be evaluated before the chief architect and his followers initiates the change program. It is very likely that the stakeholders will be easier won over if they can see a logical plans that includes economical estimation of how the plan impact the enterprise’s economical situation. It is needless to say that the enterprise’s decision makers would have to have an insight on how well the enterprise can process the various resources it has at hand and thereby produce the products and services that its customers want to purchase.

The evaluation process is likewise a part of how the enterprise scans its internal and external environment and as such the Enterprise Architecture program should work as the platform for the construction of a shared ontology across the enterprise. The chief architect should keep in mind that in departments or segments that can be characterized as being characterized as complex it is rather likely that their particular views can’t be generalized into an enterprise ontology if such can be formulated.

In order to get the information that the chief architect and the decision makers need in order to plan and allocate resources to the transformation the enterprise would have to go through. They would have to go into detail with how the various social networks and communities of practices and search for the information and knowledge in order to gain a firm understanding of how the enterprise works and thereby how it can be changed. In this light the chief architect and his associates would have to decide if they should apply a top-down or a bottom-up approach. The approach chosen would eventually become a part of the debate that the members of the enterprise on what has to be done. Will the decision makers tolerate increased autonomy or if they would prefer increased centralization. As earlier mentioned it seems like that the tendencies for the development organizations.

Change the Enterprise

The chief architect and the decision makers would have to go further with the change of the enterprise. The change process would have to be a part of the overall Enterprise Architecture program and it will certainly impact the enterprise and how it works. In order to do so the chief architect would have to influence the stakeholders (decision makers, the middle managers and for that matter the employees). The changes are caused by the the questioning of the how the enterprise is able to collect the data needed in order to take the decisions needed to achieve the goals that was set for the enterprise. The author is of the opinion that the grouping of information systems and social systems in order to harvest the synergies with each one of them and among each of the clusters The clusters can most likely produce synergies for each of the areas that shows the amount of gravity that produce a barrier of complexity.

Before the chief architect and the executives commit themselves to changing the enterprise they would have to understand how the enterprise and its architecture works. In order to achieve this the chief architect would have to choose an Enterprise Architecture framework, adapting the framework to the particular enterprise and implement the framework. Thereafter should the chief architect and the enterprise architects work with identifying the various artifacts, and organizing them in an Enterprise Architecture repository. While working with the identification of artifacts and organization of artifacts in the EA repository it is important that the chief architects understands that there might be barriers to create define an unified ontology and as a result of that there might be a necessity to create several different sub-units of the EA repository. The chief architect work with an assumption that each of the specialized operations of the enterprise should be mapped as a separated entity and as a separate mini architecture of the enterprise.

The author is of the opinion that it is possible to convert extremely specialized knowledge for each of the specialized processes to other parts of the enterprise without a lot of the meaning of each of the artifacts is lost. It is better that there is a platform for informed governance for each of the segments than a system that doesn’t adapt to the entire enterprise. The managers of each of these segments should in the long run participate in the community of practice that shares knowledge and know how with one another. The chief architect can at some extent work as the change manager would would have to convince the various stakeholders in the enterprise to support the changes and in the same time enable them to take the changes even further.

The change manager would have to ensure that the office of internal communication is located and positioned as a part of management and it symbolizes the foundation of management for all other segments of the enterprise. It is pivotal that the change efforts are supported by the middle managers since they act as the approvers of each of the employees time and effort to commit to the particular change system. If the middle managers ignore the call for change and disapprove of the changes that the employees suggests then it is very likely that the changes will come to a still and eventually fail. Likewise would the commitment of the employee be of great importance since it is likely that each of the employees have specialized knowledge of how the work processes interacts.

Conclusions

The author is of the opinion that the organization have to work with several different approaches to challenge their particular views on how the enterprise collects the data that are used by the decision makers. Likewise is it likely that the various decision makers of the enterprise would have to deal with identifying segments of the enterprise that are too complex to be adapted to generalized business processes. The author is of the opinion that the chief architect and his associates would have to deal with the challenges of adding value to the enterprise by applying the standardized business activities and business processes, but in the same time be able to identify where it wouldn’t make sense to apply standardized systems since that wouldn’t provide the enterprise with any kind of advantages.

The focus of the members of the Enterprise Architecture team would have to include the concept of complexity to the concept of enterprise ontology and as such should the repositories that would be able to connect the various sections of the enterprise and communicate the meaning meaning of how the enterprise works to the decision makers and other stakeholders who would have to make use of the knowledge that is represented in the repositories.

Likewise is it a necessity for the decision makers and the chief architect would have to investigate the various elements of the enterprise in order to achieve better insight into how the enterprise works and from that enable better decision making in order to achieve the objectives for the enterprise.

Bibliography

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

Dietz, J.L.G., 2006. Enterprise Ontology: Theory and Methodology, Springer.

Hamel, G., 2007. The Future of Management, Harvard Business School Press.

Hammer, M., 1990. Reengineering Work: Don’t Automate, Obliterate. , Harvard Business Review no. 68.

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

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

Wenger, E., 1999. Communities of Practice: Learning, Meaning, and Identity New Ed., Cambridge University Press.

Mintzberg, H., Ahlstrand, P.B. & Lampel, J.B., 2008. Strategy Safari: The Complete Guide Through the Wilds of Strategic Management 2nd ed., Financial Times/ Prentice Hall.

Porter, M.E., 1985. Competitive Advantage: Creating and Sustaining Superior Performance, New York: Free Press.

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

Ross, J.W., Weill, P. & Robertson, D.C., 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution illustrated edition., Harvard Business School Press.

Weill, P. & Ross, J., 2009. IT Savvy: What Top Executives Must Know to Go from Pain to Gain, Harvard Business School Press.

Weill, P. & Ross, J.W., 2004. IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press.

Weick, K.E., 2000. Making Sense of the Organization, WileyBlackwell.

The paper can be downloaded here or read at ISSUU.

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.

Integrated Governance

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

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

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

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

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

Download the paper here

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

What Enterprise Architecture is Today

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

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

What Enterprise Architecture Should Become

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

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

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

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

How Enterprise Architecture Becomes Holistic

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

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

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

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

Conclusion

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

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

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

Appendix

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

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

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

The Foundation for Coherency Management: A Framework for Change.

A Framework for Organization to Embrace Coherency Management

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

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

A Quick Summary of Coherency Management

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

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

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

The Framework

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

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

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

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

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

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

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

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

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

Key Issues

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

Conclusion

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

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

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

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

Sources

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

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

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

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

Download the paper here.

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

Organizational Change

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

The Change of Focus

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

Replacing the CIO

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

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

The Extended Architecture

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

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

Forms of Architectures
Forms of Architectures.

Conclusion

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

Sources

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

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

Download the blog post here.

Strategic Management: From the Coherency Architect’s Point of View!

Enterprise Architecture in Combination with Strategic Management

According to the discipline of Enterprise Architecture and Coherency Management then all organizations have an Enterprise Architecture. If an organization hasn’t an Enterprise Architecture then it isn’t able to deliver any kind of products or services.

The question then is how the organization is able to understand and later adapt the concepts of Enterprise Architecture to achieve better results and gain competitive advantage.

It is essential for the organization to gain the competitive advantage to lea the market and to survive in the long run.

According to Doucet et al. (2009) then Strategic Management and the concept of Coherency Management is from a strategic stand point a combination of Enterprise Architecture and Strategic Management. The combination of the two concepts have to result in better “alignment”, “Assurance” and “Agility”.

Alignment

Alignment is dealing with how various elements of an organization can be configured so they offer the optimal potential so value can be generated for the organization. The concept of alignment can together with the concept assurance and the concept of accuracy deliver “synergy” to the enterprise. The concept of “synergy” will be dealt with later in this blog post.

Alignment can be achieved by applying a framework (EA Approach) to understand the Enterprise Architecture.

Assurance

Assurance is dealing with the issue of control and openness. The control element deals with knowledge of that the amount of resources are committed to execute the processes and the products and services that the enterprise produces

Agility

Deals with the ability to adapt to change in the organization’s domain. E.g., new competitors, new technology, new substituting products and services. That also have implications for the internal situation for the organization e.g., what sort of technology that should be applied .

Synergy

Synergy deals with creating an effect that enables the organization to perform better by using the same amounts of components that are configured in a different way. Mintzberg quotes Ansoff for saying “He referred to it as the ‘2 + 2 = 5′ effect to denote the fact the firm seeks as a product – market posture with a combined performance that is greater than the sum of its parts”. (Mintzberg 2000, p. 45).

The overall idea is to use enterprise architecture to create the foundation for synergy. If the enterprise hasn’t an established EA program then it an idea to emphasize organizational change where Kotter’s Eight Phased approach can be applied.

The reason for this is that the members of the organization might be orthodox and therefore return to the original processes and work forms.

Conclusion

Synergy can be created and enhanced by using Enterprise Architecture. The more mature an enterprise architecture becomes the better the organization will be to cope with agility, alignment and assurance. To establish this organizational change management has to be applied to ensure that the change from the old ways of doing things to the new ones for this the Kotter’s approach to organizational change.

Sources

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

Mintzberg, H., 2000. The Rise and Fall of Strategic Planning, Financial Times/ Prentice Hall.

Download the paper here.