Article Preview
TopIntroduction
A primary motivation for business process modeling is to define requirements for information technology (IT) systems that support the business operations of an enterprise. To create process models, subject matter experts record the activities that are performed, their sequencing, and their data inputs and outputs. The implementation of these models in IT solutions has generally followed one of two arduous paths:
- (1)
Business process models are simply documentation of requirements. From these documents, IT solutions are manually designed and implemented by writing custom code, or by customizing and integrating legacy applications and packaged software; or
- (2)
Business process models are automatically converted into workflow definitions which are deployed on workflow engines and augmented with custom code (WfMC, 1995).
The first approach leads to the well-known business-IT gap, characterized by IT solutions that implement misinterpreted requirements, are overdue and over budget, provide inadequate support to operations, and are unresponsive to business changes.
The second approach faces difficulties as well. The workflow approach does not scale well to large, complex business processes. Implementation and maintenance become increasingly difficult and performance degrades. The primary reason for this is that the workflow approach does not lend itself well to componentization (Alonso et al., 1997). Service-Oriented Architecture (SOA) (Arsanjani et al., 2008; Zimmerman et al., 2004) can help to address the complexity and flexibility issues of business processes, and the value of aligning business processes with SOA is well addressed (Arsanjani et al., 2008; Zimmerman et al., 2004). However, this approach suffers from the lack of systematic methods to identify services and service components at the right level of granularity, and to orchestrate services into business processes (Zimmerman et al., 2004). The ad-hoc definitions of services and service components often leave an enterprise with a large, difficult-to-maintain portfolio of inconsistent services.
In response to this situation, a paradigm which models business processes as interacting lifecycles of business entities has been proposed. Appropriately, this approach is called information-centric process modeling. Business entities that are used to describe business processes in this manner have had various names, including adaptive documents (ADoc) (Kumaran et al., 2003), adaptive business objects (ABO) (Nandi et al., 2005), and business artifacts (Nigam & Caswell, 2003). In this paper, we will refer to them as business entities. Information-centric modeling first identifies the business entities, or records essential to achieving an operational goal, such as a customer order, and then represents business processes in terms of the lifecycles of the identified business entities, which manage progress towards the goal (Nigam & Caswell, 2003; Bhattacharya, Caswell, Kumaran, Nigam, & Wu, 2007). Information-centric modeling, as exemplified by Model-Driven Business Transformation (Kumaran, 2004), reduces the business-IT gap by enabling the direct generation of business process applications from information-centric process models. Information-centric modeling improves modularity and reduces complexity by decomposing a business process into interacting business entities, each being a module with an information model and a behavior model.