Skip to Content

BPM and the TOGAF Business Architecture Phase

In my first blog I introduced the concept of using TOGAF to guide the implementation of BPM in an enterprise. In this follow-up I will focus on the Business Architecture phase in TOGAF and how it can help develop the Enterprise Models required in Enterprise BPM.

The first helpful concept we encounter in TOGAF is the relationship overview of the different management frameworks that drive each enterprise

image

Figure 1 TOGAF overview of Management Frameworks

Here we see that Business Planning and Enterprise Architecture together constitute Capability Planning. This area is focused on planning the priorities for continued alignment of the architecture with the business. Solution (better would be: Capability) development then takes place under architectural and project management governance. Results are implemented in Operations Management. Output from Operations Management (Actual Performance measured by Process KPI’s) is fed back into Business Planning to update priorities.

Note that in TOGAF although there is an arrow from EA into Operations Management, there is no bi-directional arrow back from  Operations Management. One of the key requirements to enable EA to manage the BPM development cycle is to close the loop back from Operations Management into Architectural models. Process simulation analysis for example is one subject that must be managed this way.

The Business Process Architecture itself falls squarely in the EA domain. This Process Architecture is driven by the business principles and drivers from the Business Strategy. The EA best practices as established in the MIT book “EA as Strategy” from Ross et al show how such a translation from business strategy to EA practices can be realized, using the Business Operating Models of an enterprise as the bridge between business and IT.

Traditionally there is a wide gap (a “leap of faith”) between the business strategy defined in an enterprise and the underlying enterprise architecture. The framework developed by Ross, Weill and Robertson (see “EA as Strategy”(2006), ISBN 978-1-59139-839-4)  provides an elegant way to translate business strategy in what they call “a foundation for execution”, a compact representation of the business operating model of the enterprise. Such a business operating model is by definition process-oriented because it shows the value chain of the enterprise in its environment, as well as the areas of competitive advantage that are crucial for that particular enterprise. Advanced inter-enterprise collaboration in the value chain can also be incorporated easily in these models.

In Enterprise BPM, enterprise modeling produces the highest level artifacts, such as value chains and business process models. Using these Enterprise Modeling tools in the Business Architecture phase of TOGAF creates a seamless link between the strategy and resulting main business model of the enterprise and the highest level enterprise BPM process models.

Developing “Business Scenarios”

TOGAF itself recommends the use of “Business Scenarios” to link the business requirements to architectural models. According to TOGAF a Business Scenario is “a description of:

  • A business process, application, or set of applications that can be enabled by the architecture
  • The business and technology environment
  • The people and computing components (called “actors”) who execute the scenario
  • The desired outcome of proper execution”

The process of developing a business scenario in TOGAF is shown in the picture below:

image

The process steps shown are:

  1. Identifying, documenting, and ranking the problem driving the scenario
  2. Identifying the business and technical environment of the scenario and documenting it in scenario models
  3. Identifying and documenting desired objectives (the results of handling the problems successfully); get “SMART”
  4. Identifying the human actors (participants) and their place in the business model
  5. Identifying computer actors (computing elements) and their place in the technology model
  6. Identifying and documenting roles, responsibilities, and measures of success per actor; documenting the required scripts per actor, and the results of handling the situation
  7. Checking for “fitness-for-purpose” and refining only if necessary

(source: TOGAF-9, 2009)

What is actually shown here is very close to the best practices in BPM enterprise modeling. It would be better if TOGAF would not limit itself to “Problems” but would widen the scope of the Business Scenario to also include “Opportunities”, or more general just the full scope of value chains deployed in the enterprise. The approach however is still the same. By developing the high level business scenarios directly from the Business Operating Model of the enterprise which itself is based on the defined Business Strategy they automatically become value-transparent. It can be made explicit what a certain business scenario contributes to the overall strategy, vision and mission of the enterprise.

Another benefit of using the approach of TOGAF “Business Scenario’s” in enterprise modeling is that the various alternative scenarios can be described on a high level. In today’s volatile business environment the translation of Strategy into Business Operating Model and Business Scenario’s should be based on “Design for Change”. It must take on board the need for agility in the approach itself.  This means that alternatives like centralization versus decentralization, as well as in- vs outsourcing of parts of the value chain can be accommodated in the same enterprise model. This also solves the issue in many enterprises that on a corporate level the drivers may be different than on a business division or unit level.

By developing a set of end to end business scenarios following the TOGAF model a catalog of value chain scenario’s is developed. This scenario catalog is then the basis for the Information Systems Architecture phase of TOGAF. Please note that such an approach leverages the process-orientation of BPM and results in different architectural consequences when compared to the traditional functional representation of business architecture we know and love from the ERP era (eg Sales, Finance, Purchasing etc) and which is much more static.

It is also possible this way to model multiple states of a value chain at the same time. Think for example of the situation where two companies merge and there is a hybrid architecture spanning and causing several years of migration and re-orientation.  

Enterprise BPM Artifacts in the TOGAF Business Architecture phase

TOGAF is a framework that deliberately intends to connect the conceptual strategic business view and the state of the actual physical systems (IT) view of the enterprise. This is the reason for its existence. This also means that in the Business Architecture phase of TOGAF the Architecture Repository is reviewed and further developed. Available and already developed resource and models in the enterprise are considered for re-use in enterprise BPM modeling. This means that in an Enterprise BPM context, available enterprise models and process models will be considered for inclusion in the Business Scenario Catalog.

In terms of BPM Architecture the Business Architecture Phase of TOGAF then leads to the following set of artifacts.

image

Figure 2 BPM Architecture Artifacts TOGAF Phase 2

The Gap Analysis

One of the key activities in the TOGAF Business Architecture phase is the Gap Analysis, which identifies the gaps (problems, issues) and analyzes the steps to be taken to migrate from current to future state architecture.

Sources of gaps may be Business domain gaps, Data domain gaps, or may reside in the Applications or Technologies domains. Key in the standard TOGAF approach of Gap Analysis is the use of the “architectural building blocks” concept. These architectural building blocks as used by TOGAF are traditionally Applications based. This approach should be slightly modified for Enterprise BPM. Rather than basing the Gap Analysis on Architectural Building Blocks, which have a direct relationship with underlying applications and technologies, the mapping should be towards Architectural Capabilities.

These architectural capabilities can be defined and categorized using the Business Operations Platform (BOP), a concept which developed from Enterprise SOA over the last few years.

The Business Operations Platform

The Business Operations Platform defines the capabilities and enabling technologies required for Enterprise BPM. Establishing and developing this platform for the enterprise is the most important responsibility IT architecture will face in the coming years.

image

Figure 3 The Business Operations Platform

The Architectural Capabilities to be used in the Gap Analysis must be defined in terms of this Business Operations Platform. That way it becomes clear which investments in enabling technologies are required and which IT delivery models (eg Cloud versus On Premise) can help in bridging the identified gaps in the TOGAF Gap Analysis.

The definition of the Information Systems Architecture in terms of the Business Operations Platform and the resulting Architectural Capabilities that support Enterprise BPM will be the subject of my next blog, which will deal with the Information Systems Architecture phase of TOGAF.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply