Enterprise Specific BPM Languages and Tools

Enterprise Specific BPM Languages and Tools

Steen Brahe (Danske Bank, Denmark)
DOI: 10.4018/978-1-60566-669-3.ch002
OnDemand PDF Download:
No Current Special Offers


Many enterprises use their own domain concepts when they model business processes. They may also use technology in specialized ways when they implement the business processes in a Business Process Management (BPM) system. In contrast, BPM tools often provide a standard business process modeling language, a standard implementation technology and a fixed transformation that may generate the implementation from the model. This makes the tools inflexible and difficult to use. This chapter presents another approach. It applies the basic model driven development principles of direct representation and automation to BPM tools through a tool experiment in Danske Bank. We develop BPM tools that capture Danske Banks specific modeling concepts and use of technology and which automate the generation of code. An empirical evaluation reveals remarkable improvements in development productivity and code quality. We conclude that BPM tools should provide flexibility to allow customization to the specific needs of an enterprise.
Chapter Preview


Business Process Management (BPM) is currently receiving much focus from the industry. Top management demands to understand and control their business processes and agility to adjust them when market conditions change. This can be achieved through Process Aware Information Systems (Dumas et al.,2005). A BPM system (Jablonski and Bussler,1996; Leymann and Roller, 2000) is one example of such a system. It allows execution and automation of a business process that can be described explicitly as an executable workflow.

Although the hype about BPM and process automation is high, previous work has shown that it is relatively complex to understand, model and implement a business process as an executable workflow (Brahe, 2007). First the process must be understood, second it must be formalized and modeled at a highly conceptual and logical level, and third the process design must be transferred to technology. Many software vendors have complete BPM tool suites for modeling and implementing business processes. Such tools are mostly based on a predefined process modeling language like the Business Process Modeling Notation (BPMN) (White, 2006) for capturing the business process at the conceptual level and one technology like the Business Process Execution language (BPEL) (BPEL, 2003) for implementing the process. These tools also assume a fixed development process where only two models exist, i.e. the conceptual business process and the implementation.

Using such tools causes two challenges for an enterprise that has specific requirements to its development process, uses its own modeling concepts and uses technology in specialized ways; First, a standardized modeling notation does not allow users to use domain concepts and may contain too many modeling constructs which makes the tool difficult to use. The models may also be difficult to understand and use as a communication media. Second, transformation of a model into implementation must be done manually as the enterprise may use a variety of technologies to implement the process and not only e.g. BPEL as many state-of-the-art tools support today. Even if one technology as e.g. BPEL is used, the enterprise may be using its own implementation patterns which cannot be generated because the transformations are hard-coded into the BPM tools.

The approach behind current BPM tools is similar to the extinct Computer Aided Software Engineering (CASE) tools from the 90es. They also often used a standard modeling language, one implementation technology and a standardized transformation. Their limited flexibility in supporting enterprise specific standards was one of the reasons why they were never accepted (Windsor, 1986; Flynn et al., 1995).

This chapter takes another approach than state-of-the-art BPM tools. In order to avoid the CASE trap we must come up with an approach that allows an enterprise to use its own modeling notations and specific use of technology. Our hypothesis is that this can be achieved through applying the basic model driven development (Stahl et al., 2006) principles of direct representation and automation (Booch et al., 2004) to BPM tools; An enterprise should be able to model its business processes directly in enterprise specific concepts, decide on a target platform and write transformations that encapsulate its specific use of technology, and that automate the generation of code.

This leads us to the research question which we will answer through this chapter: Does an enterprise specific BPM tool improve the efficiency and quality of modeling and implementing business processes, how difficult is it to create, and is it worth the effort?.

We use a design research approach to answer this question; We will implement above hypothesis though an experiment where we develop BPM languages, tools and transformations for a specific enterprise. Successively, these will be empirically evaluated to show the validity of the hypothesis. We use Danske Bank, the second largest financial institute in northern Europe, as a case study. In lack of sufficient industrial standards, Danske Bank has defined its own development process and uses a number of different tools to support it. This has caused several challenges as described by Brahe (2007).

Key Terms in this Chapter

Domain Specific Language: (DSL) A specialized programming or a modeling language that allows expressing solutions directly in concepts of a problem domain.

Workflow Specification: A document that describes additional information required to implement a Solution Process Flow model in Danske Banks extended BPM system.

Eventmap: A model of all business events that may occur in a given business context.

Solution Process Flow: A logical or conceptual model of a business process. It specifies business logic for one business event.

Control Flow Behavior: A physical model of a business process. It specifies how the process should be implemented in BPEL.

BPM Tools: A collection of modeling and implementation tools specialized for modeling a business process and implement it as a workflow in a workflow language.

Model Driven Development: A development paradigm that focuses on using models in software development. Models are used for analysis, simulation, verification and code generation

Model Transformation: A model transformation takes one or several source models and generates one or several target models, or textural documents. It is based on a transformation definition that specifies how to map elements in the source DSLs to elements in the target DSLs

Complete Chapter List

Search this Book: