Model driven development for business performance management.

INTRODUCTION

Business Performance Management (BPM) (1-4) has emerged as a critical discipline to enable enterprises to manage their business solutions in an on demand fashion. Gartner has coined the term business activity monitoring (BAM) (3) and predicts significant growth in this area. With such wide interest, the market has been flooded with terminology similar to BAM, creating some confusion. It is not the intent of this paper to attempt to clarify this confusion; we direct the reader to Reference 2, which describes in detail the IBM BPM approach and how it is positioned with respect to competing terminology. Even before Gartner drew attention to the need large enterprises had for BAM, Stephan Haeckel of the IBM Advanced Business Institute described in his book the transformation from a make-and-sell organization to a sense-and-respond organization. (5) Inspired by Haeckel's work and market needs, various IBM divisions have been developing methodologies, frameworks, tools, and software components to support adaptive enterprises. IBM Research has been active in the development of this technology and has sponsored several pilot projects (6,7) to better understand its applicability and benefits.

From the IBM point of view, (1,2) a BPM system is an on demand platform for business performance monitoring and control. It takes data monitored from targeted business solutions and events, invokes BPM services, and renders actions back to the target business solutions. The BPM reference architecture and its components are described in Reference 2, p. 37. The BPM architecture for our solution closely follows the reference architecture.

Originally, models were used in software development solely for the purpose of documentation and presentation. The advent of extensible tools (8,9) brought about Model Driven Development ** (MDD **). With it, users could create new notations to express an artifact in a model and attach software components to it. This ability makes it possible to automate the transformation of user-annotated enhanced models into deployed code and services. In recent years, new emphasis in research and development has focused on MDD (10,11) as an alternative to traditional software development methodology.

Once BPM systems are implemented, they are very hard to change because they are engineered as software development solutions that are linear and rigid or because the monitoring solution derives from process models. Solutions derived from processes are flexible but not comprehensive enough to include the nonprocess metrics needed to represent the full state of a business. Thus, a BPM approach not based on models can fall short of fully meeting business needs.

The abstraction of the BPM solution to higher-level models, as we propose, overcomes the shortcomings of BPM alone. It enables business analysts and system architects to contribute directly to the solution. The MDD approach to BPM means that business goals can be defined independent of an information technology (IT) platform. Business-level models either provide linkage to or can be automatically transformed directly to IT-level models using transformation routines. MDD can quickly reflect changing business goals and monitoring needs through models. This paper explains our modeling approach to BPM and demonstrates the ease of use of our modeling framework. We also describe the modeling annotations of various artifacts that make up the BPM solution and the process of automating the production of code from model to deployment.

OVERVIEW OF OUR APPROACH

We have developed a technology framework and software platform to represent a BPM solution by using formal BPM models in a top-down fashion. We have also developed model software components that can be attached to a modeling tool and that can automate the transformation of BPM models into deployable code.

The BPM modeling framework is a refinement and augmentation of the observation metamodel. At a high level, it captures the following aspects of a BPM solution: information gathering from real-time business events and other data sources, information aggregation to calculate business metrics, recognition of situations warranting business actions, and the invocation of actions that address the situations detected.

To enable the representation of a solution using models, we decompose various aspects of BPM into smaller manageable components, called BPM elements. These elements, together with their operational semantics, comprise the BPM metamodel. The elements are designed with ease of use in mind and are at the same time rich enough to represent a complete BPM solution. To represent BPM elements, we chose Unified Modeling Language ** (UML **) with UML Version 2.0 (UML2) profiles (12) for extension. We selected IBM Rational * Software Architect (RSA), which supports UML model extensions. Figure 1 represents the various BPM elements and their relationships with one another. Together, they collectively comprise the BPM metamodel.

[FIGURE 1 OMITTED]

The UML representation of the metamodel helps if one is designing a solution from the beginning, but if someone has an existing solution in some representation and does not want to start with BPM UML models, we also provide a representation of the BPM metamodel as an Extensible Markup Language (XML) definition. (13) This enables users to transform their solution into an XML representation.

A BPM solution as a UML model can be created with the elements shown in Figure 1 by using the RSA modeling tool. One can then use the software component plug-in to perform an automated trans formation of the model into a deployment module (e.g., a monitor runtime, data warehouse, or dashboard module). The automated transformation hides the complex inner workings of the transformations that create intermediate metamodels. The code is generated based on these intermediate models and finally packaged for deployment. One can make changes to the intermediate models to further augment the model if desired, but normally it is not needed. One also has the choice to go back to the UML model and make changes as needed. This can be an iterative process until a satisfactory version of the model is created. With MDD, business analysts can visually design BPM solutions without development team involvement.

Figure 2 shows the BPM tooling flow and user roles. In the modeling stage, one can start with either an XML editor or RSA. Both approaches can generate an observation model (OM), represented in the XML Metadata Interchange (XMI **) format. (14) In this paper, we focus on using the RSA approach.

[FIGURE 2 OMITTED]

Once the model is created, the transformation generates intermediate models, such as the OM and the data warehouse model. The intermediate models then generate code. In the figure, we show observation, action, and visibility code being generated. The code generated then generates what we call a deployment module, and each module contains multiple services.

The next step is to deploy these service components to their respective runtime environments. Figure 3 shows input sources and the deployment of BPM components, including their respective software. (The indicated execution steps are discussed later in the section on sample scenario execution.)

[FIGURE 3 OMITTED]

Input sources are modeled in UML. (Later we describe how to represent such input sources.) If an ad hoc event is input, then the data is sent through the event infrastructure, which could be, for example, an Enterprise Service Bus (ESB) (15) or Common Event Infrastructure (CEI) (16) (our choice). BPM services is a collection of runtime services and their deployment scripts generated from the BPM models. The BPM services collectively process incoming data, correlate and compute metrics, evaluate business or IT situations, send alert notifications through preferred channels, and store processed data in an operational data store (ODS). The Extraction, Transformation, and Loading (ETL) service processes data by pulling it from the ODS on a periodic basis, transforming the data, and storing transformed data in the data warehouse. The management dashboard retrieves data from the data warehouse and generates reports.

Advantages of the MDD approach

Our MDD approach to BPM has advantages over general IT systems development because the expressive power of our BPM metamodel is purposely restricted to generic and relatively simple con structs, such as metrics, maps, dimensions, business events, situations, and actions (Figure 1). By restricting the expressive power, we assure that a well-defined, nonambiguous solution is generated. In addition, our model takes a holistic view of monitoring requirements and can represent them with formal models. Our solution also performs basic model validation to assure that the BPM elements used are semantically correct and can be automatically transformed into deployable code. Our solution is deterministic and repetitive and supports the iterative MDD approach. It also generates a default dashboard component that can be deployed on the IBM DB2 * Alphablox (17); hence, one can view the output of a modeled solution and change or add features to the models.