Metamodel – Page 2

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

May 10, 2013May 8, 2013 by Serge Thorn

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

Let’s start with a definition of traceability. Traceable is an adjective; capable of being traced. Trying to find a definition even from a dictionary is a challenge and the most relevant one I found on Wikipedia which may be used as a reference could be “The formal definition of traceability is the ability to chronologically interrelate uniquely identifiable entities in a way that is verifiable.”

In Enterprise Architecture, traceability may mean different things to different people.

Some people refer to

· Enterprise traceability which proves alignment to business goals

· End-to-end traceability to business requirements and processes

· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities

· Requirements traceability which assists in quality solutions that meets the business needs

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

· Traceability between artifacts from business and IT strategy to solution development and delivery

· Traceability from the initial design phase through to deployment

· And probably more

The TOGAF 9.1 specification rarely refers to traceability and the only sections where the concept is used are in the various architecture domains where we should document a requirements traceability report or traceability from application to business function to data entity.

The most relevant section is probably where in the classes of architecture engagement it says:

“Using the traceability between IT and business inherent in enterprise architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.”

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

Using the TOGAF 9.1 framework, we would use concepts of the Metamodel. The core metamodel entities show the purpose of each entity and the key relationships that support architectural traceability as stipulated in the section 34.2.1 Core Content Metamodel Concepts.

So now, how do we build that traceability? This is going to happen along the various ADM cycles that an enterprise will support. It is going to be quite a long process depending on the complexity, the size and the various locations where the business operates.

There may be five different ways to build that traceability:

· Manually using an office product

· With an enterprise architecture tool not linked to the TOGAF 9.1 framework

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

1. Manually using an office product

You will probably document your architecture with the use of word processing, spread sheets and diagramming tools and store these documents in a file structure on a file server, ideally using some form of content management system.

Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system or an enterprise. The links between these deliverables soon becomes non manageable and in the long term impact analysis of any change will become quite impossible. Information will be hard to find and to trace from requirements all the way back to the business goal that drives it. This is particularly difficult to achieve when requirements are stored in spread sheets and use cases and business goals are contained in separate documents. Other issues such as maintenance and consistency would have to be considered.

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Many enterprise architecture tools or suites provide different techniques to support traceability but do not really describe how things work and focus mainly on describing requirements traceability. In the following example, we use a traceability matrix between user requirements and functional specifications, use cases, components, software artifacts, test cases, business processes, design specifications and more.

Mapping the requirements to use cases and other information can be very labor-intensive.

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

Below is an example of what traceability would look like in an enterprise architecture tool after some time. That enterprise architecture ensures appropriate traceability from business architecture to the other allied architectures.

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

The TOGAF 9.1 core metamodel provides a minimum set of architectural content to support traceability across artifacts. Usually we use catalogs, matrices and diagrams to build traceability independently of dragging lines between elements (except possibly for the diagrams). Using catalogs and matrices are activities which may be assigned to various stakeholders in the organisation and theoretically can sometimes hide the complexity associated with an enterprise architecture tool.

Using artifacts creates traceability. As an example coming from the specification; “A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified”. There are other artifacts which also describe other traceability: Data Migration Diagram and Networked Computing/Hardware Diagram.

4. With an enterprise architecture tool using ArchiMate 2.0

Another possibility could be the use of the ArchiMate standard from The Open Group. Some of the that traceability could also be achievable in some way using BPMN and UML for specific domains such as process details in Business Architecture or building the bridge between Enterprise Architecture and Software architecture.

With ArchiMate 2.0 we can define the end to end traceability and produce several viewpoints such as the Layered Viewpoint which shows several layers and aspects of an enterprise architecture in a single diagram. Elements are modelled in five different layers when displaying the enterprise architecture; these are then linked with each other using relationships. We differentiate between the following layers and extensions:

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

The example from the specification below documents the various architecture layers.

As you will notice, this ArchiMate 2.0 viewpoint looks quite similar to the TOGAF 9.1 Business Footprint Diagram which provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.

Another example could be the description of the traceability among business goals, technical capabilities, business benefits and metrics. The key point about the motivation extension is to work with the requirement object.

Using the motivation viewpoint from the specification as a reference (motivation extension), you could define business benefits / expectations within the business goal object, and then define sub-goals as KPIs to measure the benefits of the plan and list all of the identified requirements of the project / program. Finally, you could link these requirements with either application or infrastructure service object representing software or technical capabilities. (Partial example below).

One of the common questions I have recently received from various enterprise architects is “Now that I know TOGAF and ArchiMate… how should I model my enterprise? Should I use the TOGAF 9.1 artifacts to create that traceability? Should I use ArchiMate 2.0? Should I use both? Should I forget the artifacts…”. These are good questions and I’m afraid that there is not a single answer.

What I know is that if I select an enterprise architecture tool supporting both TOGAF 9.1 and ArchiMate 2.0, I would like to be able to be able to have a full synchronization. If I model a few ArchiMate models I would like my TOGAF 9.1 artifacts to be created at the same time (catalogs and matrices) and if I create artifacts from the taxonomy, I would like my ArchiMate models also to be created.

Unfortunately I do not know the current level of tools maturity and whether tools vendors provide that synchronization. This would obviously require some investigation and should be one of the key criteria if you were currently looking for a product supporting both standards.

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

This other possibility requires that you have an up to date Configuration Management Database and that you developed an interface with your Architecture Repository, your enterprise architecture tool. If you are able to replicate the relationships between the infrastructure components and applications (CIs) into your enterprise architecture tool that would partially create your traceability.

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

Achieving traceability within an Enterprise Architecture is key because the architecture needs to be understood by all participants and not just by technical people. It helps to incorporate the enterprise architecture efforts into the rest of the organization and it takes it to the board room (or at least the CIO’s office) where it belongs.

· Describe your traceability from your Enterprise Architecture to the system development and project documentation.

· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

If a development team is looking for a tool that can help them document, and provide end to end traceability throughout the life cycle EA is the way to go Make sure you use the right standard and platform. Finally, communicate and present to your stakeholders the results of your effort.

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

May 10, 2013May 8, 2013 by Serge Thorn

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

In Enterprise Architecture, traceability may mean different things to different people.

Some people refer to

· Enterprise traceability which proves alignment to business goals

· End-to-end traceability to business requirements and processes

· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities

· Requirements traceability which assists in quality solutions that meets the business needs

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

· Traceability between artifacts from business and IT strategy to solution development and delivery

· Traceability from the initial design phase through to deployment

· And probably more

The most relevant section is probably where in the classes of architecture engagement it says:

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

There may be five different ways to build that traceability:

· Manually using an office product

· With an enterprise architecture tool not linked to the TOGAF 9.1 framework

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

1. Manually using an office product

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Mapping the requirements to use cases and other information can be very labor-intensive.

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

4. With an enterprise architecture tool using ArchiMate 2.0

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

The example from the specification below documents the various architecture layers.

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

· Describe your traceability from your Enterprise Architecture to the system development and project documentation.

· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

On not eating the elephant

March 19, 2013 by Tom Graves

How do we make sense of an enterprise? Is analysis the best or only way to do it? That now long-running LinkedIn thread about capability, function, service and process that I referenced in a couple of recent posts just keeps rolling…

Should Business Architects use the Business Model Canvas at the Program level?

January 31, 2013 by Nick Malik

In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture. In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started. He felt that the canvas is useful for creating a clear picture of the business impacts on a program. There are problems with this method, which I’d like to share in this post.

Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.”

A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.” This business program has a management structure and is ultimately provided funding for a series of “projects.” The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs.

For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model. I’m using the term “program” for this post because the Open Group presenter used the word “program.” Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.

The practice presented by this talk is troubling to me. As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out. By doing so, he or she would understand “the” business model that impacts the program.

During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models? The presenter said, in effect, “we only create one canvas.” My jaw dropped.

A screwdriver makes a lousy hammer but it can sometimes work. The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.

The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program. First off, programs are transitory, while business models are not. The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business. Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time. It is completely inappropriate for capturing two different models on a single canvas. Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.

I have no problem with using business models (although my canvas is different from Osterwalder’s). That said, I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas. The session speaker specifically rejected this idea. I don’t think he is a bad person. I think he has been hammering nails with a screwdriver. (He was young).

Here’s where he made his mistake:

In the oversimplified value stream model above, Contoso airlines has three business models. The business owners for these three businesses are on the left: Bradley, Janet, and Franklin. Each are primarily concerned with their own business flows. In this oversimplified situation, there are only two programs, each with one project. If the session speaker were working on the Plantheon program, his idea works. there is only one business model to create. That nail can be hammered in with a screwdriver. Lucky speaker. Showing Franklin his own business model is a good thing.

But if we are working on the Flitrack program, what do we show Franklin? if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns. He will not benefit and neither will the program. In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?

Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models. The business model that Franklin cares about does not need to be created again. It can come out of the repository. The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program.

Anything less is business analysis, not business architecture.

Steps To Create a Core Diagram

December 19, 2012 by Nick Malik

To be fair, these are steps to create a solid understanding of the architecture of a business, but the deliverable is a core diagram, so that’s the title of the post. I first wrote about a method for creating core diagrams about a year ago, as I was preparing for a talk on the subject at the Open Group conference in San Francisco. Now that I’m preparing for another Open Group conference, I find myself filling out some of the details from the previous effort. Most of the text below is copied from an e-mail that I sent to a fellow business architect who was asking about how to create a core diagram.

The text below describes a five step process

Collect a list of your organization’s business models
Create or leverage a taxonomy of capabilities that reflect differentiation in business processes
Differentiate each capability on the basis of Ross’ operating model taxonomy (level of Information Integration and level of Process standardization)
Make an educated guess about the operating model of the company
Draw the core diagram and build understanding around it

Understanding how to create a core diagram starts by collecting a list of the business models that your organization performs. Each business model is unique and different from the other ones. Each will require different capabilities and will often drive variations in those capabilities for the sake of market or product differentiation. You cannot create a core diagram effectively without the list of business models.

So what is in a business model? I’ve blogged about that fairly well. A business model is a composition of elements that describes how and why a value proposition exists, who it is for, and what it drives in terms of internal and external requirements. The diagram is below. (click to enlarge)

Once you have the initial list of business models, you will want to engage with direct business stakeholders. Make sure that they understand the concept of a business model, and what makes a business model unique from other business models (e.g. selling the same product in the same way to the same people in another country is NOT a unique business model, but selling a product in three different ways to three different, potentially overlapping market segments within one country probably represents three business models). Engage. Build relationships. This is your first shot.

Once you have that list fairly well baked, you have step two on your hands: a capability taxonomy that reflects process differentiation. In this case, it is a good idea to start with a high level process taxonomy like the ones made available for free from the APQC. I don’t know if there is one for financial services yet, but there should be. If not, you can start with a general one, but it will take some editing. You want your capability taxonomy to be worded in such a way that it represents “things that could be done” without reflecting the way in which they are done. For example, “customer identity management” is OK, but “customer deduplication” is not, because we want to make sure that customers have an appropriate identity but the organization may not want to remove duplication in order to do that.

This requires some editing of a large list of items in a hierarchy. Excel is OK for this. There may be other tools as well… I haven’t experimented past Excel. This is the second point where it is good to be engaging with business stakeholders. Get their help to describe their business model to you in terms of capabilities, and make sure that all of their capabilities are included in your taxonomy somewhere (usually around the third level down in the tree).

Step three is to differentiate each business capability on the dimensions suggested in the EA As Strategy book. (This can be done at a high level. If your taxonomy has more than 200 business capabilities in it, don’t use the most detailed level(s) of the taxonomy. No one has patience for the details in a core diagram.

Draw out a grid like the one illustrated in the EA As Strategy book, only make it empty.

In each one of the boxes, write in the capabilities that are well understood by a particular business stakeholder, then go to that stakeholder and validate your choices. Make sure that you have placed the correctly for that stakeholder’s particular business models. Note that very few stakeholders will have a valid opinion about capabilities that are NOT part of their particular business model, so don’t show capabilities that they don’t care about.

You will quickly discover that most folks agree on some things and disagree on some things. Where a single capability shows up in multiple businesses, one stakeholder may say that it needs high standardization, while another will say that the capability needs low standardization (== high flexibility). Take note of these disagreements. THEY ARE THE VALUE POINTS FOR BUSINESS ARCHITECTURE.

On everything you can get reasonable agreement on, go ahead and create a master table that has the capabilities differentiated in the manner above. That will probably be about 90-95% of your business capabilities in your taxonomy.

Step four is to make an “educated guess” about the operating model that your organization has. It’s a guess because most organizations are difficult to read and no one person will be able to answer your question about what the company as a whole looks like. Most of the time, you can start with the generalizations that Jeannie Ross made when describing the four operating models in her book “Enterprise Architecture As Strategy.” If there are a large number of capabilities in the “High Integration, High Standardization” box, you can suggest that your organization is a “Centralization” model. If, on the other hand, there are a large number in the “High Integration, Low Standardization” box, you can suggest that the organization is a Coordination model. This is the educated guess part because there is no good formula for making the guess. By this point, you will know a great deal about the organization so your guess is as good as your stakeholders.

Step five is to take a cut at your core diagram… Draw it out and then work with your stakeholders to get common understanding.

For each of the four styles of models, there are different styles of core diagrams. The centralization model tends to break out capabilities by functional area since there is very little (intentional) duplication. So it will be a diagram with a series of functional areas as boxes with the capabilities for each function listed in the boxes. Good idea to put the name of the person accountable for that business function in the title of the box. Lines between the boxes represent flows of information or value between them.

The Replication model is somewhat similar. There will be some functions that are owned by “corporate” while the rest are replicated into EACH of the operating units, so there will be two large “areas” on your diagram. The corporate area will have some functions with capabilities in them, and a single “replicated” area will have the remaining functions with capabilities in them. This is wildly valuable to business planners because they can get agreement among the leaders of each replicated unit about what each one of the is accountable to do and what they MUST depend on the corporate unit to do.

The collaboration model tends to be “hub and spoke” with the hub being the most integrated capabilities and the spokes being unique to each of the business models (or in some cases, small groups of business models that share a lot of capabilities). The lines tend to be information flow, not value flow. The capabilities in the spokes are usually duplicated between the different business units but they (should be) the capabilities that each business unit needs in order to differentiate itself or its products in the marketplace.

The diversification model is the most complex because the “corporate” unit tends to have a small number of core capabilities (often just financial ones) with each of the subsidiaries having a nearly complete and quite independent set of functions with massive duplication of capabilities across them.

I hope this gives you a good start in creating your core diagram.

On human ‘applications’ in EA models

November 5, 2012 by Tom Graves

In enterprise-architecture, how should we model a human-based ‘application’ such as a customer-service line or reCaptcha or Amazon‘s ‘Mechanical Turk‘? [Note: on a first glance, this all looks really simple. As soon as we delve anywhere beneath the surface, though, it’s…

A quick metablog

October 28, 2012 by Tom Graves

Why is it that some mornings start with a flood of ideas, each of which demand a blog-post that would take a day or more to research and write? Sigh… Hence a quick metablog – a post about things I’m…

The EA Metamodel behind the Business Model Generation

August 23, 2012 by Nick Malik

Back when Alexander Osterwalder was first working on the book “Business Model Generation,” I reached out to him to see if I could discuss the data elements he had chartered for his “Business Model Canvas.” After all, from …

Speaking at TechEd New Zealand on Business Architecture

August 2, 2012 by Nick Malik

Haven’t been to New Zealand yet, but I will be there soon… From September 4 through 7 in Auckland, for TechEd New Zealand. I will be presenting two topics (Business architecture for non architects, and Aligning IT with capabilities).

Now, normally you wouldn’t see Enterprise Architecture topics on a TechEd calendar. However, in the NZ market, there just isn’t the demand for multiple Microsoft conferences every year. As a result, all the conference demand is bundled up into TechEd. Due to the efforts of Terry Chapman and the hard working architects in Microsoft New Zealand, the TechEd conference there has developed quite a reputation for hosting an advanced architecture track.

I’m fortunate to be attending and presenting. If you live or work in the region, I’d love to see you at TechEd New Zealand. If you would like to see more information about the sessions at TechEd NZ, click here.

Part 3 of 3: Building an Enterprise Architecture Value Proposition Using TOGAF® 9.1. and ArchiMate® 2.0

March 20, 2012 by Open Group

Value management through TOGAF 9.1 and ArchiMate 2.0. Continue reading →

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

June 29, 2013March 1, 2012 by Serge Thorn

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:

Categories Archimate, Business Strategy, business transformation, Enterprise Architecture, IT Business Alignment, Metamodel, Open Group, togaf, Value proposition

Helping others make sense of my work

November 2, 2011 by Tom Graves

Have been struggling hard for the past few days with a truly brilliant challenge from Bulgarian enterprise-architect Ivo Velitchkov, when he dropped by for a visit near here over the weekend. And I’d have to admit I’m no nearer solving it as yet. Hmm… His point is this: there’s a huge body of knowledge – […]