Petko Chobantonov

Sunday, March 19, 2006

BPRI (Business Process Runtime Interface)

I’m actively participating in defining business process related standards at OMG. One of those standards is the BPRI (Business Process Runtime Interface). The goal is to define a common interface for the execution engines produced by different vendors. Having such interface will drive more value for the users of such execution engines as it will reduce the long term cost. Further it will allow creating a new market for environments that will use those execution engines to provide further value to customers.

I think that there are several parts of such engine runtime interface:

Engine Interface

This part allows the following functionality
  • Start / Stop / Terminate Process. Someone could consider that the same functionality could be achieved using "Start Message Event" or "Terminate Event" in BPMN. However to use this functionality the process must be designed with this knowledge.
  • A standard interface to execute queries and to get some results back. This is the equivalent of JDBC/ODBC in the DB world.
  • Listener interfaces. For example: Every time a process or activity is started I would like an additional functionality to be invoked
  • Other important engine interfaces
Query Language
There are a lot of languages that can be used here - OCL, SQL, EJB QL, Hibernate QL, etc. Every language has some advantages and some disadvantages.


Standard Runtime Model

I think that this is very important information. The runtime model is not part of BPDM e.g. it is not design time data. It is equivalent in the DB World to have a standard set of tables describing runtime data. The standard should have the ability to define new tables and new columns on those entities.

For example:
Assuming that the standards defines a model class "Task" with the following properties
• TaskId: String
• Subject: String
• State: Enum {"Open", "Closed"}
• UserId: String

Here are several uses cases:

Using SQL, someone should be able to do the following:

Selecting all tasks of a specific user:
select TaskId, Subject
from Task
where UserId = 'John'

Selecting all opened tasks
select TaskId, Subject
from Task
where State = 'Open'

The same queries could be expressed in OCL.

However in order to express those queries we need standard set of classes, attributes and relationships between those classes. Without this BPRI customers don't know what to query on.

Monday, February 27, 2006

Model Driven Business

I’m working at Lombardi Software where we are developing BPM (Business Process Management) platform. Lombardi Software is the leading BPM vendor. It’s interesting to contemplate how BPM will change the business in the next 10 years. I think we are just in the beginning of the model-driven business era. Business Processes are very important part of a model-driven business. There are other important models too – like the Business Motivation Model.

Imagine that we have defined a model of a business company. Some obvious properties are the name of the company, relationships to its employees, employee skills, etc. This model will allow business analysts to express knowledge about a particular company using this model. Further someone could perform analysis over employee skills and maybe to figure out which skills must be improved in order to gain better ROI. For example: Six Sigma defines different levels of competency (black belts, green belts, etc.). Imagine a BPM Platform that can figure out which skills must be improved for which people in an enterprise. This could have significant impact for the company.

I don’t think that there will be one single model that will be able to express everything needed. Probably there will be different models and software programs will transform between them. This will avoid getting an agreement from a lot of people and will still serve the main purpose – express your ideas. At the end of the day we still do not have a single language (we have multiple languages - English, French, …), but we do successfully exchange ideas.