Skip to Content
Implementing Business Process Management: Enterprise Architecture to the rescue 

End to end Process Management and continuous Process Improvement are fast becoming the most important and deciding differentiators in the current business climate of globalization, extreme competition and concurrent financial crisis. All waste must be eliminated from the key processes of any enterprise, and non-key processes must be eliminated as a whole by outsourcing them as soon and comprehensively as possible.

 

Business Process Management as a discipline is the main enabler of achieving best-in-class processes, but how do you actually deliver value as soon as possible when starting such a BPM initiative? Over the last ten years there have been many examples of large BPM initiatives using state of the art tooling like IDS Scheer’s ARIS platform where the results have been less than stellar and some where the ROI has been decidedly negative.

 

Main reason for this negative ROI has been that although modeling your processes extensively and in detail can bring clarity in how you want to run your business, it does not actually change anything in the way your processes run: it is a documentation of a “wished-for” state of affairs. Implementing this to-be set of processes is disjunct from the models you have prepared and agreed.

 

For some time now a new “holy grail” of business process management has been defined which promises to bridge the age old gap between Business and IT: the arrival on the scene of Business Process Management Systems. These systems enable the (layered) modeling of business processes just like the old modeling environments, but they have one crucial additional characteristic: they can actually run the process you have modeled: “What you model is what you run”.

 

The principle behind these BPMS-es is that you model the processes using a very specific modeling language, which has execution capabilities under the hood. These execution capabilities are intrinsic to the model, because each symbol and diagram element has a specific meaning in terms of execution. By mapping the model to underlying executable objects, such as application components or Services created by SOA-design the functionality from various sources can be executed. The flow of the process can then be actively managed from within the process layer in the BPMS. If a process step is delayed or throws an exception the process layer can react on this and enable steps to be taken to remedy any fault situation that occurs.

 

The result: super efficient processes that can be managed end-to-end instead of piecemeal by different departments applying different back end silo-systems.

 

Even in the current relatively immature technology status of these new tools the results when used in the right context can be spectacular. In a recent real life project using the latest (and brand new) SAP BPM technology the average process throughput time of an end to end process was reduced from three weeks to one day. You can imagine that significant ROI is achieved with metrics such as these.

 

Now BPM is a rather complex animal, because it requires an integrated approach from Business and IT to deliver the desired results.

There are basically two main approaches to BPM: one is holistic and top down, the other is tactical and bottom up. The real benefits appear when both approaches are used together.

 

The top down approach involves definition of an improved set of business processes applying business architecture and value chain modeling concepts enabled by enterprise modeling tools like ARIS from IDS Scheer.

 

The bottom up approach involves careful selection of one or more “broken processes” involving several departments, manual handovers, silo IT systems and considerable slack in processing time. Using the BPMS tooling a new process is designed and implemented in conjunction with required back end functionality. After successful implementation the next process on the list is “attacked” and improved.

 

Both approaches used together will produce both the fastest and most strategic results. This will however also increase the complexity of organizing the BPM initiative and will require a framework to make it all work.

 

The picture below shows just such a framework. It is based on a few simple principles:

v      BPM initiatives are rooted in business strategy and take business models as their starting point

v      Requirements drive all initiatives, large or small

v      Prioritization and sequencing of individual projects is driven by enterprise level modeling and analysis

v      Execution tooling only comes into play at the level of the individual projects

v      BPM initiatives are cyclical and iterative in nature

 

 

image

 

But then it immediately becomes apparent that to make such a framework actually work you need a strong, integrated methodology unifying all stakeholders, models, execution programs across departmental boundaries and disciplines. And does the world really need another separate framework?

 Enterprise Architecture as the natural Framework for BPM

We have already established that the greatest potential for a positive ROI of BPM is achieved when a top-down strategic approach is combined with a bottom-up tactical implementation approach.

 

The natural framework to use for this purpose is a widely used Enterprise Architecture framework, preferably a process oriented one like The Open Group Architecture Framework (TOGAF) or the TOGAF-based SAP Enterprise Architecture Framework (EAF).

 

TOGAF provides a holistic, end to end and iterative framework that enables continuous improvement. It brings together all disciplines and stakeholders required for Enterprise Architecture, butalso Enterprise BPM, and it aligns exceptionally well both with regular Enterprise Governance processes on the business side and the standard IT development cycles.

 

Key in TOGAF is the principle of multiple iterations improving the existing enterprise architecture. Any development or change is based upon a clear statement of requirements, and is designed, implemented and governed from a holistic perspective. Business architecture drives required Information Systems and Technology architectures, project execution is always part of program portfolio management, and changes to existing solutions are evaluated, planned and implemented using the same iterative governance model.

 

BPM initiatives fit naturally in this framework. The top-down BPM approach can deliver as well as at the same time be part of the TOGAF Strategic Framework definition, the Business Architecture definition and strategic Portfolio Planning. The bottom-up tactical BPM implementation approach tackles Requirements definition, and is managed in execution by the Opportunity & Solutions mapping, Migration Planning and Project Implementation governance phases of TOGAF.

 

If we take a closer look at the Enterprise BPM Framework as shown in figure 1 there is a clear similarity in the way the phases and concerns of the framework with the standard TOGAF model. As such, it can be easily mapped on the TOGAF cycle as shown in the picture below.

image

 

One of the key challenges of Enterprise BPM is to bridge the traditional gaps between Business and IT. The new generation of BPMS systems enable holistic “what you model is what you run” solutions.

 

A holistic framework is required to manage the contributions of all end-to-end stakeholders, including business management, IT and even business partners.

 

Enterprise Architecture has developed a strong set of best practices in Business/IT alignment over the last ten years, culminating in industry-leading frameworks like TOGAF.

 

Business Process Architecture is an intrinsic part of Enterprise Architecture.

 

The way forward for Enterprise BPM is not to re-invent the wheel, but to include its specific requirements, methodologies and best practices in a framework like TOGAF.

 

A next blog will focus on best practices in architecture and BPM that can be aligned in each phase of TOGAF, starting with the Business Architecture phase of TOGAF.

To report this post you need to login first.

3 Comments

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

  1. Karthik Ramachandran
    Dear Hans,
      First of all, thank you for this very good blog.
    Would you like to comment on the matrices / diagrams that would be created after the respective phases in the methodology of TOGAF / EAF ?

    Would it make sense to think about catalogs too here ?

    Thanks !
    Karthik

    (0) 
    1. Anonymous
      Hi Karthik,

      Sorry for being so late to respond!
      I will discuss the deliverables and products of each phase in TOGAF as they pertain to BPM and will suggest some best practices as I go along.
      I am of course also very interested in concrete examples that you can provide.

      Best regards,
      Hans

      (0) 

Leave a Reply