Five Things to do in order to deal with KPIs for Enterprise Architecture Processes

Measuring Enterprise Architecture Processes

In most enterprises that applies Enterprise Architecture will there be a need to measure how the enterprise is progressing from adapting the Enterprise Architecture Program and there will be some stakeholders who would like to know what value or benefits they gain by investing (and keep financing) the Enterprise Architecture Program.

Enterprise Architecture Processes

Implementing Enterprise Architecture principles, standards, systems and strategies would need some changes, processes and scoping. In this particular paper the idea of Enterprise Architecture processes deals with the concept that a chief architect sets a set of tasks in motion in order to uncover systems, social networks and business processes. The Enterprise Architecture processes differs from business processes by the architectural processes changes systems, business processes, information systems, IT, technology and social systems. Business processes deals only with optimizing the flow of production and goods.

The Enterprise Architecture Processes deals with implementing the structured approach to Enterprise Architecture and to keep maintaining and maturing it. It is quite right that the Enterprise Architecture program would have to be maintained in order to ensure its functional in the long run.

If you can’t measure it, you can’t manage it
– W. Edwards Deming.

Measuring

The chief architect would have to develop some KPIs in order to measure the processes that are a part of the Enterprise Architecture Program. In order to gain an overview of the processes it becomes a necessity to measure the processes before the initiatives have been initiated in the Enterprise Architecture Program. In the ideal situation the chief architect would have to investigate how the business performed before the Enterprise Architecture Program was initiated. The measurement should be used in order to improve the decision makers abilities to make the right decisions. In order to investigate if the proposed changes that have been implemented with the Enterprise Architecture Program have improved the situation for the enterprise, the chief architect would have to measure the “as-is” situation for the processes and “to-be” would have to be like. After the processes have been implemented the ideas would have to give the decision-makers an idea of or if the enterprise has moved closer to a desired state. For this key performance indicators can be a rather good tool for measuring.
The next section of the paper deals with the concept of key performance indicators.

Key Performance Indicators

In this paper a key performance indicator is defined as a number (simple indicator) indicating how a process or segment of an enterprise works. Key performance indicator is a simple tool that gives the various stakeholders data for interpretation and as such the KPI can’t stand alone it has to be accompanied with in-depth analysis documents.

Key performance indicators (KPIs) are suitable situations when the decision-makers would have to a quick overview of how the enterprise works (processes, segments and systems).

The KPIs would have enable the chief architect and the various other profiles that are a part of the Enterprise Architecture group with the appropriate data from the various systems.

KPIs have a significant factor within the concept of the Enterprise Architecture Program due to the various elements of the enterprise’s architecture works.

The KPI is needed is used as by the decision-makers in order to find out if there are any particular problems in the day to day management. Each of the KPIs can guide the decision-makers and it would be able to misguide the decision-makers. In order to find out if the KPI is adding the right value to the the overview that the decision-makers understand the KPI and how it should be used. Likewise does it become a necessity to deal with the KPI in order to understand if the KPI can be used in order to gain the overview in the in the enterprise. KPIs are by all means simplified and it becomes a necessity for the chief architect and for that matter the enterprise architects investigates if the KPI is too simplified and if the KPI can be implemented in the enterprise at hand.

Validating the KPIs

In order to validate the KPIs the chief architect would have to go into the situation of the various groups in the enterprise e.g. do the various actors understand what is to be measured and how they are measured. It is a necessity to challenge each of the KPIs and their stakeholders in order to find the best possible way to ensure that the KPIs measures contributes with value.

Five Things to do in KPI – EA Development

As promised I will hereby present five things that the chief architect could do in order to develop usable KPIs:

1) Identify what KPIs are relevant for the enterprise from a business point of view. Associate other KPIs when the business KPIs have been identified.

2) Probe the views of the enterprise’s decision-makers and those who would make use of the KPIs. Ensure that the business-stakeholders understands why the KPIs have been chosen and what they represent.

3) Articulate a draft for the KPIs and simulate how they impact the decision-makers and if they give the right kind of indication to the decision-makers. Ensure that you incorporate business-politics in your plan for implementing the KPIs.

4) Refine the KPIs and educate the various stakeholders and decision-makers in how the make use of the KPIs and when not to make use of them.

5) Build in the KPIs for the Enterprise Architecture program and ensure that the KPIs are visible in all the various forms of governance structure that are directly related to the Enterprise Architecture program.

Value of Enterprise Architecture

One of the fundamental questions of Enterprise Architecture is how to measure the value of the enterprise architecture program. Then again is Enterprise Architecture a program or a business function, I my opinion it can be both.

I have investigated how Enterprise Architecture contribute to the enterprise with value but also how the value can be measured. The investigation took me through four different paradigms and through the triangulation of the theory for each of the paradigms. The four paradigms I ended up investigating were functionalist paradigm, the interpretive paradigm, the radical humanist paradigm and the radical structuralist paradigm (Burrell & Morgan 1979 and Hirchheim & Klein 1989).

I found out that the various philosophers that can be identified within each of the paradigms have different views on what value really is and that lead to that I chose to focus on four philosophers (one from each of the paradigms).

The focus of the paper then turned to how a Chief Architect for any given Enterprise Architecture program can apply ideas presented in each of the paradigms to investigate a systemic approach as the Enterprise Architecture program.

This lead to an idea that the Chief Architect has to see the enterprise from several different angles and each of the angles needs to be taken into consideration when the investigation of value is taken processed.

In the paper I have made some examples of how each of the paradigms can be applied in the investigation and what questions should be asked when the Chief Architect designs his or her approach to collect information and evidence that support his or her claims on how the enterprise architecture creates value.

The core concept of the paper is that systemic programs, processes or functions needs to be investigated through several perspectives before anything can be said or concluded about them and each enterprise is unique and therefore should each attempt to investigate the EA program be customized for the particular enterprise.

I am of the opinion that the paper shows how the Enterprise Architecture program adds value both through monetary issues like increased profit and competitiveness but also through that other elements in the enterprise is taken care of e.g., the work environment and the ability to improve the platform for innovation etc.

These factors have to be taken care of to ensure that the enterprise in the long run will be able to achieve a competitive advantage by using enterprise architecture and for that matter Coherency Management. If the enterprise isn’t seen as an holistic entity and the various elements of the enterprise architecture program isn’t dealt with through different perspectives that aides the Chief Architect and the other stakeholders in the enterprise with understanding why it is important that they commit their effort and resources to the Enterprise Architecture program.

To conclude the this blog post then I will make use of a quotation by Aristotle.

“The whole is more than the sum of its parts” – Aristotle

Download the paper here or read it online at issuu.com.

 

Challenges of Enterprise Architecture: A Focus on the Transformation!

Barriers for Enterprise Architecture

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

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

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

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

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

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

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

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

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

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

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

Win Over The Opposition

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

  1. Individuals.

  2. Subunits.

  3. Organizations.

  4. Hierarchies.

  5. Organizations and Environments.

  6. Activities.

  7. Ideas.

  8. Intentions.

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

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

The Burning Platform?

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

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

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

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

Enterprise Architecture and Organizational Transformation

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

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

Projects Don’t Transform the Enterprise

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

Sources

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

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

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

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

Loosely Coupled Systems: A Reconceptulation.

Download the paper here.

Can IT Make a Competitive Difference: From a Coherency Architect’s Point of View.

The Introduction

Erik Brynjolfsson and Andrew McAfee has written the paper “Investing in the IT That Makes a Competitive Difference” that was published in 2007 in by Harvard Business Review. The paper deals with how enterprises deals with competition in the United States. McAfee & Brynjolfsson argues that most enterprises are in state of hard competition and it will increasingly become more difficult to deal with the competition. They claim that they have found a collaboration between the investment in IT and the way enterprises are able to manage competition.

Premises of the Paper

The first premise of investing in IT that makes a competitive advantage is that the authors claims that the enterprise can gain a competitive advantage through investing in IT. The authors are of the opinion, that they can conclude that investments in IT can create competitive advantages from statistics.
McAfee & Brynjolfsson concludes that many industries experience though (almost perfect) competition. This form of competition has lead to a focus on operational efficiency where IT has become a key factor to achieve operational efficiency. This argument can be supported by Ross & Weill and their research into achieving competitive advantages through IT governance and IT strategies. McAfee & Brynjolfsson works with data that suggest that IT intensive companies can generate more value through governing their IT assets and applying IT to re-build their business processes.

“The firm with the best processes will win in most of the all markets. At the same time, competitors will be able to strike back much more quickly: Instead of simply copying the first mover, they will introduce further IT-based innovations [...]”

- McAfee & Brynjolfsson (2007), p. 6.

The authors suggest that there are six elements of the successful IT – enabled process. The first element is that it cover a wide span, the process produce results immediately, the process is precise, the process is consistent, the process makes monitoring easy and last but not least the process has embedded enforceability.
The three companies that McAfee and Brynjolfsson put their attention is on Cisco Systems, Otis (the elevator company), and CVS.
What is the common key for the three companies is that they make use of enterprise wide systems to somehow revolutionize and optimize their business processes. I believe that Harmon entitled this “obliteration of processes” which suggests that the business processes could be re-invented along side the addition of Information Technology. This would lead to that the true benefits of Enterprise Architecture can be reached.
The two authors then discuss two different approaches to enabling the IT processes. The first one is the “Top Down approach” and the second approach is the “Bottom Up approach”.
According to McAfee & Brynjolfsson then the authors makes use of the CVS as a case. They claim that while the enterprise made use of highly centralized systems then some discontent employees (they where discontent with the service the IT department provided for their Macs). The employees created a Wikipedia where they wrote articles on how to overcome the obstacles they experienced when they made use of their macs in the enterprise.
The later example was an example of a decentralized service.

Criticism

The article suggests that IT savvy enterprises do often perform better than enterprises that aren’t. This is in line with the MIT approach to IT strategy that McAfee, Brynjolfsson, Ross & Weill are working with. The role of IT needs to be addressed compared to organizational culture, the employees and their capabilities and their focus on adding value for the enterprise.
The classical anti-thesis to the MIT approach is Carr’s view of investments in Information Technology. Carr is of the impression that the investment in IT often leads to quite an opposite of what the intention was. Carr argues that when enterprises invest in IT then they often over emphasize the cost reduction.
The reductions are then re-invested into lower prices which is easily matched by a company that are in an industry that experience perfect competition.
Carr suggests that enterprises should follow other enterprises when it comes to the usage and investment in IT, likewise should the enterprises focus on risk instead of potential (innovate when the risks are low) and last should the enterprise invest less in IT.

Competitive Advantage

When it comes to competitive advantage then Porter (1998) suggests that the enterprise can’t achieve competitive advantages through focusing on operational efficiency. The enterprise has to focus on innovation to enable positioning the products the enterprise produces in a different way. Through positioning then competitive advantage should be enabled.
Likewise does Porter (1998) suggest that the enterprise has to be enable several processes to enable a sustainable competitive advantage.
Carr (2004) argues that Information Technology only leads to short term competitive advantages and is therefore not desirable to invest in. Instead should the enterprise focus its attention to work with several non-IT related competencies and eventually apply IT support them or re-invent them.
Patrick Turner (2010) suggests that IT needs a strong governance to become an enabler.

“When giving a high profile IT project to a junior project manager is like giving a teenager a rather powerful racing car, he will eventually crash it into a tree.”

- Patrick Turner

Ross & Weill (2009) suggests that Information Technology is only good for two specific things. Standardization that deals with the standardization of data and then integration which deals with information sharing through the entire process.

Reflection

McAfee & Brynjolfsson suggests that IT can make a strategic advantage (competitive advantage), if the enterprise understands to invest in the right IT and re-thinking its processes(the IT that makes a competitive advantage). However many other theoreticians suggest that operational efficiency which investments in IT can be identified as isn’t a strategy or for that matter a strategic enabler. The enterprise needs to invest in business processes and re-invent the processes when it makes sense for the enterprise to do so. McAfee & Brynjolfsson suggests that the schumpeterian competition that many enterprises have experienced in the U.S.
IT might become an enabler for most enterprises if they re-think their business processes by adding IT when it makes sense. McAfee & Brynjolfsson suggests that IT can be an innovation enabler since the enterprise IT can give technical assistance to support the employees.

Appendix

Carr, N.G., 2004. Does IT Matter?: Information Technology and the Corrosion of Competitive Advantage, Harvard Business School Press.
McAfee & Brynjolfsson, 2007, Harvard Business Review.
Porter, M.E., On Competition, Harvard Business Review, Boston, 1998, p.40-42.
Turner, P., 2010, On IT strategies, Enterprise Architecture Summer Camp.
Weill, P. & Ross, J., 2009. IT Savvy: What Top Executives Must Know to Go from Pain to Gain, Harvard Business School Press.

Download the paper here.

Economic Perspectives of Enterprise Architecture: Four perspectives the Coherency Architect Should be Aware of!

Perspectives and the Extended Enterprise

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

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

Business Efficiency

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

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

Business Innovation

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

Technology Efficiency

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

Technology Enabling

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

The Enterprise Architecture Value Model

The Enterprise Architecture Value Model.

Conclusion

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

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

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

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.