BPM: Knowing the Future Means Knowing the Past (Part II of II)

Untitled Document

See Part I for a background on BPM development.



As a result of Business Process Management evolving over two states it cannot only be defined from one perspective -- below are two definitions catering to both the business and technology perspectives of BPM:

  • BPM is a management discipline concerned with managing change to improve business processes that is cross functional in nature and makes extensive use of technology to model processes, analyze the model, automate the processes and measure and optimize process performance.
  • BPM is unifying the previously distinct disciplines of Process Modeling, Simulation, Workflow, Enterprise Application Integration and Business to business integration into a single organizational platform or infrastructure.

If we consider the two definitions above we see three core focal points in defining BPM, as a much confusion has occurred when defining BPM.

The first focal point when defining BPM is that it is a management discipline -- more focused on the business side of the organization, where issues such as organizational change management are taken into account. However, as many of us have realized one is not able to embark on a BPM journey without technology playing an enabling role.

The second focal point when defining BPM is that it is a new software technology -- this is not entirely true as the underlying concepts and principles that the Business Process Management Suites unify under a single organizational platform or infrastructure have existed for many years, the only difference now is that they have been packaged into a single offering.

The third and final focal point when defining BPM is that it is a new type of implementation. This is probably where the greatest progress has been made with regards to BPM, as businesses are now able to drastically reduce if not eliminate the round-tripping aspects of business application implementation. Through the ability that the BPMS's now provide businesses are able to model a business process and then have the preconfigured application rendered for business confirmation of the requirements within minutes, allowing for a more iterative nature of business requirements gathering and the true realization of Model Driven Architecture.

In the final phase of this business evolution we will consider Business Process Re-engineering (BPR) as compared to Business Process Management. The initial point of comparison will consider the current business processes within the organization. From a BPR stand point the thinking was that the processes are fundamentally flawed and an entirely new set of processes will need to be engineered; whereas the BPM thinking is more in line with TQM, one would take the current processes as they are and automate them to continuously and incrementally improve. One key aspect to bear in mind here is that one should begin automating ones processes as soon as possible -- as the realization of MDA within the BPMS now provide one the ability to very quickly rectify bottlenecks or waste within a process there is no longer a need to conduct large scale process analysis engagements before beginning with automation.

The second point of comparison is that BPR initiatives conducted workshops and joint application development sessions (JAD's) with business users, the primary goal being to produce a document containing all the organizations business processes. BPM initiative conduct workshops and JAD's to ensure that the business processes become a living component of the organization, as models are now documented within technology to enable MDA and the ability to immediately assess from a business application aspect that all the business requirements are in fact realized.

The third comparison is that BPR defined the organization into silo's and is function based whereas BPM defines the organization end-to-end and across functions and is results based.

The fourth comparison is that BPR engagements typically took anything between 6 to 24 months to provide any form of return on investment whereas BPM engagements can now show return on investments in as little as 90 days.

The fifth comparison -- in BPR engagements IT and business collaboration is optional whereas in BPM engagements collaboration is critical, as BPMSs are intertwining the Business and IT roles to provide adaptability and agility to an organization.

The sixth comparison is that BPR was fundamentally focused on cost reduction whereas BPM is focused on asset optimization -- or the ability to increase capacity while still utilizing the same number of resources.

The seventh comparison pretains to the nature an engagement is implemented; traditionally and in most instances today a waterfall or system development lifecycle approach is adopted. BPM engagements should be conducted in an iterative manner, with the approach being aligned to rapid application development.

The final point of comparison is that within BPR engagements workflow and enterprise application integration were utilized each within a standalone environment. With BPM there is the advent of the BPMS which provides a single organizational platform that unifies previously standalone environments.

Now that we have established the differences between BPR and BPM we will turn our attention to three of the core process methodologies that have been developed over the years.

The first methodology we will adress is Six Sigma; its primary focus is that of reducing variation, the end result being standardization. The manner in which BPMSs cater to reducing variation is through simulating processes. BPMSs can create multiple scenarios against which simulations can be run and then produce graphical and tabular representations of the results all at a touch of a button. These results are then interpreted and the necessary adjustments made in order to ensure that the process variation is minimal and standardization is achieved.

The second methodology is Lean Engineering; its primary focus is to remove waste and ensure that the flow time of a process is as short as possible. BPMSs achieve this through their ability to monitor the flow of the process in real-time, highlighting bottlenecks or activities that do not provide value. BPMSs also cater to Lean Engineering in their ability to distribute work via push or pull mechanisms.

The third methodology is The Theory of Constraints; primary focus is to elevate or exploite constraints and in so doing ensuring faster throughput and increased capacity. The end result of this methodology is to determine the maximum amount of volume that can be pushed through a given process before the process reverts to a chaotic state. The mechanism utilized by BPMSs to enable this is Service Level Agreement (SLA) escalation. BPMSs provide the ability to specify an SLA per activity. Should these SLAs not be met escalation procedures can be activated, ensuring that the constraints are addressed sooner rather than later.

To conclude this section of BPM we will discuss Business Process Modeling Notation otherwise known as BPMN. BPMN was first initiated by the Business Process Management Initiative whose core focus was to develop a modeling notation that would be readily understandable by all stakeholders, these being business users, business analyst, technical analysts and developers. BPMN plays a key role in the realization of MDA and as a result I will briefly describe the core element set.


Figure 2

As graphically illustrated in Figure 2 above the core elements of BPMN are:

  • Flow Objects: signal the start or end of a Business Process Diagram (BPD), what tasks and activities are conducted within the BPD and how the flow is routed. Flow objects are comprised of:
    • Events - An event is something that "happens" during the course of a business process. These events affect the flow of the process and usually have a cause (trigger) or an impact (result). Events are circles with open centers to allow internal markers to differentiate different triggers or results. There are three types of Events, based on when they affect the flow: Start, Intermediate, and End.
    • Activities - An activity is a generic term for work that the company performs. An activity can be atomic or non-atomic (compound). The types of activities that are a part of a Process Model are: Process, Sub-Process, and Task. Tasks and Sub-Processes are rounded rectangles.
    • Gateways - A Gateway is used to control the divergence and convergence of Sequence Flow. Thus, it will determine branching, forking, merging, and joining of paths. An element placed within the diamond shape indicates the type of behavior control.
  • Connecting Objects: indicate the direction of the flow of the process within the BPD and are comprised of:
    • Sequence Flow - A Sequence Flow is a solid line with a filled triangular arrow-head used to show the order that activities will be performed in a Process.
    • Message Flow - A Message Flow is used to show the flow of messages between two participants that are prepared to send and receive them. In BPMN, two separate Pools in the Diagram will represent the two participants (e.g. business entities or business roles).
    • Association - An Association is a solid line with an open arrow-head used to associate information with Flow Objects. Text and graphical non-Flow Objects can be associated with the Flow Objects.
  • Swimlanes: these elements act as containers for organizations, departments or roles and are comprised of:
    • Pool - A Pool represents a Participant in a Process. A Pool can contain one or more swimlanes however; it can also act as a "swimlane" and a graphical container for partitioning a set of activities from other Pools, usually in the context of B2B situations.
    • Lanes - A Lane is a sub-partition within a Pool and will extend the entire length of the Pool, either vertically or horizontally. Lanes are used to organize and categorize activities.
  • Artifacts: provide the ability to provide metadata to the BPD and are comprised of:
    • Data Object - Data objects are considered Artifacts because they do not have any direct effect on the Sequence Flow or Message Flow of the Process, but they do provide information about what activities are required to be performed and/or what these activities produce.
    • Text Annotation - Text Annotations are a mechanism for a modeler to provide additional information for the reader of a BPD.
    • Group - A grouping of activities that does not affect the Sequence Flow. The grouping can be used for documentation or analysis purposes. Groups can also be used to identify the activities of a distributed transaction depicted across more than one Pool.

With the business evolution concluded I will now describe the technology evolution and how this evolution has occurred from standalone applications to workflow to business process management.

In describing the technology evolution I will measure each one of the components of this evolution against its core focus, application type, organizational impact, reporting capability, ability to update and adapt processes and its MDA capability.

The first component of the evolution is standalone applications and with these applications I have also grouped imaging/document management applications. If we look at the core focus of the standalone application it was to define a sequence of events and these would traditionally be either manual or custom applications. Standalone applications organizational impact was very much functional or silo specific as a result of the application being a point solution. Standalone applications reporting capability were very basic and in most instances one had to wait for the end of the month for batch reports which resulted in a very reactive approach to problem solving. In terms of its ability to update and adapt processes this would take several weeks if not months as custom code had to be developed and the full System Development Lifecycle needs to be followed. From a model driven architecture perspective standalone applications did not have any modeling capability and so could not realize MDA.

The second component of the evolution is workflow applications, which core focus is the routing of tasks. It began from the imaging and document management applications where organizations once had their documents in electronic format. They soon realized that they needed to route these documents to assessors, decision makers, etc. From an application type perspective workflow applications were fairly tightly coupled between integrated applications as custom Application Programming Interfaces (API's) were utilized. Workflow applications organizational impact was as per standalone applications as these solutions were still very functional or silo specific. The reporting capability still resulted in a reactive approach to problem solving however the ability to generate reports in shorter time periods did improve. Workflow applications ability to update and adapt processes would take several weeks as once again custom developed code would be manually created and would then need to go through the testing lifecycle. From a MDA perspective workflow applications had some modeling capability although there would still be a significant amount of custom development that would be required to be undertaken in order to meet the business requirements.

The final component of the evolution is business process management, which focuses on the process of lifecycle management -- taking into account the business processes, escalations, SLA's etc. The application type from a BPMS perspective utilized standard adapters when conducting enterprise application integration and for business to business integration web services. Its organizational impact is across the value chain and enterprise wide thereby ensuring that the processes are managed from inception to completion. BPMS have the ability to conduct dashboard and real-time reporting, resulting in the organizations ability to be proactive in problem resolution, as soon as issues or errors occur with a process these can now be rectified. This leads to the ability to identify, avoid or mitigate issues before they occur. BPMS's ability to update and adapt to processes is extremely high and can in most instances be conducted within hours if not minutes. BPMSs have at its core business process modeling and almost all utilize BPMN as their modeling notation of choice. With business process models at its core BPMSs are able to truly realize MDA.

This then concludes our technology evolution and now with both the business and technology evolutions described it is time to discuss the missing link and really the glue that brings business and technology together in this evolution cycle -- model driven architecture.


Figure 3

Figure 3 above indicates the model driven architecture continuum and as we move from left to right the ability to execute against a model increases along with the ability to generate code automatically.

Let's start on the left hand side of Figure 3 at the code only stage; this typically occurred in the assembler and mainframe days when pages and pages of code were written in one monolithic application. This naturally made maintenance and enhancements to the code extremely challenging and led to code visualization where code began to be modularized or packaged, becoming the module that one could depict a diagram of broken code with.

We now find ourselves at the round-tripping stage and amazingly almost 80 to 90 percent of organizations are still at this stage of the continuum. They first send in the business analyst who models a business process, it is then passed on to a systems analyst who models this business process in terms of technology and it is finally passed onto the developer who produces an application which in most instances may not be 100% correct as the market may have changed in the time that elapsed.

With the advent of workflow applications we started to move to the model centric stage and began to aquire a better understanding of the concept of a model where one could graphically model the process and code stubs would be automatically generated. However, not all the requirements were met. As a result one still had to customize 70 to 80 percent of the application.

The final stage of the model driven architecture continuum is where BPMSs are today. One can merely model a business process and have a preconfigured application automatically generated, thus eliminating the round-tripping effect and meeting the business requirements to within 80 to 90 percent. The 10 to 20 percent of customization still required consists of integrating into existing line of business systems.