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

1 07 2010

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.


Comments : Leave a Comment »
Tags: , , , , , , , , ,
Categories : ATOM Frameowrk, Enterprise Architecture, Frameworks

A Compendium for Understanding Enterprise Architecture.

11 06 2010

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.


Comments : Leave a Comment »
Tags: , , , , ,
Categories : Compendium, Enterprise Architecture, Methods

Artifacts: The Items the Enterprise Architect has to Identify.

27 05 2010

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.


Comments : Leave a Comment »
Tags: , , , , , , , ,
Categories : Corporate Strategy, Enterprise Architecture, IT Governance

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

7 05 2010

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.


Comments : Leave a Comment »
Tags: , , , ,
Categories : Enterprise Architecture, Frameworks, Methods, Opinion, Up in Time

The Enterprise Architecture Framework

6 05 2010

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. 


Comments : 2 Comments »
Tags: , , , , , , , ,
Categories : Enterprise Architecture, Methods

Extending and formalizing the framework for Information Systems Architecture

4 05 2010

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.


Comments : Leave a Comment »
Tags: , , , , , ,
Categories : Enterprise Architecture, IT Alignment, IT Governance

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

27 04 2010

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

Comments : Leave a Comment »
Tags: , , , , ,
Categories : Enterprise Architecture, Frameworks

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

19 04 2010

Organizational Change

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

The Change of Focus

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

Replacing the CIO

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

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

The Extended Architecture

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

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

Forms of Architectures

Forms of Architectures.

Conclusion

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

Sources

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

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

Download the blog post here.


Comments : Leave a Comment »
Tags: , , , , ,
Categories : Architecture Maturity, Business Architecture, Enterprise Architecture, IT Alignment, IT Governance, IT Strategy, Organization, Strategic Management

The EA Management Program: From the perspective of a Coherency Architect.

23 03 2010

Why a Program and not a Project

Enterprise Architecture is dealing with configuring many different components of an organization (Bernard) and these components can rarely be configured properly through a big bang change as a project would usually be. A program can be defined as a series of projects that will change different components in a evolutionary approach.

Since Enterprise Architecture and Coherency Management is dealing with more than people then it the changes can’t be implemented with a big bang approach since it will either fail by the people will go back to the old way of doing things or they will be overworked in changes (of which John P. Kotter has written the book titled “Creating the Sense of Urgency”).

Therefore should the Coherency Architect work with establishing a so called Enterprise Architecture Program (EA Program) or more advanced a Coherency Architecture Program. The difference between the two types of programs are that organizations that works with the Coherency Architecture program can be identified as having an Enterprise Architecture titled as “Extended Architecture” and above.

The Enterprise Architecture

First of all the Coherency Architect needs to identify the AS – IS Enterprise Architecture to understand the enterprise architecture as it current is. When the Enterprise Architecture has been investigated and a significant overview has been created then the Coherency Architect should develop a transition plan. The transition plan that is known as the Enterprise Architecture Management Plan. The plan is foremost a documentation method.

The Enterprise Architecture Management Plan

The plan is the transition between from the ”AS IS” (the current state) to AS IS (the future state). This means that the organization needs to launch a series of projects that enables clarifies the business processes (business architecture, the information systems and data needs (the information architecture) and how the various technical platforms operates and interacts (technical architecture).

If the organization chooses to apply Bernard’s EA3 Cube as the preferable EA approach to document the “AS IS” state for the Enterprise Architecture then the Enterprise Architects have to investigate the five levels from a top down approach. The first level is the goals and initiatives, the second layer is products and services, the third layer deals with data and information, the fourth layer deals with systems and application and the fifth layer deals with network and infrastructure.

The EA3 Cube.

The EA3 Cube.

The documentation process is often costly and it takes time; however by investigating the Enterprise Architecture then the architects can aide the top management of the organization by identifying gaps and potentially inefficient processes and systems that needs to be replaced or upgraded. When the gaps have been identified and the top management has given its permission to initiate the the transformation then the EA program can be established.

The program can be defined as a set of projects that all have that in common that they deal with components of the Enterprise Architecture. For that it is necessary to understand how the EA related projects are to be defined.

The EA Related Projects

The projects are usually strategic and the outcome of the projects impacts either the business architecture, the information architecture, the application architecture and the technological architecture or all of them.

An example of such a project is the implementation of a new ERP software application or implementation of a new project management flow system.

The two mentioned projects have an impact on their respective architectures; however if they are implemented the proper way where the business processes are re-defined then they will impact all the architectures (for that principles needs to be articulated).

These projects needs to be evaluated to identify how they contribute to the transformation of the Enterprise Architecture. In this process it is notable that the projects shouldn’t entirely be evaluated on economic costs and benefits (TCO and ROI) but also on how the projects enable the organization to accomplish its visions.

Conclusion

The EA management plan needs to be taken into consideration when organization begins to achieve success so management is able to react to potential gaps there might be in the organization. In the same time there will be a need for the Enterprise Architecture Management Plan to obtain knowledge of ways to innovate the organization and enhance its ability to develop new products and services if not to mention compete for market share or resources.

Sources

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

Download this paper here.


Comments : Leave a Comment »
Tags: , , , , , ,
Categories : Enterprise Architecture

Business Models: From a Coherency Architect’s Point of View.

10 02 2010

Concept for a Business Model

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

Business Models in a context

Context of the Business Model

The Business Model in Context

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

Elements of a Business Model

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

Sources

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

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


Comments : Leave a Comment »
Tags: , , , ,
Categories : Alignment, Business, Enterprise Architecture, IT Alignment, Organization

« Previous Entries