For some time I have been working with adapting the business model canvas for explaining how an enterprise architecture program delivers value to the it-department. The scope of the model has been on the foundation architecture where the outcome of the enterprise architecture program is mainly used by the IT department.
I am aware of that Tom Graves has done something similar, though he has made a completely different model, and as such his model is fine, but the audience that I intend to communicate with would be more likely that they will understand the value proposition of enterprise architecture through a model designed upon the business model canvas compared to a model based upon Graves’ model.
As you might have guessed then I had to adjust the business model canvas in order to expose the data on how the enterprise architecture program delivers value in the best way possible.
The first seven phases have been renamed in order to adapt the model for how a department or function within an IT department delivers values.
The first phase is about key partners needed in order to produce any form of value by the enterprise architecture program.
The second phase is about how the key activities that are needed in order to produce value. The needed activities would have to be organized around on handling the resources.
The third phase is about the key resources needed to produce the services or products needed by the segments of the it department.
The fourth phase is about the value proposition. In other words its about the initiatives at hand.
The fifth phase is about team relations and they are usually essential for both implementing and producing the services. Especially if we assume that enterprise architecture is about creating value through others.
The sixth phase is about channels. How does the enterprise architecture program deliver resources
The seventh phase is about the segments of the IT department that receives the services from the Enterprise Architecture program.
The eight phase is about the Enterprise IT Investment structure. This particular section of the business model deals with the identification of how the current situation of the IT Architecture the IT organization processes.
The ninth phase is about scenario planning, that deals with planning for a better IT Investments for the IT department.
The tenth phase is about the Improved Enterprise IT Investment Structure that deals with multiple actionable plans for changing and optimizing the total architecture.
All together these phases can present the necessary data to the decision-makers in order to give them an insight on how enterprise architecture delivers value to them. Value is key in situations where organization have limited access to resources.
The foundation architecture is as earlier mentioned scoped on delivering value to the IT department and through to the IT department to the rest of the enterprise. The model is published under the Creative Commons license (share alike).
While working with the concept of Enterprise Architecture it usually becomes a necessity to chose and implement a framework. As such the chief architect can either implement a standard framework, and as such commence the project of documenting the AS – IS situation1. It is an option to adapt the standard framework in order to make it suitable for the enterprise as such make it work better in the implementation process. An alternative to deal with a standard framework the chief architect could develop his or her own framework that from the start has been developed in mind to the specific enterprise. This specific paper is dealing with some pitfalls that I have identified while I have been working with developing a framework by myself.
I will first and foremost outline my definition of what a framework is, then I will deal with which five problems I have encountered and how these problems can be avoided. As such this will become a list of dos and don’ts. Finally I will summarize my findings in a conclusion.
What is a Framework
There are several reasons to apply a framework e.g. the potential of increasing the success rate of the implementation of the Enterprise Architecture program, and as such I have chosen to go in depth with a definition of what I think a framework is about.
I have defined the concept of the Enterprise Architecture framework as essentially a document that outlines which artifacts the chief architect and the Enterprise Architecture group should be identifying, describing and organizing into a repository. Thereto does the framework defines which roles that are supposed to be in the Enterprise Architecture group and how the AS-IS state should be documented. Likewise does the framework details how the scenarios deals with the process of change from the AS – IS situation to a desired TO-BE situation. In between these two it usually a good idea to have a transition plan (Bernard 2005, p. 33).
I have now defined how I understand the concept of the framework. The framework is a key element in order to implement an organized documented overview of the AS – IS situation of the enterprise.
Problems and Solutions
The chief architect should include stakeholders for its internal environment in order to gain an understanding of how they understand the enterprise’s social systems, business systems and information systems. As such the chief architect would have to gain an understanding of how each of the parts of the enterprise works and how these systems interact with one another.
The framework should reflect the organization since it would have to reflect the current conditions yet the framework would have to be used as common reference model for the Enterprise Architecture group. Eventually should the framework be adaptable to filters in order to give the various stakeholders the information that they would need in order to ensure buy-in and support for the changes needed in order to transform the enterprise to the desired state.
While developing the framework the chief architect shouldn’t make the framework too complex in order to the level of details and the language used. Likewise should the chief architect be aware of that the repositories that he choses should be dynamic due to the possible rapid changes in the architecture of the enterprise while the organizational changes are occurring. I am of the opinion that organizations changes more rapidly than the decision makers realizes since people changes habits and their ways to deal with certain tasks due to the changes in their (and thereby the enterprise’s environment). I have come this particular opinion due to an article I have read by Orton and Weick (1990) where Orton & Weick argues that there are several voices of loosely coupling, and one of these voices (the voice of typology) deals with the fragmented environment impacts the possibility to enforce change onto the social systems (Orton & Weick 1990, pp. 207-210) due to connections and impacts of the internal and external environments will in some points stop a centrally planned change.
It is a necessity to avoid rigidity and too much bureaucracy so to say the chief architect would have to avoid creating a paper tiger. It is one of the major problems with Enterprise Architecture , and Wagter et al. (2005, p. 178) discusses in their book titled “Dynamic Enterprise Architecture”. Likewise does Wagter et al. discusses the concept of implementing Enterprise Architecture in small steps and small sections due to the unnecessary usage of the enterprise’s resources in implementing a system in a world where all resources should be contributing to the enterprise’s competitive advantage.
Dos and Don’ts
In order to give the various chief architects or other individuals in the Enterprise Architecture groups in the enterprises out in the industries, I have articulated five things to do order to develop a good framework. Likewise have I articulated a list of five pitfalls that the chief architect or others in the Enterprise Architecture group should avoid in order to implement a successful framework.
1) Do include stakeholders in the development of the framework.
1) Don’t focus too much on the technical architecture while you develop your framework.
2) Do work with both social systems, business processes and IT.
2) Don’t assume that the framework can be used for a total codification of knowledge in the enterprise.
3) Do work with the business architecture. After all it is the enterprise’s business systems that generates value.
3) Don’t assume that the framework is perfect after you have designed it at the desk. The framework has to be improved during the implementation and after the implementation since new stuff and perspectives will occur.
4) Do work with an approach to keep the framework simple.
4) Don’t assume that people align themselves with a centrally planned strategy. Assume that the organization consists of many different entities that can be impacted by elements outside the organization’s boundary.
5) Do work with the stakeholders understanding of what the framework is and why it is important.
5) Don’t develop a “paper tiger” it makes no sense to develop at lot documents that nobody reads or acts according to.
Which leads to the conclusion of this paper.
A framework is a fundamental element that the chief architect and the decision makers of the enterprise have to be involved with in order to ensure that the Enterprise Architecture program can be implemented in the enterprise. As such there are five things that the chief architect should take into consideration while developing his action plan e.g. Include the stakeholders in the development of the framework, the inclusion of business and IT, the business architecture is the primary architecture, keep the framework simple and ensure that the stakeholders understand what the framework is about and why it is important. Likewise are there five pitfalls that the chief architect has to take into consideration while he develops on the framework e.g. avoid to focus too much on the technical architecture, he shouldn’t assume that the framework is a Swiss army knife in regards to knowledge sharing, he shouldn’t think that the framework is perfect, especially pre-implementation, he shouldn’t believe that people just align themselves with planes developed by a central administration and last but certainly not least. The chief architect shouldn’t develop a paper tiger.
The keyword to framework development is simplicity, prototyping and iterative change.
Bernard, S., A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.
J. D Orton and K. E Weick, “Loosely coupled systems: A reconceptualization,” The Academy of Management Review 15, no. 2 (1990): 203–223.
Roel Wagter et al., Dynamic Enterprise Architecture: How to Make It Work, 1st ed. (Wiley, 2005).
During the summer of 2010 I worked with a literature review that basically dealt with how Enterprise Architecture (through Coherency Management) could be addressing the issue of rewiring the form of leadership which exists in the enterprise.
The IGIA-Framework is a form of synthesis of various theories within the field of corporate governance, IT strategy, IT governance, Workforce planning, Enterprise Architecture and Coherency Management.
The edition of the framework that is released with this blog post is advocating a big bang change approach which demands a lot of resources and a long term commitment. This will be altered with the next edition of the framework which I plan to release during 2011.
The IGIA-Framework needs to address the short turn achievements while using Enterprise Architecture and Coherency Management, and for that reason should the IGIA-Framework be evaluated and developed into a framework that can enable enterprises with gaining a better form of leadership, structure, architecture and not to forget a chance to achieve a sustainable competitive advantage.
With these words I publish “Integrated Governance: A Way to Achieve Competitive Advantage” the certified edition.
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.
I wondered on how an Enterprise Architecture framework could be developed in a way so it was practical and academic. Therefore I started on developing the ATOM-framework. I want to clarify that ATOM stands for Architectural, Technological, Organization and Managerial and as such the framework addresses all four aspects.
The Foundation of the Framework
The framework is based on that the enterprise (regardless if it is within the sphere of the public sector or the private sector) has to have a vision and a mission for why the enterprise is existing and what it should accomplish. The vision and the mission isn’t necessarily a statement on how to create profits but how to create value. Value can then be defined either as value through profits or value through the usage of resources or through the products or services the enterprise provides the customers or clients).
Through the vision and the mission is the goals for what the corporate strategy should deal with. The corporate strategy is by that a tool (a plan) for how the enterprise should achieve its goals. From the corporate strategy a lot of so called sub-strategies can be identified e.g., the financial strategy, the HR strategy (workforce planning), communication strategy and technology planning.
However there is one particular sub – strategy that differs from the rest of the sub strategies and that is the IT strategy & IT governance section.
The reason for this is that the importance of Information Technology has increased dramatically the later years and therefore this particular form of strategy has to be regarded with great care. However the IT strategy & IT governance approach shouldn’t be based on the idea that the IT strategy or for that matter the governance section can stand alone.
The assumption is that every enterprise has an architecture and as such the architecture is a necessity for that the enterprise can perform the activities that creates value. Every enterprise has an architecture but how the enterprise architecture can aid the enterprise with gaining a competitive advantage. For this the enterprise architecture has to be matured.
When maturing the architecture then there are several issues that the executive team has to deal with the architecture to achieve better results that in time will enable the enterprise in achieving competitive advantages.
The principle assumption is that technology is a tool that can be used to achieve better results for the enterprise e.g., computers, e-mails, and information systems. When speaking of technology then the enterprise can also be in a situation that ordinary technology such as cars, machines and other stuff that is used to make the employees, managers and top managers in achieving the goals and visions of the enterprise.
The enterprise consist of people. People have to change the way they do their work, interact with one another and think when they work. All in all the behavior the employees act after is the paradigm.
The managerial aspect of the framework deals with how the executive team of the enterprise deals with the decision making in how to apply the changes needed to enable the enterprise in achieving its goals and thereby its transformation processes. If the executives do not support the transformation processes through anchoring their decision making through embodiment through their actions.
The assumption of the corporate strategy is that strategy can be both what is articulated in a particular plan but it can also be the way the strategy is implemented through the actions taken by the executives, middle managers and employees.
The Structure of the Framework
The initial phase of the framework is based upon the idea that architecture is the driving force, then technology will enables, organization is build upon adjusting the behavior of the members of the enterprise (managers, middle managers, employees etc.).
When implementing the framework then it is a necessity to think that the framework and the concept of enterprise architecture needs to be supported by the management (managerial) and therefore the managerial column has been rearranged. Secondly to that then technology is an enabler for achieving competitive advantage and therefore it shouldn’t be considered as secondary. Then why is architecture in front of the organization and managerial level? The reason for this is that all enterprises have an architecture and when the architecture is matured then the enterprise is able to achieve better results from its managerial, organizational and technological elements.
This leads to the principles of the architecture.
The Principles of the Architecture Aspect
The architecture is the driver for change in the enterprise. The architecture needs to be uncovered so the executives and the assumed chief architect can define what projects that are needed to make the enterprise more able to adapt to its environment, be more efficient and making the enterprise architecture able to achieve its goals.
The architecture aspect deals with identifying various artifacts that already exists in the enterprise. The focus will be on artifacts such as the current corporate strategy, IT strategy, financial strategy and work force strategy. Likewise will artifacts such as concepts of operation, business models diagrams, documents on IT-governance, and documents on how the enterprise adds value to its customers. When speaking of IT governance then business cases, project descriptions and documents that creates an overview of how the IT and business projects are aligned have to be uncovered.
It is worth to mention that if the enterprise hasn’t articulated the various artifacts then the chief architect among others have to develop the artifacts.
When working with classifying the architecture it might be a help for the enterprise architect to assume that the corporate strategy is the driver for how the various projects within the framework that the enterprise (organization) is.
The ATOM-framework it can be assumed that the enterprise somehow is organized like an ancient egyptian pyramid.
The first level deals with the management of the enterprise and as such with the formulation of the corporate strategy.
The second level deals with the business models and business processes of the enterprise. This deals with how the enterprise creates value to its customers (or clients).
The third layer deals with the business to IT alignment phase. This means the enterprise focuses on making their IT work as intended.
The fourth phase deals with the information related artifacts e.g., how are the information systems and databases designed. The information systems process the information that is stored in the database.
The fifth layer is build upon the idea that every other layer in the enterprise is related or build upon the usage of Information Technology.
When the artifacts have been categorized then they have to be organized into a what is called a repository that can be used to communicate the various artifacts to the various stakeholders and actors with in the enterprise. This will enable the holistic view on how the enterprise functions and how the enterprise should be changed.
As such the assumption is that the executives in the enterprise that articulates the corporate strategy and as such all the other strategies have to be aligned with the corporate strategy.
The Artifacts for the Strategic Level
Artifacts that can be identified are the corporate strategy and the elements therefore e.g., the enterprise strategic portfolio. What are the goals of the enterprise and how can it achieve the goals?
The strategy can be driven both through a formal strategy as well through and embodiment of the actions of how the executive team works.
The Artifacts for the Business Level
The artifacts at this level are the business model (or business models), concept of operations and business modeling.
The Artifacts for the IT-alignment Level
The artifacts within this level are lists and specifications of how the enterprise’s business processes and business projects are aligned through the IT projects.
The Artifacts for the Information Systems Level
This level is characterized through the identified information systems and databases systems. The databases have to be categorized and the usage of the enterprise’s databases. Artifacts that can be identified are database diagrams, E/R-diagrams and Information Systems diagrams. IS-diagrams includes maps & diagrams of ERP and BI systems.
The Artifacts for the Technology Level
This level deals with that technology that is used in the enterprise to enable the enterprise to create the products or services they sell. It is notable that technology as such also can be supportive for internal processes in the enterprise.
Technology can be both the ‘ordinary’ forms of technology such as machines and the newer forms of technology such as Information Technology.
Artifacts that can be identified in this level is network diagrams, Obashi diagrams, switch diagrams etc.
The Principles of the Managerial Aspect
The executives have to understand and to work with the issues of Enterprise Architecture and as such the managerial team (executives and middle management) of the enterprise have to act accordingly to the corporate strategy.
As such the managerial actions have to reflect the corporate strategy (embodiment of strategy) and the program for Enterprise Architecture has to be anchored to the executive group so resources and responsibilities can be allocated.
The Enterprise Architecture group should be given the resources to establish its self and the document and ultimately change the way the way the enterprise (and thereby the members of the enterprise e.g., executives, managers, project leaders, workers etc.). As such the organizational approach needs to be dealt with as well before the concept of enterprise architecture and coherent governance can be achieved.
Within the group of people who will work with the enterprise architecture there have to be certain roles e.g., Chief Architect and ordinary architects who have to work with identifying or developing the artifacts needed to implement a repository.
The Chief Architect can be identified as the person in charge of choosing the framework, modifying and giving the necessary responsibilities to the architects. Depending on the maturity of the enterprise architecture there are different forms of architecture.
The Principles of the Technology Aspect
The technology aspect deals with that the enterprise make use of technology to produce or aide the production of services the enterprise in some way or the other with production of the services. The aspect of technology is it needs to be utilized and applied to alter the business processes more effective than they were before the processes were re-engineered. As such the aspects of technology needs to be measured and benchmarked so the economic benefits of deploying the technology can be justified and the individuals, groups and committees that are responsible for the implementation are hold responsible for the benefits that where estimated before the enterprise chose to implement the the particular technology (through an business based IT project or program).
The technology aspect has to be aligned with the managerial and the organizational aspects due to so technology generate the greatest amount of value for the enterprise as possible. However it is notable that if the enterprise and the enterprise architects as such assume that operational efficiency is the key to achieve competitive advantage then they have to refocus their attention. According to Porter then the focus of how to achieve a competitive advantage then the sole focus on operational efficiency will not result in a competitive advantage (Porter 1998).
The Principles of the Organization Aspect
When the enterprise architecture is changed the focus has to be on how the members of the enterprise (executives, middle managers and employees) think and behave.
Therefore should the enterprise architects focus on elements from the field of organizational theory and organizational change. E.g., it is almost universal that a communication plan has to be developed so the chief architect a long side the executive team can communicate to the stakeholders on why the change (adaption of Enterprise Architecture) is needed and the communication needs to address the changes over time and that the members of the enterprise needs to be reassured on that they are doing the right thing and the change (as an overall program) is unavoidable.
Kotter (Kotter 1995) addressed the aspect of communication as one of the key failures that lead to lack of change in enterprises. In a response to communication should an attempt to change be based on communicating facts and feelings (Kotter 2008). Culture as such consist of ideas and feelings that are shared among a certain group of individuals (members of the enterprise) and to impact these feelings then it is a necessity to impact the feelings. Among these feelings are the feeling of winning the one that needs to be emphasized in the communication.
Besides the impact on how to impact the organization culture then the enterprise needs to restructure the organizational hierarchy so it is possible for the Chief Enterprise Architect and the Enterprise Architects can implement the changes needed without being undermined through other factions in the enterprise. Ideally should the Enterprise Architecture group be assigned to be working with or under the Chief Operations Officer since Enterprise Architecture should be generating the benefits of generating the overview that is necessary to initiate coherent improvement programs. If the Enterprise Architecture group is located under the CIO then it will often lead to a too IT-focused EA – approach that is implemented.
Implementing the Changes
When thinking of the success of the strategy that the enterprise has to implement then it is a need that the enterprise takes all of the four aspects into consideration. Leavitt (Leavitt 1965) designed the diamond to represent that when a task has to be changed then the structure of the organization and the way the employees acts has to be changed and like wise does it impact the technology that is applied in the organization.
It is fundamental that the policy makers and the strategists takes this into consideration and that can be done through applying Enterprise Architecture and using the ATOM-framework.
The Further Development of Enterprise Architecture & the ATOM-framework
Enterprise Architecture can be considered both as an form of documentation but also as a form of governance. Bernard (Bernard 2005) and later Doucet et al. (Doucet et al. 2009) defined EA as form of governance that would make the enterprise better suited to adapt to its environment.
The focus of the ATOM-framework has to be considered as an all around approach on how the strategies (corporate strategies) impacts the various other components and levels of the enterprise. When it comes to development of enterprise architecture and the ATOM-framework then the question of how Enterprise Architecture can enable the employees to contribute more to the enterprise through their passions and creativity, how the enterprise can be assure that their procedures and policies enables the enterprise to achieve its goals.
For that further research into Coherency Management (the extended approach to Enterprise Architecture) has to be investigated in case studies. The same can be said about the ATOM-framework and likewise should the further development of the ATOM-framework support complex issues of employee motivation & behavior, artifact categorization & establishment, and management innovation. Likewise does the framework need to be tested in a series of case studies to first of all be tested and as such be improved when the flaws of the framework desig are discovered and dealt with.
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.
Kotter, J.P., 1995. Leading Change: Why Transformation Efforts Fail. Harvard Business Review, (March – April 1995), 9.
Kotter, J.P., 2008. A Sense of Urgency, Harvard Business School Press.
Leavitt, H.J. , 1965. “Applied organizational change in industry: structural, technological and humanistic approaches”, in: Handbook of organizations, edited by J.G. March. Chicago: Rand McNally.
Porter, M.E., 1998. On Competition, Harvard Business Review, Boston, p.40-42.
The focus is to combine lean, Toyota Production System, Enterprise Architect and Coherency Management into a guide line like the Bushido: The ways of the warrior.
The main principle of Coherency Management is to implement a holistic management approach that enables the management to achieve alignment, assurance and agility.
Enterprise Architecture is the foundation of achieving Coherency Management and it is possible to combine that with efficiency to achieve an enterprise that have a lesser amount of slack and adds more value to its share holders and customers.
First of all an Enterprise Architecture program has to be established.
Second of all an economic analysis of the activities that the organization performs to get income.
Third of all communication of change needs to be performed. That means that the Chief Enterprise Architecture needs to communicate to various stakeholders. The various forms of stakeholders needs to be dealt with in different ways. The various stakeholders needs different kind of information.
Third of all the Enterprise Architect has to work with various applying a framework e.g., the EA3 Framework, TOGAF, OIO or other framework.
Forth of all the Chief Architect needs to demonstrate the value of the Enterprise Architecture. The Enterprise Architect should apply the evaluation models that give the information that the stakeholders needs to make their mind (approve or disapprove) the Enterprise Architecture program. It is necessary to apply the evaluation model for the business processes and IT processes before the EA program has been established. This is needed to compare the before and after approach.
Fifth of all the Enterprise Architect has to make use of his or her talent to deal with the persons who have to change their way of working after the Enterprise Architecture program has been established. According to Doucet et al. (Doucet et al 2009) then the organization then there are three forms of applied Enterprise Architecture. The first form is known as Foundation Architecture. The Foundation Architecture is when the organization has applied Enterprise Architecture in the IT department. The IT department has been the driver of the Enterprise Architecture and made use of it to uncover the the operational model of the Enterprise Architecture. When the organization mature the Enterprise Architecture then it should over time come to the Extended Enterprise Architecture where both the business side of the enterprise and the IT side. The IT side and the business side works uncovering the business and its processes. There are several forms of architects who have various functions and responsibilities. There will be a centralized office for Enterprise Architecture and there will be a commitment from the Executive Group1 to enhance and use Enterprise Architecture to govern the enterprise. There are business architects, process architects, technology architects information architects and the Enterprise Architects. The Enterprise Architects will be dealing with handling the overall aspects of Enterprise Architecture. The Enterprise Architects will be dealing with keeping the other architects in line with the Enterprise Architecture program.
After the ExtendedEnterprise Architecture level then the organization will be moving toward the EmbeddedEnterprise Architecture. The form of architecture is so far a kind of utopia where every employee in some way acts as an architect which leads to that there are explicit and implicit architects. Theres is a focus on a central EA department that consist of the best Enterprise Architects who works with the overall Enterprise Architecture framework and enabling the other architects with their work through empowering the framework and governance of the Enterprise Architecture.
Sixth of all the Chief Architect has to implement a Coherency Management framework so far there is only one kind of a kind. That means the CoMOF framework has to be adapted. As it is with all other frameworks then the CoMOF framework is a generic framework and it has to be modified for the particular organization. While applying the modified CoMOF framework in the organization then Coherency Architect (or Chief Architect) has to make use of the efficiency theories such as LEAN, Six Sigma or Toyota Production System. This is a necessity to improve the organization’s enterprise.
Seventh of all the Coherency Architect has to ensure that executive group continues supporting the Enterprise Architecture program and Coherency Management program. This have to be done through emphasizing the support for Enterprise Architecture by using external pressure to enable the internal pressure(groups with power) to invest resources into renewing the program. If the Enterprise Architecture program isn’t renewed then the value of the Enterprise Architecture program will lose value. The same is the case for the Coherency Management program.
Eight of all the Chief Enterprise Architect should be working for improving the channels of how the Enterprise Architecture is transforming.
The Coherency Architect should be therefore be working with being efficient, effective and use his or her experience to develop develop efficient enterprises through Enterprise Architecture.
Focus has to be on efficiency and effectiveness. The ideal is that the Coherency Architect should be thinking in systems where to much slack is minimized; however enough slack to harvest the benefits of innovation.
The vision of Enterprise Architecture has to be communicated to the stakeholders . The people skills and abilities to communicate fluently with people are virtues.
Improving the Enterprises and their Enterprise Architectures then the Coherency Architect have to focus on influencing the organization cultures to institutionalize improvement through Enterprise Architecture.
Applying the Code
The code can be applied through the model dealt with above . The path to improvement is designed around the stones n the circle. The circle represents continuity. Bernard’s EA 3 framework is located in the bottom is matured a long side the principles of the CoMOF-framework. The lines with arrows are symbolizing the maturing process and a part of the continues process.
1Top managers including CEO, CIO, CFO and COO etc.
According to Bernard (Bernard 2004) then a Chief Enterprise Architect or what equals to an Enterprise Architecture program manager is selected then the definition of the EA framework and the EA methodology becomes a necessity.
The Definition of the EA Framework
An EA framework is dealing with what the EA program will document.
The Definition of the EA Methodology
The EA methodology deals with how the Enterprise Architecture documentation is articulated and used.
The EA Cube and its Construction
The simple edition of the EA cube that explains the various components, and layers within the framework.
The Documentation Process
There are six steps that needs to be gone through according to Bernard (Bernard 2005, p. 97):
The process includes a framework.
The process includes the components.
The process includes the current architectural views.
The process includes future architectural views.
The process deals with the transition plan for going from “TO BE” and the “AS IS” architecture.
The process deals with threads that influence the enterprise architecture on all levels.
A Comparison of EA Frameworks
The foundation of the EA Framework is John Zachman’s Framework. It was originally based on an approach that it could be explained and dealt with as if you had to build an airplane or a house. The blueprint analogy was used to articulate the framework.
In general there is one single mistake that the Enterprise Architect can do when working with the Zachman framework and that is to focus too much on documentation. This is known as the “Zachman Trap”.
OIO IT Architecture Framework
The OIO framework (based on the white book on IT architecture) was developed for the Danish Ministry of Science. Its focus is on the Danish Public sector. The intention was to implement Enterprise Architecture to give the decision makers in the Public Sector a better foundation for how the single organizational entities operates.
From a management perspective the idea was to enable the public sector to standardize and centralize processes and decision making.
The OIO framework is based on the same paradigm as the EA 3 Cube by John Zachman.
As the illustrated above then there can be defined a governance process and a documentation process.
The two circles represent activities used to deal with updating and developing the architecture. The circle located in the bottom of the third illustration deals with the process of the “AS IS” and this is connected to the process of creating a vision, a business architecture, information architecture and the technical architecture.
The OIO-framework is often criticized for being to comprehensive and often the Enterprise Architects have to invest too much of their time to identify artifacts on various levels and organizing the artifacts according to the OIO-framework. Secondly it has been some time since the last edition of the framework was revised which might be an indicator for that the Danish Public sector is either static in its development or that the state plans to release a new edition of the framework or an entirely new framework. In the other hand the OIO-framework has an entire section dealing with defining and identifying architects which in my opinion is a strength by using the OIO-framework since it enables the Chief Enterprise Architect to communicate to the stakeholders who have what abilities, responsibilities and not to mention accountability during the Enterprise Architecture process.
The EA 3 Cube
The EA 3 Cube was developed in 2004. The Framework is designed as a cube and it is build upon the idea that hierarchies are needed to avoid sub-architectures (Bernard 2004, pp. 104 – 105).
According to Bernard then the business goals are the drivers of how the Enterprise Architecture is designed.
The EA 3 Cube is based on the primary function of organize and planning IT resources and documentation of the Enterprise Architecture. (Bernard 2004, p. 105).
The framework is build upon five levels and as before mentioned these are hierarchical to avoid sub-architectures.
The Five Layers of the EA 3 Cube
Goals and Initiatives is as before mentioned the driving force of the Enterprise Architecture and therefore are these located in the top of the cube (as the first and primary layer).
Products and services shows how Information Technology impacts the various products and services.
Data and Information is used to document how the Enterprise makes use of information “AS IS” and how the information flow should be designed for future situations “TO BE”.
Systems and Applications is used to organize and group the various information systems that give the organization its IS capabilities.
Networks and Infrastructure deals with the so called backbone of the Enterprise Architecture and it includes how the networks interact and how various technologies interact such as VOIP and LAN, WAN etc.
Lines of Business (LOBs) that can be considered as a specific activity within the organization and all the have all the five layers of the architecture. The LOBs are named “Vertical Mission Areas”. The LOBs can have their own administration and functions that can be considered divisions within the divisionalized organization.
Crosscutting Components are established so the LOBs don’t create redundant features e.g., e-mail hosting and IT services.
Threads are defined as security, standards and workforce. These three threads go through each level of the framework.
These three frameworks are all located within the same paradigm and are therefore compatible with one another; however in some situations it will be better to choose the one of the frameworks over the other e.g., if analyzing an Enterprise Architecture for a public institution in Denmark then it recommendable to make use of the OIO-framework.
The frameworks have their strengthens and their weaknesses such as the Zachman framework that focus too much on documentation instead of changing the Enterprise Architecture from the “AS IS” stage to the “TO BE” stage. Likewise does the EA3 framework and the EA 3 Cube some benefits and advantages. E.g., is the EA3 Cube a rather simple framework and is therefore easily applied to small and medium sized organizations. In the other hand it tends to be a bit simple and generic which can end up being a disadvantage.
The Coherency Architect should therefore emphasize on choosing the right framework for the right situation and the right type of organization by using a SWOT – matrix or other form of matrix that can assist him or her with making the right choice.
Bernard, S.A., 2005. An Introduction To Enterprise Architecture: Second Edition 2nd ed., AuthorHouse.
The development of information systems have become more complex. The development of the systems and the cost of development has to lead to that the systems can minimize the barriers (constraints of the organization system).
The complexity of the systems leads to issues that the system only adds value to the organization when it is implemented. The barriers that have been diminished by the information systems have lead to that many organizations have become more flat in their structure.
The flatness of the structure leads to decentralization. The decentralized organization will end in anarchy if the system is not build upon an architecture. Zachman deduces that the information systems architecture is related to strategy both the corporate strategy and the IT strategy.
Since it becomes of strategic importance then the enterprise has to invest more attention to the concept of the Information Systems Architecture. The meaning of an Information Systems architecture is losing its meaning without the creation of a framework (this was later known as the Enterprise Architecture framework or Zachman’s Framework).
The framework and the paper is not supposed to present a new strategy planning framework though as before mentioned the foundation for IS architecture is closely related to the concepts like IT strategy and business strategy. The Focus on Architecture The framework was in its origin based on ideas that origin from the architecture paradigm. This means that Zachman is of the idea that enterprises (organizations and companies / corporations) can learn from the thousands of years of experience. The Bubble Charts and the Process Along The first step for an architect is to draw a bubble chart. The bubble chart shows the relationships among the various components.
Thereto the bubble char indicates the shapes and the size of the building. The purpose of the bubble chart is to deal with the communication between the architect (later the Enterprise Architect) and the customers. Then the bubble chart is refined to something a bit more “serious”. This is called the “the architect’s plan” of which the contractors and the sub-contracters will draw their plans. It is notable that the plan might change several times since the estimated costs will lead to changes in the design since the cost is a constraint. This means that the chart has to include more information in a more precise sketchup. Which leads us further into the analogy. The contractor then redraws the architects plan so it fits with the perspective of the persons who are building the systems. Zachman summarizes the various design plan purposes in a table similar to this. It is worth mentioning that the “Nature or Purpose”:
Nature or Purpose (architecture)
Nature or Purpose (EA)
Basic concept of building
Basic outline of architecture.
Final building to be seen by the owner.
“AS IS” or “TO BE” outlined for the decision makers.
Final building to be seen by the designer.
Transformation plan or a more detailed view on “AS IS” and “TO BE”.
Final building to be seen by the contractor.
This is the IT infrastructure and the various other infrastructures.
Sub – contractors designs or sub segments.
Various artifacts within the various plans and charts.
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.
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:
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.
Internal Validity deals with establishing casual relationships where certain conditions are believed to lead to other relationships than spurious1 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.
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.
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:
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.
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.
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.
Yin, R.K., 2008. Case Study Research: Design and Methods Fourth., SAGE Publications Inc.
Coherency Management is about gaining agility, assurance and alignment and these gains are closely linked to the maturity state of the architecture of the organization. All organizations have an architecture the question is how matured it is.
It is therefore desirable for most organizations to one way or the other to identify, mature and monitor the process. Before the identification takes place then the various characteristics of the architectures have to be dealt with.
In this section I will shortly deal with the architectures that are presented by Doucet et al. (Doucet et al. 2009)
The architecture that hasn’t been exposed to Enterprise Architecture and as a result of this the management or other actors in the organization are not aware of how the organization, its processes and its various layers are designed and interacts. This includes that the organizations isn’t aware of how their IT is used to support the various business processes.
The Foundation Architecture is an architecture that has been exposed to Enterprise Architecture; however this has only been applied for the IT side of the organization to bridge the gap between business processes and IT. In this state the Chief Information Officer (CIO) and the IT department has a great influence on how the Coherency Management tools are applied though this a downside and that is that the rest of the organization rarely understands the idea of Enterprise Architecture.
The Extended Architecture is bit more mature in the context of applying Enterprise Architecture. In context this means that other departments in the organization have identified that Enterprise Architecture tools can be made use of to improve the ability of the organization. In relation to who is in charge for the Coherency Management implementation then it is likely that this has passed from the CIO.
The Embedded Architecture is the so far the most mature level an organization can reach by applying Enterprise Architecture tools and change management. This means that the entire organization make use of Enterprise Architecture tools identify, initiate and implement new processes. This means that the organization has enforced a framework that has to be taken into consideration when new processes have been applied.
In addition to the above mentioned architectures the Balanced Architecture (Doucet et al 2009 p. 224) can be added. This is a future state within the Coherency Management concept.
I will therefore discuss the tools that can be applied.
Why Should Architectures be Matured?
When an architecture matures then the organizations that make use of them also become more agile and better in the sense that the organization easily can implement new processes, flows, systems etc.
This means that the organization can gain value for its stakeholders if the organization apply Enterprise Architecture tools to mature its architecture.
There are several tools that can be applied to identify and monitor the state of the organization architecture. I have chosen to make use of Barnard & Grasso (Doucet et al. 2009) that have written a chapter which deals with how Enterprise Architecture can be matured.
According to Barnard & Grasso then these factors are useful to measure:
The above mentioned indicators can be used to identify on what state the organization is on. If the organization is pre-dominantly in the un-mature part of the scale e.g., that the organization has an un-mature architecture. If the organization in any way has indicators that indicates that the organization is on a better level than the sublevel then the Coherency Architect should assume that the organization is maturing its architecture (perhaps implicitly).
There are methods that can be used to mature the architecture. For this the EAAM approach can made use of. The EAMM approach deals with how the Coherency Architect can measure and audit the architecture of the organization.
As with all plans then it is a necessity to work with auditing and control which deals with controlling if the various goals used in the EA programs have been realized. This process is mandatory for every Enterprise Architecture project as it is for every strategic approach.
For this an Enterprise Architecture Audit Program should be established. According to Barnard & Grasso there are to forms for such a program. The first form is the light edition that consist of one to two persons who audit the EA programs in the organization. The analysis of the organization is build upon a superficial (high impact) analysis. The other is the advanced program where two to five persons go through a complete analysis of the EA program.
Gary Doucet et al., Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance (International Enterprise Architecture Institute, 2009).