EPC: Event-driven Process Chain

The EPC (Event-driven Process Chain) (Davis, 2001) (Scheer, 2000) is the diagrammatic language of the control view of ARIS framework for modeling business processes within the enterprise model. The importance of EPCs in the practice of business process modeling can be attested by the existence of several successful commercial tools which offer support for these diagrams, e.g., IDS Scheer’s ARIS Toolset, Microsoft’s Visio and BOC’s ADONIS. Further, EPCs have been used in the documentation of the widely-employed SAP R/3 enterprise resource planning system, which has led to the SAP Reference Model with over 600 EPCs (Mendling, 2008).

Due to the economic value of EPCs, several academic studies have considered different aspects of the language. For example, (Kern, et al., 2007) (Mendling, et al., 2004) (Mendling, et al., 2005) (Mendling, et al., 2005) have proposed transformations between EPCs and other (platform-independent or platform-specific) models using Model-Driven Development techniques.

In addition, several studies in the literature propose formal execution semantics for EPCs using Petri nets (Kindler, 2006) (Rosemann, et al., 2007) (Van der Aalst, 1998) (Van Dongen, et al., 2005), with the purpose of demonstrating the absence of structural problems within the language and its models and to assure that the business processes specified in EPCs are prone to unambiguous execution and automation. In EPCs, the dynamic behaviour of business processes is modeled in terms of three main modeling elements: functions, events, rule elements (or logical operators). These concepts are showed in figure 1.

Figure 1 - Business Process 

Functions are the basic elements for EPC process modeling. They represent either technical activities or activities performed on some objects with the purpose of achieving one or more business goals (Scheer, 2000). An activity can be performed by either a person or an application system (Scheer, 2000), and has inputs – such as information or raw material – and outputs, such as new information or products. Furthermore, activities can consume and create organizational resources during their execution (Davis, 2001). In figure 1, the notational elements used to represent Functions are green rectangles. Examples of Functions are “Request purchase” and “Analyze purchase request”.

An event represents a state which is relevant to the process management and affects the flow of execution. They may be originated either internally in the execution of some business process or may be created by actors which are external to the process (Davis, 2001) (Scheer, 2000). When internally originated, events are said to establish the preconditions and postconditions for each stage of the process (Davis, 2001). Preconditions represent a state of reality which triggers one or more activities, while postconditions, in their turn, represent a state of reality that exists only after the activity has been performed. In other words, an activity is triggered by one or more events and one or more activities can trigger one or more events. In figure 1, events are illustrated by pink hexagons (e.g. “Need of Purchase identified” and “Request approved”). While both Scheer (Scheer, 2000) and Davis (Davis, 2001) defend that every relation between functions in EPCs should be mediated by an event as a form of representing situations in the business processes, this restriction is not enforced by the ARIS Toolset (i.e., it is not enforced in the language’s meta-model).

Rule elements (or logical operators) control the flow of the process model on the basis of the results and effects of its preceding tasks. These rules (as explained in Table 1) are used for creating “joins” and “splits” in the business process. The join connectors have multiple incoming branches and one single outgoing branch and the split connectors have one incoming branch and multiple outgoing branches. As syntax rule, splits from functions are only allowed since the function is linked to a connector and each arc which leaves the connector is linked to an event to represent the condition where the control flow must follow (conversely, splits to functions are only allowed when the function is preceded by a connector and each arc which reaches the connector is linked to an event). Splits from events to functions are forbidden because it does not become explicit the arc where the control flow must follow.

There are three types of logical operators (AND operator, XOR operator and OR operator) that
determines the execution flow. The AND-split triggers all outgoing branches concurrently and AND-join propagates control only if all incoming branches have already finished. XOR-split choices among one of multiple exclusive branches and XOR-join waits for only one of the incoming branches. OR-split activates one or more of multiple branches accordingly events while OR-join waits for one or more of the incoming branches. Figure 1 presents an example of an XOR “split”, indicating that the “Analyze purchase” can be followed by either “Finalize purchase” or “Inform client”, but not both.

Rule	Symbol	Join	Split
OR		Any incoming branch, or a combination of incoming branches, will initiate the outgoing branch	One or more outgoing branches will be enabled after the incoming branch finishes
XOR		One, and only one, incoming branch will initiate the outgoing branch1	One, and only one, outgoing branch will be enabled after the incoming branch finishes
AND		The outgoing branch initiates only after all the incoming branches have been executed	Two or more outgoing branches are enabled after the incoming branch finishes

In addition to the three basic elements of EPCs (functions, events and rules), there can exist other elements in EPCs. These elements in fact belong to the ARIs Organizational Model and are referenced in an EPC to describe participants in organizational activities. Figure 1 depicts the elements “Client” and “Seller”. These elements indicate that the participants of the business process are responsible for performing the functions in their swimlanes. In figure 1, Client” is responsible for carrying out “Request purchase”, while “Seller” is responsible for carrying out “Analyze purchase request”, “Finish purchase” and “Inform client”.

References

• Davis, Rob. 2001. Business Process Modelling with ARIS - A Practical Guide. s.l. : Springer, 2001.
• Kern, H. and Kühne, S. 2007. Model Interchange between ARIS and Eclipse EMF. 7th OOPSLA Workshop Domain-Specific Modeling, Computer Science and Information System Reports. 2007.
• Kindler, E. 2006. On the Semantics of EPCs: A Framework for Resolving the Vicious Circle. Technical Report. University of Paderborn, Computer Science Department at Germany. 2006.
• Mendling, J. and Nüttgen, M. 2004. Transformation of ARIS Markup Language to EPML. In Proceedings of the 3rd GI Workshop on Event-Driven Process Chains. 2004.
• Mendling, J., Neumann, G. and Nüttgens, M. 2005. Towards Workflow Pattern Support of Event-Driven Process Chains (EPC). In Proceedings of the 2nd GI Workshop XML4BPM - XML for Business Process Management. 2005.
• Yet Another Event-Driven Process Chain. Technical Report. University of Economics and Business Administration at Vienna. 2005.
• Mendling, Jan. 2008. Metrics for Process Models - Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness. s.l. : Springer, 2008. p. 193. Vol. 6.
• Rosemann, M. and Van der Aalst, W. 2007. A Configurable Reference Modelling Language. Information Systems. 2007, Vol. 32.
• Scheer, A. W. 2000. Aris – Business Process Modeling,. s.l. : Springer, 2000.
• Van der Aalst, W. 1998. Formalization and Verification of Event-driven Process Chains. s.l. : Computing Science Reports. Eidhoven University of Technology at Eindhoven, 1998.
• Van Dongen, B., Van der Aalst, W. and Verbeek, H. 2005. Verification of EPCs: Using Reduction Rules and Petri Nets. In Proceedings of the 17th Conference on Advanced Information Systems Engineering (CAiSE 2005). 2005.

DoDaF: The Department of Defense Architecture Framework

The Department of Defense Architecture Framework (DoDAF) comprises in a foundational framework to describe enterprise architectures as well as the system architecture in a consistent manner (USA Department of Defense, 2007). It has been initially developed in 1996 by the US Department of Defense to ensure a common basis for the definition of architectures of commands, military services and defense agencies. In 2003, a new version of the framework has been released. Although DoDAF is clearly oriented to military systems, it has a broad applicability in architectures descriptions that are more general (Lankhorst, 2005).

The DoDAF provides a set of products which are structured in four main views, namely, All-View (AV) Operational View (OV), System View (SV) and Technical View (TV) as mechanism for communicating and visualizing the broad scope of the organizations.

Goals, vision statements and tactics are captured as cross-cutting concerns (global conditions that compose the context of the architecture) within the framework in the AV products (AV products capture overarching aspects, providing information pertinent to the entire architecture but do not represent a distinct view of the architecture).

by Evellin & Paulo

ARIS: A Framework for Enterprise Description

ARIS (ARchitecture for integrated Information Systems) has been developed in Saarbrucken (Germany), in 1992, with the main aim of providing an architectural framework for enterprise description. The ARIS framework is structured in terms of five different views (Organization, Data, Control, Function and Output) and three abstraction layers (Requirements Definition, Design Specification and Implementation Description). While the division in abstraction levels allows one to capture the information about the enterprise in different granularities, the viewpoints aim at specifying details referring to each organizational aspect.

The Organizational View describes the hierarchical structure of the organizational units, its relationships and responsibilities. The organizational structure defines the competencies realms of the organization, indicating its specialties areas and allowing one to identify the hierarchy of roles. The main purpose of this viewpoint is to provide subsidies to strategic decisions, such as how to aggregate similar organizational functionalities so that they can be assigned to organizational units, conversely, how to aggregate roles in specific units according to the functionalities required by these units or by the business process which these units execute.

The Functional View defines the organizational functions which can be described in various aggregation levels in a hierarchal way. Functions designate activities or tasks which must be executed for the production of some good. The term is not defined generically, but is used synonymously with the terms process, activity or task. The name of a complex function is also used for the designation of a business process (Scheer, 2000).

The Data View describes the business information that is manipulated by functions. The data objects have several roles in the flow of business process, such as: describe the events and messages which control the flow of business processes, describe the environment status of business process, represent the outputs produced by activities and so forth (Davis, 2001).

The Control View describes the transformation of information within business processes through a function or a set of functions. Since these functions represent potentially complex organizational tasks, the control view is used for modeling business processes into ARIS. The purpose of this view is to integrate the remaining views of the language (Functional View, Organizational View and Data View) which have been separately modeled. This promotes the description of the state modifications and consequently, the description of dynamic behaviour of processes which manipulate information and other kind of objects previously modeled in other views. Therefore, the Process View provides the linkage among all the enterprise views.

The main models involved in the Process View are: the Value Added Chain (VAC) model, the Event-driven Process Chain (EPC) model and the Function Allocation Diagram (FAD) model. This separation allows one to manage the complexity of modeling as well as the integration among the views. Among these models, EPC models can be considered the most important models since it captures the enterprise procedures, highlighting how the enterprise intends to achieve its strategies.

The importance of EPCs in the practice of business process modeling can be attested by the existence of several successful commercial tools which offer support for these diagrams, e.g., IDS Scheer’s ARIS Toolset, Microsoft’s Visio and BOC’s ADONIS. Further, EPCs have been used in the documentation of the widely-employed SAP R/3 enterprise resource planning system, which has led to the SAP Reference Model with over 600 EPCs (Mendling, 2008).

ARIS provides both components for creating enterprise descriptions: first, it provides a modeling language to capture enterprise models and second, it provides methodological support for the construction of these models, having a large market share due to its integration with the SAP suite in the corporate and government sectors. This acceptability and leadership in the business community can be accounted by the fact that it provides support for modeling several aspects of complex business models (including processes, data, organizations, systems and so on), support for modeling software systems (using UML) as well as other technical advantages (such as windows compliance, rich functionality and configurable for user requirements, support for business objectives, measures and balanced scorecard, among others)(Davis, 2001).

More information about ARIS products can be found at

http://www.ids-scheer.com/international/en

by Evellin & Paulo

References:

Davis, Rob. 2001. Business Process Modelling with ARIS - A Practical Guide. Springer, 2001.

Mendling, Jam. 2008. Metrics for Process Models, Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness. Lecture Notes in Business Information Processing (LNBIP). Springer-Verlag, Vol. 6, pp. 17-57.

Scheer, A. W. 2000. Aris – Business Process Modeling, Springer.

Archimate: A Service-Oriented Framework for Enterprise Architecture

ArchiMate is a modeling language for describing enterprise architectures which presents a clear set of concepts and relationships between architectures domains, and offers a simple and uniform structure for describing the content of these domains (The Open Group, 2009).

The language has been developed in the ArchiMate Project which lasted from July 2002 until December 2004 in a broad consortium from industry and academia (comprising ABN AMRO, Stichting Pensioenfonds ABP, the Dutch Tax and Customs Administration (Belastingdienst), Telematica Instituut, Ordina, the Centre for Mathematics and Computer Science (CWI), the Leiden Institute for Advanced Computer Science (LIACS), and Radboud University Nijmegen ) with the aim of providing a visual design language with adequate concepts for specifying interrelated enterprise architectures. 

The design of the language has been guided by the issue that managing the complexity of the organizations requires the description of the language in terms of several domains of knowledge as well as the relations within these domains. Therefore, the main goal of the language is to promote the integration of the several viewpoints of the organization, albeit it is not intended to introduce a language that can replace all existing domain-specific languages. 

The central characteristic of the architecture is the service orientation. According to (Lankhorst, 2005), “services are defined as the unit of functionality that some entity (e.g. s system, organization or department) makes available to its environment and which has some value for certain entities in the environment (typically the “service users”)”. The service orientation proposed in the ArchiMate enables a layered view of the architectural models, where the concept of the service is one of the main linking between the different layers. The service layers which the services are made available to higher layers are interleaved with implementation layers that realize the services. Within a layer, there may also be internal services.

The language distinguishes three main layers (abstraction levels): the Business Layer which offers products and services to external customers realized by business processes executed by actors or roles; Application Layer which supports the business layer with software applications services; and Technology Layer which offers infrastructural services for software applications (composed by software systems, computer and communication devices). Each of these layers can be decomposed in sub-layers. However, the level of abstraction must be chosen according to stakeholders concerns. 

In the structural/behavioral dimension, the behavioral concepts are assigned to structural concepts to show who or what displays the behavior. The structural concepts are in turn refined in active structural elements (concepts which indeed display the behavior) and passive structural elements (objects in which the behavior is applied). For instance, in the business layer, roles, interfaces and collaborations (structural concepts) are assigned to business processes, business services and business interactions, (behavioral concepts) respectively. 

Concerning the second dimension, there is a distinction between the external view and internal view. The external view is concerned about the functionality (and its associated non-functional aspects) which are exposed to the environment, whereas the internal view refers to internal realization of the services. In the internal realization of the services, the behavior may be performed by an individual structural element (e.g. actor, role and component) or by a collective structural element (collaborations). From an external perspective, it is usually irrelevant whether a service is realized by individual or collective behavior. Services are accessed through interfaces, which constitute the external view of the structural aspects. 

The language puts emphasis on concepts which captures the design and realization of the organization, without however providing concepts for capturing the intentional aspect (goals, strategies, policies and so forth). This “intentional dimension” is indispensable in the sense that it captures the principles which govern the design process for creating the enterprise as well as the translation of the abstract definition to the actual architectural implementation.

by Evellin & Paulo

References:
Telematica Instituut. 2009. Archimate Resource Tree. http://www.telin.nl/NetworkedBusiness/Archimate/ART/. [Online] 2009. .

The Open Group. 2009. What's ArchiMate. http://www.archimate.org/. [Online] 2009. http://www.archimate.org/en/about_archimate/what_is_archimate.html.

Lankhorst, Marc. 2005. Enterprise Architecture at Work - Modelling, Communication, and Analysis. s.l. : Springer-Verlag, 2005.

Important links for Archimate:

http://www.telin.nl/NetworkedBusiness/Archimate/ART/

http://www.archimate.org/

http://www.bizzdesign.nl/joomla/ (unfortunatelly, it is written in Dutch)

A Big Picture About Enterprise Architectures: Why do we need them?

The increasing competitiveness drives organizations to promote change in an attempt to improve the quality of the services and products they offer. In recent years, many of the efforts related to managing change in organizations have been conducted in the scope of Business Process Reengineering (BPR) activities (Hammer, et al., 1993) (Hammer, 1990). BPR is based on the assumption that change in business processes should generate radical improvements in critical performance measures (such as cost, quality, service and speed) (Hammer, et al., 1993). Moreover, it is believed that implementing radical changes in business processes is the way to achieve dramatic and satisfactory results (Hammer, et al., 1993) (Hammer, 1990).

However, predicting how a given enterprise environment should respond to changes by simply adopting a business process centered view is unfeasible since there are a large number of issues to be considered, such as infrastructure, power and politics, managerial control, organizational culture, among others (Yu, 1995). In turn, these issues provide potentially conflicting quality criteria whose prioritization (or postponement) impacts in the performance of the organization as a whole.

To properly address the interconnection among these factors in organizations often requires the utilization of an enterprise architecture. An enterprise architecture comprises in “a coherent whole of principles, methods and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure” (Lankhorst, 2005). Thus, the insights provided by enterprise architectures help overcoming the difficulty of managing organizations, allowing the determination of needs and priorities for change a given business perspective (Jonkers, et al., 2006).

By Evellin & Paulo


References:


Hammer, M. 1990. Reengineering Work: Don’t Automate, Obliterate. Harvard Business Review, 1990.


Hammer, M. y Champy, J. 1993. Reengineering the Corporation: A Manifesto for Business Revolution. London, England. Nicholas Brealey Publishing.


Yu, Eric. 1995. Modeling Strategic Relationships for Process Reengineering. PhD. Thesis. Departament of Computer Sciences, University of Toronto.


Lankhorst, Marc. 2005. Enterprise Architecture at Work - Modelling, Communication, and Analysis. Springer-Verlag.


Jonkers, Henk, et al. 2006. Enterprise architecture: Management tool and blueprint for the organization. Information Systems Frontiers, Springer. Netherlands.