In week 31 I will be attending the summer school dealing with Enterprise Architecture, Enterprise 2.0, Government 2.0 and organizational development. The summer school is a part of the IT University’s approach to developing an elite program dealing Enterprise Architecture and Coherency Management.

The summer school will be taking place in Sweden (about a 12 hour drive from the southern part of Sweden) in a ski resort located near of the Norwegian border. The summer school has been sponsored by companies like Accenture, Qualiware and not to mention Gotze Consulting (a company owned by John Gotze).

Program

I plan to make use of the time up there to write some notes on the topic of Enterprise 2.0, Coherency Management and Government 2.0 and write on a couple of new blog posts for the CoherencyArchitect.com . I plan also to be working with a presentation of some of the findings that have been working with in one of the literature reviews I have made during the summer holiday. The literature review will be published in its full length when I have had the time to improve it and made it ready for publishing.

Blogs

I plan to make vlogs (Video Blogs) up from the summer camp; however these will not be published while I am attending the summer camp (due to the cost of data roaming within the European Union).

]]> http://coherencyarchitect.com/2010/07/29/enterprise-architecture-summer-camp-preparing-for-week-31/feed/ 0 coherencyarchitect http://coherencyarchitect.com/2010/07/12/the-breakout-strategy-a-review-by-a-coherency-architect/ http://coherencyarchitect.com/2010/07/12/the-breakout-strategy-a-review-by-a-coherency-architect/#comments Mon, 12 Jul 2010 08:00:30 +0000 CoherencyArchitect http://coherencyarchitect.com/?p=354 ]]> What is a Breakout Strategy

First of all lets establish the necessary assumptions needed to understand the concept of what a strategy is. A strategy is a tool for how an enterprise (business, public institution, government institution or other form of organization) uses a strategy to realize the goals that the executive team of the enterprise has articulated.

There various ways of seeing how the enterprise and its strategy should be handled and how they interact. Mintzberg (Minztberg et al 2009) has identified 10 different schools of planning.

The Breakout Strategy can be identified as belonging to the school that is defined by Mintzberg as the entrepreneur school. This is based on that the Finkelstein et al. (Finkelstein et al. 2007) works with the assumption that the local leaders in the enterprise have to act as entrepreneurs that identifies, develop and enforce an updated business model.

As such Finkelstein et al. emphasizes that they have applied their theories on cases that have both prevailed and failed. As such the authors applies their theories to explain what happened and what didn’t happen.

One of the core messages of the book is that the enterprise, its decision makers and the acting employees needs to think as the customers.

Systemic Thinking

The concept of systemic thinking is represented by the business model and through the ideas on implementation that Finkelstein et al. (Finkelstein et al. 2007) focuses on that the leader (or leaders) needs to take charge and enable change through their actions (embodiment). Thereto is notable that the business model is build upon six different aspects of the value the enterprise as a whole deliver to its customers. As such the six aspects enforces the enterprise to view on what part it has to build up and what part it can limit in its struggle to achieve better results.

The Business Model

According to Finkelstein et al then the business model is build around six different elements that in total defines the feelings of the value and the value the enterprise adds (value added).

The six components are price, features, quality, support, availability and reputation. Within each of these six components are there five options within each of the components e.g., for the price component premium, Premium competitive, Competitive, Competitive / Leader and last the Leader.

Finkelstein et al. (Finkelstein 2007, p.184) identifies (correctly) that the vision of the future has an impact on how the enterprise’s business model should be like and the executives should as such consider the six components when they are articulating the corporate strategy.

Leadership

As such the theories presented in the breakout strategy are focused on that the leadership of the enterprise (top management or what is defined as the executive group) has to show that their intentions are and they have to win over the employees. Finkelstein et al. talks about British Airways as a case where the CEO failed to win over the employees and as such he (and the executive team) faced challenges. As the breakout strategy deals with winning over opposing fractions.

Communication

Finkelstein et al emphasizes that communication of the values, goals and vision for where the business model should develop to have to be communicated to the members of the enterprise. As such the breakout strategy embraces the holistic management approach which is also present in the theories concerning Enterprise Architecture.

Four Forms of Breakout Strategy

Finkelstein et al (Finkelstein et al 2009, p- 20) defines four different forms for the breakout strategy to be applied and the breakout strategy have four different conditions. The breakout strategy can be used in a market that is narrow and its beginning (and as such subordinate) to the established market and their industries. Typically the two forms of conditions (taking by storm, expanding horizon) are to be found in the narrow market. In the broad market then the laggard to leader and shifting shape form is to be found.

Forms of Breakout Strategies

Thereto does Finkelstein et al defines four forms of breakout companies and as such also four forms of breakout strategies. The four different break out forms are organized on emergent markets and established markets. The emergent markets are characterized by that the enterprise that is within them is able to work with a new form of technology, service or market space that is adaptable to the product or service the enterprise sells. The established markets are characterized by that they are mature markets such as there are enterprises that competes on gaining market share. Typically will the industry go into a spiral where the products are seen as commodities and as such commodities are sold primarily based on the price of the product.

Growth Opportunities

For the particular markets the forms of breakouts are characterized as the true originals, revolutionaries, the wave raiders and the big improvements.

The originals usually shapes and develop a new market e.g., by inventing new superior services e.g., they go from a red ocean to a blue ocean. In the same time the revolutionaries in an established market re-invent their enterprise in a way that makes the enterprise able to compete by differentiating the products or services.

The wave riders work with the assumption that they find market space and the market space over time will expand. The big improvers include enterprises that is able to define a business model and value proposition. Likewise is it able to refashion its business model.

Discussion

An Enterprise Architect and a Coherency Architect can make use of the breakout strategy since it has the approach to systemic thinking. As such it is notable that the approach can be used to either aide the enterprise architect or the coherency architect with explaining how enterprise architecture and integrated governance can aide the enterprise with optimizing its business model and avoid failure in the effort to change. In the same time does Finkelstein et al (Fineklstein et al. 2007) handle the issues of the current state (in Enterprise Architecture known as the to be state) and how the enterprise evolves into a new and better enterprise that is able to achieve the goals of the particular enterprise.

The Coherency Architect should be aware of that the business model defines several issues of how the enterprise should adapt to the market and how it operates. The operation model can in some aspect be defined as the operation model or at least there is an overlap. The operation model is discussed by Ross & Weill (Ross & Weill 2004, 2009 & Ross et al 2006) and as such it serves as a map or conceptual idea on how the enterprise operates.

Bernard (Bernard 2005) defines integrated governance as being a part of strategic planning, Enterprise Architecture, workforce planning, capital planning and security,. As such the Coherency Architect can make use of the breakout strategy to articulate a vision for how the AS – IS state of the enterprise architecture should be dealt with and how the transition from the AS – IS state to the TO – BE state can be done.

As such the Enterprise Architect and the Coherency Architect should be aware of that the enterprise shouldn’t move from the AS IS situation through a so called big bang change where everything is changed in the same time. The reason for this is that when big bang change occur then it often fails. Therefore big bang change should be considered a risk and as such the enterprise architect and the coherency architect should avoid using the approach. Instead should the focus be on how the enterprise should move gradually to achieve its approach and by such the program for change should accept this focus.

Competitive Advantage

When it comes to competitive advantage then the breakout strategy emphasizes that not a single process or single element of the business model can lead to a competitive advantage and as such that is in line with the what Porter (Porter 1998) emphasizes. Likewise is it worth to mention that the enterprise can’t achieve the competitive advantage just by focusing on operational efficiency solely in the manner than the processes should be done more efficiently and neglect innovation. The innovation processes can essentially aide an enterprise with succeeding in a market.

When speak of competitive advantage then it is a necessity to understand that a competitive advantage can only be enabled through several processes (activities within the enterprise) and the competitive advantage has to be sustainable before the enterprise will be able to achieve success.

Conclusion

The Enterprise Architect and the Coherency Architect can make use of the Breakout Strategy to make use of to communicate to the executives on how to alter the way the enterprises does business. In this way the enterprise can make use of elements of enterprise architecture e.g., the transition plan so the structure of the enterprise moves from being as it is to something in the future.

The focus of the breakout strategy can be used as a driver for applying Enterprise Architecture as a method to enlighten, develop and mature the Enterprise Architect.

Appendix

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

Porter, M.E., On Competition, Harvard Business Review, Boston, 1998, p.40-42.

Ross, J.W., Weill, P. & Robertson, D.C., 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution illustrated edition., Harvard Business School Press.

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.  Porter, M.E., On Competition, Harvard Business Review, Boston, 1998, p.40-42.

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)

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

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

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

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.

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.

When an organization choses to pursuit the implementation of Coherency Management then it the organization have to focus on organizational change. The idea of the organizational change is when the managers, middle managers and the employees will have to work in a different way and humans and organization culture have a tendency to be conservative and react hostile against change.

For this the Coherency Architect should focus on how create the proper form of change within the organization.

A Quick Summary of Coherency Management

Coherency Management deals with how to achieve alignment, agility and assurance through maturing the enterprise’s Enterprise Architecture. According to Doucet et al (2009) then there are three stages for an Enterprise Architecture. The first one is the form that is called the Foundation Architecture which is typically led by the IT department and sponsored through the CIO. The second stage is the so called extended enterprise architecture where both the business side and the IT-organization have adopted and applied Enterprise Architecture to expose the current situation (AS IS architecture) and is used to manage the enterprise’s strategic, business and technology elements.

The third and last stage is called the Embedded Architecture. This particular form of architecture is defined by the most employees in some way or the other work with the Enterprise Architecture. However there are two forms of Enterprise Architects. The first form is the explicit of architect of which there can be defined to dominant forms. The mature and advanced form of Enterprise Architects that are working with an established architecture office that handles the various forms of strategies to create a so called coherent overview. The other form of explicit architect are working with various sub architectures such as the business architecture, technology architecture or the solution architecture.

It is worth to mention that these three stages of architectures are supported by Herzum in his 2003 paper on the topic.

The Framework

When dealing with organizational change then the Coherency Architect needs to work with developing and internal pressure for enabling change. The question can be if the organization is loosely coupled or not. In this particular framework the assumption is that the organization (enterprise) isn’t loosely coupled.

When the organization (enterprise) isn’t a public given monopoly such as the Danish postal services then it will face competition. The competition deals with that the competitors will work for gaining market share this is done through various strategies and those enterprises that sees that they can’t make money in a particular market focuses on differentiating their products or services.

The various moments the competing enterprises makes are in a way a path to more innovation (since it emphasis the development of new products or differentiating the products e.g., make products of a better quality), and this can be defined as a part of the external pressure. It is worth mentionable that not only does the competitors add to the external pressure e.g., the government, press or other external entity. The external pressure can be an enabler for an internal pressure of which is needed to create the urge for change. Change or initiatives for change can be limited through the persistence of organizational culture (as before mentioned organizational culture tends to be rather conservative) and urge is a feeling among the actors within the organization to approve the change initiatives.

It is a preferable situation for the enterprise and the Coherency Architect would be if there can be created a synergy between the external pressure and the internal pressure. This particular synergy would be the burning platform.

When the external pressure e.g., competition, law (regulation) or other element changes in the enterprise’s domino then the Coherency Architect should work with influencing the various groups within the organization that holds some form of power. For this the Coherency Architect needs to produce valid arguments for the need for change and arguments on what to do. For this an elevator pitch can be necessary. According to Bernard (Bernard 2005) then the concept of Enterprise Architecture embraces strategy, business and technology so all of them can be aligned.

The elevator pitch could therefore be something like this “Enterprise Architecture assists in creating a coherent overview of business, strategy and technology”. The elevator pitch has to be supported through an economic and strategical estimation of the benefits that Enterprise Architecture and Coherency Management can add to the enterprise.

When done so then the Coherency Architect should establish an Enterprise Architecture group where he or another person should be appointed the Chief Architect and this person should be granted the resources, responsibilities and power needed to implement an Enterprise Architecture program. Before Coherency Management can be implemented then the organization needs to implement an Enterprise Architecture program and through the principles of Coherency Management evolve the Enterprise Architecture to more than just the “Foundation Architecture”. When establishing the Enterprise Architecture program a suitable Enterprise Architecture framework should be applied e.g., Bernard’s EA 3 Cube framework. The framework should as a documentation form and as a management form ensure that the enterprise’s current projects are investigated and if possible aligned with the strategy, business and technology goals for the Enterprise.

While the Enterprise Architecture program is established then the Coherency Architect should communicate with the sponsors

When the alignment has been established then the Coherency Management framework CoMOF framework should be adapted to the needs of the organization e.g., should issues like repositories be dealt with which leads to the example of the Modular (modular repositories) Coherency Management Framework (needless to say that the framework is based on Doucet et al. basic suggestions for a framework). When the maturing process for the Enterprise Architecture has been matured then it is important for the Coherency Management to verify and moderate the feedback channels that is the foundation of the renewing the Coherency Management and Enterprise Architecture programs and eventually the need for changes have to be implemented along side a new burning platform.

Key Issues

An Enterprise Architecture program should be enterprise – wide and therefore the Coherency Architect will have to deal with resistance to change and for that communication is vital for all the necessary stakeholders. Therefore a communication plan is needed and it has to focus on three particular issues. 1) The stakeholders don’t think like the Coherency Architect. 2) The various stakeholders needs different kinds of information. 3) The need for urgency needs to be enabled through communication and therefore should the Coherency Architect communicate the victories and the victories needs to be sequenced over the period of time one iteration takes and the communication needs to be done in a way that appeal to the feelings of the stakeholders.

Conclusion

When an Enterprise Architecture program and a Coherency Management program is about to be established then it is vital for the success of the program, that the Coherency Architect deals with the issues of pressure to establish a burning platform and then anchor an EA office or for that matter a coherency management office to the power bases in the organization. When done so communication about victories has to be prioritized and sequenced to so the stakeholders continue with their support for both the Enterprise Architecture and Coherency Management program. Since Coherency Management is based on the foundation of Enterprise Architecture then it is a necessity that the EA program is anchored first and for that the proper approach is to apply an EA framework e.g., Bernard’s Enterprise Architecture 3 Cube Framework and use the EA program to align the business and IT projects of the organization to support new or improved business processes (TO BE architecture) that are dictated by the corporate strategy.

When the EA program has been established then the usage of a Coherency Management framework needs to be implemented and the framework needs to be modified to the needs of the particular enterprise e.g., by adding multiple repositories.

When both the EA program and Coherency Management program has been established then it is vital that the Coherency Architect ensures improvement and that can be done by established and routinized channels for verification and feedback.

The need for adaption to the domain of the organization will lead to a continued demand for the establishment of a burning platform.

Sources

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

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

Herzum, P., 2003. Applying Enterprise Architecture. Cutter Consortium Executive Report, 6(3), 36.

Kotter, J.P., 2008. A Sense of Urgency, Harvard Business School Press.

Download the paper here.

]]> http://coherencyarchitect.com/2010/06/06/the-foundation-for-coherency-management-a-framework-for-change/feed/ 0 coherencyarchitect modified_applied_comof http://coherencyarchitect.com/2010/05/27/artifacts-the-items-the-enterprise-architect-has-to-identify/ http://coherencyarchitect.com/2010/05/27/artifacts-the-items-the-enterprise-architect-has-to-identify/#comments Wed, 26 May 2010 22:35:13 +0000 CoherencyArchitect http://coherencyarchitect.com/?p=314 ]]> 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.

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.

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.

The Path to Improvement

The focus is to combine lean, Toyota Production System, Enterprise Architect and Coherency Management into a guide line like the Bushido: The ways of the warrior.

The main principle of Coherency Management is to implement a holistic management approach that enables the management to achieve alignment, assurance and agility.

Enterprise Architecture is the foundation of achieving Coherency Management and it is possible to combine that with efficiency to achieve an enterprise that have a lesser amount of slack and adds more value to its share holders and customers.

First of all an Enterprise Architecture program has to be established.

Second of all an economic analysis of the activities that the organization performs to get income.

Third of all communication of change needs to be performed. That means that the Chief Enterprise Architecture needs to communicate to various stakeholders. The various forms of stakeholders needs to be dealt with in different ways. The various stakeholders needs different kind of information.

Third of all the Enterprise Architect has to work with various applying a framework e.g., the EA3 Framework, TOGAF, OIO or other framework.

Forth of all the Chief Architect needs to demonstrate the value of the Enterprise Architecture. The Enterprise Architect should apply the evaluation models that give the information that the stakeholders needs to make their mind (approve or disapprove) the Enterprise Architecture program. It is necessary to apply the evaluation model for the business processes and IT processes before the EA program has been established. This is needed to compare the before and after approach.

Fifth of all the Enterprise Architect has to make use of his or her talent to deal with the persons who have to change their way of working after the Enterprise Architecture program has been established. According to Doucet et al. (Doucet et al 2009) then the organization then there are three forms of applied Enterprise Architecture. The first form is known as Foundation Architecture. The Foundation Architecture is when the organization has applied Enterprise Architecture in the IT department. The IT department has been the driver of the Enterprise Architecture and made use of it to uncover the the operational model of the Enterprise Architecture. When the organization mature the Enterprise Architecture then it should over time come to the Extended Enterprise Architecture where both the business side of the enterprise and the IT side. The IT side and the business side works uncovering the business and its processes. There are several forms of architects who have various functions and responsibilities. There will be a centralized office for Enterprise Architecture and there will be a commitment from the Executive Group¹ to enhance and use Enterprise Architecture to govern the enterprise. There are business architects, process architects, technology architects information architects and the Enterprise Architects. The Enterprise Architects will be dealing with handling the overall aspects of Enterprise Architecture. The Enterprise Architects will be dealing with keeping the other architects in line with the Enterprise Architecture program.

After the Extended Enterprise Architecture level then the organization will be moving toward the Embedded Enterprise Architecture. The form of architecture is so far a kind of utopia where every employee in some way acts as an architect which leads to that there are explicit and implicit architects. Theres is a focus on a central EA department that consist of the best Enterprise Architects who works with the overall Enterprise Architecture framework and enabling the other architects with their work through empowering the framework and governance of the Enterprise Architecture.

Sixth of all the Chief Architect has to implement a Coherency Management framework so far there is only one kind of a kind. That means the CoMOF framework has to be adapted. As it is with all other frameworks then the CoMOF framework is a generic framework and it has to be modified for the particular organization. While applying the modified CoMOF framework in the organization then Coherency Architect (or Chief Architect) has to make use of the efficiency theories such as LEAN, Six Sigma or Toyota Production System. This is a necessity to improve the organization’s enterprise.

Seventh of all the Coherency Architect has to ensure that executive group continues supporting the Enterprise Architecture program and Coherency Management program. This have to be done through emphasizing the support for Enterprise Architecture by using external pressure to enable the internal pressure(groups with power) to invest resources into renewing the program. If the Enterprise Architecture program isn’t renewed then the value of the Enterprise Architecture program will lose value. The same is the case for the Coherency Management program.

Eight of all the Chief Enterprise Architect should be working for improving the channels of how the Enterprise Architecture is transforming.

The Code

The Coherency Architect should be therefore be working with being efficient, effective and use his or her experience to develop develop efficient enterprises through Enterprise Architecture.

1. Focus has to be on efficiency and effectiveness. The ideal is that the Coherency Architect should be thinking in systems where to much slack is minimized; however enough slack to harvest the benefits of innovation.

2. The vision of Enterprise Architecture has to be communicated to the stakeholders . The people skills and abilities to communicate fluently with people are virtues.

3. Improving the Enterprises and their Enterprise Architectures then the Coherency Architect have to focus on influencing the organization cultures to institutionalize improvement through Enterprise Architecture.

Applying the Code

The Bushido Framework.

The code can be applied through the model dealt with above . The path to improvement is designed around the stones n the circle. The circle represents continuity. Bernard’s EA 3 framework is located in the bottom is matured a long side the principles of the CoMOF-framework. The lines with arrows are symbolizing the maturing process and a part of the continues process.

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

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.

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.

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.

]]> http://coherencyarchitect.com/2010/05/07/enterprise-architecture-frameworks-a-comparison-of-ea-3-oio-and-zachman/feed/ 0 coherencyarchitect The EA3 Cube Zachman's Framework (According to Bernard) Strategy Process. The EA3 Cube http://coherencyarchitect.com/2010/05/06/the-enterprise-architecture-framework/ http://coherencyarchitect.com/2010/05/06/the-enterprise-architecture-framework/#comments Thu, 06 May 2010 08:00:56 +0000 CoherencyArchitect http://coherencyarchitect.com/?p=296 ]]>

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

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.

]]> http://coherencyarchitect.com/2010/05/04/extending-and-formalizing-the-framework-for-information-systems-architecture/feed/ 0 coherencyarchitect