simon.townson

6 Posts

BACKGROUND

In the first and second parts of this blog, I focused on why it is so difficult to define the value of Enterprise Architecture.

The Value of Enterprise Architecture - Part 1- Introducing the problem

The Value of Enterprise Architecture - Part 2 - Why is it so difficult to define?

In the third part, I summarized the main benefits of EA to show where to start to look to define that value.

The Value of Enterprise Architecture - Part 3 - Summarising the key benefitsThe Value of Enterprise Architecture - Part 1- Introducing the problem

In the fourth and fifth part, I showed how to construct a model to start to observe and measure that value for architecture stakeholders.

The Value of Enterprise Architecture - Part 4 - Applying Value Management

The Value of Enterprise Architecture - Part 5 - Example value models

This is the final concluding part of my blog series on EA value.

 

SO WHAT NOW?

From reviewing the literature and work available, it is clear there is no silver bullet or magic solution to defining EA value, and no stepwise guide or method to follow.

Most experts agree that EA does contribute important benefits, that these increase the more mature an organization’s approach to EA is, and that it is relatively straightforward to identify anecdotal examples. However, there is no clear method for defining that value, and then measuring it.

In order to solve that problem, one would need to define a series of standardized measures, and analyze these over time, to make more concrete correlations. The process to rigorously collect the required structured data across many organizations and industry types has not yet been defined. If this were to be achieved, and the data analyzed, one could then make clearer statements and conclusions on the topic.

If organisations are to develop “mature enterprise architecture..... demonstrating that business strategy will be pervasively understood and supported within EA and across business and IT”, (Ref. 1), and one of top challenges identified for EAs is to be addressed (Ref. 2), it is clear that the topic of value management is going to be key in 2011-12.

Value Management typically follows four key steps:

 

  •  Value Identification - where we identify the benefits to be gained, baseline the current state, and develop conservative estimates of what we can achieve ; guided by architecture stakeholders and their priorities as it will be impossible to measure everything;

 

  • Plan Benefits Realization – where we design and identify effective measures, develop a value model, build a measurement process and get agreement from those stakeholders;

 

  • Execute Realization Plan and Evaluate Results – where we review progress against the plan and take necessary corrective actions, and ensure we communicate the results to those stakeholders;

 

  • Establish Potential for Further Improvements – by identifying additional changes or investment needed.

 

It is clear Enterprise Architects in future will need to be:

 

  • Much clearer on what they are delivering and be able to measure this; although demonstrating what is going on does not always demonstrate overt value, it does define what is happening. This awareness of what is happening is key if people are to buy into the results of EA;

 

  • Much clearer on the organization’s business goals and the required organizational performance to deliver these, and be able to measure these; otherwise how can they ever hope to relate their activities to real business value?

 

  • Be able to construct and explain a value model of the above to their stakeholders; otherwise they will not be able to spell out the desired value of EA via the explicit benefits gained from it.

 

As part of value identification, it is typical to create a business case. A similar approach can be adopted for EA where one can define the tangible and intangible benefits can be gained against the costs of setting up and running an EA practice in an organization.

Figure 1 below shows an example business case structure, based on the some of the example benefits identified in this paper. This addresses both sides of the EA equation; namely those related to business value and those related to technical value. The technical part mostly addresses the TCO and TCI side of potential benefits. The business value side addresses the contribution that EA can have on the business objectives of an organization (Ref.3).

 

Business Case

Figure 1 – Structuring EA Benefits into a Business Case

 

In this way, Enterprise Architects will be more able to gain the support and resources they need to support their organization effectively. Successful EA programs are ones that are visible to senior executives and provide evidence of their business contribution based on solid metrics, scorecards and reporting systems. These will demonstrate the impact of EA on both IT and Business investments and how such an approach can reduce cost and complexity, mitigate risk, and enable new opportunities to be exploited.

 

 REFERENCES

  1. Enterprise Architecture Hype Cycle (2010) Gartner.http://www.gartner.com/it/page.jsp?id=1417513
  2. ASUG Enterprise Architecture Best Practices Survey – (October 2010) Aggregate Findings Report. ASUG.  http://www.asug.com/EventsCalendar/EventDetails/tabid/150/EventID/2024/Default.aspx
  3. Von Rosing and Van den Dungen (2011) - SAP Lead Enterprise Architect Development (LEAD) Program.

BACKGROUND

This is the fifth in a six-part blog post that address one of the most important topics facing Enterprise Architects; namely how to justify the value of Enterprise Architecture (EA).

INTRODUCTION

In the fourth blog in this series, we explored how to use a value tree model, using the metamodels of TOGAF and Value Management to explain the value of a new investment. In this blog, we will examine how to use a similar technique to model EA Value.

Van Steenbergen and Brinkkemper (2008) used this same concept effectively using an “Architecture Effectiveness Model”, mapping the deliverables of an enterprise architecture practice, to the business goals of an organisation. Three examples are presented where organisations have defined such a value model(Ref. 1).

Figure 1 below shows such a model showing on the left the enterprise architecture practice, and on the right the business goal of the organisation. Organisational performance steps or “changes” in between link the two. The model can be used effectively by Enterprise Architects to show the intended contribution of architecture to the business goals by way of a number of intermediate steps.

Figure 1 – General structure of an Architecture Effectiveness Model (Van Steenbergen and Brinkkemper 2008)

In the three examples presented where they applied the model, although no direct relationship between architectural results and business goal effects was observed, all showed architecture results linked to business goals via organizational performance effects. 

Using the benefits of Enterprise Architecture discussed in Part 2 of this blog earlier, we can draw a strawman Architecture Effectiveness Model that can be used by Enterprise Architects when deciding what value to measure and what value to observe for their particular organisation. This is shown in Figure 2 below.

Figure 2 – Strawman Architecture Effectiveness Model

 

Van Steenbergen and Brinkkemper (2008) noted in their study that by adding Process Performance Indicators (PPIs) to the effects, the actual contribution of an architecture practice over time could be measured. (Ref. 1). Stutz (2010) provides an example, as shown in Figure 3 below for a Swiss banking solutions provider where a similar model has been constructed including derived measures and metrics for enterprise architecture traceability. (Ref. 2).

Figure 3 – Case study – application of Process Performance Indicators for EA processes

Using the same technique, we can add example Process Performance Indicators to the strawman model from Figure 2. This is shown below in Figure 4. These can be used to target and track areas of performance improvement, and to provide evidence for the value that EA is providing.

Figure 4 – Strawman Architecture Effectiveness Model (including Process Performance Indicators)

 REFERENCES

  1. Van Steenbergen and Brinkkemper (2008) Modelling the contribution of enterprise architecture practice to the achievement of business goals. Proceedings of the 17th international conference on Information Systems Development (2008) 
  2. Stutz (2010) -How to Measure the Value of Enterprise Architectures – Deutschsprachige SAP-Anwendergruppe (DSAG). Zurich

BACKGROUND

This is the fourth in a six-part blog post that address one of the most important topics facing Enterprise Architects; namely how to justify the value of Enterprise Architecture (EA).

In this part, I will describe how to construct a model to observe and measure that value for architecture stakeholders.

 

APPLYING VALUE MANAGEMENT TO EA

Organisations rarely define or understand the relationship between the products of Enterprise Architecture and their defined business goals.

Stutz (2010) (Ref.1) summarised one of the difficulties facing those aiming to quantify the value of EA as “the distance of EA from a company’s value chain”; i.e. if the aim or objective of an organization is to sell more of particular product it makes, EA should provide the guidelines and principles advising how the process is best supported by implementing CRM; but it is difficult to define how much more product the company will sell as a result of that.

This is a common problem in any normal value lifecycle management exercise.  Benefits Management and Value Modelling Techniques have been used for some time already to help organisations map objectives to deliverables and metrics.  Value lifecycle management takes an outline business case down to the next level, to map benefits to the required process changes and the specific solution design attributes required.

Swanton (2010)(Ref.2) provides the example of SAP which has made a major investment during the past six years in helping companies develop rigorous business cases, and understanding the process changes needed to generate value, and the measurements to ensure that it is achieved. These tools and services are wrapped in methodologies for value management and implementation, with the goal of getting customers to take the necessary steps to ensure that their projects deliver benefits.

When creating such a Value Model it is important to understand the metamodel or ‘object definitions’ of what is being mapped. If one can use existing standard industry metamodels, this will greatly improve the desired understanding of the model as the objects being mapped will be commonly understood. In Enterprise Architecture terms, the TOGAF 9 metamodel is the nearest the example of a common architecture metamodel. (Ref. 3)

Van den Dungen and Visser (2010) show how one can take the existing metamodels of TOGAF, and couple them to the metamodels of value management and performance management, in order to map the value of a key business change. (Ref. 4 and 5)

 

EXAMPLES OF MODELLING VALUE 

A strawman example is shown below in Figure 1, using typical objects from a combined TOGAF9 metamodel and value management metamodel to map the value of a Transformation Programme to its architecture components:

Figure 1 – Mapping the Value of a Transformation Programme

Further metamodel entities could, of course, be added such as Measures or Business Services.

Taking this a step forward, one can use the same technique, to demonstrate the value of an enterprise architecture practice. The fifth blog in this series will further explore this.

REFERENCES

  1. Stutz (2010) -How to Measure the Value of Enterprise Architectures – Deutschsprachige SAP-Anwendergruppe (DSAG). Zurich
  2. Swanton (2010) - Vendor Focus for SAP: SAP Value Management Services - Gartner Research. Available from  http://download.sap.com/download.epd?context=A342CC38D467FE6B3B04DE78043E324DCB8D29FCD516FE6C54888827A287EA1139B7A2C6FB9419CF5C8B0638A7075C4832D620B0492CF27C
  3. The Open Group Architecture Framework. (2009) Version 9. The Open Group.
  4. Von Rosing (2010) - How to apply Performance Management & Value Management to TOGAF Meta Model A and B -  Available from http://www.openroundtable.org/http://www.openroundtable.org
  5. Van den Dungen and Visser (2010) Using the TOGAF 9 Meta Model to Measure Value in an Enterprise Architecture. Proceedings of The Open Group Conference Amsterdam, 18 – 22 October, 2010. Available from http://www.openroundtable.org

BACKGROUND

This is the third part in a six-part blog post that address one of the most important topics facing Enterprise Architects; namely how to justify the value of Enterprise Architecture (EA).

In this part, I will summarize the main benefits of EA to show where to look to define that value.

 

THE BENEFITS OF ENTERPRISE ARCHITECTURE

The potential benefits of Enterprise Architecture are well documented.

Van Steenbergen and Brinkkemper (2008), Ross et al. (2006), Rosser (2006), and Allega (2005) all summarise a range of benefits of EA to varying degrees. (Ref. 1,2,3,4, and 5).

All cite increased benefits through increased EA maturity as exemplified in Figure 1 below.

Figure 1 – Benefits correlated to EA Maturity (Copyright MIT Sloan Center 2005, Ref 2.)

 

Potential benefits can be summarized as follows:

 

  • Reducing IT costs by consolidating, standardizing and integrating corporate information systems

A clear understanding of AS-IS and TO-BE architecture, and the migration plan of how to progress from one state to the other means the implementation of duplicate/overlapping systems can be avoided or managed out, and acquisition and integration can be accomplished more effectively.

To solve duplication and overlap, an organization needs a comprehensive view of its applications, software, and infrastructure and their interrelatedness. By understanding what it has, what it needs, and what is redundant, an organization can tailor its investment to the areas of most need, and identify reuse more frequently.

If development standards and guidelines are in place that define the boundaries of what it is possible for the application developer or infrastructure builder to do, and in effect describe how to behave when creating new capabilities, this can increase the efficiency of development projects.

EA, through its focus on traceability and consistency, reveals duplicate and overlapping processes, services, data hardware and software.  By having fewer, as opposed to many, means higher unit volumes and a better ability to support those products, and plan timely transitions that respond both to the business need and the technology progress rate.

Familiarity with standard components also provides repeatable experience on performance, risk and maintenance. Sound choices enable an ability to monitor and track the system in ways that help deliver better client service. Less effort is then needed to integrate, accommodate or link different systems. Installations and upgrades will be simplified, with a reduced need to replace ineffective systems.

 

  • Increasing IT responsiveness by using standard, pre-designed components

The development of enterprise architecture enables earlier preparation for new technologies, smarter timing of projects, and the reuse of development best practices, standard designs and components.

The reuse of existing services, components and infrastructure, and the application of standards, reference models and patterns, can reduce design and development time and reduce support requirements.  This mean enhancements and scale-ups can be delivered faster, infrastructure capacity can be increased rapidly, and the enhanced platform can then better accommodate innovations and advances.

 

  • Providing Better Access to Information Across Applications and Improved Interoperability

Enterprise application integration architecture enables more effective data sharing across an organisation and beyond it to trading partners.

By being aware of what applications exist, what data they need and where it is stored, a pro-active plan to ensure it is in the right place at the right time can be established.

Consistency in integration and interfaces can also improve access for external suppliers, customers and partners to the data they require, enabling them to respond faster to the organisation they serve.

 

  • Less IT Risk

Developing a TO-BE architecture and a managed migration plan will mean that the IT function will be prepared to deliver new capabilities in a timely manner, avoiding unexpected surprises and demands.

In short, a more rigorous architecture-led planning process can ensure the organization plans the introduction of new technologies and the timing of projects to its best advantage, rather than being forced into something due to an unforeseen business demand or technology life issue.

This will enable efficient transitions to new capabilities.  Capacity planning and monitoring will then improve as system retirements and upgrades can be planned in advance. 

A clear two to three year plan for the enterprise is a typical product on EA. Using this, the organization can forecast the required budget, make realistic commitments, and plan in good time for IT changes. An organization without a strategic plan is often consumed day-to-day with the next “emergency”.

While some may say “what’s wrong with that? Everyone is focused on what matters” …….the situation is not healthy for IT or for the business.  With focus on the short term, and without adequate time to plan, each new solution is at risk for becoming another silo. Increasingly, more time is spent trying to make each new solution “fit in” than on the solution itself.  Capacity planning and applications management becomes very difficult in such environments, which in turn causes further unplanned capacity and system upgrades. This causes a spinoff downward spiral of further project overruns. 

 

  • Improved IT Performance and Job Satisfaction

Through better architectural understanding, better comprehension of the solutions being implemented is achieved, leading to more effective design review and testing processes being established.

More-cohesive and shared perspectives are created, and common goals are understood, leading to improved IT performance and job satisfaction.

 

   

  • Reducing risk and fulfil regulation requirements by cleaning up existing information systems.

EA provides clear traceability between business processes, data, user roles, applications and infrastructure. This traceability makes it easier to fulfill legal and compliance regulations.

A reliable architecture model aids consistency and manageability, and an organization has a much better chance of implementing corporate business standards and planning and managing to those standards on an ongoing basis.  An example of the measures and metrics that can be used to demonstrate this is discussed later.

If an organization does not have visibility of its business process, information and how this relates to IT infrastructure, information silos and inconsistent systems will result. This symptom has been exacerbated in recent years by mergers and acquisitions. These have added to the complexity of an organization’s IT estate resulting in duplicate processes.

When changes occur that cause unplanned downtime or other problems manifest themselves such as fraud or regulatory challenges, and no one understands who did it, how it happened, or why it happened, then the odds are high that it will happen again.

The Business and the IT environment are in a constant state of change. A change two or three cycles in the past may not have an impact until the worse possible moment sometime in the future, cascading across the enterprise.

If an organization does not have a clear model of its business, application and technical architecture and the dependencies and interrelatedness, and installed processes and standards to manage that environment, then there will be no traceability or accountability.

EA identifies the processes, applications, and data that need to be consistent if consistent business decisions are to be made. EA also identifies opportunities for integration and reuse that prevent the development of inconsistent processes and information.

 

  • Better traceability of cost

EA provides greater understanding of the interrelated nature of business, application, and infrastructure assets. This enables greater understanding of how the architecture is structured, and enables more accurate cross-charging or service billing. It enables high cost areas of the IT estate to be identified more accurately, and a fairer cost model to be developed. 

Most organizations can identify the individual cost of an asset. However, many cannot understand the cost of an asset as it relates within the organization with all its interrelatedness and interdependencies.  IT departments can typically identify that a server costs so much, but they cannot identify what organizations that server supports, what the maintenances costs are, or what critical business applications are using that server. In many cases, organizations don’t have a mechanism to understand holistically all the costs associated with those related assets.

 

  • Enabling strategic business goals via better operational excellence, more customer intimacy, greater product leadership or more strategic agility.

Without an understanding of business, application and technical architecture, a business doesn’t know what it is going to take to align and to implement IT to execute its business strategy. In essence, it doesn’t know what it has or doesn’t have.

This ensures when planning programmes and projects, that effort is targeted onto those aspects that really matter, and this adds to the strength of the enterprise, rather than diluting or duplicating something it already has, or investing in something that is not a priority.

The topic of Business-IT alignment is nothing new and it is a commonly agreed goal that IT investment is targeted on the key business goals and performance. Value Management and Portfolio Management techniques also address this issue. EA specially focuses on “how” an organization will build a business or IT capability to meet that its business goal, rather than “why” or how much proportion of the portfolio budget it needs.

Without EA, organizations frequently approve projects that, from all outward appearance, are not associated with any business strategy.  Organizational clout, supposedly self-funding business cases, and compartmentalized decision processes drive these behaviors. If you cannot easily identify the strategy supporting the funding decision, then there probably isn’t one.

If IT can introduce new technologies and functionalities faster to key business areas, this ensures the organization can respond faster to competitive pressures, and deploy differentiating capabilities faster. These areas are most likely to be spotted when business and IT staff collaborate closely in the EA process because a more rigorous analysis of business process-application-technology interrelationships will have occurred than would otherwise have been the case.  The outcome is that technology is ready when it is needed, transitions are smoother, and unnecessary change is minimized.

Similarly, if the organization can free up more cash it can allocate that to alternate targets, such as innovation. Assuming that the innovation results will enhance the organization’s competiveness then this is another good example of an indirect value contribution of EA.

Common symptoms in organizations without a robust EA are emergency projects and high-than-average project overruns. When new, important strategic projects are created, without a comprehensive understanding of the current state, the desired state, or the interrelationships of processes, people, and technology affected by that project; unforeseen problems will occur resulting in project overruns.

The business goals and objectives that can achieved quicker depend on the organization of course; typically they could involve:

  • Lower business operating cost
  • Faster time to market
  • Faster production cycle time
  • Faster response to service requests
  • Better customer relations through easier, more-convenient information access
  • Less consumption of working capital
  • Being more advanced and innovative in the marketplace
  • Superior collaboration — internally and externally
  • Better facilitation of mergers and acquisitions or divestitures
  • More agility to enter new businesses
  • Richer choices or service options for the customer to select

If we need a topical example of the problems and opportunities that can be identified, we can take the rental car industry. Currently, the rental car industry is undergoing a major upheaval as new rental car companies enter the market in many countries. These companies are offering a new competitive service where one can rent a car for specific hours and the car is parked at fixed slots distributed in the town.  The classic rental car companies now have a competitive agility problem, since their IT processes and systems are often not flexible enough to deal with hourly rentals. However, by analyzing the existing capabilities they offer, this might reveal a key opportunity for the classic rental company; their systems are wide enough in scope to be able to manage the movement of vehicles between urban areas (since this is what they already do); the classic company can then offer that service to the new companies that currently cannot do this.

EA recognises that there is no single perfect architecture for everything – and an advantage of one enterprise architecture (redundancy, robustness) might be a disadvantage in another dimension (fast and easy to change and adopt). Similarly, not all business processes are equally important. By defining a prioritised set of business objectives and linking these to the architecture of the organisation, one can then identify which capabilities and systems to invest in or change.

For example, a HR system of an average company can afford to be out-of-action for a few hours a day, a very high level of redundancy is not required. However, if a company’s key business is in the area of Professional Services, or is a service/outsourcing provider of HR processes for other companies, the HR system is a key system.

The point is not so much which goals benefit from EA, but that EA means that IT can target the goals that matter to the business more effectively, and proactively identify the possibility of new goals or innovative opportunities through the more intense dialogue that is created.

 

SUMMARY

In summary, EA can bring benefit to IT by identifying unnecessary duplication and cost, reducing the level of complexity involved, and through effective provision of strategic building blocks, reducing the time it takes to respond to new business requirements, and reducing the risk involved. Meanwhile, the business can then use IT to improve its job performance, by employing IT specifically where it can contribute directly to the strategy the business unit is pursuing, and by shaping and instigating of visionary investments or new opportunities.

In Part 2 of this blog (The Value of Enterprise Architecture - Part 2 - Why is it so difficult to define?), we recommended that we should look to measure and observe the impact of EA introduction if we are to demonstrate its value, just like any business would if they decided to do something innovative. In Part 4, we will look at where to start in how to decide what to measure and what to observe.

 

REFERENCES

  1. Van Steenbergen and Brinkkemper (2008) Modelling the contribution of enterprise architecture practice to the achievement of business goals. Proceedings of the 17th international conference on Information Systems Development (2008)
  2. Ross, et al. (2006). Enterprise architecture: Creating a foundation for business execution. Harvard Business School Press
  3. Allega (2005) - Enterprise Architecture Will Never Realize a Return on Investment. Gartner Research
  4. Rosser (2006) - Measuring the Value of Enterprise Architecture: Value Context. Gartner Research
  5. Rosser (2006) - Measuring the Value of Enterprise Architecture: Metrics and ROI. Gartner Research

 

BACKGROUND

This is the second in a six-part blog post that address one of the most important topics facing Enterprise Architects; namely how to justify the value of Enterprise Architecture (EA).

The first part of the blog is published here. The Value of Enterprise Architecture - Part 1- Introducing the problem

In this part, I will focus on why it is so difficult to define such value.

 

THE $64,000 QUESTION...SO WHY IS IT SO DIFFICULT TO DEFINE?

 

Why is a lack of business case or value proposition such a problem for Enterprise Architects if surveys such as the ASUG/SAP EA Best Practices Survey (which I discussed in my first blog in this series) (Ref.1)  present clear examples?

The problem is anecdotal evidence of this is not new ; there are many examples of industry studies showing the potential value that EA delivers, largely from similar anonymised surveys and studies:

 

  • Ross (2004) found from a study of 103 firms that were most effective in achieving strategic objectives through EA initiatives had a greater relative profitability to their competitors. (Ref 2.)

 

  • Allega (2005) found empirical evidence from a 2001 survey of CIOs, which demonstrated the average cost per end user for IT functions with EA as $12,736, while without EA it was $27,709, showing that architecture best practice can reduce IT expenditure by more than 30 percent. (Ref 3.)

 

  • Recent research from EA Executive Board (2010) has found that increased EA Maturity can significantly impact project delivery performance demonstrating percentage improvements of more than 40% in on-time and on-budget performance. (Ref 4.)

 

Indeed anecdotal evidence can often easily be gathered within an organisation from its own architects’ experiences to show examples of the value of EA (Rosser 2006) (Ref 5. and 6.).

 

In the author’s own experience, the value of EA has often been justified based on cost avoidance of software procurement due to identification of overlapping functional scope of two or more proposed projects in an organisation, or the potential cost savings of IT support by standardising on one solution. The flipside of cost and risk avoidance of course must also be considered. Enterprise Architecture often also plays the role of a key shaper and instigator of visionary investments. Its structured approach can ensure that companies more effectively discover new opportunities by linking technology innovation to their business objectives. Enterprise Architects when citing anecdotal evidence should concentrate on both views.

 

Anecdotal examples are an important source of information to show that EA does achieve what it aims to do, and is contributing real value, but a more formal approach is needed to demonstrate value if we are to solve the common problem of a lack of business or value proposition.

This challenge is not new to the Business or IT world. It is generally alot easier to identify costs of doing something than the value delivered by it.

  

HOW WE PUT A VALUE ON CHANGE

 

In any “change”, we either decide to do new things, do the things we do already better, or stop doing things we are already doing. The value of doing these changes can be identified as:

 

  • Financial – i.e. by applying a cost/price or other valid financial formula to a quantifiable benefit, a financial value can be calculated of implementing such change;

 

  • Quantifiable – i.e. sufficient evidence exists to forecast how much improvement/value should result from the change; 

 

  • Measurable – i.e. the aspect of performance we wish to change is currently being measured but it is not possible to estimate by how much performance will improve when the changes are complete ; nevertheless we can track it;

 

  • Observable – i.e. by use of agreed criteria, we can decide, based on experience and judgment, to what extent the benefit has been realized.

The degree of explicitness of value we can define depends on what we change. For example, if we decide to stop doing something we already do (e.g. sending out paper invoices), or improve what we already do (e.g. process payments quicker); we should be able to explicitly define the financial value involved as the knowledge of the costs/value will be much more intimately known within an organisation.  (Ward and Daniel, 2006) (Ref 7.)

However, if we decide to do something new we haven’t done before (e.g. enter a new market, deliver a new product through a totally new channel) we are unlikely to have enough experience or knowledge to define the value to be created from that change, and little financial evidence to produce quantifiable benefits. (See Figure 1 below).

Figure 1: Explicitness of IT Value (adapted from Ward and Daniel 2006)

 

In the case of EA as a method of practice, we should be able to:

 

  • Measure the implications of EA using existing or new measurement techniques (if we measure the right things);

 

  • Observe the implications of EA (if we know the sorts of things to look out for).

EA is no different to any business change; the trouble is for many organisations it is a new support process where it is difficult, almost impossible, to quantify the value generated.

Allega (2005) concludes that the benefits of EA are almost impossible to define to a level of financial explicitness (Ref 3.).  Return-on-investment (ROI) calculations require the financial outcomes expected from a project in the form of additional revenue or cost savings to be forecast and compared to the costs of undertaking the project. Techniques used to determine the ROI of individual projects, are not valid when applied to EA, because the benefits cannot often not be allocated to EA itself. The use of EA deliverables are not applied, and the benefits are not visible from the short-term payback requirements of such techniques.

Furthermore, although applying EA achieves qualitative benefits (these will be discussed in Part 3 of my blog), any quantification of those results also depends on the effective application of other key techniques, which also would claim similar value.  For example, an EA may create a future-state roadmap, or architecture guideline, but if it is not used in creating a new service (because the organisation lacks say effective IT Service Planning); then the value of EA will be severely limited.

 

THE REAL PROBLEM

It is clear that Enterprise Architecture Best Practice provides a clear framework, principles, and method to deliver a design or roadmap or strategic advice; however, it will not be the EA steps that lead, for example, to lower IT spend.

 

It is the realized and implemented design, that will lead to that lower IT spend. For example, EA may contribute that a specific SAP Business Suite best practice is most appropriate for an organization; however it is the running of that SAP Business Suite process that delivers the efficiency improvement, not the EA.

 

EA is a key competency, but a support process, analogous to other support processes e.g. strategic procurement. That support process ensures a proven way of working that then generates more efficient downstream results.

Stutz (2010) (Ref.8) summarises the difficulties facing those aiming to quantify the value of EA as:

 

  • The distance of EA from a company’s value chain; i.e. if the aim or objective of an organisation is to sell more of particular product it makes, EA should provide the guidelines and principles advising how the process is best supported by implementing CRM; but it is difficult to define how much more product the company will sell as a result of that.

 

  • The indirect and diluted effect of the enterprise architecture activities on company’s activities; i.e. although EA delivers the structured framework, and method that enables more effective IT Service Planning or Enterprise Portfolio Management, it is difficult to isolate that specific effect.

 

  • The time-lag between the initiated enterprise architecture activity and its generated benefits; i.e. the value of creating a corporate storage architecture roadmap now cannot be fully defined, as it is difficult to predict the cost and benefit of a project in two years time that would use that architecture or account for it. Most organisations’ financial processes focus on short-term payback and lack the benefits management techniques to track such benefits over many years.

However, just because an ROI cannot be demonstrated, this does not mean we should not try to identify the value of EA, or spell out the benefits gained from it. Indeed, the value from EA must be defined, and be convincing if Enterprise Architects are to receive any form of consistent support for their efforts, and for people to change their current ways of working. Other methods of measurement to Financial ROI must therefore be employed to define it.

Ward and Daniel (2006) (Ref.8) identify that it is not always possible or desirable to justify projects solely on the basis of financial measures, such as ROI.  If this was taken to extreme and we justified and measured all business change according to financial measures ;  the level of innovation or new processes/systems in an organisation would be squeezed out as such initiatives would be very difficult to cost justify as there would be no existing cost information available. Doing new things would simply not be financially justifiable or quantifiable. On the flip-side, projects with the largest or fastest financial return would take the lion’s share of an organisation’s investment.

So in short, given that EA for many organisations is “something new we must do”, we should look to measure and observe the impact of its introduction if we are to demonstrate its contribution, just like any business would if they decided to do something innovative. Typically the first step in this process is to define Process Performance Indicators (PPI) so that we can start to measure this contribution; this is discussed in later blogs.

In Part 3 of this blog, we will identify the different types of benefits gained through the application of Enterprise Architecture that can be used as a starting point to identify its value within an organisation. This will help Enterprise Architects focus on what to measure and what to observe.

 

REFERENCES

 

  1. ASUG Enterprise Architecture Best Practices Survey – October 2010 - Aggregate Findings Report. ASUG.
  2. Ross (2004) - Generating Strategic Benefits from Enterprise Architecture. Research Briefing Volume IV Number 3A. CISR Sloan School of Management – MIT.
  3. Allega (2005) - Enterprise Architecture Will Never Realize a Return on Investment. Gartner Research
  4. EA Executive Council (2010) “Create Impact in the First 100 Days-Executive Summary”. Available from  https://www.eaec.executiveboard.com/Public/ExecutiveSummary/Documents/First-100-Days_ExecSumm.pdf
  5. Rosser (2006) - Measuring the Value of Enterprise Architecture: Value Context. Gartner Research
  6. Rosser (2006) - Measuring the Value of Enterprise Architecture: Metrics and ROI. Gartner Research
  7. Stutz (2010) -How to Measure the Value of Enterprise Architectures – Deutschsprachige SAP-Anwendergruppe (DSAG). Zurich
  8. Ward and Daniel (2006) - Benefits Management: Delivering Value from IS and IT Investments - John Wiley & Sons.

BACKGROUND

 

This blog series addresses one of the most important topics facing Enterprise Architects; namely how to justify the value of Enterprise Architecture (EA).

Increasingly, many organizations are value-driven; their business models, objectives and primary processes are designed to achieve maximum value.

Enterprise Architecture is a capability and competency that contributes benefits and opportunities as a key support process.

It is common for such business support processes to define their value proposition and offer this as a service to their internal consumers.

The objective of this blog series is to help Enterprise Architects who want to be able to define the benefits of their activities to their stakeholders, and to help IT Executives understand how Enterprise Architecture contributes to the primary value-adding objectives and processes.

In this way, Enterprise Architects will be more able to define the benefits they provide more effectively to their stakeholders and gain the support and resources they need to support their organization, and IT Executives can understand the contribution that EA delivers.

 

INTRODUCTION

 

There is no denying the popularity of Enterprise Architecture today as a global IT core competency:

 

  •  As of January 2011, there were over 14,000 certified individuals of The Open Group Architecture Framework (TOGAF) in the world today (Ref 1.)

 

  • In August 2010, in its Hype Cycle for EA, Gartner found that 73 percent of surveyed clients aspired to support "mature enterprise architecture" during the next three to five years, demonstrating that business strategy will be pervasively understood and supported within EA and across business and IT. (Ref 2.)

 

  • When SAP launched its own EA training courses in 2007, by 2009 they rapidly became the second most popular in the training curriculum ; from 2009 to 2010, participants in classroom training grew by over 25%, and EA-related certifications grew by 40% ( Ref 3.)

 

  • EA Tool vendors are also experiencing this popularity, most EA tool vendors reported continued revenue growth in 2009 and into 2010, despite the recession, with annual revenue ranges typically between $10 million and $25 million (Ref. 4)

What remains as a key issue for Enterprise Architects is defining and communicating the value of Enterprise Architecture.

 

In September 2010, ASUG/SAP published the findings from the EA Best Practices Survey conducted in 2009-2010.  (Ref. 5)

 

Some of the top challenges identified in the survey are not new to Enterprise Architects and the first one we can immediately recognize:

 

  •  “Lack of business case and value proposition of EA to sell it to IT and business community”

 

  • "Lack of architecture governance and execution”

 

  • “Lack of business buy-in to support aligning business and IT strategy and architecture”

 

  • “Lack of understanding and adoption of EA best practices”

The study however also concludes that these same companies, who adopted EA Best Practices, also experienced a series of benefits:

 

  • Companies with higher overall Enterprise Architecture maturity have on an average 64% lower IT Spend as % of Revenue as compared to companies with lower maturity; see Figure 1 below;

Figure 1 - EA Maturity versus Average IT Cost

 

  • Companies with higher overall Enterprise Architecture maturity have on an average 36% lesser Emergency Projects (as a % of Total Projects) and 36% lower Number of Interfaces per Billion Revenue ; see Figures 2 and 3 below ;

Figure 2 - EA Maturity versus Emergency Projects

Figure 3 - EA Maturity versus Number of Interfaces

 

  • Companies with Higher Maturity in Enterprise Architecture Processes category spend on an average 1.5 times more of their IT budget on Innovation as compared to companies with lower maturity. (See Figure 4. below)

Figure 4 - EA Maturity versus Innovation Cost Share

 

This is the first in a six-part blog post that address one of the most important topics facing Enterprise Architects; namely how to justify the value of Enterprise Architecture (EA).

In the next part, I will focus on why it is so difficult to define such value.

In the third part, I will summarize the main benefits of EA to show where to look to define that value.

In the fourth part, I will describe how to construct a model to observe and measure that value for architecture stakeholders.

In the fifth part, I will look at two worked examples.

In the sixth part, I will summarize and conclude what this means for Enterprise Architects.

 

REFERENCES

 

  1. The Open Group TOGAF Directory of Certified People (January 2011)http://www.opengroup.org/togaf9/cert/cert_archlist-short.tpl
  2. Enterprise Architecture Hype Cycle (2010) Gartner.http://www.gartner.com/it/page.jsp?id=1417513
  3. Kirby (2009) - SAP EAF and TOGAF 9 - History, differences, similarities, and recommendations for the future. The Open Group Conference. Proceedings of The Open Group Conference London, 2010.
  4. Wilson and Short (2010) Magic Quadrant for Enterprise Architecture Tools – October 2010 – Gartner RAS Core Research Note.
  5. ASUG Enterprise Architecture Best Practices Survey – (October 2010) Aggregate Findings Report. ASUG.  http://www.asug.com/EventsCalendar/EventDetails/tabid/150/EventID/2024/Default.aspx

Actions

Filter Blog