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

7 05 2010

Framework and Methodology

According to Bernard (Bernard 2004) then a Chief Enterprise Architect or what equals to an Enterprise Architecture program manager is selected then the definition of the EA framework and the EA methodology becomes a necessity.

The Definition of the EA Framework

An EA framework is dealing with what the EA program will document.

The Definition of the EA Methodology

The EA methodology deals with how the Enterprise Architecture documentation is articulated and used.

The EA Cube and its Construction

The simple edition of the EA cube that explains the various components, and layers within the framework.

The EA3 Cube.

The EA3 Cube.

The Documentation Process

There are six steps that needs to be gone through according to Bernard (Bernard 2005, p. 97):

  • The process includes a framework.

  • The process includes the components.

  • The process includes the current architectural views.

  • The process includes future architectural views.

  • The process deals with the transition plan for going from “TO BE” and the “AS IS” architecture.

  • The process deals with threads that influence the enterprise architecture on all levels.

A Comparison of EA Frameworks

Zachman’s Framework

The foundation of the EA Framework is John Zachman’s Framework. It was originally based on an approach that it could be explained and dealt with as if you had to build an airplane or a house. The blueprint analogy was used to articulate the framework.

Zachman's Framework (According to Bernard)

Zachman's Framework (According to Bernard)

In general there is one single mistake that the Enterprise Architect can do when working with the Zachman framework and that is to focus too much on documentation. This is known as the “Zachman Trap”.

OIO IT Architecture Framework

The OIO framework (based on the white book on IT architecture) was developed for the Danish Ministry of Science. Its focus is on the Danish Public sector. The intention was to implement Enterprise Architecture to give the decision makers in the Public Sector a better foundation for how the single organizational entities operates.

From a management perspective the idea was to enable the public sector to standardize and centralize processes and decision making.

The OIO framework is based on the same paradigm as the EA 3 Cube by John Zachman.

Strategy Process.

The OIO-Framwork (The Two Main Processes).

As the illustrated above then there can be defined a governance process and a documentation process.

The two circles represent activities used to deal with updating and developing the architecture. The circle located in the bottom of the third illustration deals with the process of the “AS IS” and this is connected to the process of creating a vision, a business architecture, information architecture and the technical architecture.

The OIO-framework is often criticized for being to comprehensive and often the Enterprise Architects have to invest too much of their time to identify artifacts on various levels and organizing the artifacts according to the OIO-framework. Secondly it has been some time since the last edition of the framework was revised which might be an indicator for that the Danish Public sector is either static in its development or that the state plans to release a new edition of the framework or an entirely new framework. In the other hand the OIO-framework has an entire section dealing with defining and identifying architects which in my opinion is a strength by using the OIO-framework since it enables the Chief Enterprise Architect to communicate to the stakeholders who have what abilities, responsibilities and not to mention accountability during the Enterprise Architecture process.

The EA 3 Cube

The EA 3 Cube was developed in 2004. The Framework is designed as a cube and it is build upon the idea that hierarchies are needed to avoid sub-architectures (Bernard 2004, pp. 104 – 105).

According to Bernard then the business goals are the drivers of how the Enterprise Architecture is designed.

The EA 3 Cube is based on the primary function of organize and planning IT resources and documentation of the Enterprise Architecture. (Bernard 2004, p. 105).

The framework is build upon five levels and as before mentioned these are hierarchical to avoid sub-architectures.

The Five Layers of the EA 3 Cube

  1. Goals and Initiatives is as before mentioned the driving force of the Enterprise Architecture and therefore are these located in the top of the cube (as the first and primary layer).

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

  3. Data and Information is used to document how the Enterprise makes use of information “AS IS” and how the information flow should be designed for future situations “TO BE”.

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

  5. Networks and Infrastructure deals with the so called backbone of the Enterprise Architecture and it includes how the networks interact and how various technologies interact such as VOIP and LAN, WAN etc.

The EA3 Cube.

The EA3 Cube.

Lines of Business (LOBs) that can be considered as a specific activity within the organization and all the have all the five layers of the architecture. The LOBs are named “Vertical Mission Areas”. The LOBs can have their own administration and functions that can be considered divisions within the divisionalized organization.

Crosscutting Components are established so the LOBs don’t create redundant features e.g., e-mail hosting and IT services.

Threads are defined as security, standards and workforce. These three threads go through each level of the framework.

Conclusion

These three frameworks are all located within the same paradigm and are therefore compatible with one another; however in some situations it will be better to choose the one of the frameworks over the other e.g., if analyzing an Enterprise Architecture for a public institution in Denmark then it recommendable to make use of the OIO-framework.

The frameworks have their strengthens and their weaknesses such as the Zachman framework that focus too much on documentation instead of changing the Enterprise Architecture from the “AS IS” stage to the “TO BE” stage. Likewise does the EA3 framework and the EA 3 Cube some benefits and advantages. E.g., is the EA3 Cube a rather simple framework and is therefore easily applied to small and medium sized organizations. In the other hand it tends to be a bit simple and generic which can end up being a disadvantage.

The Coherency Architect should therefore emphasize on choosing the right framework for the right situation and the right type of organization by using a SWOT – matrix or other form of matrix that can assist him or her with making the right choice.

Sources

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





Tools for Strategic Evaluation: Tools and Methods the Coherency Architect should Apply.

15 03 2010

The SWOT analysis

The Coherency Architect should be making use of a SWOT-analysis to evaluate the organization (enterprise) of which he or she is working with.

The SWOT analysis is a perfect tool to evaluate an organization’s strategical options in the current situation (AS – IS) and what the organization can do to move to a new desired steady state (TO BE). Please note that in some cases technology can also be evaluated through the usage of the SWOT analysis.

It is notable that the Coherency Architect shouldn’t rely solely on the SWOT analysis since it has a tendency to overemphasize the current situation (AS – IS). The Coherency Architect should therefore focus on using other approaches and methods to support the view of the future situation for the organization. However the SWOT analysis can be a good idea to make use of initiate a strategical analysis.

SWOT stands for Strength, Weaknesses, Opportunities and Threats. Where strength and weaknesses are internal factors for the organization. Opportunities and Threats are external factors of the organization.

However in some cases opportunities that haven’t been created or applied for the organization (though the fundament can be found in the organization) can be considered an opportunity.

SWOT - analysis.

SWOT - analysis.

An Example

This organization (enterprise) is in a situation where its products are seen as a commodity by the customers and as such new players in the market has started to produce products that are of similar quality and can do almost exactly as the products as the organization produces; the products the competitors produce are often a bit cheaper do the fact that the competitors are able to gain economies of scale.

The organization (enterprise) has a home – made Enterprise Resource-planning System, a heterogeneous portfolio of 132 computers (both old and new computers of diverse brands and specifications and operating systems) and the organization has access to one server that runs an elderly Microsoft ® Based Operating System where the ERP software is hosted and the user administration is managed. The organization (enterprise) consist of 300 employees and about 25% of these have an education on college level or above. The COO has a PhD in field of process development. The last 75% o the organization consist of people who have been minded on practical educations and are as such not theoretically in their approach to solve the problems the organization faces.

The organization (enterprise) has access to a credit limit of €10 million which their bank has granted them access to if the organization needs access to external funds to finance their investments.

The Business Processes have a lot of tightly coupling and they are working through a so-called J-I-T system (Just in Time) where the organization produces their products just as many units as needed to the various retailers. This is based on an idea that the organization can save money on storage facilities. The organization is almost like a division organization as Mintzberg described it.

The organization (enterprise) has an internal IT department; however the IT department is overworked and they often spend most of their time with user support and maintenance of the elderly systems and the management of the organization do not value the inputs the IT manager gives to the CFO.

SWOT - Analysis Example

SWOT - Analysis Example

The Coherency Architect can then identify the weaknesses of the current strategical situation (AS IS) and then use the SWOT-analysis as a part of the documentation to create the overview which is needed to articulate a transition plan for the Enterprise Architecture.

Conclusion and Discussion

The SWOT-analysis can be made use of to give the Coherency Architect an overview of the enterprise’s situation (AS IS) and it can assist the Coherency Architect with creating an overview of the strategical and the tactical situation; however the SWOT-analysis should be supplemented by other models and approaches such as the Porter’s Five Forces model and Porter’s internal value chain including Robson’s IS value chain.

Both an organization (enterprise) and technology can be analyzed by applying the SWOT-analysis; though the Coherency Architect needs to take it in to consideration that the analysis method often emphasizes on the “AS IS” state and therefore be questionable to be used in relation to articulation of an transition plan.

Download the paper here.





Economic Benefits of Enterprise Architecture: The Coherency Architect’s Economic Toolset.

4 03 2010

Why Economic Estimation is Necessary

When the Coherency Architect is working with implementing and maturing the Enterprise Architecture then he has to convince various stakeholders on to investing in the transition from the existing Enterprise Architecture maturity level to the new level (“TO BE”).

For this the Coherency Architect has to create a stakeholder communication plan where he or she will need to involve the stakeholders and win the over to invest in the change.

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

The communication has to be based on the stakeholder analysis which means that the various stakeholders have different needs for information and they need different ways to be informed about the Enterprise Architecture program.

Likewise have the various stakeholders various ways to react on the information and they have various means to influence the decisions and the over all commitment to the Enterprise Architecture transition plan.

To identify and manage the stakeholders then the Coherency Architect should brainstorm and note all the stakeholders (individuals and organizations) who can have an influence on the project.

An example of a brainstorm is in the illustration below:

Stakeholder Brainstorm

Stakeholder Brainstorm.

Then the stakeholders have to be categorized into their influence on the EA transformation program (Transition Plan) and how likely it is that they will make use of their influence to support (and implement) the transformation program or sabotage the transformation program.

Stakeholder Matrix

Stakeholder Matrix.

When the segmentation of the stakeholders is done then the Coherency Architect can identify what kind of Key Performance Indicators that can be applied. The KPIs should be used to communicate the value of the Enterprise Architecture and the Enterprise Architecture Program.

Questions the Coherency Architect Need to Deal with Before Evaluating the Economic Perspective of the Enterprise Architecture

First of all the economic benefits of an Enterprise Architecture be measured? In many cases the measurement of value of an organization’s enterprise architecture is like measuring the value of the Human Resources Department; the primary difference is that most industries the orthodoxy is that a HR department is needed. However how do you measure the benefits of an Enterprise Architecture and an Enterprise Architecture program.

Jaap Schekkerman has written the book “The Economic Benefits of Enterprise Architecture” and as far as I understand the message of the book then focus should be to measure efficiency (before the establishment of the EA program and of course after to evaluate the effect), the impact on the strategy e.g., has the EA program enabled the organization to come closer to fulfill the mission / vision? And finally measurement should be focusing on potential cost reduction the organization can benefit from.

I am a bit unsure if this is the right approach to measure the economic benefits of Enterprise Architecture; however if you (the readers) have any ideas on how to do it better then please don’t hesitate to comment this blog post (or contacting me).

Never the less I have tried to organize the three ways main perspectives on how to measure the economic benefits of Enterprise Architecture.

Efficiency

One of the primary economic reason for working to improve (maturing) the Enterprise Architecture is to gain efficiency and secondly to lower operational costs and thirdly to gain strategic advantages.

To gain efficiency the Coherency Architect needs to use tools and methods within the Business Process Management and Business Process Improvements.

When the Coherency Architect is working with Business Process Improvements then it might become efficiently to work with two concepts. The first concept deals with an in depth investigation of the business processes. This approach might prove to become rather comprehensive and rather expensive.

The second approach deals with business processes that have a great impact on the business, the so called “core processes”.

The core processes are in many ways better to identify and better to work with from the point of view that the analysis work isn’t as comprehensive as the full analysis.

The core processes are easier and often more profitable to work with before the change process is initiated.

When the processes are altered then it is important that the Coherency Architect doesn’t focus to much on just keeping the same design of the processes and adding the technology to the processes. When the core processes are altered then it will lead to a change of strategy; otherwise the realization of benefits will not be crystallized.

Tools the Enterprise Architect can make use of to investigate the “business architecture” is the BPMN, BPML, OBASHI flowchart and the ordinary flowchart

This leads to the section of strategy section.

Strategy

Jaap Schekkerman introduces the Enterprise Architecture Value model (Schekkerman 2005, p. 66 ) that introduces the four concepts that an Enterprise Architecture can contribute with in relation ot the strategic approach the organization makes use of.

The model introduces four perspectives such as the Technology Effectiveness approach, Business effectiveness, Technology Enabling and the Business Innovation approach.

The Business effectiveness deals with improving the business processes to achieve the corporate strategy of the organization. Typically is the Enterprise Architecture program used to define how the processes (AS IS) is designed and how they should be to gain competitive advantage (TO BE).

The Business Innovation approach deals with the creation of new services and products and not to mention on how to define new business value. This particular approach is often used to identify how the “business side” of an enterprise can be aligned with the “IT side”. In my opinion it is up to discussion if you really can differ IT and Business since they are components in the Enterprise Architecture.

The Technology Efficiency approach deals with keeping the costs down e.g., the Total Cost of Ownership. The focus as before mentioned is to lower the costs of using technology within the organization. The focus of the Enterprise Architecture Program is to give the organization is view on how to organize their information architecture and their technology architecture to gain this advantages.

The Technology Enabling approach deals with how the technology can add value to the organization e.g., by obliterating business processes and then redefine them so the usage of technology can lower the cost, improve the efficiency and improve the quality of the processes. The Enterprise Architecture Program is used to give top management an idea on how to the business processes can be enabled by the usage of existing and new technology.

Enterprise Architecture Vakue Model

Enterprise Architecture Value Model (Schekkerman 2005, p.66).

This leads to the section that deals with the concept of cost reduction.

Cost Reduction

The third perspective that Jaap Schekkerman introduces in his book is what I assume is the cost reduction perspective. It is presented as the focus on Advanced Management Accounting concept and how to calculate the “Cost Benefit Analysis”.

However this is an interpretation I have done of what Jaap Schekkerman has written in his book. Which leads me to my conclusion of how to measure the economic benefits of Enterprise Architecture.

The Conclusion

As I see it the most important issue with measuring the economic benefits of the Enterprise Architecture is to identify the stakeholders and use the tools they expect to be used to identify potential and to evaluate each potential.

If the stakeholders are cost minded then the Coherency Architect should choose an approach that focuses on how to measure cost reduction or if the stakeholders are focusing on improvements and innovation then the focus should be on how to enable this in the proper approaches.

All in all the focus is stakeholder communication. As mentioned in the blog post then I am unsure on how to identify the full potential of measuring the economic benefits of the Enterprise Architecture since it is an issue that is up for interpretation. If there are any one out there who knows of better ways to interpreter Jaap Schekkerman’s book on measuring value or knows of better ways to measure value of Enterprise Architecture then please do not hesitate to reply to this blog post or to contact me.

Sources

Schekkerman, J., 2005. The Economic Benefits of Enterprise Architecture, Trafford Publishing.

Download the paper here.





The Front Lines of EA: An Insight to Innovation, Strategy and Enterprise Architecture.

25 02 2010

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 24th 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 and Peter F.T. Sjoelin

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

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





The IT Strategy: An Articulation of the IT Strategy from a Coherency Architect’s Point of View.

22 02 2010

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.

Pott's View on Managers

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





A Coherent Architecture as a Strategy

22 11 2009

There are several issues that influence the competitiveness of any organization.  These factors are to be found in any domain (and are almost generic). This means that the organization will lead to the innovation, growth and decline of organizations.
Some organizations are privileged by owning a monopoly either backed by a government or by the fact that their products or services are superior to any of the competitors on the market. This makes the organization rather good to earn money since they often can set the price for the products and services as they want to; however this also leads to lack of agility since the pressure of the free market isn’t influencing the decision making of the management or the employees.
When organizations growth then they have a tendency to become more bureaucratic since there is a greater need for coordinating among the members of the organization, departments and management. This leads to a great degree of standardization but it also leads to a decline in agility compared to changes in the domain of the organization.
Therefore it becomes a question on how to cope with the need for coordination (bureaucracy) and the need for agility.
This can become an influence that impacts the organization and if it is used correctly then the organization can gain a competitive advantage.
Likewise can the way the organization make use of a technology become a competitive advantage for the organization. An example of this is that the organization might be superior to any competitors to utilize their information technology like software and hardware to support and develop their processes. These processes might in return prove to become easier to handle and create more value than the processes the competitors of the organization have.
Organization culture might also prove to become a competitive advantage since it indoctrinates the employees to act in a specific way. If the organization culture makes the members of the organization find and discover errors and eliminate the errors then the cost of repair and service fall and re-enforce the brand of the organization and re-enforce the good will the customers of the organization has to the organization.
Thereto will coherency management assist the host organization with creating a competitive advantage since it will assist the management and the various other stakeholders in the organization developing the necessary overview and consistent information that can be used to make the proper decisions.
Thereto if IT, business processes, organization culture, corporate strategy aren’t aligned then the organization will experience that the system is not able to fulfill the its potential and will therefore the organization will experience opportunity costs.
It is therefore in the interest of the management to work with the organization to achieve its goals and it is in the interest of the employees to assist making their work place better for them. It is the interest of them to feel productive and feel that their work matters for the organization. It is therefore a paradigm to involve them in the decision making but they too should be kept informed on how the organization develops.
Coherency Management is building on the principles on identifying the underlying architecture in the organization and enhancing the development of the architecture and by that the organization.
This is done by applying the tools from Enterprise Architecture to identify and evaluate the various processes and adding the technology needed to enhance the processes or re-think the processes to generate more organizational value.
It is therefore a strategical tool to evaluate and rebuild the architecture of the organization to match those tasks and challenges the organization will face in the future competition. A solid architecture which can be extended and reused will be a necessity in the future so the organization can grow and develop an architecture that can be used to connect the processes, people, departments and organizations to develop the right products and services to the right price.

Organizations will in the future be able to align them self to one or more syndicates to create products which are cheap enough to sell to the people in the third world. The organizations in these  syndicates have to know their architecture to understand and connect to these shifting syndicates and if these organizations either don’t know or understand their architecture then they will not be able to join the syndicates and gain the benefits from it.

Therefore is it of strategic importance that all organization work with and articulate their architecture to enable abilities of agility, knowledge and innovation and to that all the support functions and processes to enable interactions with so called networked organizations and syndicates.

To give the analyst some insight into how IT influences the an Architecture then it is advised that the analyst reads about critical issues in IT management.





Critical Issues in IT Management

19 11 2009

IT is a fundament when it comes to Coherency Architecture and it is therefore necessity to be able to understand the critical issues in IT management.

Therefore have I chosen to publish my notes from the course “Critical Issues in IT management” which I attended at Copenhagen Business School in year 2008.

As with all other documents at this blog the license for the document is Creative Commons V3 U.S. Edition share alike (read more under the general license for this blog).

Link to document: issuu.com

 

Enjoy the notes.

 





The Coherency Architect

15 11 2009

Since the start of the blog then I have mentioned the work of the Coherency Architect. In this blog post I will describe what abilities the Coherency Architect should posses to perform his or her job. This description could be considered a template for a job description for the Coherency Architect.
The Coherency Architect has to be a generalist that have to understand the basis and depth of organizational behavior and understand human psychology in how the organization works.
The organization consists of various contexts which the Coherency Architect has to be able adjust to and develop suitable solutions for.
For being agile then the Coherency Architect has to understand and work by a set of principles based on an academic study of Management Accounting, Project Management, IT strategy, Corporate Strategy, Organizational studies, knowledge Management and change Management.
Some of the above mentioned disciplines are of course logical for a Coherency Architect to understand and to make use of; however some of the courses like Management accounting has to be understood otherwise the Coherency Architect wouldn’t be able to understand the economic flow or the cost structure of producing the products or the services in the organization.
The costs have to be understood to identify the bottle heads in the organization and it enable the Coherency Architect with the the tools needed to solve major problems for the organization.
Coherency Management and Coherency Architectures derives from field of Enterprise Architecture which originally was an engineering discipline for developing technical solutions for organizations. These technical solutions were derived from the IT strategy and the IT strategy was again derived from the Corporate Strategy. In that way IT and business had to be some how aligned to achieve sufficient results. This could be called Coherency in a simple state.
For this the understanding of business models, strategies and corporate strategies is needed and therefore should the Coherency Architect develop an understanding of these disciplines to be able to add value by changing the processes and adapting coherent processes.
For this the Coherency Architect should understand people (their psychology and their organizational abilities). The Coherency Architect should not get all his or her knowledge from the academic world but also gain knowledge from experience e.g., by working with people and developing his or her people skill and the Coherency Architect should be able to lead people into the new situation meaning that he or she has to understand rhetoric and leadership to inspire the members of the organization to help change instead of fighting change.
However people are often not good to stay focused on a goal that is distant in a matter of time frame and therefore should the Coherency Architect work on his or her motivation skills and to be able to create short term goals and short term wins that are aligned with a vision.
Especially the short term wins are important to keep commitment from the stakeholders in the organization.
The Coherency Architect has to understand how to operationalize programs for changing the organization and the be able to keep stakeholder commitment which is a classic project Management discipline.
It is vital to understand that the Coherency Architect has to be able to gain knowledge from both the academia and by gaining knowledge from working in practice in the organization. In some ways the a practical approach can be the proposal to align the processes so they are coherent.

Nonaka's SECI Model

Nonaka's Framework

Therefore should the organization that is about to apply for a Coherency Architect work with several perspectives on knowledge and not just be working with the idea that a pure academic would be able to solve the problems better than a person who only have practical education; however the middle ground would in most conditions be preferable.
The Coherency Architect and the organization have to adapt to each other otherwise Coherency Management can’t be applied properly.
The Management and the stakeholders of the organization have to invest their trust into the Coherency Architect to show to the rest of the host organization that the Coherency Architect has the power, the initiative and the right to give them orders to change the way they work.
It is often the failure of the Management to show commitment to the Coherency program that blocks for coherent changes in the host organization.
Since organization consists of humans then all organizations are alike and yet they aren’t. Therefore should the Coherency Architect also adapt to the organization.

The Mind Map below deals with the primary issues of the Coherency Architecture.

The Skills of the Coherency Architect

The Coherency Architect





How to Identify Architectures?

8 10 2009

Every organization has an architecture otherwise it wouldn’t be possible for the organization to do business or transform raw materials into products or labour power into services.

However the Coherency Architect has to focus on how to identify the architecture in a methodical way so the Coherency Architect can make develop a functional approach on how to define potential coherence related problems and how to mature the architecture so the organization will make progress and work in a smarter way to reach the goals of the organization (those defined in the official strategy).

To identify the various problems then the Soft Systems Methodology or the Work System Method which can be used to collect data about the architecture in a systematic way. If the Coherency Architect doesn’t make use of a systematic approach then it is likely that he or she will miss potential flaws, errors, dangers etc. that might have a great impact on how good the coherence of the organization is.

There are two general approaches the Coherency Architect can make use of to identify the processes in the organization. The first one is the so called exhaustive approach that deals with the Coherency Architect identify all the processes in the organization and create plans for them. The second one is called the “high – impact” approach that deals with that the Coherency Architect deals with identifying the core processes in the architecture (organization). To start with then it might be preferable for the Coherency Architect to deal with the core processes and then adapt the Coherency Program to alter them.

Besides the two above mentioned methodologies then the organization can make use of various techniques such as the rich picture and flowcharts to analyze how the various elements in the organization impact the general outcome of the organization.

An example of a functional approach to analyze an architecture could be that the Coherency Architect made use of a qualitative data collection method which means that the Coherency Architect would go an observe and interview potential members of the organization. The members have to be put located various places in the organization so the Coherency Architect can create the best overview of the organization as possible. When the first round of interviews have been collected and processed then Coherency Architect should go observe the members of the organization perform their daily tasks and identify how the raw materials are transformed into products or services. The Coherency Architect should especially focus on how the various linked processes interact use this view to identify potential problems with the coherency of the processes. When these problems have been identified then it is likely that the Coherency Architect should make use of either the SSM or the WSM methodologies. These methodologies are used to create an understanding of what is happening within the system. However it is notable that the two methodologies belongs to two different paradigms which view the world very differently.

The Work System Method belongs to the “functional paradigm” where the Soft Systems Methodology belongs to the “interpretive paradigm”. The two paradigms are defined by Burrell and Morgan (1979) in their article dealing with sociological paradigms and organizational analysis.
The functionalist paradigm works with the idea that the architect will collect the needed data and then come to a conclusion based on his or her own world view. The interpreting paradigm works with the idea that the architect has to facilitate the different world views in the organization and thereby assist the members of the organization with developing a solution e.g., a new work system, information system or a third solution.

The two paradigms will lead to various kinds of conclusions and of which there might be opposing. It is therefore vital that the Coherency Architect is able to identify the limits of his or her own world view and identify how the members of the organization thinks and acts according to their world views. If the Coherency Architect makes use of the wrong approach then his or her suggested solutions might turn out to be out of touch with how the organization assume its business works and the solution will be turned down.

When the Coherency Architect has gone through this process then he or she will be able to identify one of the three different forms of architecture an organization might have. As mentioned earlier then every organization has an architecture.

Doucet et al. (2009) identifies three possible architectures. The first one is the architecture of an organization before an EA (enterprise architecture) toolkits have been applied. The architecture is called the articulated architecture.

The more mature architecture is called extended architecture where the EA toolkits has been applied for the IT side and some of the processes at the business side has been identified and is making use of EA principles.

The most mature architecture is called the embedded architecture where the EA principles are embedded into every business and IT project. Doucet et al (2009) defines this state as where the EA grid is put into practice and where all project, processes and sides of the business work with practices from EA and therefore have achieved the goal of Coherency Management.

To summarize then the Coherency Architect has to focus on:

  1. The methodology used to collect data.
  2. The paradigm the Coherency Architect make use of to identify issues with the Coherency of the processes, structure, people, tasks and technology within the organization.
  3. The world view the Coherency Architect make use of when he or she develops his or her coherent solutions for the organization.
  4. The states of the architectures in the organization and how to reach them.

Sources

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

* Burrell, G., & Morgan, G. Sociological Paradigms and Organizational Analysis (1979).





Governance versus Innovation

22 09 2009

Currently the IT department has a lot of control on how to govern and administrate the computers in the organization. It is usually based on the idea that the economies of scale is the preferred perspective to make use of e.g., when it comes to discussion on how to enable the users to operate with new features.

The CIOs tends to favor ideas of that when the governance committee has decided how the group is designed and who should be consulted when it comes to input and enforcement but they tend not to understand the need for user customization that has the potential to crystalize innovation and by that strengthen the organization.

After all it is the users who usually understand how they can improve their work conditions and their way to handle various forms of tasks e.g., organizing, information handling or knowledge sharing.

In this perspective it is rather clear that the persons who have a first hand impression of the situation are those who should be able to find suitable solutions for the problems at hand.

The IT department often play a critical role of the degree of freedom and thereby degree of innovation the users can achieve. If the IT department enforces the strategies the strategy committee has articulated and enforcing its view of governance then the employees often have to live by the rules of the IT department.

From the CIOs point of view then the organization’s use of IT has to be efficient both in usage and in costs. This means that the organization has to focus on keeping costs down on maintenance and focusing on pleasing the stakeholders of the IT projects. With this in mind then the IT department will focus on limiting the possible configurations of the computers and information systems in the organization so end user support and technical support can be easily deployed.

In other words the organization is in a constant struggle between efficiency and innovation.

As mentioned before then it is of vital importance that the organization is able to innovate its processes and by that the employees of the organization actively engage in the improvement of the organization structure. The Coherency Architect has to focus on both the efficiency (costs and support) and the issues of innovation in the core of the organization.