#architecture layers

[boatinggoesleo]

116/365

[digital-roadmap-management]

Pictures That Describe What TOGAF Is

Today´s post is provides an overview of what TOGAF is and what it stands for. It does so with a short series of pictures which each address an important aspect of TOGAF.

TOGAF Timeline / History

TOGAF was first published in 1995 by The Open Group. Since then, new versions have been released every few years. In the recent past, the frequency of new releases has lowered. The latest version of TOGAF, which is version 9.2, was released in 2018.

The TOGAF ADM

The TOGAF Architecture Development Method provides a stepwise approach to architecture development projects. While the method itself is fixed phases, The Open Group clearly emphasizes that it can be used in different agile contexts and it provides several possibilities of how an architecture project can cycle through the different phases and repeat them depending on the need and maturity of the output.

The TOGAF Architecture Layers

The TOGAF Architecture layers build today´s basis for many architectural approaches and ways of thinking. The layers that TOGAF provides are rather simplistic and limited to 3 main layers, which are the business layer, information systems layer, and the technology layer. In addition, the information systems layer has two sub-layers, which are the applications layer and the data layer. Today´s enterprise architecture best practices usually amend the TOGAF layers by additional layers or put more emphasis on particular aspects.

TOGAF Content Metamodel

The TOGAF content metamodel provides a model to sort different enterprise architecture outputs into a broader model. Just as the ADM, it build on the TOGAF architecture layers and adds a more visionary and strategic category on top, as well as a more operational and realizing category at the bottom to it.

TOGAF Enterprise Continuum

The Enterprise Continuum is a concept to determine the reusability of an enterprise architecture artifact of general output. It is a scale on which generic and reusable artifacts are placed on the left side, while very specific and non-reusable artifacts would be placed on the right side. It is not a real and tangible file ordering system, but is rather meant to explain what type of artifacts can exist and if a reusage would be possible.

TOGAF Views and Viewpoints

In the context of artifacts and enterprise architecture work, TOGAF talks often about views and viewpoints.  While an artifact provides a particular view on something, a viewpoint is a generic position from which something can be looked at. For example, one could develop an application architecture view from its Marketing domain and another application architecture view from its Sales domain. While both artifacts would have the same viewpoint – which is the application architecture – each artifact would provide a different view.

[digital-roadmap-management]

Top 5 Use Cases for Business Capabilities to Transform an Organization

Business capabilities take over the role as primary concept to manage alignments and gain transparency of an organization. In this article, I present five major use cases that business capabilities can enable and what is needed to achieve the desired benefits.

 1. Provide IT Landscape Transparency on All Enterprise Architecture Layer

The first and most common use case of applying business capabilities is to provide a generic, easy to understand, and holistic view of an organization that can be used to map IT components, such as applications, data, or technology to it. Understanding the As-Is and To-Be landscape of the application layer, the data layer, and the technology layer is at the heart of Enterprise Architecture Management. Business capabilities can be the linking element, located in the business layer, that IT can map components to, and that business is able to understand easily. Before the start of a landscape assessment, have a clear picture of what you want to do with the data after you gathered it (and hence what you actually want to assess in detail), how you want to store it, share it, and how it should be governed and updated over time.

 2. Prioritize Projects Based on the Strategic Importance of the Underlying Business Capabilities

This use case requires that projects identify the business capabilities that they support and that the result is centrally collected before the beginning of the demand and portfolio process. This also requires that there is a business capability map in place for the whole organization and that there is an indication of the strategic relevance for every capability. This can be done by breaking down existing business strategies and understanding what those strategies actually imply.

Consider this example: If your company wants to increase digital sales, your e-commerce capability would probably be of high strategic relevance. If your organization collects the data for this use case, it would be able to show the strategic importance of business capabilities based on the underlying projects – depending on which capabilities they enable. The resulting analysis could help to decide whether a project should be funded or not.

 3. Capabilities-Based Demand Management

A very popular use case is to support the demand management process of your organization. Unfortunately, it is also one of the hardest to implement. In order to add value to the demand management process with the help of capabilities, you need to have a detailed capability map in place, as well as a very good As-Is transparency of your landscape mapped to it. Your As-Is landscape might consist of applications and their functionalities, of systems and supported technologies, or even of ready-to-use solution bundles.

If you gather all this information, you could map incoming demands (e.g. a business-drawn user journey) to business capabilities and identify whether you already have that capability in your map or not. If it already exists, you can analyze the IT components mapped to it. You can also evaluate whether they might be suitable to meet the described demand or if you really need to develop something new. The result of this exercise would most likely be a reduced set of capabilities and hence functionalities that need to be developed from scratch or purchased, while you can maximize the re-usage of existing IT components and therefore reduce costs and required resources, enhance stability through tested components, and reduce time-to-market.

Yet, this approach often stays theoretic, because it cannot be applied in areas in large applications cannot be separated into its single capabilities. Therefore, they do not allow to use single parts of it for new demands. Also, the As-Is landscape is often not described in enough detail to allow for such an approach, so that there is a lot of upfront effort required.

 4. Application Lifecycle Optimization

Some organizations have thousands of applications. Applying business capabilities to cluster them according to the business abilities they enable makes it much easier to optimize the application landscape. The goal is to have such a granular business capability map that no more than 5 to 10 applications are mapped to one business capability.

This allows to analyze the applications per independent from each other per business capability cluster. This can for instance be done by applying a TIME analysis, which assesses the business fit and the IT fit of each application and allocates it on a matrix. The business fit could be the result of business value added, business criticality, number of users, departments, countries using the application, or allocated revenues. The IT fit could be the result of the support of the underlying technology, the application security, availability of the source code, response times, issues etc. There are many indicators that you could think of and you should evaluate which ones your organization can assess and are helpful for your goal.

If you put the business fit on the x-axis and the IT fit on the y-axis, you will create the following quadrants:

Top Left, Tolerate: Those applications have a low business fit, but their IT fit is high. You can therefore keep them in your organization as they do no harm.

Top Right, Invest: Those applications have a high business fit and a high IT fit. You should further strengthen them and further invest in them, as they are the best category of your applications.

Bottom Right, Migrate: Those applications have a high business fit, but a low IT fit. You probably need their functionalities, but the underlying technology is not optimal. You should consider changing the provider, migrate to a new server or do something else to enhance their IT fit.

Bottom Left, Eliminate: Those applications have a low business fit and a low IT fit. You do not need those applications and they have no suitable IT foundation. The best option for them is to be eliminated to reduce the number of applications and to drive down costs.

Doing this analysis on a capability basis ensures that you always have transparency on whether the capability is still supported via an application although you decide to eliminate another.

 5. Capabilities-Based IT Post Merger Integration Approach

The key benefit of using business capabilities in a post-merger integration is their generic nature that makes them understandable across organizations. While processes are often specific to an organization and hence differ in terms of their scope or wording, capabilities aim at providing the same foundation for all.

Especially during the merger of two different companies, this is extremely important, as those companies have different backgrounds, different cultures, and need to be clear when communicating with each other prior to Day 1. Business capabilities provide that foundation and can be used to map all kinds of IT components from both companies to them, so that the further analysis can be based on those capability clusters.