Model driven development for business performance management.

This basic approach has been further refined and the software transformation components made more robust by implementing the solution on many IBM Research projects, such as Distributed Enterprise Services (DES) and On Demand Distributed Computing Services (ODCS). MDD BPM is still in an early stage of development, but is expected to continue gaining wider acceptance. The work we are presenting is part of the larger Model Driven Business Transformation (MDBT) toolkit effort within IBM Research. The MDBT toolkit with instruction documents is available to download.

Related work

Due to its high-level abstraction and code reuse feature, the MDD methodology has been widely applied in related areas such as software reuse, (18,19) reverse engineering, (20) and user interface design. (21) The benefits of adopting MDD include reduced software development time, enhanced code quality, and improved code maintenance. (10,22)

There are also numerous related works about business processes. Widely considered as an extension of a workflow management system, business process management enables the management and analysis of operational business processes. (23) Most recent work has focused on modeling business processes, consistency checking for model integration, and composing Web services and business processes by using the model-driven approach. (24-26) Recently, model transformation has received much attention because it can bridge between source models and target models. (22,27) Though there are many standards defining individual models, there is no one model transformation standard. Domain-specific languages (28-30) and UML profiles have been defined and used to express the transformation logic or mapping rules.

Our work focuses on a generic model-driven framework that aims at code customization, code reuse, merging multiple models, and constraint validation. Due to the well-defined BPM observation metamodel and the many strict constraints imposed by it, we chose to deal with the model transformation and mapping the code after the code-generation phase for both the source model and target model. We used the well-developed Eclipse Modeling Framework (EMF) (31) to generate model manipulation code for instantiating in-memory model instances, which have strong built-in validations.

To better understand our technology framework, we used the IBM DES project as an example and a generalized scenario.

SAMPLE SCENARIO

The IBM DES pilot project was the first to demonstrate the BPM solution using UML models and MDD techniques. We describe DES and then a sample scenario known as service delivery.

Large enterprises with a number of relatively homogeneous but independently operating sites at which the central value of the enterprise is created are referred to as distributed enterprises. Examples are national retail chains or banks with many branch offices. Each property operates in many ways as an independent business but with varying degrees of central ownership, shared resources, and business function. Such enterprises have a project management office (PMO) that centrally serves the needs of the distributed customers, promotes the efficient use of resources, and manages costs by using economies of scale. This scenario is called the service delivery model, and a generalized business process for such a model is shown in Figure 4. The business operations were defined as an artifact(32,33) based model, a business modeling technique particularly suited to direct business goal mapping and business integration. The operational model of the business consists of the steps required to achieve operational goals and the flow of business artifacts through them.

[FIGURE 4 OMITTED]

The goal of delivering a complete service to a customer site on an agreed-upon schedule is captured in the DES operational delivery model. Actually, it involves two interacting sets of goals: satisfying customer needs and performing specific services to that end. This leads to three primary artifacts:

1. Schedule--An attachment to a statement of work for services and equipment delivered to a particular site. The schedule is the primary artifact for customer delivery interactions. Services defined in the schedule include a delivery plan organized by task. The task information maintained in the schedule represents units of work required to complete the schedule, including service provision and equipment delivery.

2. Supplier task--A unit of work performed by a service provider.

3. Project--A set of schedules.

Process monitoring, measurement, and metric information can be obtained by monitoring the process events generated at probe points within tasks and repositories. Figure 4 shows the event source probe points E1, E2, and E3. These events must contain sufficient information for correlation and metric calculation. The BPM technique can be used to provide sophisticated real-time notification of complex patterns of events. An entire suite of composite metrics can be updated at the end of each business event.

GUIDELINES FOR IMPLEMENTING A BPM SOLUTION

Based on our experiences with DES and several other projects, we have developed a set of guidelines that can ease the task of designing and developing a complex BPM solution (Table 1). Although the guidelines are expressed as six steps, we recognize that it might take several iterations of design and development before an optimal level of solution maturity is achieved and business monitoring requirements are met. It is advisable to start with a project of small scope with few metrics, but important enough for stakeholders to measure the success of BPM technology.

Step 1: To gather requirements, the end user of the solution and the sources of the input data for the BPM runtime system are determined, and the reports that the end user would like to see on the dashboard are identified. It is also necessary to identify the metrics (business goals) that the end user wants to monitor, the business conditions that must be detected, and the actions that may need to be taken. Some metrics may be related to one another; others may need sophisticated calculation. Gather all such information at this stage. The input data sources might be well-defined business processes that emit (generate) business events, existing data warehouses, or operational databases. It is important that an agreement is reached with the stakeholders regarding the business goals and how these goals are defined and calculated.

In the DES scenario, the input data sources are business events. The end users are of two types, operational and executive. For operational metrics, we selected the following key performance indicators (KPIs):

[] Total number of schedules or tasks by status (planned, live, completed, or canceled)

[] Total outstanding schedules or tasks at the project level

[] Time span between when schedules and tasks are planned and their actual completion time

[] Total time between plan and completion at the project level

Executive-level metrics might be total service-level agreement (SLA) violations and the total number of pending schedules. Metric results can be displayed on the dashboard in real time and one can probe more deeply for finer detail and see broader aggregate views.

Step 2: The requirements are analyzed to identify the elements needed for the BPM model. These might include events, KPIs, metrics, management contexts, business conditions, and reports. One needs to identify appropriate metrics and their relationships with other metrics and the management context.

In the case of the sample scenario, the events identified were ScheduleEvent and TaskOrderEvent. The management contexts identified were bySchedule, byTaskOrder, and byProject. Similarly, metrics and business conditions need to be defined without ambiguity because the BPM solution is modeled based on these elements. Later, we show the BPM elements in a requirement model.

Step 3: BPM requirements are modeled using RSA with extended UML2 profiles for BPM elements. For clarity, it is a good idea to create an individual model for each management context identified in Step 2. One might need to go back to Steps 1 and 2 while modeling the solution. The models created in this step are the OMs. The details of how models are created are given in subsequent sections.

Step 4: To augment the OM, the expressions that are needed to calculate metrics or to add business conditions or outbound events in response to changing business situations are provided. Also, it is determined whether there is a need for data warehousing. If so, the appropriate data warehouse model needs to be created, based on the OM created in Step 3.

Step 5: The transformation of the models is performed by selecting the transformation menu in RSA. The transformation results in the generation of intermediate models in the output folder. Usually one does not need to perform any updates at this stage, but if there are certain complex needs that could not be addressed by means of our model framework, this would be the time to reflect those changes in the intermediate models. This step may also be of use if non-modeled BPM solutions are transformed to our intermediate models and there is a need for updating.

Step 6: From the intermediate models, the Platform-Specific Model, code, and deployment scripts are generated. The person managing the deployment then deploys the various components in the appropriate environment (Figure 3).

BPM MODELS