01 March, 2012

Building an Enterprise Architecture value proposition using TOGAF® 9.1. and ArchiMate 2.0

When introducing Enterprise Architecture as a program or initiative, it is regularly done from an IT perspective rarely considering what the costs will be and if there will be any return on investment. This presents a particular challenge to Enterprise Architecture.

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
As an example among others, the problem with most IT plans is that they do not indicate what the business value is, and what strategic or tactical business benefit the organization is planning to achieve. The simple matter is that any IT plan needs also to have a business metric, not only an IT metric of delivery. Another aspect is the ability to create and share a common vision of the future shared by the business and IT communities.
  • Integration
With the rapid pace of change in business environment, the need to transform organizations into agile enterprises that can respond quickly to change has never been greater. Methodologies and computer technologies are needed to enable rapid business and system change. The solution also lies in Enterprise Integration (both business and technology integration).

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
In recent years the scope of Enterprise Architecture has expanded beyond the IT domain and Enterprise Architects are increasingly taking on broader roles relating to organizational strategy and change management. Frameworks such as TOGAF 9.1 include processes and tools for managing both the business/people and the technology sides of an organization. Enterprise Architecture supports the creation of changes related to the various architectures domains, evaluating the impact on the enterprise, taking into account risk management, the financial aspects ( cost / benefit analysis), and most importantly ensure the alignment with business goals and objectives. Enterprise Architecture value is essentially tied to its ability to help companies to deal with complexity and changes.
  • Reduced time to market and increased IT responsiveness
Enterprise Architecture should reduce systems development, applications generation and modernization timeframes for legacy systems. It should also decrease resource requirements. All of this can be accomplished by re-using standards, or existing components such as the architecture and solution building blocks in TOGAF 9.1. Delivery time and design/development costs can also be decreased by the reuse of reference models. All that information should be managed in an Enterprise Architecture Repository.
  • Better access to information across applications and improved interoperability
Data and information architectures manage the organization assets of information, optimally and efficiently. This supports the quality, accuracy and timely availability of data for executive and strategic business decision-making, across applications.
  • Readily available descriptive representations and documentation of the enterprise
Architecture is also a set of descriptive representations (i.e. "models") that are relevant for describing an Enterprise such that it can be produced to management's requirements and maintained over the period of its useful life. Using an Architecture Repository, developing a variety of artefacts and modelling some of the key elements of the enterprise; will contribute to build this documentation.
  • Reduce IT costs by consolidating, standardizing, rationalizing and integrating corporate information systems
Cost avoidance can be achieved by identifying overlapping functional scope of two or more proposed projects in an organization, or the potential cost savings of IT support by standardizing on one solution.
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
Enterprise Architecture should serve as a driver of innovation. Innovation is highly important when developing a target Enterprise Architecture, and realizing the organization’s strategic goals and objectives. For example, it may help to connect the dots between business requirements and the new approaches SOA and cloud services can deliver.
  • Enabling strategic business goals via better operational excellence
Building Enterprise Architecture defines the structure and operation of an organization. The intent of enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. It must be designed to support an organization’s specific business strategies.

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
Enterprises which are customer focused and aim to provide solutions for their customers should design its business model, IT systems and operational activities to support this strategy at the process level. This involves the selection of one or few high-value customer niches, followed by an obsessive effort at getting to know these customers in detail.
  • Greater product leadership
This approach enabled by Enterprise Architecture is dedicated to providing the best possible products from the perspective of the features and benefits offered to the customer. It is the basic philosophy about products that push performance boundaries. Products or services delivered by the business will be refined by leveraging IT to do the end customer’s job better. This will be accomplished by the delivery of new business capabilities (e.g. on-line websites, BI, etc.).
  • Comply with regulatory requirements
Enterprise Architecture helps companies to know and represent their processes and systems and how they correlate; fundamental for risk management and managing the regulation requirements, such as those derived from Sarbanes-Oxley, COSO, HIPAA, etc.

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.

13 comments:

Keith said...

Hi Serge,

Insightful post. I understand that the ArchiMate tool is available download via the Open Group website for registered users?

Serge Thorn said...

Hi Keith. Not quite. ArchiMate is downloadable as a specification from the Open Group website but if you need a tool supporting ArchiMate then you need to buy one..:-)

Paul Vermette (@kinecthedots) said...

http://archi.cetis.ac.uk/ has an ArchiMate 2.0 compliant modeling tool based on eclispe. I used it for a little bit and seems to work well. It is opensource and free to use.

Paul Vermette (@kinecthedots) said...

http://archi.cetis.ac.uk/ is an opensource ArchiMate modeling tool that is based on eclipse and is compliant with the latest version of the ArchiMate 2.0 Specification.

Serge Thorn said...

Hi Paul, thanks for that. Yes I know the tool. Not sure if Keith was as king for a tool or the specification!

Anonymous said...

@michelbenard : I'm a bit puzzled by the not so aligned archimate-togaf views on the architecture layers. What I mean is that Togaf is using these layers : business arch. , information arch. ( = Application architecture + Data architecture) and Technology Architecture, whereas Archimate uses those : business, application, technology. There is a mismatch between IS layer in Togaf and Application layer in archimate which is rather confusing when you want tu use both frameworks.

Serge Thorn said...

Michel, I agree this is not as clear as it should be, still the notion of Objects can refer to data entities. Soon there will be a new whitepaper algning the two frameworks. Thanks

Bas van Gils said...

hi all! First of, great post. A lot of good insights on using TOGAF and ArchiMate in practice. Some thoughts:

Archi is a good tool to get started with Architecture modeling. For more detailed analysis (impact analysis, roadmapping etc.) and advanced visualizations, have a look at e.g. BiZZdesign Architect.

The ArchiMate metamodel is consistent with TOGAF's ACF. The concepts can be matched. The layering may seem a bit different. This is due to the fact that "information" maps to "passive structure" in ArchiMate and covers concepts such as the business object, data object and artefact.

It is understandable that it takes some getting used to. I'm convinced you'll find it useful in the end though!

By the way: we're planning a series of blogposts on ArchiMate usage on blog.bizzdesign.com soon. I'll make sure we cover some of the aspects mentioned here!

Anonymous said...

@michelbenard to Bas : I don't want to argue but even if archimate and togaf layers are "consistent" (if I would be pedantic I would say isomorphic ) , they are not identical.

I'm not sure it this could (and should) be ever ironed out as the archimate core concepts (behaviour, passive structure and the like ..) have no direct counterparts in Togaf . But I may be wrong.

Anyway, I do think archimate is a great addition to togaf, and I look forward reading Serge's posts on that matter as long as those on blog.bizzdesign.com .

@michelbenard said...

Nice presentation here that discusses in depth togaf/archimate alignment

Erik Iglesias Abella said...

Serge:
I want to be devil's advocate:
application function, service and function: isn't this a huge redundance of information?

I have the Business FUnctional Architecture model of my bank in this form, but to be honestly, it is for me absolutelly un-manageable ... (I support it + the part of the process and the application architectures).
Where it is afforbale to use thse 3 levels? ...

Thank you.
Regards,
Erik Iglesias.
erik.iglesias.abella@gmail.com

Serge Thorn said...

To really make this clear, you would need an Enterprise Architecture Metamodel where you describe the core entities of your enterprise. Usually we divide architectures in 4 domains, respectively Business, Data, Application and Technology. Most frameworks suggest the same approach.

The core entities of your Metamodel will describe the relations between functions, service, organization, etc… For example, you may have Business Functions, Applications functions, Business Services, Application Services, Data Services, Infrastructure Services and more. Without a Metamodel I understand this could be confusing.

To help you I strongly suggest you look at 2 things:

1.The TOGAF Metamodel which describes these relationships and helps you to create the traceability between architecture domains
2. ArchiMate which is an Enterprise Architecture modeling language where you will also understand how to links all these concepts together

The question should not be “is this affordable” to use these 3 levels, but more “how can I work on something which worked somewhere else based on best practices”. I have been doing this in Banking and finance for several years based on the TOGAF framework and this mas perfectly manageable based later on an Enterprise Architecture tool.

Best regards

Erik Iglesias Abella said...

Serge:

1. Yes, we have the EA metamodel with these metaobjects, (the process area decomposed, the functional is decomposed on these without the application functions and so on…) We have also dividet the metamodel on these 4 areas and even with a micro-segmentation further )e.g. Business is dividend into strategy, product, process(including org and docs) and functional.
2. We have for years the model in „compliance“ with Togaf … and maybe that is the problĂ©m, that if you make something „pure“ often in the real Word it is not so huge used, but on the other hand you spend a lot of time mapping all of these … (and discussing chat is behaind chat). Archimate we have as one of our secondary (source) notations and reference model together with UML, BPMN and with ITIL, CMMi...)
3. The problem for me is still the same. It is in 80% of cases and projects not used. I start to fill that many times it will be good to streamline the really needed metaobjects that are really core to manage and don't make it so complex / only a practical imperfect point of view, that’s were my question (as the devil's advocate] but I fill that it is hard to discuss and so, please, I get this my question back.
Thank you.
Best regards,
ERIK IGLESIAS ABELLA