Generally speaking, IT departments have all sorts of criteria to justify projects and measure their performance. They use measurements and metrics, KPIs. Going to the solution level, they commonly use indicators such as percentage uptime for systems from the System Management team, error rates for applications from the Development Support team, or number of calls resolved on the first call from the Service Desk, etc. These KPIs usually are defined at an early stage and very often delivered in dashboards from various support applications.
On the other hand it is much more difficult to define and implement quantifiable measure for Enterprise Architecture. Many activities introduced with appropriate governance will enhance the quality of the delivered products and services, but it still will be a challenge to attribute results to the quality of Enterprise Architecture efforts.
This being said, Enterprise Architects should be able to define and justify the benefits of their activities to their stakeholders, and to help executives understand how Enterprise Architecture will contribute to the primary value-adding objectives and processes, before starting the voyage. The more it is described and understood, the more the Enterprise Architecture team will gain support from the management. There are plenty of contributions that Enterprise Architecture brings and they will have to be documented and presented at an early stage.
There won’t be just one single answer to demonstrate the value of an Enterprise Architecture but there seems to be a common pattern when considering feedbacks from various companies I have worked with.
Without Enterprise Architecture you can probably NOT fully achieve:
- IT alignment with the business goals
For business integration we use Enterprise Architecture methodologies and frameworks to integrate functions, processes, data, locations, people, events and business plans throughout an organization. Specifically the unification and integration of business processes and data across the enterprise, and potential linkage with external partners become more and more important.
To also have technology integration, we may use enterprise portals, enterprise application integration (EAI/ESB), Web services, service-oriented architecture (SOA), business process management (BPM) and try to lower the number of interfaces.
- Change management
- Reduced time to market and increased IT responsiveness
- Better access to information across applications and improved interoperability
- Readily available descriptive representations and documentation of the enterprise
- Reduce IT costs by consolidating, standardizing, rationalizing and integrating corporate information systems
Consolidation can happen at various levels for the architectures: for shared enterprise services, applications and information, for technologies and even data centers.
This could involve consolidating the number of database servers, application or web servers and storage devices, consolidating redundant security platforms, or adopting virtualization, grid computing and related consolidation initiatives. Consolidation may be a by-product of another technology transformation, or it may be the driver of these transformations.
Whatever motivates the change, the key is to be in alignment, once again, with the overall business strategy. Enterprise architects understand where the business is going, so they can pick the appropriate consolidation strategy. Rationalization, standardization, and consolidation process helps organizations understand their current Enterprise Maturity level and move forward on the appropriate roadmap.
- More spending on Innovation
- Enabling strategic business goals via better operational excellence
Jeanne W. Ross, Peter Weill, David C. Robertson in “Enterprise Architecture as Strategy: Creating a Foundation for Business” wrote “Companies with more-mature architectures reported greater success in achieving strategic goals” (p. 89). This included better operational excellence, more customer intimacy, and greater product leadership (p. 100).
- Customer intimacy
- Greater product leadership
- Comply with regulatory requirements
This list could be continued as there are many other reasons why Enterprise Architecture brings benefits to organizations. Once your benefits have been documented you could also consider some value management techniques. TOGAF 9.1 refers in the Architecture Vision phase to a target value proposition for a specific project. Here we would apply the value proposition concept to the Enterprise Architecture initiative as a whole.
Value Management uses a combination of concepts and methods to create sustainable value for both organizations and their stakeholders. Some tools and techniques are specific to Value Management and others are generic tools that many organizations and individuals use. There exist many Value Management techniques such as Cost-benefits Analysis, SWOT Analysis, Value Analysis, Pareto Analysis, Objectives Hierarchy, Function Analysis System Technique (FAST), and more…
The one I suggest to illustrate is close to the Objectives Hierarchy technique, which is a diagrammatic process for identifying objectives in a hierarchical manner and often used in conjunction with business functions. Close, because I will use a combination of the TOGAF 9.1 metamodel with the ArchiMate 2.0 Business Layer, Application Layer and Motivation Extensions Metamodels, consider core entities such as value, business goals, objectives, business processes and functions, business and application services, application functions and components. This approach being inspired by the presentation by Michael van den Dungen and Arjan Visser at the Open Group Conference in Amsterdam 2010 and I’m here adding some Archimate 2.0 concepts.
Firstly the entities from the TOGAF 9.1 metamodel:
Then I will consider the entities from ArchiMate 2.0. Some may be identical to TOGAF 9.1. In the Business Layer, one key concept will obviously be the Value. In this case I will consider the Product (“A coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.” Source Archimate 2.0 Specification), as the Enterprise Architecture program. In addition to that; I would refer to Business Services, Functions, and Processes.
In the Motivation Extension Metamodel, the Goals. The Objective entity in TOGAF 9.1 can also be represented using the concept of “goal”.
And in the Application Layer Metamodel, Application Services, Functions, and Components.
It is important to mention that when we deliver a value proposition, we must demonstrate to the business where the benefits will be with concrete examples. For example: the business see Operational Excellence and Customer Intimacy as key drivers, soon you will realize that BPM suites or CRM could support the business goals. These are the reasons why we consider the Application Layer Metamodel.
We could then use a combination of the ArchiMate 2.0 viewpoints such as: Stakeholder Viewpoint, Goal Realization Viewpoint, Motivation Viewpoint, or some other viewpoints to demonstrate the Value of Enterprise Architecture for a specific business transformation program (or any other strategic initiative).
To be mentioned that the concept of Benefit does not exist in any of the meta-models.
I have added the concept as an extension to ArchiMate in the following diagram which is the mapping of the value to a program related to the” improvement of customers’ relationships”. I also have limited intentionally the number of concepts or entities, such as Processes, Application Services or Measures.
Using these ArchiMate 2.0 modelling techniques can demonstrate to your stakeholders the Value Proposition for a business program, supported by an Enterprise Architecture initiative.
As a real example, if the expected key business benefit is Operational Excellence through process controls, which would a goal, you could present such a high level diagram to explain why Application Components like a BPM Suite could help (Detecting fraud and errors, embedding preventive controls, continuously auditing and monitoring Processes, and more).
There is definitely not a single way of demonstrating the value of Enterprise Architecture and you probably will have to adapt the process and the way you will present that value to all companies you will be working with. Enterprise Architecture contributes without a doubt to the success of an organization, and brings numerous benefits, but very often it needs to be able to demonstrate that value. Using some techniques as described previously will help to justify such an initiative.
The next steps will be the development of measures, metrics and KPIs to continuously monitor that value proposition.