What is Leadership?

Understanding Balanced Scorecards

More than 50 percent of Fortune 1000 companies use balanced scorecards to measure business performance. Kaplan and Norton created a way to look at business strategy that digs deeper than just the financials.

Speaker: Jay Gulick, Director, BNET

Length: 02:30

What is SOA?

Service oriented architecture may be over-hyped, but it does offer lower-cost and easier integration.

Length: 02:10

www.bnet.com

Tuckman's Model: Fight Right

Conflict isn't necessarily a bad thing, in fact, it can create highly performing teams. Bruce Tuckman's theory of team development suggests that all groups progress through various stages of performance: from forming to storming, then norming, and finally performing. By learning to fight about the right things--goals, roles, and strategies—teams can reach the final stage more quickly.

Speaker: Edward Muzio, President & CEO, Group Harmonics

Length: 03:10

Workflow Modelling

um-srv01.wiwinf.uni-due.de

Foundations - Workflow Modelling WfMC and Workflow Specification Languages | XML Process Definition Language (XPDL) | Basic Workflow Concepts | Extended Workflow Concepts This section provides a short introduction into workflow management by giving an overview on common terminology and the description of the standards of the Workflow Management Coalition. WfMC and Workflow Specification Languages The Workflow Management Coalition (WfMC) was founded in 1993 as an alliance of companies and organisations dealing with workflow management. The mission of the WfMC is to establish a common terminology and standardised interfaces for workflow management. These interfaces comprise the definition, execution and management of workflows as well as references to external documents and applications [Jung01, pp. 126]. The conceptualisation of the interfaces is given by the WfMC's reference model depicted in the figure below. The workflow enactment services - using one or more workflow engines for the execution of workflows - represent the core of the reference model [Holl95]. A workflow engine is a software managing workflows with respect to given workflow definitions.

WfMC Reference Model [Holl95, p. 20]

The five different interface definitions correspond to the integration of external aspects:

• Interface 1 specifies the exchange of workflow models between external modelling tools and a workflow management system. External tools might be graphical or textual editors for workflow definitions. Some general purpose process modelling tools supporting the WfMC standard can be used for the specification of workflows, too [Holl95, p. 20].
• Interface 2 describes the communication between a WfMS and workflow client applications. Workflow client applications are applications directly correlated with the workflow engine. They usually implement basic functionality of workflow applications like notification and data transfer [Holl95, pp. 31].
• Interface 3 addresses the need to integrate external applications. Usually, the needed functionality is not provided by the WfMS itself. Hence, there has to be an interface to other applications already running in the enterprise [Holl95, pp. 35]. Examples for such kind of applications are business related software and special software tools.
• Goal of interface 4 is to integrate other workflow management systems. The specification comprises the invocation of remote activities, data transfer as well as synchronisation aspects between different workflow enactment services [Jung01, p. 126] [Holl95, pp. 41].
• Interface 5 describes the communication between the workflow enactment services and external monitoring and administration tools [Jung01, p. 126].

Interface 1 is the most relevant specification for the purpose of mapping business process models to workflows. It concentrates on the specification of different types of workflows (processes) as well as associated organisational units and applications. The system-specific integration of applications is done using interface 2/3 [Holl95, p. 20].
The Workflow Process Definition Language (WPDL) is the first attempt of the WfMC to specify of a standard for the interchange of workflow definitions. Being a standard for exchanging models, it does not comprise a graphical notation. Meanwhile, WPDL has been replaced by the XML Process Definition Language (XPDL), an XML-based document definition for workflows (see [Nori02]). Top XML Process Definition Language (XPDL) Concepts supported by XPDL are represented by the meta-model shown in the figure below. This meta-model generally comprises static entities (e.g. data or applications) as well as dynamic concepts (processes). Static entities are represented by the meta-types

• Workflow Relevant Data,


• Workflow Participant Specification and


• Workflow Application Declaration.

Workflow-relevant data is initialised, created, read from external applications, and used during the execution of workflows [Nori02, p. 10]. It might be produced by an activity within a workflow or extracted from an external data source (e.g. an enterprise information system). For example, corporate databases are typical external data sources. These data sources are represented by the meta-type System and Environmental Data.
The workflow participant specification describes the resources which perform the given workflow processes [Nori02, p. 9]. This specification does not necessarily correspond to a human or a single person. It actually represents an abstract resource or a role which can be filled by one or more humans as well as an automated machine. Hence, the specification of a workflow participant corresponds to a resource available in an organisation or an entity in an organisational chart (Resource Repository or Organisational Model). The workflow application declaration provides the description of software applications needed for the execution of a workflow process [Nori02, p. 9]. Those applications are usually invoked by the workflow engine and workflow-relevant data has to be passed as a parameter (e.g. internal or external applications like corporate information systems or common office applications). Internal applications are usually provided as part of a workflow management system or can be developed using a proprietary development environment or language.

XPDL Meta-Model [Nori02, p. 12]

A workflow process definition is an aggregation of static entities (data, applications, participants) as well as the description of the system's dynamic behaviour. Dynamic aspects of the meta-model are represented by the entity-types Transition Information as well as Workflow Process Activity and its concrete subtypes

• Block Activity,
• Atomic Activity and
• Sub-Process Definition.

An activity is a given unit of work which will be executed by a participant using computer applications and relevant data (see [Nori02, p. 8]). Additionally, every activity is characterised by a start- and end-time as well as the fact whether it can be executed automatically by the WfMS or by a workflow participant. The transition information specifies the control flow between activities [Nori02, p. 9]. It consists of a starting activity, an end-activity and a condition under which the transition is made. An atomic activity is an indivisible unit of work which has to be done at one go. A sub-process definition allows the embedding of another workflow process definition. A block activity consists of a set of other activities (type Activity Set). The semantics of an activity set is similar to the one of a macro. If an activity set is called during the execution of a workflow process, the activities contained in the set are copied into the calling process definition [Mato03, p. 13]. Basic Workflow Concepts Main concepts for the description of the dynamic aspects of a workflow system are activities and transitions. Activities correspond to defined units of work which can be atomic or consist of a set of activities. The control flow between activities is specified by transitions. Hence, a transition relation between two activities defines the ordering of these activities. An activity can be started if its preceding activities (connected by transitions) have terminated. Transitions, activities, and static entities (i.e. IT-related resources) are grouped by a so called workflow process definition. Workflow Process Definition A workflow process definition groups all elements necessary for the execution of a workflow. As shown in the meta-model depicted in the figure above, these elements comprise dynamic (activities and transitions) and static aspects (data, applications and participants). Additional attributes are a unique identifier, a name and two headers:

• The process header comprises the creation date, a textual description and different time-related properties (e.g. estimated duration of a process' execution) of a workflow process.
• The redefinable header consists of information about the author of the process definition, a country key, its publication status, responsible participants and a version number.

An activity set is a set of activities and transitions. All transitions contained in this set can only start from activities within this set and end in activities within this set. In other words, there are no transitions leaving an activity set or coming from outside. Properties of an activity set are a list of activities, a list of transitions and a unique identifier. Workflow Process Activities As shown in the figure below there are different types of activities within a workflow process definition. An atomic activity is an indivisible unit of work executed under the control of a WfMS. Such an activity can be executed automatically or by a human participant and usually works on workflow-relevant data. In contrast to this, block and route activities do not refer to workflow-relevant data. A block activity executes an activity set and has no own behaviour. Invoking an activity set means the start of the first activity in the set. The execution terminates with the last activity in the activity set (see the figure below [Nori02, p.30]). A route activity is an activity with no behaviour. It only serves as a dummy activity for cascading transition conditions (see subsequent section on transitions).

Different kinds of activities in XPDL [Nori02, p. 30]

According to XPDL there is only one general XML-element for activities called Activity. Specific elements for route, block or sub-flow activities are missing. The differentiation between different types of activities is done by the annotation of alternative attributes. Those attributes are named Route, Implementation and BlockActivity. Activities can additionally be specified in terms of their level of automation (automatic or manual) as well as their implementation alternatives (no implementation, tool or subflow):

• An automatic activity can be fully controlled by the workflow engine using internal and external applications.
• Manual activities require the involvement of a human being.
• Activities corresponding to the no-implementation alternative cannot be supported by an WfMS (e.g. manual tasks).
• A tool supported implementation implies the usage of a software application.
• If the implementation type is set to subflow, the execution has to be delegated to another workflow process definition. Parameters can be passed to such a sub-flow activity and the synchronisation can be specified with respect to a synchronous or asynchronous execution. Synchronous execution requires the calling process to wait for the termination of the called process. After its termination the called process might pass output values to the calling process. During an asynchronous execution the calling process does not have to wait for the termination of the called process and no output values can be returned.

Additional information for activities are deadlines and simulation information:

• A deadline is the expiration of a given period of time. A deadline might for example be a milestone (given a project management context) or a specific appointment. The occurrence of a deadline can be handled synchronously (the current activity is interrupted by the deadline) or asynchronously (the handling of the deadline has to be done parallel to the currently running activity).
• Simulation information extends the model by giving specific data for the simulation of models. Examples for specific data are average costs, expected duration and average waiting time.

As shown in the figure above, every activity is a join-point for several incoming transitions (join element) and specifies the type of splitting for outgoing transitions (split element). Both - join and split - can refer to parallel or alternative executions of workflows. An alternative split (XOR) represents a fork specifying that exactly one of the given alternatives can be executed. An alternative join corresponds to the synchronisation of an alternative split . The parallel execution of activities is started by an AND-split and ended by an AND-join. Rules for the construction of workflow descriptions regarding parallel and alternative connectors (splits and joins) are classified by so called conformance classes:

• A NON-BLOCKED conformance class implies no formal properties of a diagram regarding the relationships between splits and joins.
• If the conformance class is set to LOOP-BLOCKED, the graph build by the activities and transitions is a directed acyclic graph (DAG).
• A FULL-BLOCKED graph implies that every AND-split has exactly one AND-join, every XOR-split exactly one XOR-join and vice versa. Additionally every path starting from the split will reach the corresponding join.

Transitions A transition is partly specifies the control flow between activities. As shown above the information whether incoming transitions of an activity are disjoint (alternative) or conjoint (parallel) is assigned to the activity. Additional information about a transition is assigned to the so called transition information [Nori02, p. 40]. Basic elements of such a transition are

• its name (i.e. a character string),
• a textual description and
• a condition.

A condition should be a (semi-)formal specification - represented by a Boolean expression - of the circumstances enabling or disabling a transition. Additionally, a starting and an ending node are assigned to transition information. Consequently, every transition is characterised by exactly one source activity (from), exactly one destination activity (to), and a Boolean expression representing a firing condition. There are four different kinds of conditions in XPDL:

• CONDITION: A transition can fire if its condition is evaluated to true.
• OTHERWISE: Indicates a default transition which will fire if no other transition's condition evaluates to true.
• EXCEPTION: An exception is a special transition indicating an abnormal behaviour. An exception-condition can trigger the rising of a special condition.
• DEFAULTEXCEPTION: A default exception is triggered if all other exception conditions are evaluated to false.

Top Extended Workflow Concepts

Workflows are managed by a workflow management system by assigning tasks (as parts of workflow instances) to given resources. Such a resource might be either a human participant or a workflow application. A human resource usually corresponds to a role filled by a specific person in an organisation. A workflow application might be categorised into internal and external applications. An internal application is usually implemented by the WfMC itself and is closely coupled to the workflow system. An external application is an application independent from the WfMS.

Regarding the specification of resources for the execution of workflows there is one major problem. On the one hand, XPDL aims to be a language for a system-independent workflow definition interchange. Hence, a workflow model described using XPDL should be independent from any specific workflow engine. On the other hand, the description given by an XPDL-document should be sufficiently precise for the execution of workflows. This aspect might require the annotation of specific users or applications which are subject to a proprietary definition by a WfMS. Consequently, the XPDL-definition only provides an abstract mechanism for the specification of human resources and software-applications. Workflow Participants The XPDL-specification describes workflow participants as "an abstraction level between the real performer and the activity, which has to be performed" [Nori02, p. 43]. The engine has to map every abstract participant to a user given in the workflow management system's environment. The characterisation of every abstract participant includes its unique name and type. Possible types of workflow participants are:

• RESOURCE: A specific resource given in a workflow management system's environment.
• RESOURCE_SET: A set of resources.
• ROLE: A role description that directly corresponds to a role given in an organisational chart. Such a role might be a function or some kind of qualification filled by a human.
• ORGANIZATIONAL_UNIT: An arbitrary element of an organisational chart.
• HUMAN: A human being interacting with the WfMS by worklists and/or applications (i.e. a concrete human being, like 'John Miller')
• SYSTEM: A software application representing the participant of a fully automated workflow.

Those participants are assigned to activities of a workflow model using the Performer-attribute of an activity [Nori02, p. 31]. Hence, an activity keeps a reference to an abstract participant using the performer-attribute (which is rather a character string than a reference to a workflow participant). Workflow Application Declaration According to Junginger, workflow applications can be divided into internal and external applications [Jung01].

• An internal workflow application is implemented as part of the WfMS. They are usually implemented using a programming language given by the WfMS. In the context of XPDL, those applications are called procedures.
• An external application is an individual software package which can be used by a WfMS.

Using XPDL, a workflow application is specified by a unique identifier, its type and a list of parameters. The name of an application represents a unique id and does not necessarily correspond to its physical location or a specific implementation. Like the description of workflow participants, the identification of a workflow application is only a symbolic link. The interpretation of such a symbolic link representing a workflow application depends on the WfMS at hand. There are workflow engines supporting internal applications, external applications, or both [Jung01]

Business Process Modelling

um-srv01.wiwinf.uni-due.de

Foundations - Business Process Modelling Introduction | Business Process Modelling with MEMO-OrgML | Further Business Modelling Concepts Introduction The analysis, representation, and management of knowledge about an organisation and its processes has always been very important [KoPl00]. A lot of work has been done on the development and evaluation of ontologies for process modelling, the specification of process modelling languages as well as on business process modelling methods and concepts (see e.g. [WaWe93], [Web97], [GrRo99], [EJLT99], [SuOs97], [Herb97], and [Öst95]). Business process models can be used for various purposes:

• Documentation of processes of an organisation to foster communication
• Analysis of business processes
• Simulation of processes
• Support for business process re-engineering
• Software development of process-oriented applications

Business process models represent a common medium for the communication of domain experts and novices. They offer domain level concepts and enable a broader distribution of knowledge.The analysis of business processes relies on a detailed description of process models and related concepts with respect to the analysis' purpose.
Depending on the analysis' purpose, a modelling language has to offer language features for modelling the facts which are in its scope. Analysis might for example support the detection of weaknesses in existing processes. Appropriate language features provided by a process modelling language support the identification of media clashes, unnecessary processes, or potentials for further optimisations. The potential for further optimisations relies on the degree of formal description of the business process model. Depending on identified weaknesses, business process re-engineering might be applicable. Business Process Modelling with MEMO-OrgML

Multi-Perspective Enterprise Modelling (MEMO) is a method for modelling organisations according to different views as well as different levels of abstraction. MEMO includes several languages for modelling static, functional, and dynamic aspects of an enterprise. One of these languages is MEMO-OrgML (Organisation Modelling Language), which supports modelling of organisational structures and processes. Resource modelling has not been subject of the first conceptualisation of MEMO-OrgML, but will be added shortly.

An introductory example for a process that has been modelled using MEMO-OrgML is given in the figure below. An order is received by the distribution department and the data will be checked directly afterwards (process No. 1 called 'Check Data'). The order will be further processed if the given data is valid (event No. 4 called 'Valid Data') or aborted if the data seems to be invalid (event No. 3). Aborting an order results in sending a rejection message to the customer in process No. 9 ('Compose Rejection Message'). Further processing of the order comprises entering data into the order-management-system (process No. 2: 'Enter Order') followed by the parallel execution of the processes 6, 7 and 8. Process No. 6 is a composed process which consists of one or more sub processes. The process called 'Compose Acceptance Message' (No. 7) is a semi-automated process executed by the distribution department. Process No. 8 is a fully automated process sending a default email-message to the customer. The following list gives a brief overview of language concepts and their notation in MEMO OrgML. Symbols depicting processes

	Abstract process			Aggregated process			Manual process
	Semi-automatic process			Automatic process			Continuing process
	Process performed by contractor			Process performed by an autonomous institution			Externally managed process('Black Box')

Hierarchie of composed processes

Displays processes as components of abstract or aggregated processes.

Symbols depicting events

	Start-Event			End-Event			Relevant change of information change (unspecified event)
	Message arrived			Temporal event - certain time interval has exceeded			Temporal event - certain point in time has been reached

Control structures

	Process produces event			Event triggers process
	Parallel execution			Synchronization after termination of one of the parallel processes
	Synchronization after termination of all parallel processes

Exceptions

Exceptions are defined for the entire system (e.g. collapse of communication channel, time out)

Annotations (natural language)

Constraints

Other comments

Top Further Business Modelling Concepts In addition to the process-oriented concepts given above, there are two further concepts relevant for process-oriented modelling of organisations. Organisational units correspond to departments, divisions or roles assigned to a particular business process. Resources are actors or tools which are required for the execution of a business process. Organisation units

The static structure of organisations can be described by an organisational chart. Such a chart shows an organisation by its sub-units and their respective relationships. The meta-model for the modelling of organisational charts is given in part a) of the figure to your right. An abstract organisation unit might either be a position or an organisational unit. Every organisational unit is a composition of other abstract organisational units. A position is an elementary description of the responsibilities of an employee. An example for an organisational chart is given in part b) of the figure to your right: An imaginary company consists of three departments (procurement, production, and distribution). Organisational units and roles are elements assigned to business processes and refer to human actors which are responsible for the execution of a business process. Organisational units and positions as described here can be assigned to business processes. Roles are not necessarily defined in an organisational chart but can be assigned to business processes.

Resources Resources are essential for modelling processes [PSO99]. Processes and their relationships mainly describe dynamic aspects and the order of events. Resources assigned to processes additionally specify objects required or used by business processes. Resources are usually not available in an unlimited amount (see [Nübe01],[PSO99]). Hence, the usage of scarce resources has to be taken into account for the analysis or simulation of processes as well as for the development of a workflow application or an information system. As the resource-modelling-language for MEMO-OrgML is currently under development, no graphical notation will be given here but a short introduction into the underlying meta-model. An excerpt from this meta-model is shown in the figure below. The class AbstractResource is the root of the generalisation hierarchy on resources. Every resource has a name (name : String), a textual description (description : String) and a list of resource attributes (attributes[0..*]:ResourceAttribute). Every resource attribute is a name-type pair for the specification of user-defined attributes on resources.

Within the context of process modelling, we generally distinguish human, physical, and intangible resources. A human resource is an abstraction of different perspectives on staff. Examples for such perspectives are concrete employees, roles filled by employees or business-oriented functions. Physical resources comprise all tangible objects used within a business process. Examples for physical resources are production plants, raw material, or computer hardware. In contrast to this, intangible resources do not have a physical manifestation. Examples for intangible resources are data, information, software, or even knowledge.

Human resources might be associated with concrete persons or employees of an organisation as well as abstract organisational units in an organisational chart. Hence, a human resource can be characterised by different aspects; it

• can play an active role
• may be responsible for the execution of e-business processes
• needs some qualification and competences for its job

The type HumanResource is a subtype of AbstractResource and has the two attributes qualification and competenceProfile, both of type String. The qualification is an objectively describable criterion for the capabilities of a human resource. Usually, the qualification certificate is issued by an established educational body. The competence of a human resource reflects personal skills of human beings. Hence, a competence profile corresponds to a set of skills or competences of a particular role or person.

Physical resources comprise all tangible objects used within a business process and are neither human nor intangible. According to Heinen [Hei88, p. 242] - in the context of industrial production - it can be differentiated between non-consumable resources (Potentialfaktoren) and consumable resources (Repetierfaktoren). Non-consumable resources are not used up during a manufacturing process and are still available afterwards, whereas consumable resources either become a part of the resulting product or are used up and therefore not available anymore [SS01, pp. 89 f]. At this point we abstract from physical resources, because these are not relevant in our context of workflow applications and the perspectives we present on it.

Intangible resources are resources without a physical manifestation. Software in terms of a set of programs that run on a computer hardware is a key resource in the process of supporting workflows. The meta-type Software has two attributes: systemRequirements and scalability, both of type String. The system requirements are modelled as text and describe the environment for the execution of a software system (i.e. processor architecture, minimum main memory or operating system). Scalability corresponds to the ability of supporting growing numbers of clients. The meta-type Information was created to represent information or knowledge that is relevant within workflows. It has the attributes name (a symbolic reference to an information instance) and typeDefinition of type String which describes how the information is structured. Examples for information are certain customer data or enterprise knowledge of some kind.

Zachman: Enterprise Architecture Framework

from www.zifa.com

---

---

Download a PDF version of the Zachman Framework

---