Category Archives: Enterprise Architecture

Enterprise Architecture is more than IT

Posted on by
Reply

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

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

Challenges of Enterprise Architecture: A Focus on the Transformation!

Posted on by
Reply

Barriers for Enterprise Architecture

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

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

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

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

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

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

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

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

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

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

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

Win Over The Opposition

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

  1. Individuals.

  2. Subunits.

  3. Organizations.

  4. Hierarchies.

  5. Organizations and Environments.

  6. Activities.

  7. Ideas.

  8. Intentions.

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

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

The Burning Platform?

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

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

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

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

Enterprise Architecture and Organizational Transformation

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

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

Projects Don’t Transform the Enterprise

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

Sources

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

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

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

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

Loosely Coupled Systems: A Reconceptulation.

Download the paper here.

Integrated Governance: A Presentation of a Literature Review.

Posted on by
Reply

The Basics of the Review

The review is dealing with Integrated Integrated Governance. Integrated Governance is defined as how corporate strategy, IT strategy, IT governance and Enterprise Architecture are aligned and dealt with.

I have chosen to limit the amount of topics to cope with my limited resources. Therefor I selected what I assumed were the most relevant topics of the literature.

Corporate Strategy

In brief I worked with Mintzberg and his work titled “Strategy Safari” that basically deals with 10 different schools of strategy. The work is one of the few master pieces produced on strategy in the beginning of the 21st century and I added some of the views he expressed in his work titled “The Raise and Fall of Strategic Planning”. I chose to deal with three schools of importance, and then add a systemic approach by using the work “Breakout Strategy” by Finkelstein et al (2007).

I could conclude that corporate strategy is of no importance if it isn’t embodied in the actions of the executives, managers and employees. Likewise could I define some advantages and disadvantages from each of the schools and summed up the ideal approach to strategy development.

My initial assumption was that all other forms of strategy had to be aligned with the corporate strategy, and therefore I worked with an analysis of IT strategy and works within that particular field of strategies.

IT Strategy

I have been able to define two major schools (more likely trends) within the articulation of IT strategy. I have named them “The Integrated Strategy Approach” and the opposing view for “The Separated Strategy Approach”. When you go through the slides you will see that the two approaches do share some characteristics.

The characteristics are that IT is complex compared to the machines of the ‘old days’ and that the executives of the enterprise needs to understand how IT works to really be able to apply Information Technology in a way that achieves the benefits of using IT.

The separated strategy approach is based on the views that are represented by Ross & Weill (2009) in their work titled “IT-savvy”. They state that the IT is so complex that there is a need for an entity to administrate and develop the IT architecture, called the IT department. The IT department is almost a magical place that knows how the enterprise can develop new features and gear the enterprise to do so if only the executives form the “business” listened. For this the operating model of the enterprise has to be uncovered and defined. Through this the decision makers are able to handle the issues. One thing is for sure that the operating model has to be explicit in a document (strategy document) that is articulated after the corporate strategy has been articulated.

“The Integrated Strategy Approach” is based on the assumption that IT can’t be separated from doing business in the modern economy. The corporate strategy has to embed the IT strategy, and that dictates that the “business” and the IT-department needs to be tightly coupled. The approach promotes the view of that sub-optimization and monarchies needs to be undermined. The organization has to view IT as something similar to all other forms of investment and that can be done through abolishing the traditional title of the CIO and replace it with a new form of executive that according to Potts (who wrote the book “Fruition” that is serving as the platform of this particular view of IT strategy).

One particular view the two opposing views of IT strategies shares is that strategy means nothing if it is embodied in the actions of executives, management and employees.

That leads to the findings on IT governance.

IT Governance

IT governance is the IT strategy that is embodied. According to Ross & Weill (2004) claims it deals with defining principles, standards, investments and management of IT and Information Systems. When working with this particular form of governance then Ross & Weill argues that the top performers (40 case-studies they have worked with through their research on the topic) have made use of governance forms that makes includes both the IT department and the executives form “the business”. Two forms are known as duopoly and federation and they can take different forms when it comes to the rights of input and the rights of decision making.

But why should IT be governed in the first place? According to McKeen and Smith published the work “Making IT Happen” (2003) then IT is the foundation of any of the operations that any modern enterprise has. IT will change over time and the costs related to IT will be embedded in close to any kind of asset that can be found in a modern enterprise. Carr (2004) published his article and later his book “Why IT Doesn’t Matter” that basically states that doesn’t contribute to any kind of sustainable competitive advantages since IT is easily coped with. Porter (1998) claims that sustainable competitive advantages can’t come from a single process (or thing) that the enterprise does well, and likewise should the enterprise work with to position itself on the market and that uncovers that Porter belongs to the positioning school within the field of Corporate Strategy.

How can Integrated governance then be applied in an enterprise? My opinion is that Enterprise Architecture can be the glue that makes Integrated Governance work. First of all because it documents how the architecture is working and second of all that when used properly the executives, managers and employees are able to work with realizing the vision.

This leads to a discussion of Workforce planning.

Workforce Planning

I have worked with Gary Hamel’s approach to how management has been done through the early beginning of large social structures to the present. It is worth to mention that Hamel (2007) argues that the old fashioned management paradigm that has been founded on the basics of Frederick W. Taylor’s views on management and responsibilities. Taylorism works with the idea that the corporate management is based on that management demands and control. Hamel argues the role of management needs to be changed to a role where the managers facilitate and supports the employees with achieving goals of the enterprise.

I then approached the ideas of tightly coupled and loosely coupled organizational systems. These two particular approaches have different needs when it comes to transformation.

The tightly coupled organization can be handled through an approach that is tightly coupled to the theories that Kurt Lewin worked with (unfreezing, moving, freezing). The loosely coupled approach has to be dealt with in a different way since the various components of the organization works within various contexts and dominos that all in all moves them back and forward. In other words the enterprise can’t be freezed. Most complex organizations are loosely coupled to be able to give the various departments the autonomy that is needed to cope with the changes in the domino of the enterprise.

In cases where a complex enterprise needs to be transformed then it can be argued that a combined approach has to be applied. The approach can be a combination of Kotter’s (1995) 8-step approach for change with social networks theory that is proposed by Rogers.

This leads to the discussion of the concept of Enterprise Architecture.

Enterprise Architecture

The concept of Enterprise Architecture is defined by Bernard (2005) as the combination of Business, Strategy and Technology. Likewise does he argue that the Enterprise Architecture can be both a form of documentation and a form of management. He states that Enterprise Architecture is a program (many individual projects) that moves the enterprise from one particular state to another (desired) state.

The question becomes how Enterprise Architecture (and the next generation of Enterprise Architecture) can handle the obstacles of organizational barriers and organization culture.

Coherency Management is theoretical addition to the concept of Enterprise Architecture and the paradigm operates with that Enterprise Architecture can address the elements of culture and overcome the human barriers to enrich the enterprise.

This leads to the concept of Coherency Management.

Coherency Management

The concept or perhaps the initial start of a new paradigm deals with that Enterprise Architecture has been too IT centric and that has minimized the positive outcome of Enterprise Architecture. Doucet et al. (2009) published the work “Coherency Management: Architecting the firm for Assurance, Alignment and Agility”. In the book it is expressed that every enterprise has an architecture; however not all enterprises have taken charge of their architecture.

To kick start the approach on how to make use of Enterprise Architecture to achieve assurance, agility and alignment then it the CIO has to be replaced with one who really supports the EA program and the change from the IT centric approach. A radical approach could be to replace the CIO role with the role of the CIIO (Chief Internal Investments Officer) to move away from the IT centric approach.

The CEO role needs also to be re-defined in the sense that it needs to support the EA program to make it embrace the Enterprise Architecture program.

Appendix

Finkelstein, S., Harvey, C. & Lawton, T., 2006. Breakout Strategy: Meeting the Challenge of Double-Digit Growth, McGraw-Hill Professional.

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

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

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

Newell, S. et al., 2007. Managing Knowledge Work 1st ed., New York: Palgrave MacMillan.

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

Orton & Weick, 1990. Loosely Coupled Systems: A Conceptualization. Academy of Management Review.

Porter, M.E., 1996. What Is Strategy? Harvard Business Review, 74(6), 61-78. Available at: http://esc-web.lib.cbs.dk/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=9611187954&site=ehost-live&scope=site [Accessed January 26, 2010].

Sjoelin, P. F. T, 2010. The IT Strategy: An Articulation of the IT Strategy from a Coherency Architect’s Point of View.

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

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

Download the Slides here.

The ATOM Framework: An Idea to Develop an Enterprise Architecture Framework!

Posted on by
Reply

The Background

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.

Architecture

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.

Technology

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.

Organizational

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.

Managerial

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

The Framework (1)

The Framework (1)

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.

The Framework (2)

The Practical Approach to the Framework.

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.

The Framework (3)

The Architectural Aspect of the Framework.

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 Organization

The Organization.

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.

The Framework (4)

The Framework (4)

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 Framework (5)

The Framework (5)

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.

The Framework (6)

The Framework (6)

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.

Leavitt's Diamond

Leavitt's Diamond

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.

Appendix

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.

Download the paper here.

A Compendium for Understanding Enterprise Architecture.

Posted on by
Reply

I hereby publish the notes I have taken during the course in Enterprise Architecture that I have attended at the IT University of Copenhagen in the spring of 2010. The compendium is published under creative commons SA, BY, NC which means that it can be used for most purposes; however the purposes have to be non-commercial.

The notes are centered on Bernard’s EA Cube and the statement “EA = Business + Strategy+ Technology” and that has been the key organizer for how the notes are presented in the compendium.

You can download the compendium here.

Artifacts: The Items the Enterprise Architect has to Identify.

Posted on by
Reply

Enterprise Architecture Artifact

First of all we need a definition of what an EA artifacts is. Scott A. Bernard defines “an EA artifact as a documentation product, such as a text document, diagram, spreadsheet, briefing slides, or video clip” (Bernard 2004, p. 111).

Please note that the EA artifact documents the EA component. An EA component is in the Enterprise Architecture components are those elements that are owned by Lines of Business. The components can be shared (cross cuts) or the component can be shared a cross various levels (this is with in the EA3 Framework).

Various Forms of Artifacts

There are various forms of artifacts in the EA 3 framework. Combined with the Cube to illustrate what kind of artifacts than can be identified at the five levels of the cube.

The first (and highest level) is the layer titled “Goals and Initiatives” deals with documents and diagrams dealing with mission statement, overall strategy (corporate and IT strategy), purpose of the organization. E.g., SWOT analysis, Porter’s Five Forces analysis, competitive strategy, Concept of Operations.

The second (and second highest level) is the layer titled “Products and Services” deals with the business plans, swim lane diagrams, business cases (for investment in new business and IT projects), use case diagrams and node connectivity diagrams among other stuff.

The third (and third highest level) is the layer titled “Data and Information” deals with identifying the knowledge management plan, the information exchange matrix, objects state – transition diagram, logical data model, data dictionary / object library.

The fourth (and fourth highest level) is the layer titled “Systems and Applications”that deals with identifying systems interface diagram, systems communication diagram, systems interface matrix, system data flow diagram, system or operations matrix, systems data exchange matrix, systems evolution diagram and web application diagram.

The fifth (and fifth highest level) is the layer titled “Network and Infrastructure” deals with identifying artifacts like network connectivity diagram, network inventory, capital equipment inventory, building blueprints, network center diagram, cable plant diagram and the rack elevation diagram.

The EA3 Cube.

The EA3 Cube.

Acquiring the Artifacts

When the Enterprise Architect or for that matter the Coherency Architect have to acquire information on the various layers in the EA3 Cube.

The Enterprise Architect has to go to the CIO or other members of the executive group who the Enterprise Architect assumes have access to the corporate strategy and the IT strategy. However many organizations there aren’t isn’t an IT strategy or for that matter an explicit up to date the corporate strategy. Most of that information that all in all can be combined into a functional strategy.

In such cases the Enterprise Architect has to go an interview the stakeholders. However the Enterprise Architect should expect that he or she hasn’t unlimited resources to investigate and uncover the strategies (level 1). He or she should therefore try to focus on the stakeholders that can give them the greatest amount of value through the uncovering process.

The persons or stakeholders should be set into a matrix where the axis should be aligned around importance and impact on the uncovering process.

Importance - Contribution Matrix.

Importance - Contribution Matrix.

When the various stakeholders have been identified then those actors and stakeholders who are in the upper right quadrant should be interviewed. If it is possible then those persons who are in the lower right quadrant should be engaged as well however only as second or third priority.

When interviewing the executive group the Enterprise Architect should focus on applying techniques that enables the interview victims on expressing what they mean by illustrating the strategy e.g., rich pictures, flow charts, concept of operations diagrams etc.

The interview technique could be applied on the other levels in the EA 3 Cube. Likewise can the various managers and employees be categorized in the matrix and likewise should the Enterprise Architect focus on maximizing the values of his work through interviewing those persons who have contributes the most and who are most important to the data collection.

Conclusion

The Chief Enterprise Architecture should work with identify the proper stakeholders and make use of interview techniques to collect the necessary artifacts they need to create the “AS IS” view of the Enterprise Architecture. All organizations faces the conflict of resource shortage which means that the executives needs to prioritize their actions to create maximum value and that includes the way the Chief Enterprise Architect and the Enterprise Architects should handle.

Download the paper here.

Enterprise Architecture Frameworks: A comparison of EA 3, OIO and Zachman.

Posted on by
Reply

Framework and Methodology

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

The EA3 Cube.

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

Zachman’s Framework

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.

Zachman's Framework (According to Bernard)

Zachman's Framework (According to Bernard)

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.

Strategy Process.

The OIO-Framwork (The Two Main Processes).

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

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

  2. Products and services shows how Information Technology impacts the various products and services.

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

  4. Systems and Applications is used to organize and group the various information systems that give the organization its IS capabilities.

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

The EA3 Cube.

The EA3 Cube.

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.

Conclusion

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.

Sources

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

The Enterprise Architecture Framework

Posted on by
2

The Steps of the EA approach

There are defined 20 steps to establish the EA program according to the EA 3 Cube framework (Bernard 2005). The 20 steps have different importance in the four different phases which needs to be taken into consideration.

The first and thereby primary step is the establishment of the EA program. If the EA program isn’t established the organization will experience difficulties with improving its Enterprise Architecture.

The second phase deals with how the organization should define an methodology and the tools that are compatible with the EA approach (framework). If that is not in order then the EA program will not aggregate a proper view “AS IS” perspective.

The third phase deals with how the execution of the EA documentation program.

The fourth phase deals with how the EA program should be linked to the management and other kinds of management processes so the organization can generate the full advantage of the investment in the program.

Phase 1: Establishment of the EA Program

  1. Establishment of the EA Program and identifying the EA Chief Architect.

  2. Establish of the EA Methodology.

  3. Establish EA Governance and links to other management processes.

  4. Develop an EA communication plan to ensure EA stakeholder buy in.

The EA Program needs a person in charge to apply the right framework and the right tools and the person needs to be hold responsible and accountable. This means that the top management and management of the organization needs to buy in (#4). If they don’t buy in then the EA program will easily be detoured.

The EA program needs to be linked to other management processes so they can be coordinated and when they are coordinated they can become a greater asset for the organization. When the coordination has been established and the coordination has been applied then it might turn into a competitive advantage.

Phase 2: EA Framework and Tool Selection

  1. Select an EA documentation framework.

  2. Identify the EA lines of business (LOB) and cross cuts and the order of the documentation.

  3. Identify the EA components to be documented framework – wide.

  4. Select documentation methods appropriate to the EA framework.

  5. Select the software applications or tools to support the automated Enterprise Architecture documentation.

  6. Select and establish an online EA repository for documentation and analysis.

The documentation framework is frame for how the various elements have to be put into to create a systemic analysis. The analysis have to be focusing on identifying symptoms and finding the cure for the right problems within the organization.

The Enterprise Architecture should be documented so an “AS IS” is produced and used as a blueprint so management and the EA program chief architect can articulate a transition plan that can enable the organization to achieve its goals and thereby create the “TO BE” situation for the enterprise architecture.

Phase 3: Documentation of the Enterprise Architecture

  1. Evaluate existing business and technology documentation for the use in the Enterprise Architecture.

  2. Document the current views (AS IS) of the existing components in all frameworks areas (levels). Organize and store the artifacts in an online repository.

  3. Develop future business / technology operating scenarios.

  4. Identify future planning assumptions for each future scenario.

  5. Use the scenarios and other program / staff input to drive the documentation of future EA components in all EA framework areas. Store artifacts in the online repository.

  6. Develop an EA management plan to sequence the planned changes in the Enterprise Architecture.

The business and technology documentation is needed to create the “AS IS” since the EA consist of Business, strategy and technology and acts as a kind of governance tool for the organization.

The scenarios needs to deal with a positive scenario where everything stays the same and a scenario where things change and a scenario where everything goes down the drain (worst case scenario).

Involve the the staff to assist in making the documentation since many of them probably act as SMEs (Subject Matters Experts).

The EA management program needs to be the blueprint for changes that needs to be implemented in the enterprise architecture. This means that the program will have to be broken down to projects that can change the various components (and other elements of the enterprise architecture).

Phase 4: Use and Maintain the Enterprise Architecture

  1. Use EA – documentation to support planning making.

  2. Regularly updates current and future views of the EA components, and link information in the EA repository to create high – level and detailed perspectives of Enterprise Activities and resources in the current and in the future operating environment.

  3. Maintain EA repository and related EA modeling and analysis capabilities.

  4. Release annual updates to the EA management plan.

When working with the EA framework then it should be used to assist in the planning making (the transition plan) and not to mention that the methodology needs to be in place for the transition plan.

The EA repository needs to be maintained so every stakeholder in the organization can relate to the objects and terminology in the same way.

The EA management plan needs to be updated so it is matches the changes in the domain.

Sources

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

Extending and formalizing the framework for Information Systems Architecture

Posted on by
Reply

The Concept of the Framework

The framework can in some ways be compared to techniques such as the flowchart (that was introduced by John von Neumann back in 1945. The flowchart is fine for many different issues and a flowchart is good to illustrate algorithms and flow of goods and processes.

Entity – relationship diagrams are used to show entities among various objects, processes and databases.

The purpose of the framework is to show how everything fits together and how they interacts. There are 30 boxes that are organized in six columns. The 30 cells or boxes are indeed intended to subject matter which means it is possible for those identify the various artifacts and deal with them in each cell.

Overview of the Framework

The framework has several minor items that can be categorized or organized as:

  1. The Scope which is the first architectural sketch which is known as the bubble chart. In the ISA framework (Enterprise Architecture) it is equal to an executive summary.

  2. Enterprise or business model this is the professional drawing at an architect. In the ISA context then this is equal to the business model to the organization.

  3. System model which is equal to a list of specifications. In the ISA context this is equal to a system model designed. The model presents the information and the models that are linked to another.

  4. Technology model which is equal to a contractor that has to redraw the architect’s plan. The model serves as a way to constrain the technology. The technology model is dealing with the programming language, I/O devices or other technology.

  5. Components which in a architecture perspective deals with the sub-contractor work out a specific plans for the building a building. In an ISA context deals with the programmers or actors are aligned with a broader context so sub-optimization is handled in a proper way.

The Extended ISA Framework

Rules of the framework needs to be taken into consideration and dealt with to understand how the framework works:

  1. The columns have no order. Order would imply priority and since the cells are equally important.

  2. Each column has a basic model. It is important to understand that each model is representing a simplified version of the world. The focus is to ask what, how, where, who, when and why.

  3. The basic model of each column has to be unique. Zachman is of the opinion that the cell is unique.

  4. Each row represents a distinct and unique perspective.

  5. Each cell is unique. This means that the cells should be checked twice while the framework is applied to the current situation.

  6. The cell model are made of the perspective of the row.

  7. They logic is repetitive.

Information Systems and Enterprise Architecture: An insight to Zachman’s Initial Ideas on his Framework.

Posted on by
Reply

Implementation of Information Systems

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”:

Representation Nature or Purpose (architecture) Nature or Purpose (EA)

Bubble charts

Basic concept of building

Basic outline of architecture.

Architect’s drawings.

Final building to be seen by the owner.

“AS IS” or “TO BE” outlined for the decision makers.

Architect’s plans.

Final building to be seen by the designer.

Transformation plan or a more detailed view on “AS IS” and “TO BE”.

Contractor’s plans.

Final building to be seen by the contractor.

This is the IT infrastructure and the various other infrastructures.

Shop plans.

Sub – contractors designs or sub segments.

Various artifacts within the various plans and charts.

Building.

The physical building.

The transformed Enterprise (“TO BE”).