Introducing Business Entities and the Business Entity Definition Language

In a new article, Data4BPM, IBM’s Prabir Nandi, Dieter König, Simon Moser, Richard Hull, Vlad Klicnik, Shane Claussen, Matthias Kloppmann and John Vergo introduce the concept of business entities as a means of representing the business view of data. They propose two new standards, the Business Entity Definition Language (BEDL) and BPEL4Data for the holistic design and execution of process with Business Entities.

According to the authors:

In most business process management tool suites, data is treated mostly as an afterthought. Activities and their flows are the main abstractions and the data manipulated by the processes is essentially hidden in process variables. The presentation and aggregation of data is handled outside of the process definition, and implemented through generic service calls. This process-only approach ignores the important data perspective during business operation analysis, often obscures key aspects of the operations, and can lead to costly re-factoring throughout the solution lifecycle.

In their article they promote making data entities first class citizens of the process design and introduce Business Entities as:

... key business-relevant dynamic conceptual objects that are created, evolved, and (typically) archived as they pass through the operations of an enterprise. A Business Entity includes both an information model for data about the business objects during their lifetime, and a lifecycle model, which describes the possible ways and timings that tasks can be invoked and performed on these objects.

The article proposes a Business Entity Definition Language (BEDL) which defines the BEDL meta-model and syntax, discussing possible runtime architecture to support BEDL specifications. It also presents an overview of BPEL4Data - an approach for extending the BPEL standard to support explicit interoperation with BEDL components.

The proposed BEDL is based on the notion of Business Entity (BE) that has four main components: information model, lifecycle model, access policies and notifications. The information model of BE types is specified as a family of attribute/value pairs, where an XML schema is associated with each attribute that governs the structure of the corresponding values. Not all attributes have to be present in BE all the time. The lifecycle model for BE is specified as a finite state machine. The lifecycle specification itself does not provide detail on the activities that might be performed while a given BE instance is in a given state, nor the activities that might be performed as part of transitioning a BE instance from one state to another. They are typically expressed using BPEL which is used to supplement BE definition. BE access policies are focusing on two main: CRUD defining policies for modification of BE’s information model (or parts of this model), and Executions, defining policies for lifecycle model transitions. The last part of a BE specifications are notifications which define BE activities (changes) that might be of interest to external parties, for example, other processes.

A software component supporting BEDL provides an interface that enables external components to invoke the following capabilities:

• Requesting BE types metadata- a query interface allowing to obtain the schemas of the BE types that it is supporting.
• Accessing a Business Entity instance’s data - a CRUD interface allowing to manipulate BE’s attributes. This interface is a subject to CRUD permissions.
• Querying on BE instances - a query interface allowing to get the references to all BE instances that satisfy a query.
• Executing state transitions of a BE - a control interface instructing BE to move to a different state. This interface also includes the creation of BE instances. State transition is subject to the BE lifecycle and Execution permissions.
• Locking/unlocking (parts of) a BE instance - an interface supporting concurrency control for BE instances.
• Subscribing to data or state changes of a class of BE instances - an interface enabling to subscribe to notifications about BE’s data and state changes. This interface is subject to CRUD permissions, while an attempt is made to read BE’s changes.

The article also provides an example,of designing of a Courier Shipment BE type.

Article authors envision a specialized BE runtime, responsible for managing instances associated with multiple BE types. They discuss two flavors of such runtime:

• In the "green field" case BE runtime manages the actual BE instance data (including both attribute values and instance state) in a specialized data store - BE content store. The BE runtime, in this case, is responsible for enforcing data access policies and and sending notifications to BE subscribers.
• In the "brown field" case, it is assumed that most of the BE data is already being stored by legacy applications. In this case, instead of replicating the data, the BE runtime can be augmented with a persistent store that holds data that can be used to link or connect the BE information view of data with the legacy application view of the data.

Although BE runtime has provisions for manipulating BE data and state it does not provide any support for defining execution of state transition.It instead relies on external process, for example,BPEL/BPMN -based process, a two-tiered Web application, an off-the-shelf packaged application or a Master Data Management (MDM) maintenance workflow or a XPDL-based application.

The article outlines the following advantages of using BEs:

• Customer satisfaction

  • The BE approach complements the traditional top-down, process-centric way of decomposing business operation domains... for business processes with a large end-to-end scope, starting the design activity with a few key Business Entities provides an insight and clarity very early that is rarely achieved with the complexity of a multi-level process decomposition...
  • The BE approach enables substantially improved communication across different silos of an enterprise, because in many cases a BE type spans multiple silos, and provides a common vocabulary for the stakeholders of those different silos.

Simplicity, flexibility and time to value

• Using the BE approach, one can capture the key entities, their states and tasks that change states rather quickly even for a large complicated system...
• The approach forces a simple (but complete) start and then a spiral evolution of the design as all requirements are modeled incrementally but always stay consistent and coherent.
• Business Entity lifecycle states represent process milestones and a reflection of business objectives.

Cost reduction

• As more requirements are modeled up-front, there is less re-factorization and ripple downstream. This results in fewer change requests late in the solution development lifecycle, and in the deployment and maintenance lifecycle.
• Processes are factored around the entity life cycles. This increases the scope for reuse of the process definitions. It also leads to agility in design, as changes can be localized in process fragments without affecting other parts of design.

Data modeling is definitely an important part of process definition, but typically it is used on the enterprise semantic data model level. Whether extending its notion to BE, as defined in the article, will really makes process design and implementation better still remains to be seen.