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.

]]> http://coherencyarchitect.com/2010/06/06/the-foundation-for-coherency-management-a-framework-for-change/feed/ 0 coherencyarchitect modified_applied_comof http://coherencyarchitect.com/2010/04/23/the-oio-framework-the-ea-framework-designed-for-the-danish-public-sector/ http://coherencyarchitect.com/2010/04/23/the-oio-framework-the-ea-framework-designed-for-the-danish-public-sector/#comments Thu, 22 Apr 2010 23:17:13 +0000 CoherencyArchitect http://coherencyarchitect.com/?p=286 ]]>

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 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 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.

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.

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.

When an organization implements an EA program and a Coherency Management program then it will eventually lead to changes in the enterprise. The change in the enterprise will eventually lead to changes in the business model.
The Coherency Architect should know of how the concepts of Business Models since they are some of the core concepts of the corporate strategy. The corporate strategy is the basis for developing and articulating the IT strategy. The corporate strategy and the IT strategy are two components of Enterprise Architecture. Enterprise Architecture is the foundation for working with Coherency Management.

Context of the Business Model

The Business Model in Context

There are many different perspectives that can be applied to the understanding of a business model and how the business model interacts with the company and the corporate strategy.
In illustration I argue that the Business Models evolves and eventually drives the Corporate Strategy (Weill & Vitale 2001) & (Seddon & Lewis 2003).
In the other hand there it can be argued that there is some overlap between the business model and the way the business strategy. The business strategy differs from the business model by taking the competition into consideration and how to enable a competitive advantage compared to the other actors at the industry.
This leads to an examination of the business model.

Elements of a Business Model

The business model includes a focus on creating value for the customers, revenue generation, cost estimation of service or product, distribution of the product. The business model has to emphasize how the specific product or service creates value.
The business model consist of four perspectives of which the above mentioned elements can be organized around:
1)    Infrastructure that deals with the core capabilities that are needed to produce the service or the product needed.
2)    Offering which is the value proposition. The value proposition is the value which the product or service gives the customers.
3)    Customers which deals with the target customers or audience the product or service. There to the distribution channel which basically is how the service or product is provided to the customers. The last element in this section is customer relationship which is the link between the customer and the company.
4)    Finances deals with the cost structure and the revenue that needs to be generated to finance the production of the service.

Sources

Weill, P. & Vitale, M., 2001. Place to Space: Migrating to Ebusiness Models 1st ed., Harvard Business Press.

You can download this paper here (Business Models: From a Coherency Architect’s Point of View.).

Why this method is Important

The Coherency Architect should consider the case study method an important tool since the Architect has to investigate the organization or organizations they work with to investigate and uncover problems that needs to be solved before the organization can continue with it plans to achieve its goals.

The Case Study Method gives the Coherency Architect tools which can assist him or her with identifying the problems and articulate the right solutions for the right problems.

Therefore will the Case Study Method be presented and dealt with in this particular blog post. Please note that you can download a compendium dealing with the case study method (The Case Study Method from a Coherency Architect’s Point of View).

The First Step

According to Robert K. Yin there are logical steps the investigator (in our case the Coherency Architect) should deal with in a particular order

The Coherency Architect should articulate a problem statement. The problem statement should primarily deal with how, what, who and why questions which need explanations. The Coherency Architect should know how to articulate an academic problem statement since it is presumed that the Coherency Architect has attended a business school an University related education.

Then the second step follows.

The Second Step

This step deals with how the Coherency Architect designs the case study. The case study can be designed various form of collecting data and different forms of analyzing them. When it comes to the Coherency Architect will work with both qualitative data and quantitative data when he or she is about to study an organization.

There several forms of case studies which the Coherency Architect can choose to work with. The first one is called explanatory case study, the explorative case study and the causal case study.

The explanatory case study used to explain a phenomena or tendency. The causal case study is used to identify what kind of decisions or processes that led to the outcome of the situation e.g., why the organization developed as it did and who were in charge of it. The third is known as the explorative case study which is used to (as the name indicates) to explorer if a hypothesis is sound.

It is important that the Coherency Architect understand the theory which he or she is about to apply to the case study otherwise the design will fail. Therefore should the Coherency Architect work with this particular issue before he or she starts the procedure at this step.

Yin are of the opinion that there are two types of case studies. The first one is known as the single case study and is the most commonly known; however the second kind of case study called the multiple case study is more rare but it is easier to generalize the findings of them.

Thereto are there two forms of case studies. The first kind of case study is known in education where the investigator (in our case the Architect) doesn’t need to stay objective to the evidence (data) which he or she has collected. The other case is the scientific case study where the investigator has to stay object and critical towards the evidence (data) he or she has collected. The Coherency Architect will most likely work with the scientific case.

When it comes to scientific case study then it is important to emphasize that the Coherency Architect has to put extra attention to:

1. Construct Validity deals with identifying the right operational measures for the concepts that are being studied. In the case of science then case studies have been associated difficulty when it deals with operationalize the measure and the measure often are biased since the findings are based on personal judgement.

2. Internal Validity deals with establishing casual relationships where certain conditions are believed to lead to other relationships than spurious¹ relationships. Please note that this particular approach is only for explanatory and casual studies and can’t be applied for other kinds of case studies.

3. External Validity deals with identifying how the domain (the findings of the case study) can be generalized. This means how can the findings be applied in other organizations than the case study.

4. Reliability deals with how the findings can be replicated in other studies. The major concern is that the findings are airtight and aren’t flawed and the findings therefore are biased or non-scientific.

This leads us to the third step.

The Third Step

This step deals with the preparation of the data collection and what the Coherency Architect should do before he or she begins the data collection.

First of all should the Coherency Architect focus on developing the right contacts to those persons he or she needs to interview to get the right information on e.g., how the work systems functions. However the Coherency Architect might also make use of quantitative data such as statics or other data which can be collected this way.

The Coherency Architect should be aware of that the establishing the right contacts is more important than the theory establishing part when it comes to the data collection since if the Coherency Architect can’t collect the right data that support his or her’s hypothesis then the outcome of the case study might end up being biased and therefore not useable for any one.

The Coherency Architect should focus on establishing a case study protocol which consist of the data collection protocol which includes the questions the Coherency Architect will be asking the interviewee. The Coherency Architect should also include an outline of the report which should be the case study. The case study protocol is build upon the idea that the Coherency Architect can make use of it to stay on track.

It is notable that the Coherency Architect should create an evidence database. The database should contain the data the Coherency Architect has uncovered so a chain of evidence can be established.

The Fourth Step

This step deals with the data collection phase. It is notable that the Coherency Architect will have to work with all six data forms which Yin mention in his book (see sources).

Interviews, documentation, records from archives and physical artifacts.

It is important that the Coherency Architect has to choose the sources with a critical point of view since the collected data might lead to a biased analysis and therefore to a biased view. The Coherency Architect should therefore try to combine multiple sources to achieve something that can assist the Coherency Architect to establish an overview of the case organization and how to identify the various layers with out being in the situation that he or she will be focusing on problems that proves to have minimal impact on the various layers of the organization.

The Fifth Step

This step deals with analyzing the data (evidence) the Coherency Architect has collected. Yin is of the states that there are four general strategies:

The Theoretical Propositions Strategy

This is the most common used strategy. The strategy deals with using the techniques, tools and world view the theory the architect has made use of in design his or her questions of which were made use of while the architect collected his data

Developing a Case Description

If the architect experience problems with applying the first mentioned strategy then the development of a case description might be preferable. This strategy is an alternative to the theoretical propositions strategy and when applied it is often considered as evidence for that the initial case questions weren’t based on theory.

Applying Quantitative and Qualitative Data

This strategy can prove to become an advantage for the architect if he or she is experienced with the case study technique. Yin is of the opinion that the quantitative data if the quantitative data has to cover behavior or events that the case study is trying to explain and second the data has to cover an embedded unit that can be related to the analysis.

Examining Rival Explanations

The fourth and last strategy deals with examining other explanations or theories of how the evidence in the case is related and interlinked. When the rival explanations are examined then it can uncover flaws in the evidence or uncover new relations.

Then there are five different analytical tools that can be applied the case study evidence:

Pattern Matching

The pattern matching approach deals with identifying patterns in the evidence (data) the architect has collect through his study of a phenomenon, organization or other. Yin are pf the opinion that simple patterns can also be uncovered and applied.

Explanation Building

This form of analysis deals with creating causal links among the various forms of evidence and by that explaining what happened and why.

Time – Series Analysis

According to Yin there are there two different approaches to time series analysis. The simple time series analysis and the complex time series analysis.

The simple time share analysis is based how the case organization has developed over time. Normally the simple share analysis is like applying the pattern matching.

Logic Models

Establishing a logical model explaining how the evidence is linked (the chain of evidence). The logical model has to explain the evidence and create casual links.

Cross Case Synthesis

This form of data analysis is suitable for studies that contain more than one case organization.

Sources

Yin, R.K., 2008. Case Study Research: Design and Methods Fourth., SAGE Publications Inc.

The foundation architecture is characterized by that Enterprise Architecture tools have been applied which has uncovered processes both within IT and the business which can be managed by using an EA framework. The foundation architecture is usually under control of the CIO in the organization. This means that the project is largely IT related. The foundation architecture is superior to the un- articulated architecture since it can assist the management in the organization realize that the enterprise architecture can be used strategically.

The extended architecture is defined by that the architecture is build upon the idea that the organization has realized that Enterprise Architecture tools can be used to understand processes and alter improve the outcome of the processes by using Enterprise Architecture tools. The primary difference between the extended architecture and the before mentioned foundation architecture is that the business side of the organization has discovered that the tools can be used to obtain superior results. Doucet et al (2009) describes this as a situation which means that:
The management of the business side of the organization make use of EA to rethink the processes (obliteration).
The Human Resources department makes use of EA tools to describe what particular needs the organization needs and what courses the current members of the organization needs to be qualified to use the tools.
The business line managers conceptualize ideas by using the EA tools.
The IT department make use of EA tools to identify and support the core processes of the organization.
But as before mentioned the primary reason between the foundation architecture and the extended architecture is that the business side has adopted the tools and the EA paradigm to develop the organization.

The embedded architecture is the evaluation of the extended architecture which means that the organization has adapted processes which adds to the architecture and in that way aid the architecture. Never the less when a lot of changes are implemented over time then there is a need for a framework which evaluates and implement the various changes to the architecture.
This means that the embedded architecture becomes ubiquitous in the way that the strategy and the processes enforces the strategy.
It is worth to mention that the organization is beyond the agenda setting, matching, redefining / restructuring and clarifying phases. The organization has or is close to be through the routinization phase which means that all employees in the organization understands the innovation is relates to it when they work.

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

The Outcome of the Report
The consultants articulated their findings in the final report to the management in the organization. The report came to the conclusion that it would be most efficient if the company went through a Business Process Re-Engineering effort. That meant that each of the high impact processes had to be identified and all subprocesses had to be aligned to them. Each of the processes had to be enabled by IT so as many of the processes could be automated and the employees could use their time and energy to work with more profitable (π) processes or projects. That meant that the structure of the organization had to be altered as well and eventually also the tasks the people of the organization had to take care of.
The first EA project was commissioned to the Chief Information Officer who was in charge of IT maintenance and IT development in the organization. Besides that then the CIO had the overall responsibility for the IT Organization.
The IT organization started with a consolidation of the fragmented systems that supported the cleaning division and the security division. The IT department came to the obvious conclusion that the security division and the cleaning division had  very different processes and vary different ways to handle various was of 1) administration, 2) deployment and 3) Contract negotiation. Besides that the organization had a lot of different ways to communicate. The cleaning division had regional and local offices where the employees gathered and where coordinated where the security department had two offices located in the business areas and most of the information was communicated by telephone to the teams who handled the various clients.
The CIO and the IT department came to conclusion that the organization needed to be reformed and yet the IT systems had to be designed on the same platform (ERP system) but the processes of each of the divisions had to be configured for the particular usage.
The CIO presented his proposal to the board directors and the Chief Executive Officer. The CEO supported the idea and the project was officially initiated by the CEO and the top management. The top management wanted quick victories to show the stockholders that they did their duty to the organization and performed above expectations.

The Transformation
The processes started with the various IT systems where analyzed and all data was backed up and moved to a prototype area which would be used to convert the data so the data could be inserted into the new information systems. The prototype systems proved to be sufficient for the first tests of the ERP systems. The first tests proved to be satisfying. However the users who where invited to take place while the systems had to be designed where of many different user levels and none of them could easily picture the deployment of the new processes and how to interact with the new information system.
Thereto it proved that the language used in the user interface was too complex and often it didn’t cover what the users thought they should insert into the interface. This lead to that the final time plan for the project had to be postponed until the prototype proved to be successful. The issues with the user interface lead to a redesign so the interface was designed to be different with a different language for the two major divisions (cleaning and security).
The second prototype proved to be more understandable for the users and the processes was in some way represented as the employees and middle managers understood them. However the employees and the managers were of the opinion that the system could be better if the workflow of the ERP system worked with the various under accounts and the workflow of the subprocesses and task descriptions could be defined better.
The prototype period became a fundamental architecture for the organization since the members of the organization and the IT department made use of tools to articulate the processes, structure and IT used in the organization.

The Deployment of IT and Processes
After the modifications of the standard ‘off the shelves’ system so it supported the underlying architecture the system was rapidly deployed in the organization. This meant that the organization had to apply training for the employees and managers of the organization. This meant that the new systems had to go through an education period and extensive testing. The knowledge about the system was originally implicit in the persons. These persons spread the knowledge to other persons  by showing, talking and train them. The persons who started to test and work the system articulate then it was articulated into books, reports and manuals which was read and professionalized by other testers and persons who worked with the system in practice out in the two primary divisions. The persons who worked was about to work with the system read the manuals and reports etc. which gained knowledge from the reports and manuals and diffused the knowledge  to other persons to the organization.
Besides the knowledge process in the organization then the company had to organize its processes in a new way so the processes all in all where designed smarter and resulted in better agility and more resources to gain competitive advantage. The organization of processes led to a slightly decrease in productivity in the first two quarters after day zero. This led to some criticism from the press which influenced the stock price and by that the equity of the company. The top management chose to stand firm on the project since they realized that the organization had invested heavily in the project and therefore there would be “no going back” especially after the processes had been aligned with the new information systems. Some other organizations had tried similar projects but they had not realized the great potential of recycle the components of the system to enhance the spin off organizations.

The Outcome
The first EA / business IT – alignment project led to that the organization had their first approach to how improve the processes and how to work smarter it also led to that the organization became aware of their architecture. The project led to the organization reached its foundation architecture (the basic step of maturity). The project led to the management and stockholders understood the need to become more mature to go for the extended architecture where the business managers make use of EA tools to redesign their business.

Every organization has an architecture otherwise it wouldn’t be possible for the organization to do business or transform raw materials into products or labour power into services.

However the Coherency Architect has to focus on how to identify the architecture in a methodical way so the Coherency Architect can make develop a functional approach on how to define potential coherence related problems and how to mature the architecture so the organization will make progress and work in a smarter way to reach the goals of the organization (those defined in the official strategy).

To identify the various problems then the Soft Systems Methodology or the Work System Method which can be used to collect data about the architecture in a systematic way. If the Coherency Architect doesn’t make use of a systematic approach then it is likely that he or she will miss potential flaws, errors, dangers etc. that might have a great impact on how good the coherence of the organization is.

There are two general approaches the Coherency Architect can make use of to identify the processes in the organization. The first one is the so called exhaustive approach that deals with the Coherency Architect identify all the processes in the organization and create plans for them. The second one is called the “high – impact” approach that deals with that the Coherency Architect deals with identifying the core processes in the architecture (organization). To start with then it might be preferable for the Coherency Architect to deal with the core processes and then adapt the Coherency Program to alter them.

Besides the two above mentioned methodologies then the organization can make use of various techniques such as the rich picture and flowcharts to analyze how the various elements in the organization impact the general outcome of the organization.

An example of a functional approach to analyze an architecture could be that the Coherency Architect made use of a qualitative data collection method which means that the Coherency Architect would go an observe and interview potential members of the organization. The members have to be put located various places in the organization so the Coherency Architect can create the best overview of the organization as possible. When the first round of interviews have been collected and processed then Coherency Architect should go observe the members of the organization perform their daily tasks and identify how the raw materials are transformed into products or services. The Coherency Architect should especially focus on how the various linked processes interact use this view to identify potential problems with the coherency of the processes. When these problems have been identified then it is likely that the Coherency Architect should make use of either the SSM or the WSM methodologies. These methodologies are used to create an understanding of what is happening within the system. However it is notable that the two methodologies belongs to two different paradigms which view the world very differently.

The Work System Method belongs to the “functional paradigm” where the Soft Systems Methodology belongs to the “interpretive paradigm”. The two paradigms are defined by Burrell and Morgan (1979) in their article dealing with sociological paradigms and organizational analysis.
The functionalist paradigm works with the idea that the architect will collect the needed data and then come to a conclusion based on his or her own world view. The interpreting paradigm works with the idea that the architect has to facilitate the different world views in the organization and thereby assist the members of the organization with developing a solution e.g., a new work system, information system or a third solution.

The two paradigms will lead to various kinds of conclusions and of which there might be opposing. It is therefore vital that the Coherency Architect is able to identify the limits of his or her own world view and identify how the members of the organization thinks and acts according to their world views. If the Coherency Architect makes use of the wrong approach then his or her suggested solutions might turn out to be out of touch with how the organization assume its business works and the solution will be turned down.

When the Coherency Architect has gone through this process then he or she will be able to identify one of the three different forms of architecture an organization might have. As mentioned earlier then every organization has an architecture.

Doucet et al. (2009) identifies three possible architectures. The first one is the architecture of an organization before an EA (enterprise architecture) toolkits have been applied. The architecture is called the articulated architecture.

The more mature architecture is called extended architecture where the EA toolkits has been applied for the IT side and some of the processes at the business side has been identified and is making use of EA principles.

The most mature architecture is called the embedded architecture where the EA principles are embedded into every business and IT project. Doucet et al (2009) defines this state as where the EA grid is put into practice and where all project, processes and sides of the business work with practices from EA and therefore have achieved the goal of Coherency Management.

To summarize then the Coherency Architect has to focus on:

1. The methodology used to collect data.
2. The paradigm the Coherency Architect make use of to identify issues with the Coherency of the processes, structure, people, tasks and technology within the organization.
3. The world view the Coherency Architect make use of when he or she develops his or her coherent solutions for the organization.
4. The states of the architectures in the organization and how to reach them.

Sources

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

* Burrell, G., & Morgan, G. Sociological Paradigms and Organizational Analysis (1979).

Nonaka's Framework

The SECI model deals with that all knowledge is made by individuals, the individual share his or her knowledge with other individuals (first quadrant) in order to diffuse knowledge then it has to be articulated e.g., in papers, reports, books, blogs, videos or podcasts or other media (second quadrant). When knowledge is diffused then there are individuals who can enrich it by adding to the articulated knowledge (third quadrant). Individuals then read the papers, reports, books, blogs or watch the videos or listen to the audio and then by that learns how to make use of the knowledge and by that makes the knowledge implicit (fourth quadrant).

As before mentioned then the members of the organization are key in relation to the development of the organization architecture. Which means that the members of the organization have to be enabled to share their knowledge with one another and they would need some incentives to do so.
It is notable that economic incentives for sharing knowledge almost certainly will lead to that the cost for knowledge will increase and yet it will lead to that at some point then the members will stop sharing their knowledge and eventually when they have received all the incentives the organization can provide them with then will stop sharing knowledge.
E.g., who might want four company cellphones that are exactly a like or two company cars or multiple company paid DSL connections etc.?
To avoid this situation then the Coherency Architect has to understand the organization culture and thereto the Coherency Architect has to influence the organization culture so it becomes a necessity to motivate the members of the organization to make use of the IT tools (web 2.0) and to share their knowledge with the rest of the organization.
To enable the members of the organization to share their knowledge then the Coherency Architect has to empower the members and by that focus on moving the organization typology towards the adhocracy (Primary coordination is mutual adjustment) or towards the professional bureaucracy (primary coordination form is the skills the individual member has). Thereto should the organization should give the employees the resources to form communities of practice where they can go and communicate, work with and share the knowledge. It is notable that Coherency Architect or for that matter the organization can’t go in and interfere in the process which will lead to the members of the communities will lose their interest in working in the communities.
To make knowledge management coherent with other processes in the organization then the Coherency Architect should work with how the business processes can be supported by 1) decentralization and empowerment, 2) how IT can enable the members to break down the barriers in the organization (so the knowledge can flow freely), 3) how a functional compensation system should be designed (cultural based) so it enforces the urge to share knowledge and 4) deployment of communities of practice (winning trust among the members of the organization and providing the necessary support) and continuously align the primary business processes to the knowledge sharing processes.
The Coherency Architect has to think in new terms to ensure that the organization achives its goal in a smarter way which means that the work processes have to be obliterated and designed to interact with the technology new and smarter processes; however it is notable that the Coherency Architect has to understand that if the members of the organization finds the changes undesirable then they will reject the processes and work against them and key employees will eventually grow discontent and leave the organization taking the knowledge with them.

Coherency Management has its focus on how to make the organizations work smarter. By that the business processes have to be altered which will leads to changes in the Information Systems and changes in the organization hierarchy.

When such changes occur then the employees and the managers have to work together in a different way which means that the organization culture and the organization subcultures will be challenged. Thereto such projects needs support from the top and middle management and various other stakeholders to succeed.

Since Coherency Management can’t be achieved in one single project and the organization has to develop its architecture (and coherency) over time then the program has to be continuous where various projects are defined and implemented over time.

To be able to win over the guiding coalitions then a Coherency Initiation Plan has to articulated. The Coherency Initiation Plan has to consist of these elements:

1. A Stakeholder Analysis and Plan.

2. A Plan for coping with the political struggles within the organization (the opposing factions)

3. A Communication Plan.

4. Lobbying for further change e.g., to the management, stock owners or other internal as well as external stakeholders e.g., via the press.

When the “Coherency Initiation Plan” has been articulated then it is necessary to work with how the organization is designed in the way culture, technology, processes, structure and management interact and how they create value for the organization.

The Coherency Architect has to take this into account and therefore should the “owners” of the processes be won over to believe that they can and will gain by the process changes. As mentioned in Coherency and Organizations then the employees and the managers are key to success. This means that the Coherency Architect has to make sure that he or she understands how the various departments, employees and managers influence the processes in the organization. This can be achieved by the Coherency Architect map the processes in the organization and identifies which departments that handles the various subprocesses and then investigate who are in charge of the processes. The processes can be identified by using a flowchart diagram. The persons who are in charge needs to be involved in the process change e.g., by applying the Soft Systems Methodology or the Coherency Architect use extensive interviews to form a qualified opinion.

It is important that the Coherency Architect continues to communicate to the stakeholders so the funding and the support in form of goodwill towards the Coherency Program are kept intact.

To investigate how the organization can create value then it is necessary for the Coherency Architect to investigate how the architecture of the company is designed. Remember that the point of Coherency Management is to make the organization reach its goals in a smarter way and therefore should the Coherency Architect work with several different tools to investigate the processes, organization culture, organization structure, management and technology (some proposals for how to do so will be handled in a future blog post).