One of the most successful innovations of the BPMS vendors to date has been incorporation of process modeling within the suite. Process modeling used to be a standalone business activity, requiring expensive proprietary tools that gave little thought to any automated IT implementation. By adding a modeling tool to the suite – separate from the executable process design tool, but linked to it via shared artifacts – BPMS took a critical first step toward one of BPM’s principal objectives, bridging the gap between business and IT.
Because it assumes an eventual IT implementation, BPMS’s process modeling component looks a lot different from its predecessors in the business process analysis (BPA) and enterprise architecture (EA) worlds. Instead of a proprietary notation and metamodel, it leverages BPMN, an industry standard, and emphasizes a combination of simplicity, expressiveness, and semantic precision. That combination allows the process model to serve as more than vague “business requirements” for the to-be implementation. In leading BPMSs, the BPMN model is an artifact shared with IT and actually incorporated into the executable design. Moreover, because it is standardized, the modeling tools are low-cost, in many cases free, and understanding of the notation is no longer isolated to a small priesthood in the organization.
But the BPA and EA suites offer something that BPMSs still mostly do not: a repository of business-oriented modeling artifacts. BPMSs today provide some form of repository for executable design artifacts, but these are meant for developers not business analysts. As BPM evolves in most organizations from isolated projects to enterprise-scale programs, the need for such a business-oriented repository is now becoming apparent to BPMS vendors, and I think in 2009 it will become a key differentiator in the BPMS competitive landscape.
Such a repository would include artifacts such as the following:
- BPMN models of processes and subprocesses. If you wanted to understand how other parts of your enterprise handle new account opening, customer complaints, or employee expense reimbursement, you could find it here. If certain compliance procedures were mandated for all departments, you could find it here. Process models describe the activity flow abstractly, without implementation detail, referencing participants as roles not named individuals or groups. This part of the repository should be geared toward encouraging standardization and best practice reuse across the organization.
- Common data objects, such as Customer and Order, based on a standardized “business-oriented” representation. Data modeling is a thorny issue in BPM because developers assume, often correctly, that business people do not understand all the technical details of data elements needed for optimum executable implementation. But giving business analysts the ability to define and view common data structures like Customer or Order, or process-specific form data elements, is also important. Without that, they can have no say concerning task user interface, business rules, or the KPIs used to measure success. Let’s face it, without referencing data you can’t do a whole lot in BPM. Moreover, including data models in the repository would likely simplify the BPMS, since today each part of the design environment often has its own data model.
- Decision models, also known as business rules. BPMS vendors have finally figured out that decisions, aka business rules, need to be maintained independently of the processes that use them, but few BPMSs provide a rule repository of any sort. Decisions often reflect policies that cut across individual processes. They provide a way to simplify process design, especially when the particular activities required depend on complex attributes of the instance: If the customer is from New York and has multiple accounts with us, then do Activity A; etc. Also, decision services increase agility, since on-the-fly rule parameter changes can have immediate effect without versioning deployed processes. But that only increases the need for impact analysis capability. Which processes would be affected by a change to this ruleset? The repository should be able to answer that.
- KPI models based on process data. Suddenly empowered to create actionable KPIs, many business analysts are not sure where to start. Specifying the queries that define each KPI is hard enough; deciding on the target range is nearly impossible. Most users would rather start with KPIs developed by “experts” elsewhere in the company. The repository should make performance monitoring components easily findable and shareable throughout the organization.
- Business metadata for deployed business services. SOA platforms typically provide a service registry/repository that specifies the technical interface of deployed services: the endpoint location, the input and output messages, security parameters, etc. But this is not all the metadata business needs to know. If an activity in the process model is “Add customer to SAP system,” modelers should be able to see if such a service operation exists, where it is located, whether it is intended for (or even accessible to) use by their part of the organization, and what other processes are using the service. In other words, the service needs to be “business-discoverable.”
You could argue that such a repository and additional models would simply replicate a BPA suite inside the BPMS. And to a certain extent that’s true, except that just as they did with the BPMN tool, BPMS vendors are more likely to eliminate the bloat and focus on something simpler, more streamlined, less expensive, and totally integrated with the BPMS’s executable design environment. The business artifact repository will not replace the developer’s registry/repository, and some form of federation of the two is likely. Look for leading BPMS vendors to tout their repositories next year.
