An Introduction to Coherency Management: A keynote with Gary Doucet @ ITU 2009.

10 03 2010

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

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.

1The 18th of September 2009 a Keynote at the E-business Association at the IT University of Copenhagen.

Download the paper here.


Comments : Leave a Comment »

Categories : Architecture Maturity, IT Alignment, Keynotes

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.


Comments : Leave a Comment »
Tags:
Categories : Audit, Economic Benefits, Up in Time

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.


Comments : Leave a Comment »

Categories : IT Alignment, IT Strategy, Keynotes, Up in Time

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


Comments : 3 Comments »
Tags:
Categories : Alignment, IT Alignment, IT Strategy, Methods, Up in Time

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

10 02 2010

Concept for a Business Model

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

Business Models in a context

Context of the Business Model

The Business Model in Context

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

Elements of a Business Model

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

Sources

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

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


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

From the Frontlines: An insight to Enterprise Architecture

4 02 2010

What is Enterprise Architecture

Enterprise Architecture is a form of management and a documentation method. This means that the Enterprise Architecture can aid the management of the organization with a better view of how the enterprise works and how to bridge the gap between the current architecture and the desired future state of the architecture with a so called EA program. The EA program has to be based on an EA transformation management plan.

The documentation framework of Enterprise Architecture can be viewed as a tool the management and top leadership among others can make use of to understand how the organization interacts with the various components the organization consist of.

The best way to enable understand of how the enterprise works will be by applying (and installing) as so called repository that has to be available for all the members of the organization so they understand how the enterprise architecture is defined.

Why Enterprise Architecture is important and is diffused through one industry to another is that the management style and the documentation framework is comprehensive and tries to communicate how the systems in one way or the other can be understood by the members of the organization. Thereto are there several benefits associated with implementing Enterprise Architecture and later on Coherency Management correctly.

The rumor of the benefits often leads to that organizations in various industries wants to implement Enterprise Architecture.

“Everyone have to join the hype. Therefore should and will the business side of the organization demand that the organization (as a whole) should be able to the same as the rest of the industry” – John Goetze.

However this blog post also deals with the benefits of successfully implementing an Enterprise Architecture. Remember that all organizations have an enterprise; however the maturity of the enterprise has a great impact of how the organization can use it strategically.

Advantages of Implementing an Enterprise Architecture

There are several benefits associated with an Enterprise Architecture and as before mentioned one of these is that the organization becomes aware of the gaps in its current Enterprise Architecture and the gaps in how the “line of sight” works compared to its own architecture. This can eliminate irrational tasks and processes.

The Enterprise Architecture will lead to a greater degree of alignment of resource allocation to those processes that adds value to the organization and its customers (and other stakeholders).

The awareness that the Enterprise Architecture creates enable the advantage of greater awareness of the security of the organization.

Disadvantages of implementing an Enterprise Architecture

Implementing an Enterprise Architecture often leads to that the organization in one way or the other will allocate resources to an EA program that have to focus on how to work with several different identification tools and methods. Thereto a consultant, certification, employing a chief architect and enterprise architects aren’t cheap and since all organizations in the world have to relate to “capacity constraints” then the implementation of an Enterprise Architecture Program will be associated with a certain risk.

There are some risks that are more common than others e.g., rejection of the Enterprise Architecture if the members of the organization feels that the EA program is a hostile take over of their departments (loss of freedom), large costs of diverting people away from the business processes to focus on assisting the EA program and learning from the EA program.

It is however worth noticing that Enterprise Architecture rarely can be implemented as a “big bang” change; however CXOs often see Enterprise Architecture as a method and management style that requires .This can be summed up in the quotation below:

”Boil the Ocean – - to use all means and options available to get something done” – Louis Gerstner, Who Says Elephants Can’t Dance? HarperBusiness (2002).

However experience from the 1990s shows something differently which can be summarized in the quotation.

”If we’ve learned one thing from the 1990s, it’s that big bang, IT-driven initiatives rarely produce expected returns.” – Brown & Hagel, HBR comment to Nicholas Carr’s IT Doesn’t Matter.

This means that the Coherency Architect or the EA program manager has to manage the stakeholders expectations to the Enterprise Architecture and what it will be able to provide for the Enterprise.

Legacy systems can become an obstacle for the implementation of Enterprise Architecture but it is not an imperative to decommission legacy systems or to convert them to a new platform.

“Every Architects dream is to gain access to a ‘green field’ which can be a field that is totally empty and where the architect can build something on” – John Goetze.

The Conclusion

It can therefore be concluded that Enterprise Architecture can lead to major benefits for those organizations who apply the management style or choose to apply the documentation framework; however the allocation of resources to initiate an EA program can lea to disadvantages as well; if not to mention that the EA program can be rejected by the employees of the organization.

However for many organizations the implementation of an EA program that is based on iterations can unlock a competitive advantage for the enterprise. Never the less it demands management commitment.

The Frontlines of EA (1)


Comments : Leave a Comment »

Categories : Discipline, Enterprise Architecture

The New Age of Management: The Focus on Coherency Management!

16 01 2010

The Development of the Organizations:

As you know that the organizations have evolved over time from once in the 19th century where the organizations (companies etc.) where small and insufficient. The organizations in the United States were of the size of 1 – 4 employees who were not selected on their ability but through their social network.

The 20th century formed organizations and created tendencies and pressures in the market that demanded that the organizations had to adapt to create the goods of a high quality for a low price so new markets could be reached. The 20th century introduced a scientific approach to management which was introduced by Frederick W. Taylor. This approach led to the creation of Taylorism and the core principle of Taylorism was to eliminate ineffective work processes.

This led to the construction of a management paradigm which has led to the foundation of the current management approach for the organizations.

Today we see organizations that are multinational or global and these have thousands if not hundreds of thousands of employees e.g., International Business Machines, Ford Motors, Microsoft, Google etc.

All of these works with a specific organizational design typically these have been hierarchical and this has led to specialization, productions increase, profit maximization etc.; however since the end of the production economy by this I mean the economy which was dominated by companies that produced physical products e.g., Cars (Ford). The Western economies evolved from focusing on physical products into providing services and later to focus on how to produce knowledge. The knowledge economy is characterized by the employees are those who are the asset. Their knowledge is the asset which is used to create products and services; however the products and the services are normally produced or provided by a different company in the third world e.g., India, China, Vietnam or Indonesia. Since the employees are the most valued asset then the goal is to make sure that the employees don’t leave the organization and enable them to create more creative and sustainable solutions of which the organization will be able to capitalize on.

This leads us to the evolution of the concept of management.

The Evolution of Management:

Management is defined as:

“Management is the art to getting things done through people” – Mary Parker Follet (Barret 2003, p. 51).

Management has evolved over time like the organizations. There have been several views on how to manage organizations; however this blog post will only deal with what a Coherency Architect should conclude to be relevant.

As mentioned before then there are the first form of structured management is the Taylorism (as mentioned under Scientific Management). This form of management insufficient in the knowledge economy since knowledge workers needs other forms of stimulation than monetary incentives and written orders to perform.

Naturally there was a reaction to the Taylorist approach. This happened when the Japanese companies introduced cheaper products and of superior qualitative which meant that the Western companies had evaluate the way they managed and motivated their employees.

Since the 1970s have the Western companies in one way or the other tried to imitate Japanese companies by developing management and quality systems like Six Sigma, LEAN and Toyota Production System. The reason for why the Western companies haven’t been successful is that they so far have simplified the systemic approach the Japanese makes use of.

The Japanese have a very different approach than Western companies when it comes to management and motivation. First of all the Japanese companies make use of a bottom up approach when it comes to how the organization articulate and implement their strategies. Second of all the Japanese companies have been known for motivating their employees by making them proud of their work and putting an honor in quality. Third of all the Japanese companies are known for lifetime employment which means that they commit themselves to keep the employees employed and as a result of this they expect a higher degree of loyalty and commitment.

The IT waves in the 90s and early 2000s led to leadership and motivation; however to many organizations (typically IT related organizations) didn’t realize how to enable more productivity or for that matter crystallize better products by applying the new forms of leadership. As a result of that many of the organizations failed to survive the IT bobble which proved that to many organizations didn’t have the appeal of the market to survive or they simply didn’t understand their Enterprise Architecture. If these organizations had understood their Enterprise Architecture then a lot of them would have been able to scale the need of their consumption of resources and as result they would have survived.

The new paradigm is that the employees are the asset of the organizations and these should be encouraged to enable them to develop their own products.

Coherency Management:

All organizations have an architecture regardless if members of the organizations are aware of it or not (Doucet et al.).

Coherency Management then deals with how the organization can gain advantages by using Enterprise Architecture. This is done by maturing the organization by diffusing the knowledge of Coherency Management and the by applying the tools from Enterprise Architecture to other parts of the organization. This diffusion needs to be build upon the idea that these have to be embedded in the business processes and continuously be applied with the maturity of the Enterprise Architecture.

In many ways the concept of Enterprise Architecture is based on the same paradigm as the management systems of the 20th century which is defined as structuralism and according to Doucet (Doucet et al., 2009) Coherency Management and the underlying tools such as Enterprise Architecture are typically defused by the IT department to the rest of the organization. This is typically done by the Chief Information Officer who anchor the paradigm in the middle and top management of the organization and gives the members of the IT department the “necessary protection” to enable change within the organization.

Therefore it is safe to assume that the Coherency Management approach will lead to a top down approach as it was the case for many other Western styled organizations. This might lead to the conclusion that Coherency Management in some way will be in a different paradigm than those tools which are suggested by Gary Hamel. However Coherency Management do also have elements which needs to be diffused via the bottom up approach and it has to be embedded into the organizational culture and employees with many different backgrounds have to apply their own views onto the concepts of Enterprise Architecture.

When this come to the consideration of Coherency Management then the drive to implement the concepts of Coherency Management and Enterprise Architecture is defining what paradigm to make use of. If Coherency Management is build upon the idea that the employees should help define the framework and tools the Coherency Management Office will apply in the various processes in the organization. In the other hand quite a few people are scared of change and change anchored in the hands of employees won’t necessary led to change or innovation like Henry Ford mentions in relation the innovation of the mass produced car: “If I had asked them then they would have asked for faster horses”. Therefore should the Coherency Architect keep in mind that the only way to enable change in an organization is to influence the organization culture. The culture can be changed in many ways by the tools of many different paradigms.

In this article I will however only deal with a few frameworks for change.

The first framework is the structuralist approach which where Kotter’s framework will fit into. John P. Kotter presents in his article “Why Change Fails” and this could be supplemented by Kurt Lewin’s unfreeze, move and freeze approach.

The second framework is the interpretive paradigm where the organization constructs some form of “internal” economy where the members of the organization can influence the projects which the organizations initiates. This is done by establishing a form of stock exchange where all the members can invest a fictional amount of company-money to found the projects.

The organizations that adapt this framework needs a strong Enterprise Architecture and move towards Coherency Management; otherwise will the entire change effort be in wane.

The third framework is based on the idea that the employees themselves should be able to choose their leaders and regulate their own production schedules etc.. This kind of coordination needs like the second framework a strong focus on their Enterprise Architecture and thereby also on Coherency Management to assist the employees and the management with keeping the organization on track.

The New Age of Management: A Focus on Coherency Management!$


Comments : Leave a Comment »

Categories : Alignment, Architecture Maturity, Enterprise Architecture, Methods

The Case study Method: From a Coherency Architect’s Point of View

28 12 2009

Why this method is Important

The Coherency Architect should consider the case study method an important tool since the Architect has to investigate the organization or organizations they work with to investigate and uncover problems that needs to be solved before the organization can continue with it plans to achieve its goals.

The Case Study Method gives the Coherency Architect tools which can assist him or her with identifying the problems and articulate the right solutions for the right problems.

Therefore will the Case Study Method be presented and dealt with in this particular blog post. Please note that you can download a compendium dealing with the case study method (The Case Study Method from a Coherency Architect’s Point of View).

The First Step

According to Robert K. Yin there are logical steps the investigator (in our case the Coherency Architect) should deal with in a particular order

The Coherency Architect should articulate a problem statement. The problem statement should primarily deal with how, what, who and why questions which need explanations. The Coherency Architect should know how to articulate an academic problem statement since it is presumed that the Coherency Architect has attended a business school an University related education.

Then the second step follows.

The Second Step

This step deals with how the Coherency Architect designs the case study. The case study can be designed various form of collecting data and different forms of analyzing them. When it comes to the Coherency Architect will work with both qualitative data and quantitative data when he or she is about to study an organization.

There several forms of case studies which the Coherency Architect can choose to work with. The first one is called explanatory case study, the explorative case study and the causal case study.

The explanatory case study used to explain a phenomena or tendency. The causal case study is used to identify what kind of decisions or processes that led to the outcome of the situation e.g., why the organization developed as it did and who were in charge of it. The third is known as the explorative case study which is used to (as the name indicates) to explorer if a hypothesis is sound.

It is important that the Coherency Architect understand the theory which he or she is about to apply to the case study otherwise the design will fail. Therefore should the Coherency Architect work with this particular issue before he or she starts the procedure at this step.

Yin are of the opinion that there are two types of case studies. The first one is known as the single case study and is the most commonly known; however the second kind of case study called the multiple case study is more rare but it is easier to generalize the findings of them.

Thereto are there two forms of case studies. The first kind of case study is known in education where the investigator (in our case the Architect) doesn’t need to stay objective to the evidence (data) which he or she has collected. The other case is the scientific case study where the investigator has to stay object and critical towards the evidence (data) he or she has collected. The Coherency Architect will most likely work with the scientific case.

When it comes to scientific case study then it is important to emphasize that the Coherency Architect has to put extra attention to:

  1. Construct Validity deals with identifying the right operational measures for the concepts that are being studied. In the case of science then case studies have been associated difficulty when it deals with operationalize the measure and the measure often are biased since the findings are based on personal judgement.

  2. Internal Validity deals with establishing casual relationships where certain conditions are believed to lead to other relationships than spurious1 relationships. Please note that this particular approach is only for explanatory and casual studies and can’t be applied for other kinds of case studies.

  3. External Validity deals with identifying how the domain (the findings of the case study) can be generalized. This means how can the findings be applied in other organizations than the case study.

  4. Reliability deals with how the findings can be replicated in other studies. The major concern is that the findings are airtight and aren’t flawed and the findings therefore are biased or non-scientific.

This leads us to the third step.

The Third Step

This step deals with the preparation of the data collection and what the Coherency Architect should do before he or she begins the data collection.

First of all should the Coherency Architect focus on developing the right contacts to those persons he or she needs to interview to get the right information on e.g., how the work systems functions. However the Coherency Architect might also make use of quantitative data such as statics or other data which can be collected this way.

The Coherency Architect should be aware of that the establishing the right contacts is more important than the theory establishing part when it comes to the data collection since if the Coherency Architect can’t collect the right data that support his or her’s hypothesis then the outcome of the case study might end up being biased and therefore not useable for any one.

The Coherency Architect should focus on establishing a case study protocol which consist of the data collection protocol which includes the questions the Coherency Architect will be asking the interviewee. The Coherency Architect should also include an outline of the report which should be the case study. The case study protocol is build upon the idea that the Coherency Architect can make use of it to stay on track.

It is notable that the Coherency Architect should create an evidence database. The database should contain the data the Coherency Architect has uncovered so a chain of evidence can be established.

The Fourth Step

This step deals with the data collection phase. It is notable that the Coherency Architect will have to work with all six data forms which Yin mention in his book (see sources).

Interviews, documentation, records from archives and physical artifacts.

It is important that the Coherency Architect has to choose the sources with a critical point of view since the collected data might lead to a biased analysis and therefore to a biased view. The Coherency Architect should therefore try to combine multiple sources to achieve something that can assist the Coherency Architect to establish an overview of the case organization and how to identify the various layers with out being in the situation that he or she will be focusing on problems that proves to have minimal impact on the various layers of the organization.

The Fifth Step

This step deals with analyzing the data (evidence) the Coherency Architect has collected. Yin is of the states that there are four general strategies:

The Theoretical Propositions Strategy

This is the most common used strategy. The strategy deals with using the techniques, tools and world view the theory the architect has made use of in design his or her questions of which were made use of while the architect collected his data

Developing a Case Description

If the architect experience problems with applying the first mentioned strategy then the development of a case description might be preferable. This strategy is an alternative to the theoretical propositions strategy and when applied it is often considered as evidence for that the initial case questions weren’t based on theory.

Applying Quantitative and Qualitative Data

This strategy can prove to become an advantage for the architect if he or she is experienced with the case study technique. Yin is of the opinion that the quantitative data if the quantitative data has to cover behavior or events that the case study is trying to explain and second the data has to cover an embedded unit that can be related to the analysis.

Examining Rival Explanations

The fourth and last strategy deals with examining other explanations or theories of how the evidence in the case is related and interlinked. When the rival explanations are examined then it can uncover flaws in the evidence or uncover new relations.

Then there are five different analytical tools that can be applied the case study evidence:

Pattern Matching

The pattern matching approach deals with identifying patterns in the evidence (data) the architect has collect through his study of a phenomenon, organization or other. Yin are pf the opinion that simple patterns can also be uncovered and applied.

Explanation Building

This form of analysis deals with creating causal links among the various forms of evidence and by that explaining what happened and why.

Time – Series Analysis

According to Yin there are there two different approaches to time series analysis. The simple time series analysis and the complex time series analysis.

The simple time share analysis is based how the case organization has developed over time. Normally the simple share analysis is like applying the pattern matching.

Logic Models

Establishing a logical model explaining how the evidence is linked (the chain of evidence). The logical model has to explain the evidence and create casual links.

Cross Case Synthesis

This form of data analysis is suitable for studies that contain more than one case organization.

Sources

Yin, R.K., 2008. Case Study Research: Design and Methods Fourth., SAGE Publications Inc.

1Defined as not to have a purpose.

Download:

Download this paper (The Case Study Method from a Coherency Architect’s Point of View).


Comments : Leave a Comment »

Categories : Frameworks, Methods, Organization

Architecture Maturity

21 12 2009

Coherency Management is about gaining agility, assurance and alignment and these gains are closely linked to the maturity state of the architecture of the organization. All organizations have an architecture the question is how matured it is.

It is therefore desirable for most organizations to one way or the other to identify, mature and monitor the process. Before the identification takes place then the various characteristics of the architectures have to be dealt with.

The Architectures

In this section I will shortly deal with the architectures that are presented by Doucet et al. (Doucet et al. 2009)

The architecture that hasn’t been exposed to Enterprise Architecture and as a result of this the management or other actors in the organization are not aware of how the organization, its processes and its various layers are designed and interacts. This includes that the organizations isn’t aware of how their IT is used to support the various business processes.

The Foundation Architecture is an architecture that has been exposed to Enterprise Architecture; however this has only been applied for the IT side of the organization to bridge the gap between business processes and IT. In this state the Chief Information Officer (CIO) and the IT department has a great influence on how the Coherency Management tools are applied though this a downside and that is that the rest of the organization rarely understands the idea of Enterprise Architecture.

The Extended Architecture is bit more mature in the context of applying Enterprise Architecture. In context this means that other departments in the organization have identified that Enterprise Architecture tools can be made use of to improve the ability of the organization. In relation to who is in charge for the Coherency Management implementation then it is likely that this has passed from the CIO.

The Embedded Architecture is the so far the most mature level an organization can reach by applying Enterprise Architecture tools and change management. This means that the entire organization make use of Enterprise Architecture tools identify, initiate and implement new processes. This means that the organization has enforced a framework that has to be taken into consideration when new processes have been applied.

In addition to the above mentioned architectures the Balanced Architecture (Doucet et al 2009 p. 224) can be added. This is a future state within the Coherency Management concept.

I will therefore discuss the tools that can be applied.

Why Should Architectures be Matured?

When an architecture matures then the organizations that make use of them also become more agile and better in the sense that the organization easily can implement new processes, flows, systems etc.

This means that the organization can gain value for its stakeholders if the organization apply Enterprise Architecture tools to mature its architecture.

The Tools

There are several tools that can be applied to identify and monitor the state of the organization architecture. I have chosen to make use of Barnard & Grasso (Doucet et al. 2009) that have written a chapter which deals with how Enterprise Architecture can be matured.

According to Barnard & Grasso then these factors are useful to measure:

  • Enterprise Budget & Procurement Strategy.

  • Strategic Governance.

  • Extended Enterprise Architecture Architecture Results.

  • Extended Enterprise Architecture Developments.

  • Extended Architecture Program Office.

  • Business Units Involvement.

  • Executive Management Involvement.

  • Extended Enterprise Involvement.

  • Business & Technology Strategy Alignment.

The above mentioned indicators can be used to identify on what state the organization is on. If the organization is pre-dominantly in the un-mature part of the scale e.g., that the organization has an un-mature architecture. If the organization in any way has indicators that indicates that the organization is on a better level than the sublevel then the Coherency Architect should assume that the organization is maturing its architecture (perhaps implicitly).

There are methods that can be used to mature the architecture. For this the EAAM approach can made use of. The EAMM approach deals with how the Coherency Architect can measure and audit the architecture of the organization.

Control

As with all plans then it is a necessity to work with auditing and control which deals with controlling if the various goals used in the EA programs have been realized. This process is mandatory for every Enterprise Architecture project as it is for every strategic approach.

For this an Enterprise Architecture Audit Program should be established. According to Barnard & Grasso there are to forms for such a program. The first form is the light edition that consist of one to two persons who audit the EA programs in the organization. The analysis of the organization is build upon a superficial (high impact) analysis. The other is the advanced program where two to five persons go through a complete analysis of the EA program.

Coherency Maturity MindMap

Coherency Maturity MindMaps

Sources

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

Further Reading

Extended Enterprise Architecture Model (E2AMM v.2.0) (www.enterprise-architecture.info)


Comments : Leave a Comment »
Tags: , , , ,
Categories : Alignment, Architecture Maturity, Audit, Frameworks

Coherency Management and Innovation

2 12 2009

When it comes to innovation then coherency management is an enabling tool. This means that the organization that is aware of the various processes, the various elements and various technologies enables the  apply radical innovation and evolutionary innovation.
Schumpeter was of the idea that the single most important function of the organization was to crystalize the innovation in to products that could be used on the market and therefore can innovation be viewed as specific competitive advantage.
When it comes to coherency management then innovation can both be radical innovation and it can be process innovation.
The difference between radical innovation and evolutionary innovation is that radical innovation is game changing e.g., by creating new business models or new ways to do business. Process innovation is different in the way that the issues e.g., the processes are improved over multiple steps.
Both forms of innovation have their impact on how the organization performs e.g., organizations that have a well developed culture based upon evolutionary innovation often have the ability to perform well within their industry they operate.
Organizations that are able to enable radical innovation are often good to define new products, business models and markets that all in all give them a competitive advantage and thereby they are often able to be the first movers at many markets.

Innovation and Coherency Management

Innovation

To sparkle innovation there is a need for using the right people for the right positions within the project organization.
Tom Kelley is of the opinion that these profiles should be combined to create HOT teams that truly creates innovations:
“

  1. The Visionary is the type of person who is able to identify future possibilities (visions) and he is able to recruit the project team.
  2. The Troubleshooter is a person who in way or the other who are able to identify problems internally in the organization and is able to handle all situations that might occur in the project organization while the project is being executed.
  3. The Iconoclast is a person who is able to challenge the current believes of what is right inside the project organization and is able to see possibilities in other paradigms.
  4. The Pulse Taker is a person who is able to work like a hearth does in a human. The person has to be versatile in his or her way of thinking and is able to channelize the “life blood” of the project on to other individuals in the project organization.
  5. The Craftsman is that kind of person who is able to construct prototypes and work around with them to make innovative designs. These competences are vital for any kind of radical innovation.
  6. The Technologist is what many people would call a geek. A person who is dedicated to work with technology and is able to handle complex tasks, uncover and create deeper meaning.
  7. The Entrepreneur is a person who is able to work out with brainstorms, innovation, prototypes and communicate these to other persons.
  8. The Cross-Dresser these kinds of persons who have studied or worked with a totally different form of field then he or she works with today. These individuals make use of their skills to envision new solutions.

”

This leads to the concept of the maturity of the architectures and thereby the concept of Coherency Management.

The Concept of Coherency Management

Coherency Management deals with the maturing process of the architecture within the organization. The architecture consist of the various layers of the organization which are:

  1. People.
  2. Organization culture.
  3. Organization structure.
  4. Bureaucratic structure.
  5. Process structure.
  6. Information structure.
  7. Technology structure.

The more matured the architecture of the organization is the better the organization will be come to understand the processes, people, information and technology needed to create both evolutionary innovation and radical innovation.
Every organization has an architecture otherwise they wouldn’t be able to operate but there are three forms of architectures. The first architecture is called an architecture before Enterprise Architecture tools were applied and the organization is not aware of how it operates.
The more mature form of the architecture is called the foundation architecture. The foundation architecture is characterized by that the organization has applied Enterprise Architecture tools to the IT side of the organization. The first level of maturity with in this mode of architecture is where the IT structure and information structure is articulated for the enterprise wide perspective.
The second level of the architecture is when the needs of the business is articulated in a methodical way.
The third level of maturity is known by that the business side of the organization makes use of EA tools to identify, analyze and engineer the processes and structures after a methodical approach and after the change process has ended then the CIO takes over and apply the IT perspective.
The fourth and last maturity level for any organization is called the embedded architecture. This form of architecture is characterized by that all processes are aligned and by that there is a great need for design leadership. The design leadership has to create a framework for how the documentation and plans are to be designed. The other elements of the organization such as the Human Resources, annual planning, strategic planning, public reporting makes use of the structured framework and tools of the EA not to mention the that the strategic goal of the business drives the business requirements a and by that  drive the technological solutions.

Sources

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

Tom Kelley and Jonathan Littman, The Art of Innovation: Lessons in Creativity from IDEO, America’s Leading Design Firm, 1st ed. (Broadway Business, 2001). 


Comments : Leave a Comment »
Tags: , ,
Categories : Alignment, Discipline, Innovation

« Previous Entries