International Journal of Services Computing (ISSN ) Vol. 2, No. 1, January - March 2014

11

A

N

I

NTEGRATIVE

A

PPROACH TO

S

UPPORT

M

ULTI

-P

ERSPECTIVE

B

USINESS

P

ROCESS

M

ODELING

Keletso J. Letsholo, Erol-Valeriu Chioasca and Liping Zhao

School of Computer Science

The University of Manchester

Manchester, U.K.

{letsholk, chioasca, lzhao}@cs.man.ac.uk

Abstract

Business process modeling (BPM) has become a dominating approach for organizations to understand, plan and optimize their business processes. BPM has also become an important part in service systems development because it helps to identify service activities embedded in business processes. Several modeling languages have been developed to support BPM, including IDEF, BPMN and EPC. Yet, our research shows that these languages still lack comprehensive constructs for representing some core business concepts, such as business goals, non-functional requirements and resources. This paper has two related purposes: First, it uses the Zachman Framework to assess the modeling capabilities of some of the popular BPM languages to identify their modeling gaps. The Zachman Framework is known to be comprehensive for representing different business perspectives. Second, the paper proposes an integrative approach to support multi-perspective BPM, so as to bridge the identified modeling gaps. This approach is illustrated through an example. The proposed approach aims at supporting the creation of comprehensive models and facilitating a common understanding of business perspectives regardless of the languages that represent them. The main benefit of the proposed approach is its integration of existing modeling languages that are familiar to business analysts, rather than introducing new languages. Further it provides guidance for business analysts and helps them to select appropriate modeling languages.

Keywords: Business Process Modeling, Zachman Framework, Modeling Perspectives, Modeling Languages.

___________________________________________________________________________________________________________________________

1.

I

NTRODUCTION

Process modeling has been embraced as an appropriate approach for visually describing how businesses conduct their operations and also for increased awareness of business process knowledge (Curtis, Kellner, & Over, 1992). Moreover, process modeling focuses on understanding the underlying business process elements that are fundamental to the design and implementation of information systems that satisfy the business strategy.

Early efforts on representing the dynamic behavior of organizations, dating back to the 1960s and 1970s, have resulted in several business analysis and modeling languages, including Flowcharting (Schriber, 1980), Business Information Analysis and Integration Technique (BIAIT) (Carlson, 1979), Business Information Characterization Study (BICS) (Kerner, 1979), and Frame-work for Information System Architecture (Zachman, 2003). Business process modeling (BPM), seems to have emerged in the 1980s during the movement of business process design and re-engineering, to

represent processes through which work is accomplished within an organization (Curtis et al., 1992; Davenport & Short, 1990). BPM is similar to information systems modeling (ISM) (Curtis et al., 1992; Davenport & Short, 1990), they both share a common set of notations, such as Data flow, Control flow, State Transition, Entity Relationship diagram, Petri Nets (Murata, 1989), and UML (Rumbaugh, Jacobson, & Booch, 1999). A review of BPM and ISM languages is given in (Aguilar-Saven, 2004; Giaglis, 2001).

A business process is an ordered sequence of activities and events, designed to achieve a defined business objective. A comprehensive business process description therefore, needs to incorporate answers to the following questions: what activities are being performed and how, what objects are manipulated; when activities are performed; where and by whom they performed; finally, why are they performed. These interrogatives are referred to as perspectives in conceptual modeling, elaborated in (Curtis et al., 1992; Frankel et al., 2003) as follows:

12  Functional perspective: represents what process

elements (activities) are being performed.

 Behavioral perspective: represents when and how activities are performed.

 Operational perspective: represents where and by whom in the organization are activities performed.  Informational perspective: represents what

informational entities are being manipulated by activities.

 Goal perspective: represents why activities performed.

In spite of these perspectives, a prevailing concern in the body of information systems literature is that no single process modeling language is fully capable of describing or representing all the perspectives (Brooks, 1987; Hickey & Davis, 2004; Maiden & Rugg, 1996). Attempts towards addressing this concern have resulted in two possible research paths. One path is towards extending existing methods‘ schema to incorporate the representation of missing concepts. For example, BPMN (OMG, 2011) is inadequate in representing information and goal perspectives (Recker, 2010; Zhao, Letsholo, Chioasca, & Sampaio, 2012). Efforts have been made towards extending BPMN to incorporate these perspectives into its modeling portfolio (Gorton & Reiff-Marganiec, 2006; Recker, Indulska, & Green, 2007; Saeedi, Zhao, & Sampaio, 2010). However, such efforts are fragmented, and are not aligned with the overall BPMN schema. In the second path, BPM could adopt multi-perspective modeling frameworks similar to the ones proposed in (Frank, 2002; Hickey & Davis, 2004; Kruchten, 1995; Rumbaugh et al., 1999). This paper follows the second path. We posit that a unified modeling approach should entail a coordinated effort on the development of a common framework for model creation, extension, composition, and management.

This paper1 serves two purposes: First, it uses the Zachman Framework to assess modeling capabilities gaps of process modeling languages. Second, motivated by the assessment results and guided by business process schema (Figure 1), it proposes an integrative approach to support multi-perspective modeling of business processes. The approach suggests other requirements modeling languages such as goal-oriented and data-oriented languages, to bridge the identified gaps.

The paper proceeds as follows. Section 12 introduces different perspectives in business modeling, while Section 3 presents an overview of BPM languages and identifies their modeling capability gaps. Section 4 describes our approach and Section 5 illustrates this approach with an

1_{An early version of this paper was presented at the 9}th

International Conference on Service Computing (Letsholo, Chioasca, & Zhao, 2012).

example. Section 6 discusses our approach in relation to similar work and Section 7 gives a summary of the paper and identifies future work.

2.

P

ERSPECTIVES IN

B

USINESS

M

ODELING

2.1 Business Process Schema

In this Section, we describe a generic schema (Figure 1) that serves as the basis for defining business processes. To ensure comprehensiveness, the schema is developed in line with conceptual frameworks proposed in (Curtis et al., 1992; Frankel et al., 2003). The schema provides a foundation for capturing knowledge from what is being performed, and how, who performs it, where and when, and why is it being performed. The captured knowledge is capable of analyzing and integrating underlying concepts of an enterprise. Goals describe the objectives of a business process and are realized by activities. A business process is a composition of activities structured in some way to achieve the business goal. An Activity may be either atomic or compound and is performed by agents. Activities transform resources into specific products or services. A Resource represents the subject matter in a business process. A Resource may be physical, conceptual or financial, for example book, message or money. A Container denotes the boundary of an operation (physical or conceptual) where actions are performed. Examples of containers include geographical locations, departments, companies, and software systems. An Agent represents responsibility assignments (human or machine). Agents are part of a container, for example employees in a company. Events capture the order in which activities are performed as well as aspects of how they are performed. Examples include decisions, timing and exception handling events.

Goal * achieves owns performs Process Event Activity Resource Agent 1 triggers acts on Container part of * 1

13

2.2 Zachman Framework

The Zachman Enterprise Engineering Framework (Zachman, 2003) is a two dimensional, multi-perspective scheme for describing and modeling an enterprise and its software systems. The framework is made of six columns and five rows. The columns classify a business into different facets through What, How, Where, Who, When, and Why interrogatives whereas the rows show these business facets from the perspectives of Planner, Owner, Designer, Builder, and Sub-contractor. Crossing each row by each column, results in a cell, which contains a unique business model.

Although not proved mathematically, Zachman claims that the columns and rows in his framework are both primitive and comprehensive. He states that when used together, these rows and columns provide a complete description of a business. According to our observation, the What, How, Where, Who, When, and Why interrogatives are universal in conceptual modeling (Curtis et al., 1992; Dardenne, Van Lamsweerde, & Fickas, 1993; Lohse, Min, & Olson, 1995; Sowa, 1984). Under the guise of different analogies or synonyms: What (entity, object, subject, material, resource, information, thing); How (operation, process, function, activity, task, action); Where (location, place, container, network, structure); Who (agent, actor, people, machine); When (time, event, exceptions); Why (motivation, purpose, goal, objective, strategy, policy, desired state). This suggests that they constitute a fundamental set of modeling concepts, even if they may not form a complete set.

In this paper, we focus on the Owner perspective due to its core concern in tackling conceptual modeling issues. Figure 2 shows a set of business models from this perspective. A summary of concept mappings between this perspective and business process schema constructs is presented on Table I.

 What (Data Model): the generic representation of this model is Thing—Relationship—Thing. This model ad-dress the informational entities produced or manipulated by activities.

 How (Function Model): the generic representation of this model is Process—Input/Output—Process. This model gives the functional perspective of the process being performed.

 Where (Network Model): the generic representation of this model is Node—Line—Node. The model presents the organizational perspective, where the process elements are performed.

 Who (People Model): the generic representation of this model is People—Work—People. This model represents the agents responsible for performing activities.

 When (Time Model): the generic representation of this model is Event—Circle—Event. This model represents the behavioral perspective of the enterprise.

 Why (Motivation Model): the generic representation of this model is End-Means-End. End is the desired state while means is a course of action employed to realize the end state.

3.

I

DENTIFYING

M

ODELING

C

APABILITY

G

APS

BPM has received a lot of attention from both researchers and practitioners; consequently, several modeling languages have been developed. This paper reviews BPM languages presented in information systems and requirements engineering literature from the 1980s to present. The following survey and review articles on business process modeling languages (Aguilar-Saven, 2004; Giaglis, 2001; List & Korherr, 2006; Söderström, Andersson, Johannesson, Perjons, & Wangler, 2006),

DATA What (Things) FUNCTION How (Process) PEOPLE Who (People) NETWORK Where (Location) MOTIVATION Why (Motivation) TIME When (Time) Semantic Model

Ent = Business entity Rein = Business relationship

BUSINESS MODEL (Conceptual) Owner Business Process Model

Proc = Business process I/O = Business resources

Business Logistics System

Node = Business location Link = Business linkage

Work Flow Model

People = Organization unit Work = Work product

Business Plan

End = Business objective Means = Business strategy

Master Schedule

Time = Business event Cycle = Business cycle

Figure 2. Zachman Framework: the Owner's Perspective

Zachman Model Business Process Schema

What(Data) Resource How (Functional) Process/ Activity Where (Network) Container Who (People) Agent When (Time) Event Why (Motivation) Goal

Table I. Mapping Business Process Schema onto Zachman Models

14 provided useful information on known application areas,

limitations, modeling capabilities, and basic notation constructs of the languages. This paper only describes languages that are well established in research and industry.

3.1

BPM

L

-

A

O

Business Process Modeling Notation (BPMN) (OMG, 2011) is a single diagrammatic notation based on a flowcharting technique. Through this technique a Business Process Diagram (BPD) is produced, which is a network of graphical objects, consisting of activities and flow controls that define activities‘ performance order. BPMN‘s modeling constructs are divided into four basic categories: flow objects, connectors, artifacts and swim lanes.

Integrated DEFinition (IDEF3) (Mayer et al., 1995) is a family of methods developed by US Air Force in the mid-1970s. IDEF3 Process Description Capture method captures the behavioral aspects of a process and represents them in the context of a scenario. IDEF3 supports both process-centric and object-centric descriptions. A process-centric view captures knowledge on ―how things work‖ in an organization, while the object-centric view describes the objects allowable state transitions in a particular process.

UML Activity Diagram (Rumbaugh et al., 1999) represents activities and work-flows within a software system. The basic constructs used includes activity, fork or join control flows, and a swim lane to organize the activities according to their responsibilities.

Petri Nets (Murata, 1989) were designed with an aim of modeling the dynamic behavior of concurrent systems and nondeterministic procedures. A Petri Net is a directed graph with two nodes, places and transitions. Places represent possible states of the system. Transitions represent events or actions that cause the change of state. In process modeling terms, places represent conditions, and transitions represent events. A transition has a number of inputs and output places representing pre-conditions and post-pre-conditions of an event.

Role Activity Diagram (RAD) was developed originally for modeling coordination, but it also used today for modeling business processes. An RAD is a flowcharting notation that describes responsibilities assignments. A role is a set of related responsibilities or activities that can be performed by an agent. In general, RAD comprises a set of activities, decisions and transactions.

Event Driven Process Chains (EPC) (Mendling, 2009) is a flowcharting language used for representing temporal and logical dependencies of activities in a business process. EPC notation offers function type elements to capture activities of a process and event type elements describing pre-conditions and post-conditions of functions.

Additionally, the notation is capable to capturing organizational units and process owners.

Although efforts have been made towards developing a framework for assessing BPM languages (Giaglis, 2001; List & Korherr, 2006; Söderström et al., 2006), these efforts are still not aligned with the overall business process schema. Most assessments have concentrated on a subset of modeling perspectives whilst ignoring others. Several authors (Batini, Ceri, & Navathe, 1992; Moody & Shanks, 1994; Wand & Weber, 1993; Wang & Strong, 1996) have mentioned criteria for judging the quality of an informational perspective. Although their focus is on the informational perspective, we believe the proposed criteria can be used for assessing other perspectives in business process modeling. The most common criteria include:

 Completeness – the extent to which the modeling constructs sufficiently express all the perspectives of the modeled domain (Batini et al., 1992; Moody & Shanks, 1994; Wand & Weber, 1993) .

 Consistency – the extent to which the statements in the model do not contradict each other and minimal overlapping concepts as much as possible (Wand & Weber, 1993; Wang & Strong, 1996).

 Comprehensibility – the model should be easy enough to understand so that it could be used as a platform for communication (Batini et al., 1992; Curtis et al., 1992; Moody & Shanks, 1994).

3.2

A

R

The assessment presented in this section uses Zachman Framework as a yardstick to judge the comprehensiveness of modeling languages. We analyzed the modeling notation/schema/meta-model for the languages presented in Table II to check for the availability of constructs or elements to represent Zachman‘s perspectives. Table II gives a summary of the evaluation results. The ‗+/+‘ symbol denotes that the language has modeling constructs (notation) available to strongly represent that particular perspective. The ‗-/+‘ symbol indicates that the perspective is weakly supported by the language‘s notation and ‗-/-‘ indicates that the perspective is not represented by the language.

From the assessment results, we note that BPM languages differ in their modeling capabilities. Some modeling languages focus mainly on one business perspective while partially focused on other perspectives. For example, some have focused primarily on functions, others on behavior, and yet others on informational resources. In general, Functional and Time perspectives are well supported or represented by BPM languages. Data perspective is weakly supported while Network and People's perspectives are supported by some languages (BPMN, AD, RAD) and not supported by others (IDEF3, PN). Any BPM languages do not explicitly support the Motivation perspective.

15

3.3

D

G

O

M

L

In Table II, Goal-oriented and Data-oriented requirements modeling languages are included in the assessment. These languages specialize on perspectives weakly supported by BPM languages. Hence, these modeling languages are used to complement BPM languages. Data-oriented modeling languages (e.g., Entity Relationship Model, Data Flow Diagram, and UML Class Diagram) capture and represent informational entities within a software system. These entities can be streamlined into building blocks (objects, classes, methods, messages, inheritance and the like) used in all phases of development, from requirements to implementation.

Goal-oriented modeling languages (e.g., i* Framework (Yu, 1995), KAOS (Dardenne et al., 1993), TROPOS (Castro, Kolp, & Mylopoulos, 2002)) uses the concept of Goal to reason about requirements and to handle non-functional requirements. A Goal specifies what the system must meet and achieve, but not how. Thus, a Goal is realized by several atomic functions causing state changes on informational entities. At this level, the analyst is primarily concerned with exposing ―why‖ particular behaviors, informational and structural aspects were chosen to be included in the system requirement.

4.

T

HE

P

ROPOSED

A

PPROACH

This section presents the proposed integrative BPM approach which combines key strength of several other modeling languages to adequately represent all the aspect of a business process. Two major processes support the proposed approach. First, is to classify business domain knowledge according to the six facets of Zachman Framework (separation of concerns). The various models are not fully independent; concepts from one model are

connected to the other, based on the business process schema. Second, selecting an appropriate modeling language to represents each of the perspectives. The merit of using combination of modeling languages lies in the fact that a specialized language can be complemented with other languages, where the former is lacking.

4.1

S

C

This component classifies business domain knowledge according to different modeling perspectives. An effective requirements engineering approach must reconcile the need to achieve separation of concerns with the need to satisfy broadly scoped requirements and constraints. By treating all concerns as equal, we can choose any set of concerns as a base for addressing the problem under investigation. This faceted view of business concepts makes it possible to handle crosscutting concepts (concepts shared by multiple perspectives).

An important component when classifying business concepts is the business domain ontology. This is ontology of business concepts and their relationships, classified according to six modeling facets, namely: Goal, Functional, Informational, Behavioral, Agent, and Location. Based on keywords captured during requirements elicitation, software analyst with the help of the business domain ontology can form operational definitions. Operational definitions are formed by mapping or relating keywords to relevant facets in the domain knowledge ontology, hence adding meaning to the keywords.

Figure 3 shows the architecture for classifying business domain knowledge. The Goal facet includes concepts that describe purpose, objective, intention, qualities and desired states of a business process. A Goal is decomposed into several tasks, which are instances of the Functional facet. The concepts for the Functional facet are identified as verbs, denoting actions or activities that manipulate informational entities. Activities may take some input and transform it into a particular output. The Informational facet captures resources (physical or

BPM Language Goal-Oriented Data-Oriented

Zachman Framework BPMN IDEF3 AD PN RAD EPC i* KAOS TROPOS ER DFD CD

What(Data) -/+ +/+ -/+ -/+ -/- -/+ -/+ -/- -/- +/+ +/+ +/+ How (Functional) +/+ +/+ +/+ -/+ +/+ +/+ -/+ -/+ -/+ -/+ -/+ -/-Where (Network) +/+ -/- +/+ -/- +/+ +/+ -/- -/- -/+ -/- -/- -/-Who (People) +/+ -/- -/+ -/- +/+ -/+ +/+ -/+ +/+ -/+ -/- -/+ When (Time) +/+ +/+ +/+ +/+ +/+ +/+ -/- -/- -/- -/- -/- -/-Why (Motivation) -/- -/- -/- -/- -/- -/- +/+ +/+ +/+ -/- -/-

Legend: +/+ Notation available / possible to represent; -/+ Notation partially available / possible to represent -/- Notation not available / not possible to represent

AD - Activity Diagram; PN - Petri Nets; KAOS - Goal-Driven Requirements Engineering; ER - Entity-Relationship Model; DFD - Data Flow Diagram; CD - UML Class Diagram

16 conceptual), which are often identified as nouns or noun

phrases that may or may not be coupled with a state descriptor (e.g., available or unavailable, etc.). Behavioral facet is made up of concepts that describe the order in which activities are performed. These include sequences, timing and exception handling events. Location facet groups concepts that denote geographical locations where actions are performed. Additionally they may denote containers where informational entities are stored. Finally the Agent facet classifies concepts that denote responsibility assignments (i.e., human or machine).

4.2

S

M

L

According to Hickey & Davis (2004), software analysts use a particular modeling language for any combination of the following reasons. (1) It is the only language they know. (2) It is their favorite language for all situations. (3) They are following a certain methodology that prescribes that particular language. (4) They understand intuitively that the language is effective in that particular situation. The fourth reason is an ideal level of maturity expected from analysts, but it is not always the case. Analysts do not always understand intuitively available languages and their context of application.

We propose the use of a modeling language ontology that contains knowledge on the key properties of modeling languages. This knowledge will support analysts when selecting an appropriate language for the problem at hand. Figure 4 shows a partial listing for the BPMN descriptor; note that only four facets are shown (Functional, Behavioral, Location, and Agent). This is so because BPMN is lacking in representing Informational and Goal perspectives. The selection is based on how close the language‘s properties are to the business concepts identified from a requirements specification. The selection criteria do not fix or restrict any aspect of the process model to any modeling language. The choice is guided by the characteristics of the problem and the solutions domains.

Our approach, allows analysts to start from any modeling language of their choice (e.g., whether it is their favorite or they are following a certain methodology). For the chosen language, one can then select other languages to complement their choice. This is done by moving horizontally on the matrix (see Figure 5) and selecting a specialized language where a chosen is lacking. For example, when modeling a particular business process, an analyst might choose BPMN as a base language. BPMN is fully capable to representing Functional, Location, Agent and Behavioral perspectives. However, it is limited on representing Informational and Goal perspectives. Moving horizontally on the matrix, Entity-Relationship (ER) model and i* Framework can be selected to complement BPMN respectively.

Modeling languages (i.e. UML, BPMN) provide little guidance on how detailed a requirement should be represented and offer little help on how a requirements specification should be decomposed, thus after a language is selected, the modeling process is based mainly on the analyst‘s experience and judgment. We assume that analysts are familiar with the mentioned modeling languages (Section 3).

To avoid overlapping concepts and model complexity issues, each modeling language concentrates on a subset

Figure 5. Matrix for selecting complementary modeling languages

Figure 3. Architecture for classifying business concepts

17 of modeling perspectives. A separate diagram for a subset

of business perspective(s) represented is created per modeling language. The output is a set of models, making up a business process model, incorporated into a requirements specification document to be used in the next phases of software development.

4.3

M

I

P

We regard an inconsistency as any situation in which two models representing different perspectives do not obey some relationship that should hold between them. This definition covers inconsistencies between models represented in different notations. This definition subsumes logical contradiction, but does not require us to translate specifications into a formal notation to detect inconsistencies. In order to detect inconsistencies, relationships that should hold between different perspectives are to be explicitly stated. The relationships may refer to both syntactic and semantic aspects of the models. They may also be process relationships, in the sense that two models may be inconsistent because they are at different stages of development.

The Zachman framework provides no mechanism to ensure the consistency or interoperability of the models created using the different languages, unless this task is accomplished by choosing a truly integrated family of languages (based on common metamodels). However, Nuseibeh, Kramer, & Finkelsteiin (1993) and (1994) proposed a flexible framework for expressing the relationships between multiple viewpoints in requirements specifications. This framework encourages multiple representations and is a deliberate move away from attempts to develop monolithic specification languages. It is independent of any particular software development method. Viewpoints are defined as loosely coupled, locally managed, and as distributable objects, which may overlap with each other. These overlaps are the focal point for consistency checking between viewpoints (Nuseibeh, Kramer, & Finkelstein, 2003). A viewpoint template, consisting of five slots, represents viewpoints: a style, a work plan, a domain, a specification, and a work record. The complex relationships between viewpoints should conform to inter-viewpoint rules defined in the work plan slot.

From our observation, the perspectives proposed in this paper can be incorporated into the style slot and work plan slot of the viewpoint template. In particular, the model representation can be defined in the style slot and the separation of concerns and selection of modeling languages can be defined in the work plan. The consistency between models representing different perspectives can be checked through defining the inter-viewpoint check actions in the work plan slot and invoking them when required. Consistency checking is

performed by applying a set of rules, defined by the method, which express the relationships that should hold between particular Viewpoints (Nuseibeh et al., 1994). These rules define partial consistency relationships between the different representation schemes. This allows consistency to be checked incrementally between viewpoints at particular stages, rather than being enforced as a matter of course. Furthermore, inconsistencies can be managed within individual perspectives. The modeling languages used in our framework (see Figure 5) are based on reliable ontologies (metamodels with semantic rules), to ensure the required consistency and determine the expressive power of modeling as required by the respective modeling perspective.

5.

C

ASE

S

TUDY

:

O

RDERING

M

ATERIAL

P

ROCESS

In this Section, we illustrate the applicability of our approach through a process for requesting and ordering material. This scenario is used for training new employees and enforcing company-purchasing standards. The following is a narrative description of the process:

“The first thing we do is request material using a Purchase Request form. Then the Purchasing department either identifies our current supplier for the kind of material requested or sets out to identify potential suppliers. If we have no current supplier for the needed item, Purchasing requests bids from potential suppliers and evaluates their bids to determine the best value. Once a supplier is chosen, Purchasing orders the requested material. Those requesting material must first prepare a Purchase Request. The requester must then obtain the Account Managers approval or that of the designated backup, for the purchase. Purchase Requests submitted for Account Manager approval must include the Account Number for the Project that will fund the purchase. Account Managers or their designated backup, are responsible for, and must approve, all purchases made against their project accounts. After the Account Manager approves the purchase, an authorization signature may be required. To avoid a potential conflict of interest, the requester cannot be the same individual who approves or authorizes the request. Purchase Requests involving Direct projects require an authorization signature whereas Indirect projects do not. Once all the appropriate signatures are in place, the requester submits the signed Purchase Request to Purchasing. Purchasing then orders the requested material and tracks it as a Purchase Order (Mayer et al., 1995, p. 12)”.

18

5.1

S

C

Figure 6 shows the identified business concepts from the scenario classified according to the different perspectives. Goals identified include: Request material, Order requested material, Authorize purchase request, Select supplier, etc. The ―Order requested material‖ goal is decomposed into three functions (Figure 6) which manipulates the purchase request and the purchase order form. The purchasing department performs these functions. The account manager is responsible for approving purchase requests, and in doing so, they perform two functions, first they check the account number; second they sign the purchase request form if a signature is required.

5.2

S

M

L

For this process, BPMN is selected as the base language. As already pointed out BPMN is inadequate in representing Informational and Goal perspectives, thus we select IDEF3 and i* Framework to complement BPMN. In the following sections, we illustrate how the selected languages are used to represent the different perspective.

Functional, Behavioral, Location, Agent. We represent the mentioned models using BPMN, mainly for the following reasons. Firstly, BPMN is a process-centric notation, capable of representing different types of processes; Secondly, BPMN supports the representation of multiple cross-cutting processes between different actors, departments and enterprises with the use of lanes and pools. Thirdly, BPMN schema fully supports the representation of events and control flows.

The business process diagram in Figure 7 consists of a network of activities (Functional), order of their performance (Behavioral), responsibility assignments (Agent) and responsibility boundaries (Location). Activities are denoted by rounded-corner rectangles and are connected by unidirectional lines indicating the order of execution. Activities are contained within lanes and pools. Decision points are denoted by gateways, for example, making a decision on whether to request for an authorization signature or not, is depicted by an XOR gateway. An intermediate timing event is also included to signify that purchasing department waits for two days before tracking their purchase order.

Materials Company (container) is represented with pool, and it is divided into four lanes (Requester, Account manager, Authorizer, Purchasing department), representing various agents and their roles. Supplier is external to the Materials Company therefore represented with a different pool. Activities for the Supplier are not shown on the diagram; however, interactions between the two enterprises are denoted by message flows.

Informational. For Informational modeling, we use IDEF3 Object Schematics, which is capable of capturing, managing, and displaying object-centered descriptions of a process. For instance, object transformations and state transitions during process execution. The following objects are identified: purchase request, purchase order, material, and account number. A purchase request form is a key document in this process, and is ultimately transformed into a purchase order via a sequence of activities. Figure 8 shows state transitions traversed by the purchase request form in an occurrence of an activity. From unprepared to prepared following the ―prepare purchase request‖ activity, then from prepared to approved after the account manager authorizes the purchase request. We have changed the Unit of Behavior (UOB) symbol in IDEF3 to match the activity symbol supported by BPMN. Furthermore, we changed the round circle object symbol, to avoid a conflict with an actor symbol in i* modeling framework discussed next.

Goal. To represent underlying motivations and intentions behind activities and flows in other process models, we use Strategic Dependency model presented in i* modeling framework. Figure 9 shows Strategic Dependency model of the Materials Company. Nodes represent actors or process participants; these are denoted as lanes in the business process diagram in Figure 7. Links between two actors indicates that one actor depends on the other in order for the former to achieve a particular goal. For instance, Requester‘s intention is to request material. In the process of requesting material, they depend on the Account Manager and Authorizer to approve and authorize the purchase request respectively. The process description did not explicitly state goals, objectives and or quality measures; hence, we make some assumptions during modeling (see Figure 9).

Figure 6. Partial Classification of business concepts from the Order Material Process

19

6.

R

ELATED

W

ORK

6.1

E

D

BPM

L

Although some efforts have been made towards developing a framework for assessing BPM languages, they are still fragmented and have limited coordination with the overall business process meta-model. Furthermore, a number of studies have been published on the evaluation of BPM languages. List & Korherr (2006) proposed a similar evaluation framework to the one proposed in this study. Their process meta-model is

categorized according to the perspectives proposed by Curtis et al. (1992), which are of Organizational, Functional, Behavioral, and Informational perspectives. These perspectives can be mapped to four models in Zachman framework. However, the Goal and Agent perspectives are not explicitly evaluated.

Giaglis (2001) presented a taxonomy of business process modeling and information systems modeling languages. This classification is to assist decision makers in comparatively evaluating and selecting suitable modeling languages. The taxonomy classifies modeling languages into four facets: informational; organizational (where, who); behavioral (when, how) and functional Figure 7. Functional, Network, People, Time Models – BPMN

20 (what). The intent or goal perspective is not included in

this classification.

Söderström et al. (2006) proposed a framework for comparing process modeling languages, which was used to compare three different process modeling languages: Business Modeling Language (BML), Event-driven Process Chains and UML State Diagrams. Similar to Zachman, this framework consists of a meta-model that classifies concepts into six interrogatives.

Wand & Weber (1993) proposed the BWW Framework which consists of a set of ontological constructs that are said to be necessary and sufficient to describe the structure and behavior of things in the real world. These constructs describe things in terms of their properties, types, states, transformations, events, and systems. The BWW Framework has been used to evaluate the strengths and weaknesses of process modeling languages in general (Green & Rosemann, 2000) and BPMN in particular (Recker, Indulska, Rosemann, & Green, 2006). The results of the latter evaluation show that BPMN is limited in representing states of things. A complete definition and description of the BWW constructs is given in (Wand & Weber, 1993) and (Green & Rosemann, 2000).

Krogstie (2003) proposed the Semiotic Quality Framework, an analytical framework that uses five quality criteria to analyze the quality of conceptual modeling languages. These quality measures include domain appropriateness; participant language appropriateness; knowledge appropriateness; comprehensibility appropriateness; and technical actor interpretation appropriateness. A detailed analysis of BPMN using this framework is presented in (Wahl & Sindre, 2005).

6.2

E

M

-P

F

The concept of multi-perspective models has long been recognized in the information systems discipline. General purpose modeling languages such as UML (Rumbaugh et al., 1999) dates back to the mid-1990s. UML in principle supports modeling of a wide range of application domains in object-oriented software systems. However, it does not provide sufficient concepts and graphical representations that are appropriate for all business perspectives (Frank, 2002). UML suffers from several shortcomings (see Mendling (2009) for an evaluation).

A theory of maximum ontological completeness (MOC) and minimum ontological overlap (MOO) based on observations of how users combine modeling languages is developed in Green, Rosemann, & Indulska (2005). This theory is useful in understanding how users utilize modeling languages to obtain maximum expressiveness from specific languages. The evaluation carried out for this theory imply that in practice analysts combine different modeling languages, hence, an integrative approach to guide this practice is needed.

Frameworks such as CIMOSA – Computer Integrated Manufacturing Open System Architecture (Kosanke, 1995), and ARIS – Architecture of Integrated Information Systems (Scheer, 2000) offer multi-perspective frameworks for information system architectures. ARIS specifies four views for business process modeling (Function, Organization, Data and Output), which are similar to the ones proposed in CIMOSA (Function, Information, Resource and Organization). However, these frameworks lack or did not specify modeling languages to represent their particular views. Although EPC is suggested in ARIS, our evaluation shows that EPC is inadequate in representing What, Who and Why models.

A similar approach to the one presented in this paper is MEMO – Multi Perspective Enterprise Modeling framework (Frank, 2002). This framework offers a set of visual modeling languages for describing corporate strategies, business processes, resources or information models. MEMO offers three specialized languages that support the construction of these models. The languages further support the representation of various interrelated concepts within the models. A downside to this initiative is that, it introduces new modeling languages. Given the abundance of process modeling languages, software engineers must do more than just create new languages. According to Scheer (2000), only a few of process modeling languages created are widely accepted in the BPM community. Therefore, an understanding of modeling capabilities and gaps of existing languages is required before inventing new languages. Furthermore, ways on how these gaps can be bridged need to be devised.

Figure 9. Motivation Model (Strategic Dependency) i* Framework

21 The approach presented in this paper goes further than

just identifying modeling perspectives. It promotes the leveraging of existing modeling languages through suggesting them for modeling the identified perspectives. Furthermore, the approach acts as a guide for selecting appropriate modeling language(s) for representing different perspectives of a business process. The selected modeling language is then complemented with other languages where the former is lacking. We do not advocate for a single modeling language that represents all modeling perspectives and still be applicable in all modeling situations. Such a language, according to Curtis et al. (1992) and Giaglis (2001), would generate complex models resulting on difficulties in communication. Rather, we argue for separation of concerns and the alignment of concerns with the business process schema. Thus, a specialized language can effectively represent each concern. For this purpose, a comprehensive business process schema is required. The emphasis for our approach is on creating comprehensive models, which entail a common understanding of concepts regardless of how they are represented.

6.3

T

S

M

-P

F

A typical software development task typically requires a combination of modeling languages, which may require the use of several modeling tools, which in turn calls for model interchange and cross-consistency checking capabilities. However, some developers have built tools that support multi-perspective frameworks in modeling. Thus, such tools can support a framework such as proposed in this paper.

Grundy, Hosking, & Mugridge (1998) proposed a software architecture, Change Propagation and Response Graphs (CPRGs), for managing inconsistencies in multiple view software development tools. This environment provides mechanisms for developers to configure inconsistency detection, allowing developers to choose the most suitable approach to inconsistency management for different artifacts, tools and process stages. Ptech, Inc. (2001) developed a methodology-independent integrated modeling environment called FrameWork. It is based on an object-oriented data structure whose semantics is fully defined via metamodels. Being a methodology neutral, FrameWork is claimed to have wide applicability (such as to be able to capture, analyze and design data and link it to organizations, activities, locations, etc.). FrameWork offers support for the Zachman framework via the Zachman framework Control Panel, containing a template and most of the model types required).

6.4

L

P

A

A prevailing concern for the proposed approach is the interoperability of data between multiple perspectives, which can be represented by different notations on different tools or even on different machines. This concern is augmented by the syntactic and semantic differences of information to be exchanged between perspectives. Integrating languages requires common concepts. The higher the level of semantics that is provided by those common concepts the tighter the integration (Frank, 2002). For instance: If two languages share a common notion of an integer, they are less integrated than two languages that share a common notion of an application level concept - because in the second case the chances for deviating interpretations are clearly lower. Our objective is to use modeling languages that conform to the Meta-Object Facility (MOF) standard developed by the Object Management Group (Kleppe, Warmer, & Bast, 2003). Hence, from a formal point of view, it will be easy to define common concepts for a set of modeling languages. However, metamodels for modeling languages such as KAOS, i*, IDEF, etc, are not yet defined in MOF standard.

Requirement modeling research is done in different communities and there is no common platform for agreeing on the definitions for notations. As a result, different models are created and managed autonomously by heterogeneous tools. There is a need for a holistic approach towards modeling that would allow different modeling perspectives to share relevant information. However, with the advent of frameworks such as Model-Driven Architecture (MDA) (Kleppe et al., 2003) a significant progress has been made towards developing common modeling standards, of which our integrative approach can benefit from.

7.

C

ONCLUSIONS

This paper presents an integrative approach to support multi-perspective BPM, which is guided by the six models of Zachman Framework (What, How, Where, Who, When, Why). The Zachman Framework is known to be comprehensive for representing different business perspectives and its models are universal in conceptual modeling. A comprehensive business process model should incorporate information such as what activities are being performed; what informational entities are being manipulated; when and how are they performed; where and by who are they performed; finally, why are they performed. The comprehensiveness of a BPM language is thus judged on how well it represents the above-mentioned perspectives.

22 The contribution made by this paper is twofold. First it

provides an evaluation of commonly used BPM languages against Zachman Framework. The evaluation results show that BPM languages in their current scope are inadequate to represent the Informational and Goal perspectives. Second, rather than extending or inventing new modeling languages, the paper presents an integrative approach that uses existing informational and goal-oriented languages to bridge the identified modeling gaps. The main benefit of the proposed approach is its integration of existing modeling languages that are familiar to business analysts, rather than introducing new languages. The proposed approach provides guidance for business analysts and helps them to select appropriate modeling languages.

In acknowledging that not all software analysts understand intuitively what modeling language(s) to use for problems at hand, we intend to further our work by developing a language selection tool. The tool will support the matching of business problems to appropriate modeling language(s), hence, assisting analysts in making informed decisions. The intention is not to restrict any perspective to a particular language, but rather, select appropriate languages for each modeling perspective based on the nature of the problem at hand.

8.

R

EFERENCES

Aguilar-Saven, R. S. (2004). Business Process Modelling:

Review and framework. International Journal of Production

Economics, 90(2), 129–149.

Batini, C., Ceri, S., & Navathe, S. (1992). Conceptual Database

Design: an entity-relationship approach. Unknown Journal.

Menlo Park: Benjamin/Cummings Pub. Co.

Brooks, F. P. (1987). No Silver Bullet Essence and Accidents of

Software Engineering. Computer, 20(4), 10–19.

doi:10.1109/MC.1987.1663532.

Carlson, W. M. (1979). Business Information Analysis and

Integration Technique (BIAIT): the new horizon. ACM SIGMIS

Database, 10(4), 3-9.

Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements-driven information systems engineering: the

Tropos project. Information Systems, 27(6), 365–389. doi:DOI:

10.1016/S0306-4379(02)00012-1

Curtis, B., Kellner, M. I., & Over, J. (1992). Process Modeling.

Commun. ACM, 35(9), 75–90.

Dardenne, A., Van Lamsweerde, A., & Fickas, S. (1993). Goal

Directed Requirements Acquisition. Science of computer

programming, 20(1-2), 3–50.

Davenport, T. H., & Short, J. E. (1990). The New Industrial Engineering: Information Technology and Business Process

Redesign. Sloan Management Review, 31(4), 1–27.

Frank, U. (2002). Multi-perspective Enterprise Modeling (MEMO) Conceptual Framework and Modeling Languages.

System Sciences, 2002. HICSS. (pp. 1258–1267). IEEE.

Frankel, D. S., Harmon, P., Mukerji, J., Odell, J., Owen, M., Rivitt, P., Rosen, M., et al. (2003). The Zachman Framework

and the OMG‘s Model Driven Architecture. Business Process

Trends.

Giaglis, G. M. (2001). A Taxonomy of Business Process Modeling and Information Systems Modeling Techniques.

International Journal of Flexible Manufacturing Systems, 13(2),

209–228.

Gorton, S., & Reiff-Marganiec, S. (2006). Towards a Task-Oriented, Policy-Driven Business Requirements Specification

for Web Services. Business Process Management, LNCS (Vol.

4102, pp. 465–470). Springer Berlin / Heidelberg.

Green, P., & Rosemann, M. (2000). Integrated process modeling:

An ontological evaluation. Information Systems, 25(2), 73–87.

doi:DOI: 10.1016/S0306-4379(00)00010-7

Green, P., Rosemann, M., & Indulska, M. (2005). Ontological Evaluation of Enterprise Systems Interoperability Using ebXML.

Knowledge and Data Engineering, IEEE Transactions on, 17(5),

713–725.

Grundy, J., Hosking, J., & Mugridge, W. B. (1998). Inconsistency Management for Multiple-View Software

Development Environments. Software Engineering, IEEE

Transactions on, 24(11), 960–981.

Hickey, A. M., & Davis, A. M. (2004). A Unified Model of

Requirements Elicitation. Journal of Management Information

Systems, 20(4), 65–84.

Kerner, D. V. (1979). Business Information Characterization

Study. ACM SIGMIS Database, 10(4), 10–17.

Kleppe, A. G., Warmer, J., & Bast, W. (2003). MDA Explained:

the model driven architecture: practice and promise.

Addison-Wesley Longman Publishing Co., Inc.

Kosanke, K. (1995). CIMOSA-Overview and Status. Computers

in Industry, 27(2), 101–109.

Krogstie, J. (2003). Evaluating UML using a generic quality

framework. UML and the Unified Process, 1–22.

Kruchten, P. B. (1995). The 4+ 1 View Model of Architecture.

Software, IEEE, 12(6), 42–50.

List, B., & Korherr, B. (2006). An Evaluation of Conceptual

Business Process Modelling Languages. Proceedings of the

2006 ACM symposium on Applied computing, SAC ‘06 (pp.

1532–1539). ACM.

Lohse, G. L., Min, D., & Olson, J. R. (1995). Cognitive

Evaluation of System Representation Diagrams. Information

and Management, 29(2), 79–94.

Maiden, N. A. M., & Rugg, G. (1996). ACRE: Selecting

Methods for Requirements Acquisition. Software Engineering

Journal, 11(3), 183–192.

Mayer, R., Menzel, C., Painter, M., deWitte, P., Blinn, T., &

Perakath, B. (1995). Information Integration for Concurrent

23

Method Report. Unknown Journal. Knowledge Based Systems,

Inc.

Mendling, J. (2009). Event-Driven Process Chains (EPC).

Metrics for Process Models, 17–57.

Moody, D., & Shanks, G. (1994). What makes a good data model? Evaluating the quality of entity relationship models. In P.

Loucopoulos (Ed.), Entity-Relationship Approach - ER ’94

Business Modelling and Re-Engineering, Lecture Notes in

Computer Science (Vol. 881, pp. 94–111). Springer Berlin / Heidelberg.

Murata, T. (1989). Petri Nets: Properties, analysis and

applications. Proceedings of the IEEE, 77(4), 541–580.

doi:10.1109/5.24143

Nuseibeh, B., Kramer, J., & Finkelsteiin, A. (1993). Expressing the relationships between multiple views in requirements

specification. Proceedings of the 15th international conference

on Software Engineering (pp. 187–196). IEEE Computer

Society Press.

Nuseibeh, B., Kramer, J., & Finkelstein, A. (1994). A framework for expressing the relationships between multiple

views in requirements specification. Software Engineering,

IEEE Transactions on, 20(10), 760–773.

Nuseibeh, B., Kramer, J., & Finkelstein, A. (2003). ViewPoints:

meaningful relationships are difficult! Software Engineering,

2003. Proceedings. 25th International Conference on (pp. 676–

681). IEEE.

OMG. (2011). Business Process Model and Notation (BPMN).

Unknown Journal. Retrieved from

http://www.omg.org/spec/BPMN/2.0

Ptech. (2001). IBM Enterprise Architecture Method enabled

through Ptech FrameWork. Retrieved from

http://www.channelingreality.com/Documents/IBM_Ptech_Fra meWork.pdf

Recker, J. (2010). Opportunities and Constraints: The current

struggle with BPMN. Business Process Management Journal,

16(1), 181–201.

Recker, J., Indulska, M., & Green, P. (2007). Extending Representational Analysis: BPMN User and Developer

Perspectives. Business Process Management, LNCS (Vol. 4714,

pp. 384–399). Springer Berlin / Heidelberg.

Recker, J., Indulska, M., Rosemann, M., & Green, P. (2006). How good is BPMN really? Insights from theory and practice.

Proc. the 14th European Conference on Information Systems,

1582–1593.

Rumbaugh, J., Jacobson, I., & Booch, G. (1999). Unified

Modeling Language: Infrastructure. Unknown Journal. Addison

Wesley Longman, Inc.

Saeedi, K., Zhao, L., & Sampaio, P. R. F. (2010). Extending BPMN for Supporting Customer Facing Service Quality

Requirements. 2010 IEEE International Conference on Web

Services (pp. 616–623). IEEE.

Scheer, A. W. (2000). ARIS - Business Process Modeling.

Springer Verlag.

Schriber, T. J. (1980). Fundamentals of Flowcharting. Krieger

Publishing Co., Inc.

Söderström, E., Andersson, B., Johannesson, P., Perjons, E., & Wangler, B. (2006). Towards a Framework for Comparing

Process Modelling Languages. Advanced Information Systems

Engineering, LNCS (Vol. 2348, pp. 600–611). Springer Berlin /

Heidelberg.

Sowa, J. F. (1984). Conceptual Structures: Information

Processing in Mind and Machine. Unknown Journal.

Addison-Wesley Publishing Company.

Wahl, T., & Sindre, G. (2005). An analytical evaluation of

BPMN using a semiotic quality framework. Advanced topics in

database research, 5, 102–113.

Wand, Y., & Weber, R. (1993). On the Ontological Expressiveness of Information Systems Analysis and Design

Grammars. Information Systems Journal, 3(4), 217–237.

doi:10.1111/j.1365-2575.1993.tb00127.x

Wang, R. W., & Strong, D. M. (1996). Beyond Accuracy: What

Data Quality Means to Data Consumers. Journal of

Management Information Systems, 12(4), 5–33.

Yu, E. (1995). Modeling Strategic Relationships for Process

Reengineering. Unknown Journal. University of Toronto,

Department of Computer Science.

Zachman, J. A. (2003). Excerpted from The Zachman

Framework: A Primer for Enterprise Engineering and

Manufacturing. Unknown Journal. Retrieved from

http://www.zachmaninternational.com

Zhao, L., Letsholo, K., Chioasca, E.-V., & Sampaio, P. (2012). Can Business Process Modeling Bridge The Gap Between

Business and Information Systems? 2012 ACM Symposium on

Applied Computing (Vol. 2, pp. 1723–1724).

Authors

Keletso J. Letsholo is a doctoral student in the Software Systems Research Group at the University of Manchester, UK. His current research investigates ways of automating the process of building traceable analysis models from a textual requirements specification written in English. His grand vision is to contribute to the continuing quest for better ways to improve our ability to develop and maintain analysis models. Keletso received a BSc in Computer Science from University of Botswana, and an MSc in Computer Science (Software Engineering) from the University of Wollongong, Australia.

24

Erol-Valeriu Chioasca is a PhD candidate in the School of Computer Science at the University of Manchester. His main research area is in Software Engineering, specifically in Requirements Engineering. His current research focuses on using natural language techniques to support automated requirements modeling and analysis.

Dr. Liping Zhao is an academic member of School of Computer Science at the University of Manchester. Her research focuses on the discovery and development of reusable software patterns, symmetries and models, and the application of these fundamentals to model-driven development and service-oriented computing. A pioneer in service sciences, she co-funded and led the first academic network on service sciences in the UK. Her contribution to software patterns and the service sciences agenda has earned her three IBM Faculty Awards