The paper defines integrated governance, and introduces a framework that most enterprises will be able to make use of to implement integrated governance. It is obvious that more forms of governance can be incorporated into the framework; however since it has been an academic study, I had to delimitate what forms of governance I had to deal with (otherwise it could be a rather long paper on various forms of governance that would be more or less relevant to include).

It is notable that the enterprise needs to adapt the framework for its specific context; otherwise it is very likely that the enterprise will not be able to gain any of the benefits that integrated governance as a concept can provide the enterprise with.

One of the most important aspects of the framework is the quality assurance feedback channels that needs to be established, since this is the only official approach to collecting the data needed to understand how the changes influences the enterprise.

The findings of the paper and the paper itself is published under Creative Commons version 3 SA BY U.S. Edition. This means that you are able to make use of the paper in a commercial context and you are welcome to make derivatives as long you stay loyal to the license and you credit me (Peter Flemming Teunissen Sjoelin) as the author of the original paper.

Download the paper here

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

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

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

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

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

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

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

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

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

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

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

Win Over The Opposition

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

1. Individuals.

2. Subunits.

3. Organizations.

4. Hierarchies.

5. Organizations and Environments.

6. Activities.

7. Ideas.

8. Intentions.

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

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

The Burning Platform?

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

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

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

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

Enterprise Architecture and Organizational Transformation

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

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

Projects Don’t Transform the Enterprise

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

Sources

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

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

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

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

I have been able to identify two major approaches to articulate IT strategies.

The first major approach is the typical MIT Sloan School of Management approach that support the issues of a some how detached IT strategy from the corporate strategy. The strategy is build upon the assumption that IT is complex, and needed to compete with other organizations on particular issues. IT is a vital component and can’t be ignored in the ever changing competitive environment that most enterprises are in.

The notable theoreticians within the paradigm of the MIT Sloan School of Management are Erik Brynjofsson, Jeanne Ross and Peter Weill.

I title this approach the separated IT approach.

I have likewise been able to identify an opposing approach. The opposing approach deals with that IT is that dominant that the executives have to include IT in their corporate strategy. IT can’t be seen as a unique form of investment since IT is equal to many other forms of technology e.g., machines, cars, boats etc.

There are so far rather few theoreticians who commit openly to this approach to IT strategy, the most notable is properly Chris Potts and Scott Bernard (who indirectly support this approach through his views on Enterprise Architecture).

The later approach seems promising since it promotes that the various actors within the enterprise should work along side in a coherent fashion which is in the spirit of Enterprise Architecture.

The two approaches do share some common features e.g., the time frame, the focus on technology and principles needs to be addressed and that IT is a necessity to compete in the modern economy.

IT-strategy paradigms.

The Integrated Strategy Approach

The executives have to understand IT when they work with strategy and they have to understand the impact of applying Information Technology to e.g., Information Systems such as ERP systems, CRM systems or similar. McKeen & Smith (2004) that Information Technology is in nearly all aspects of an enterprise today. That means that the enterprise and the management of the enterprise needs to adjust to the new situation. McKeen & Smith argues that the IT department needs to be proactive to cope with the changes in the industry and the social conditions of the enterprise.

The IT managers don’t necessarily understand the future work with the business and it might lead that they develop assumptions that are out of touch with reality. Neither can we expect that IT persons (or for that matter other persons) knows everything or equally good at anything.

What is important in tis particular approach Potts argues that the need for governing the enterprise as a coherent entity and therefore should the enterprise avoid the detached IT department.

Chris Potts works with the assumption that any kind of modern and Western economies have to include IT in some way. Therefore should the executives (or other strategists) include IT in the articulation process of the corporate strategy. Potts argue that the IT department shouldn’t be separating from “the business” will lead to that the IT department, and the services the IT department provides the business will be seen as an external entity and therefore can’t the IT department have any influence on the corporate strategy.

This leads to the separated strategy approach that have some opposing views on how the enterprise should be dealing with IT in the strategy planning session.

The Separated Strategy Approach

The operating model is what the enterprise should be working with. This particular model maps how the enterprise works. Ross & Weill”s approach is that there are four different generic approaches that the enterprise can make use of (Ross & Weill 2009).

The operating models are then deal with through the needs of the business; but the assumption that Ross & Weill works with is that IT is complex and that executives from the business don’t understand how IT works.

Along side McKeen & Smith they claim that IT needs to become a proactive force but yet IT is that complex that it needs to be governed and dealt with by specialists or generalists who have an understanding of how IT works and how the various implementation approaches of IT works.

What The Approaches Share

Both approaches share features from one another e.g., the both approaches defines IT as a complex form of investments that needs to be governed. Likewise does both approaches suggests that the articulation of the strategy isn’t enough. The strategy needs to be embodied in the actions of the executives.

Both approaches suggests that IT is a corner stone in how the enterprises do business now a days. Both approaches argues that “the business” and the IT department needs to understand one another to make the necessary decisions to create synergy and through that make the business perform as it had more resources at hand.

Coherency Management

In a context of Coherency Management IT plays a decisive role in the foundation architecture, and the ideas presented in Ross & Weill (2006 & 2009) and FruITion both appeal to the usage of Enterprise Architecture to combine business and IT to create competitive advantages. The foundation architecture is characterized by the CIO and the IT department is the driver for enabling an Enterprise Architecture program. It is essential for any enterprise that pursues assurance, alignment and agility to establish an understanding of how the enterprise works and then apply the tools to elevate the Enterprise Architecture program to embrace more than just the IT department.

In conclusion an IT strategy should be tightly coupled to the corporate strategy to make any kind of benefit from working and governing IT.

Appendix

McKeen, J.D. & Smith, H.A., 2003. Making IT Happen: Critical Issues in Managing Information Technology, John Wiley & Sons.

Potts, C., 2008. fruITion: Creating the Ultimate Corporate Strategy for Information Technology illustrated edition., Technics Publications, LLC.

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.

Download the paper here .

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 http://coherencyarchitect.com/2010/04/19/implementing-enterprise-architecture-from-a-coherency-architects-point-of-view/ http://coherencyarchitect.com/2010/04/19/implementing-enterprise-architecture-from-a-coherency-architects-point-of-view/#comments Mon, 19 Apr 2010 08:00:20 +0000 CoherencyArchitect http://coherencyarchitect.com/?p=275 Continue reading →]]>

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.

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.

Perspectives and the Extended Enterprise

When the Coherency Architect has to convince his or her opponents on how Enterprise Architecture and Coherency Management can improve the organization’s strategic capabilities then it might turn out to be useful to use economic estimations and KPIs; however it can be useful to make use of perspectives. Jaap Schekerman presents four perspectives on how Enterprise Architecture can generate value for the organization. Each perspective brings prospects and consequences.

Never the less can the economic views be challenged and aren’t there other economic perspectives of EA than those that Jaap Schekkerman has identified and dealt with in his Book “The Economic Benefits of Enterprise Architecture”.

Business Efficiency

Deals with improving the business processes by adding technology (especially ICT and information systems). This means that the Coherency Architect has to focus on obliterating business processes and add Information Technology. Usually this leads to a desire for world class processes.

This approach isn’t focusing on cost reductions that means it is comparably more expensive that the technology efficiency perspective; however it brings more benefits. In this focus Enterprise Architecture is used to identify how IT and technology can enable the current processes (AS IS) and how future processes be designed (TO BE).

Business Innovation

This perspective deals with using Enterprise Architecture to identify areas of which the organization can create new products, services or possibilities for creating game changing products and services and that can give the organization a competitive advantage. This perspective is focusing on the future competitive advantage that the organization can crystalize a competitive advantage.

Technology Efficiency

Technology Efficiency is based on the on the ideas that the cost (TCO) of using technology. It rarely leads to benefits for the organization since their focus often is on how to save money (sink the costs) of using technology and the costs of its business process. This perspective is ‘cheapest’ perspective but it also contains the fewest future benefits for the organization. This approach is currently the most used perspective.

Technology Enabling

Technology enabling is a perspective that focusses on adding new technology to the business and the business processes. This should in the long run lower the costs the organization occurs by using technology. The main question in this perspective is how ICT can enable the business processes and make value out of the technology by using Enterprise Architecture as a tool for alignment of the corporate goals with information and communication technology. However this perspective is known for being costly and it brings few benefits.

The Enterprise Architecture Value Model.

Conclusion

The four perspectives are useful to identify how an organization views its strategy, economy and not to mention how Enterprise Architecture can generate benefits for the organization. However the four perspectives can only be considered generic and they don’t make much room for customization for the organization to mix between the four different ways to handle it. It is notable that if the organization is a division organization then it is likely that the focus on technology and enterprise architecture might be different and shouldn’t therefore be put into one and the same “perspective”.

Last of all. It is important that the four perspectives are combined with the organization’s strategic management.

The Basics of Coherency Management

Enterprise Architecture is a discipline is about 30 years old. Based on a paper by John Zachman who worked at IBM at the time. Enterprise Architecture is evolving over time and currently it is improving the coherence of enterprises to bridge gaps in organizations and enterprises. Coherency Management is for using Enterprise Architecture to advance the alignment, agility and assurance. It might lead to that IT will help the enterprise in doing its business. To explicitly manage coherency which is a new perspective within this discipline. Coherency Management as a concept is not about if the company is a success or not but a way to investigate the enterprise to find factors that enables the organization is coherent with its goal and processes.

The explicit architecture will assist the management on future development of the organization, its processes and its way to function as an organism.

People is the key in relation to rapid change (and a barrier). This perspective is supported by the view that Chris Potts introduces in his “fruITion strategy”.

“Enterprise Architecture is about people” – Chris Potts, IT University of Copenhagen 2010.

Enterprise Architecture is often a Chief Information Office lead project. The main purpose of the Enterprise Architecture is building good IT systems and the Enterprise Architecture project is disconnected from the rest of the organization. Every organization has an architecture. The purpose of the Enterprise Architecture is to make the architecture better.

“Ross and Weill (2005) fell into a trap with their definition of Enterprise Architecture since it is way to technology orientated. It should be on how to improve the way the organization does its business.” – Gary Doucet, IT University of Copenhagen 2009¹.

In general there are four forms of architectures. The first is formalized architecture and the second the un-formalized architecture. There are however three modes of Enterprise Architecture where the more advanced form is called foundation (the extended mode of Enterprise Architecture) where the architects is focusing on understanding the business. The most advanced form is called embedded Enterprise Architecture where you find the process owner and make them modifying the processes.

An example of harvesting artifacts is the government of Canada where the chief of treasure wanted to know about the services they provided for the aboriginal community (first nations) and he therefore asked the best analysts in his administration to find the information; however it took about six months before they finished the process to understand what happened.

Enterprise Architecture is the inherent (existing as permanent and separate) design and management (management and control) approach (you need an approach that works for your organization) essential for organizational coherence leading to alignment (aligning the components of the organization with one another), agility (the ability to change quickly) and assurance (to check up that the products and services and administration is done correctly and accordingly to the corporate strategy).

People always focus on projects but the steady state should be the focus. The Enterprise Architecture is a continuous improvement model. If the organization gets a coherent view then the management and the employees eventually do better decisions. Coherency Management is a new concept but it incorporates existing elements, applications and objectives of Enterprise Architecture but in particular new aspects in particular:

• Incorporating other process owners.

• Managing coherency explicitly.

• Enterprise Architecture as a continuous improvement agent, not simple “AS IS”, “TO BE” and the way to get there.

• The coherency planning office should be in charge of the coherency project(s).

It is not a new name for Enterprise Architecture. It should be considered a practice within Enterprise Architecture. It is not a project. It is not a demotion for chief architects. It is not an attempt to control all management functions. It is not a quick fix. It is not something that only pays back in 15 to 20 years.

The next thing which has to be implemented in Coherency Management is a measuring model and the involvement with consultancy community.

Enterprise Architecture and Strategic Innovation

This blog post will deal with the view on Enterprise Architecture and Innovation that Chris Potts presented in his keynote at the the ITU the 24^th of February 2010.

First of all did Chris Potts presents his strategic framework called the “fruITion” strategy that he builds on the tendency:

1. The first generation strategy was focused on technology (this was the early beginning) which took place in the 70s, 80s and early 90s.

2. The second generation strategy the managers changed the scope from the technology to IT efficiency since they wanted to control the cost of strategy. This happened in the mid-90s and the end – 90s. The organizations outsourced expensive technology and operations to companies that where better keep the cost down.

3. The third generation is characterized by the managers are focusing on how to create value by using technology and incorporate the IT strategy into their corporate strategy.

4. The fourth generation is dealing with investing in change and not focusing on technology since it is embedded in the organization. The Investment managers and the Enterprise Architecture will be dealing with the change and the adaption of the organization and technology.

When it comes to the third and fourth generation then the managers have to focus on applying theory and concept of Enterprise Architecture to investigate the current state of the Enterprise Architecture (“AS IS”) and how the Enterprise Architecture should be transformed (transformation plan) into fulfilling the strategy.

Chris Potts focuses on the promise of a strategy (e.g., We will be the largest ICT supplier in Great Britain within two years) and the Enterprise Architect (in our case the Coherency Architect) should put his or her attention on developing a transition plan that enables the employees and management of the organization to achieve the strategy.

The Need for an Enterprise Architecture Approach

Why a company needs to innovate its Enterprise Architecture and what Innovations should an Enterprise Architect recommend. It is notable that Chris Potts made use of a case titled “SpaNets”.

The case is “an enterprise of enterprises” (or a divisionalized form of organization according to Mintzberg’s organizational compass) and from that can these three general ideas be aggregated:

1. The Global Economy has lead to a price lead competition and the EA analysis (“AS IS”) can assist the enterprise in innovating its processes.

2. The enterprise can use the Enterprise Architecture to give them a proper view of the subsidiaries the the organization has acquired.

3. The enterprise can use the Enterprise Architecture to document the processes to align them or to apply standardized business processes.

You can argue that an organization has a functional enterprise architecture by judging it on its ability to generate a surplus.

Chris Potts defines the concept of Enterprise Architecture as system where the animal spirit of the founders of the organization are combined with the structure of systems within the organization.

“Enterprise is defined on a bold or courage undertaking and the animal spirits of the entrepreneur. The architecture is the science of designing structures and a style of structure.” - Chris Potts, The IT University of Copenhagen, 2010.

Never the less the concept of the Enterprise Architecture is more than just dealing with the configuration of systems within systems or architectures within architectures. First of all is Enterprise Architecture about people.

“Enterprise Architecture is about people” – Chris Potts, IT University of Copenhagen, 2010.

This makes sense since the enterprise architecture consist of labour, land and capital (resources) combined with strategy and it matches the focus of knowledge management as Nonaka dealt with it in his knowledge spiral. Knowledge is acquired (in tacit form) form the individual who either socializes or externalizes it. When the knowledge is socialized or externalized then the organization (or the enterprise can apply it or crystallize it).

Nonaka's Framework

One imperative for the Coherency Architect is to create space for the employees of the organization so they can use their creative skills to create innovation. This focus can be supported by the theory that Gary Hamel proposes in his book titled “The New Age of Management” from 2007. Gary Hamel argues that the employees of the organization should be enabled to create their own projects within the framework of the organization and the organization should promote that the old management orthodoxies should be banished.

“When you are an enterprise architect it is all about people, space and purpose.” – Chris Potts, IT University of Copenhagen, 2010.

Processes Within an Enterprise Architecture

When the Coherency Architect is designing the “TO BE” Enterprise Architecture then he or she should focus on the customers since the dilemma often becomes if the enterprise owns (has a process) or the customer owns a process and who exist for who.

“Do has the company a process or is it the customer who has a process” – Chris Potts, IT University of Copenhagen, 2010.

When it comes to processes and architectures in the enterprise then Chris Potts states that most companies are aware of managing the Systems and Technologies architecture but they haven’t managed or designed the rest of the architectures.

“All but the technologies architecture are rarely defined or actively managed” – Chris Potts, IT University of Copenhagen, 2010.

However in most organizations the Coherency Architect will most certainly face a political situation when or if he or she goes to the CXOs and informs them that the organization’s Enterprise Architecture isn’t matched with the strategy and principles of the organization.

“It takes courage to go to the executive suite and tell the executives that we found out that the company is broken” – Chris Potts, IT University of Copenhagen, 2010.

The Coherency Architect should therefore focus on change management principles as well as using the corporate strategy as a key driver to convert the resistance among the CXOs to assistance in the transformation process (making them change agents).

The Enterprise Architecture and Strategic Issues

When it comes to EA approaches and methods then an Coherency Architect group might phase the issue of defining what artifacts that should be interpreted as what and how these should be organized; however in the end the Coherency Architects should focus on making something useful and that is where the strengths of knowledge management and innovation becomes useful.

“We had 15 people and we got 15 answers on what Enterprise Architecture was an should be. [...] We all see it as something different; however what matters is that we had to boil it down to something useful ” – Chris Potts.

However it is notable when the organization starts to mature its enterprise architecture then an EA program has to be imitated and the Coherency Architect needs to be hold accountable to achieve the strategy and by defining the principles of which the Enterprise Architecture strategy needs to be implemented by.

As mentioned in the blog post “The IT Strategy: An Articulation of the IT Strategy from a Coherency Architect’s Point of View.” then Chris Potts advices that the strategy needs to be embodied by the strategist (in our case the Coherency Architect) and the de facto strategy is not the one mentioned in the articulated strategy.

Conclusion

The conclusion of the keynote was that Enterprise Architecture can be used to identify problems within the Enterprise. In the same time can Enterprise Architecture applied to gain a competitive advantage for the enterprise.Thereto should Coherency Architect identify the constraints of the organization before initiating the Enterprise Architecture transformation program. Then identify how the value can be created by using the technology available if not to mention how create a combined strategy (EA strategy) for the enterprise that both focuses on keeping the animal spirit of the founders and enabling the employees of the organization to innovate. The enablement of employees to innovate is an imperative since Enterprise Architecture is about people.

The Coherency Architect has to show courage when it comes to inform the top management on misalignment in the Enterprise Architecture and in the same time be able to compromise with the rest of the Coherency Management Group in defining the proper solution for the enterprise.

When the Enterprise wants to benefit from its Enterprise Architecture then it has to initiate an EA program to mature the enterprise since only through the EA approach will the organization be able to activate the proper synergies among the various components that the organization consist of.

The Coherency Architect has to focus on the strategic promise he or she articulates (the promise is a single line that includes a statement for what the enterprise should be) and the de facto strategy the Coherency Architect implements. If there is a misalignment between the two then the strategy needs to be redefined and reimplemented. The Coherency Architect needs to challenge the orthodoxies of the enterprise and the industry of which the enterprise operates to release the true potential of Enterprise Architecture.

Chris Potts (right) and Peter F.T. Sjoelin (left)

The Front Lines of EA (2): An insight in to Strategy and Innovation.

Articulation of the IT Strategy

The Coherency Architect needs to be able to deal with the IT strategy otherwise he or she will not be able to drive any value from the Enterprise Architecture. There are many approaches to how an IT strategy can be articulated and what the primary focus should be.

This blog post will deal with the approach Chris Potts have proposed in his book titled “FruITion”. Chriss Potts have proposed a bit controversial approach to IT strategy e.g., he focuses on other models and claim that when the organization manages its investments then the right portfolio of technology will be selected, likewise does he propose that the role of the CIO isn’t an imperative. In the novel Chris Potts suggest the title “CIIO” for Chief Internal Investment Officer.

The Coherency Architect can make use of the approach to challenge his or her own view on the strategy and thereby be able to produce better strategy.

It is notable that the book is organized around a novel that deals with a CIO that faces a situation where he can’t pin point what kind of value the IT department brings value to the organization.
Potts then write emphasize some observations that can be made on each of the chapters in the book.

The Strategy Articulation Process

This section is based on the definitions that Potts describes in his work “FruITion” (Potts 2008, p. 13):

1. Most robust strategies emphasize high value on its environmental feedback.

2. Make sure the strategy is meaningful to the stakeholders of the strategy.

3. Distinguish between the strategic level and the operational level thinking.

4. Disinterest should never be understood as trust.

The following four statements are based on Potts’s “fruITion” (Potts 2008, p. 25):

1. A document that contains the strategy is not the strategy.

2. The language used to articulate a strategy shows the mindset of which the person who articulated made use of (or has).

3. If the host organization (enterprise) has an IT strategy then it is necessary to include all of the Information Technology the organization (enterprise) makes use of.

4. It is an imperative that the IT strategy has to summarized in one meaningful sentence; otherwise the strategy needs to be reworked.

5. If the organization (enterprise) has an IT roadmap then it is imperative that the driver of the roadmap isn’t the suppliers but the tactical goals and strategies of the organization.

6. If the CIO runs the IT department as an external business (weak links to the enterprise) then the enterprise will threat the IT department as such.

The following four statements are based on Potts’s “fruITion” (Potts 2008, p. 54):

1. Shape the strategy by exploring why the company isn’t already fulfilling its promise.

2. The CIO should validate who the promise is “talking about”.

3. Build the strategy on a model that emphasize the customer and supplier perspective and never the “Business and IT” perspective. The over all reason for this is that the organization and IT department is one and the same.

The following four statements are based on Potts’s “fruITion” (Potts 2008, p. 204):

1. If the organization manages its investments well then it is likely that the most appropriate technology will be selected.

2. The organization should assign an executive accountability for maximizing the total value the company creates by its internal investments in change.

This leads to the Alignment phase.

The Alignment Phase

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.34):

1. Never under estimate the pace (of change) of the Corporate Strategy.

2. The strategy has to be compatible that stakeholders change their minds.

3. Build the IT strategy on a promise and not on aims.

4. If the IT strategy is organized around solving a particular problem, then it is a necessity that the IT strategy solves the problem.

5. Are the persons who develops and articulates the strategy (strategists) game players?

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p. 44):

1. If the business side of the organization perceives the IT department as an external supplier then it is likely that the IT department and the CIO can’t influence the corporate strategy.

2. Different kinds of strategies needs different kinds of strategists.

3. The CIO should know his relative strengths and weaknesses when it comes to analysis and synthesis. In a strategy it is the synthesis part that is the most important thing to handle.

4. If the IT department or organization (enterprise) have issues with identifying what value the IT brings to the organization then it is likely that the organization (enterprise) experience wider business related problems.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p. 61):

1. A corporate strategy that is focused on exploiting IT is focused on value, money and organization. The corporate strategy is not focusing on technology.

2. The directors of a company is an independent community that adds value to the company.

3. Value is defined as a portfolio of measures and types.

4. The “business side” of an organization will in many cases assume the money the enterprise is spending on IT is a random number.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.124):

1. Each stakeholder in a strategy has something distinctive to offer.

2. Language and communications are critical to a strategies success.

3. The concept of theoretical, practical and abstraction depends on the audience. The strategy should be articulated and aligned to the audience.

4. People in organizations develops the projects rather fine but they tend not to make the most out of the projects when the projects have been implemented.

This leads to the value adding phase.

The Value Adding Phase

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p. 70):

1. Many relationships are based on perceptions and high profile characteristics.

2. The business side of the organization expects service and therefore should service levels between the IT department as a supplier and the customers be negotiated and incorporated into the strategy.

3. The corporate strategy is about numbers. The focus of the IT strategy should be the same.

4. Often there is a gap between those in the enterprise who adds value and those who spends the value. Is that also the case for the IT strategy?

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p. 159):

1. The CIO (or the Coherency Architect) should make use of color coding to distinguish the business investments from the IT investments.

2. The CIO (or the Coherency Architect) should prove that looking and managing the IT investment as something apart from the business investment isn’t sufficient.

3. The CIO (or the Coherency Architect) should show that the strategic projects aren’t necessary those projects that aggregate the highest ROI.

4. Explorer the cause and effect with of IT investments and business investements.

This leads to the change management phase.

The Change Management Phase

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.72):

1. When changes occur (as it will with the implementation of a new strategy) then the change process will also impact the employees (and managers) personal life.

2. Numbers is a dispassionate way to analyze the strategic landscape with. It should include what the CIO and the enterprise knows and doesn’t know.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.81):

1. The IT strategy has to be articulated in an iterative approach.

2. Look at the numbers in the budget and evaluate if they speak for themselves.

3. The CIO (or the Coherency Architect) has to explore how the company budgets , manages, and measures business change that comes through IT related projects.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.175):

1. The CIO (or Coherency Architect) has to cause other people to change.

2. The CIO should know what he would die in the ditch for.

3. The business side of the organization often experience the IT side of the organization as being “promising a lot and never keeps the promises and it doesn’t care about the business side”.

4. 100% alignment among strategies can be dangerous and it occurs rarely that the strategies are 100% aligned.

5. The future role of the CIO is not assured.

6. The CIO or Coherency Architect has to understand that there are competencies else where in the enterprise that is in duplication of the those competencies that are in the IT department.

7. The new strategy for IT demands a new operation model.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.180):

1. Strategists deal only in success and so should the CIO and the Coherency Architect.

2. It can be hard for the CIO and the Coherency Architect to challenge the orthodoxies of the organization.

3. If the CIO will not cross the bridge then let someone else take care of the investments.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.182):

1. Leading strategy can be a lonely job.

2. The over all focus of a strategy is about winning. If the CIO or the Coherency Architect is not committed 100% to achieving the strategy then it is not really a strategy.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.191):

1. Set down your Promise, Principles and Tactics for the key stakeholders to explore and ratify.

2. The stakeholders wants to see the combination of ideas in relation to the organizational system.

3. The strategy can look like the obvious but it is important that the CIO or Coherency Architect emphasize that the strategy isn’t applied.

4. The CIO or Coherency Architect should test the best practice of the industry.

5. The strategy is what the CIO or Coherency Architect does (de facto strategy).

This leads to the implementation phase.

The Implementation Phase

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.96):

1. Use the “Promise, Principles and Tactics” framework while the strategy is in the articulation process and when it is about to become executed.

2. The “Promise and Principles are the stabile core of the strategy. Tactics are more fluent or adaptable when it comes to events.

3. Address each of the stakeholders individually (preferable personally) before the stakeholders are addressed as a group.

4. Lead the execution of a strategy don’t manage it.

5. When it comes to the investigation of IT investments then start with identifying value and then work backwards. When using a spreadsheet then the focus should be on columns and not on rows. This should help create the overview that is needed (according to Potts).

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.103):

1. The strategist (CIO) is the embodiment of the strategy.

2. Organize the collaboration around one set of numbers and strategic themes; however each person who works with the strategy should be given the opportunity to have an influence on that part of the strategy that they work with.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.115):

1. A relationship is owned by two people.

2. Experimenting with the numbers (in the budget) can uncover a new understanding of the problem.

3. The CIO (or Coherency Architect) should make use of a bottom up value portfolio.

4. The CIO (or the Coherency Architect) should evaluate the investment strategy to sparkle a discussion on what priorities the organization (enterprise) has.

5. The Coherency Architect should be focusing on the exposing the scenarios for what will happen if the investment strategy is changed.

This section is based on the definitions that Potts deals with in his work “FruITion” (Potts 2008, p.134):

1. Strategy is essential about options and opportunities and it is not about being right.

2. Take the lessons for what didn’t work as expected.

3. The relationships that people builds are influenced of previous events and relationships.

4. Look for the subtleties in the responses of the stakeholders.

Types of Managers

Potts presents the model (illustration 1) that serves as a compass for characterizing managers within the organization. Note it is a compass and most managers aren’t purely technical, purely operational, purely environmental or for that matter purely organizational.

Potts's View on Managers.

The operational manager focuses on execution and internal processes.

The environmental manager focuses on how the strategy’s external context.

The technical manager focuses on specifications, technologies and products/services etc.

The organizational manager focuses on organization models, cultures, structure, internal politics and sourcing.

That leads to the conclusion.

Conclusion

The Coherency Architect should be aware of that there are various ways to develop and articulate an IT strategy. Potts approach is rather clear and can in many ways be considered as a practical approach to articulate an IT strategy. Potts approach can be considered an alternative approach to IT strategy and it can be used to challenge the “industry orthodoxies” which in itself can create a competitive advantage.

The Coherency Architect has to understand how an IT strategy is and how the artifact can be produced if it doesn’t exist in an enterprise already and that makes the concept of the IUT strategy rather important to understand and challenge.

Sources

Potts, C., 2008. fruITion: Creating the Ultimate Corporate Strategy for Information Technology illustrated edition., Technics Publications, LLC.

Download the paper her (articulation_of_the_IT_strateg.).

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.

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