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.