Business Process Modeling

Kapil Pant

August 2008

Modeling Business Processes

The transparency of the process flow is crucial, as this gives the process owners, process analysts, and all others involved an insight into what is going on. An understanding of the as-is process flow also ensures that we can judge the efficiency and the quality of the process.

The main objective of process modeling is the definition of the as-is process flow. Process modeling needs to answer the following questions:

  • What is the outcome of the business process?
  • What activities are performed within the business process?
  • What is the order of activities?
  • Who performs the activities?
  • Which business documents are exchanged within the process?
  • How foolproof is the process, and how can it be extended in the future?

After answering these and some other questions, we get a good insight into how the process works. We can also identify structural, organizational, and technological weak points and even bottlenecks, and identify potential improvements to the process.

We will model business process to satisfy the following objectives:

  • To specify the exact result of the business process, and to understand the business value of this result.
  • To understand the activities of the business process. Knowing the exact tasks and activities that have to be performed is crucial to understanding the details of the process.
  • To understand the order of activities. Activities can be performed in sequence or in parallel, which can help improve the overall time required to fulfill a business process. Activities can be short-running or long-running.
  • To understand the responsibilities, to identify (and later supervise) who is responsible for which activities and tasks.
  • To understand the utilization of resources consumed in the business process. Knowing who uses which resources can help improve the utilization of resources as resource requirements can be planned for and optimized.
  • To understand the relationship between people involved in the processes, and their communication. Knowing exactly who communicates with whom is important and can help to organize and optimize communications.
  • To understand the document flow. Business processes produce and consume documents (regardless of whether these are paper or electronic documents). Understanding where the documents are going, and where they are coming from is important. A good overview of the documents also gives us the opportunity to identify whether all of the documents are really necessary.
  • To identify potential bottlenecks and points of improvements, which can be used later in the process optimization phase.
  • To introduce quality standards such as ISO 9001 more successfully, and to better pass certification.
  • To improve the understandability of quality regulations that can be supplemented with process diagrams.
  • To use business process models as work guidelines for new employees who can introduce themselves to the business processes faster and more efficiently.
  • To understand business processes, which will enable us to understand and describe the company as a whole.

A good understanding of business processes is very important for developing IT support. Applications that provide end-to-end support for business processes, can be developed efficiently only if we understand the business processes in details.

Modeling Method and Notation

Efficient process modeling requires a modeling method that provides a structured and controlled approach to process modeling. Several modeling methods have been developed over the years. Examples include IDS Sheer's the ARIS methodology, CSC's Catalyst, Business Genetics, SCOR and the extensions PCOR and VCOR, POEM, and so on. The ARIS methodology has been the most popular methodology, and has been adopted by many software vendors. In the next section, we will describe the basics of the ARIS methodology, which has lately been adapted to be conformant with SOA.


ARIS is both a BPM methodology, and an architectural framework for designing enterprise architectures. Enterprise architecture combines business models (process models, organizational models, and so on) with IT models (IT architecture, data model, and so on).

ARIS stands for Architecture of Integrated Information Systems and comprises of two things, the methodology and framework, and the software that supports both. Here, we will give a brief introduction to ARIS methodology and framework, which dates back to 1992.

The objective of ARIS is to narrow the gap between business requirements and IT. The ARIS framework is not only about process models (describing business processes), although process models are one of the most important things of ARIS. As enterprise architecture is complex, ARIS defines several views that focus on specific aspects such as business, technology, information, and so on, to reduce the complexity. The ARIS framework describes the following:

  • Business processes
  • Products and services related to the processes
  • The structure of the organization
  • Business objectives and strategies
  • Information flows
  • IT architecture and applications
  • The data model
  • Resources (people and hardware resources)
  • Costs
  • Skills and knowledge

These views are gathered under the concept of ARIS House, which provides a structured view on all information on business processes. ARIS House offers five views:

  1. The process view (also called the control view) is the central view that shows the behavior of the processes, how the processes relate to the products and services, organization, functions, and data. The process view includes the process models in the selected notation, and other diagrams such as information flow, material flow, value chains, communication diagrams, and so on.
  2. The product and service view shows the products and services, their structures, relations, and product/service trees.
  3. The organizational view shows the organizational structure of the company, including departments, roles, and employees. It shows these in hierarchical organizational charts. The organization view also shows technical resources and communication networks.
  4. The function view defines process tasks and describes business objectives, function hierarchies, and application software.
  5. The data view shows business data and information. This view includes data models, information maps, database models, and knowledge structures.

The ARIS House is illustrated in the following figure:

Business Process Modeling

In ARIS House, the process view is the central view of the dynamic behavior of the business processes and brings together the other four static views, the organizational view, data view, function view and product/service view.

In this book, we will focus primarily on the process view.

Each ARIS view is divided further into phases. The translation of business requirements into IT applications requires that we follow certain phases. Globally, three general phases are likely to be used:

  • Requirements phase
  • Design specification phase
  • Implementation phase

    ARIS is particularly strong in the requirements phase, while other phases may differ depending on the implementation method and the architecture we use. We will talk about these later in this article.

Let us now look at the other important aspect, the business process modeling notations.

Modeling Notation

Process modeling also requires a notation In the past, several notations were used to model processes. Flow diagrams and block diagrams were representatives of the first-generation notations. Then, more sophisticated notations were defined, such as EPC (Event Process Chain) and eEPC (Extended Event Process Chain). UML activity diagrams, XPDL, and IDEF 3 were also used, in addition to some other less-known notations. A few years ago a new notation, called Business Process Modeling Notation (BPMN) was developed. BPMN was developed particularly for modeling business processes in accordance with SOA. In this article, we will use BPMN for modeling processes.


BPMN is the most comprehensive notation for process modeling so far. It has been developed under the hood of OMG (Object Management Group). Let us look into the brief introduction of the most important BPMN elements so that we can read the diagrams presented later in this article.

The most important goals while designing BPMN have been:

  • To develop a notation, which will be understandable at all levels: In business process modeling different people are involved, from business users, business analysts, and process owners, to the technical architects and developers. The management reviews business processes at periodic intervals. Therefore, the goal of BPMN has been to provide a graphical notation the is simple to understand, yet powerful enough to model business processes at the required level of detail.
  • To enable automatic transformation into executable code, that is, BPEL, and vice-versa: The gap between the business process models and the information technology (application software) has been quite large in existing technologies. There is no clear definition on how one relates to the other. Therefore, BPMN has been designed specifically to provide such transformations.

To model the diagrams, BPMN defines four categories of elements:

  • Flow objects, which are activities, events, and gateways. Activities can be tasks or sub-processes. Events can be triggers or results. Three types of events are supported: start, intermediate, and end. Gateways control the divergence of sequential flows into concurrent flows, and their convergence back to sequential flow.
  • Connecting objects are used to connect flow objects together. Connectors are sequence flows, message flows, and associations.
  • Swim lanes are used to organize activities into visual categories in order to illustrate different responsibilities or functional capabilities. Pools and lanes can be used for swim lanes.
  • Artifacts are used to add specific context to the business processes that are being modeled. Data objects are used to show how data is produced or required by the process. Groups are used to group together similar activities or other elements. Annotations are used to add text information to the diagram. We can also define custom artifacts.

The following diagrams show the various notations used in BPMN:

Activities are the basic elements of BPMN and are represented by rectangles with rounded corners. A plus sign denotes that the activity can be further decomposed:

Business Process Modeling

Decisions are shown as diamonds. A plus sign inside the diamond denotes a logical AND, while an x denotes a logical OR:

Business Process Modeling

Events are shown as double circles:

Business Process Modeling

Roles are shown as pools and swim-lanes within pools:

Business Process Modeling

A Document is shown as follows:

Business Process Modeling

The order of activities is indicated by an arrow:

Business Process Modeling

The flow of a document or information is shown with a dashed line:

Business Process Modeling

BPMN can be used to model parts of processes or whole processes. Processes can be modeled at different levels of fidelity. BPMN is equally suitable for internal (private) business processes, and for public (collaborative) business-to-business processes. Internal business processes focus on the point of view of a single company, and define activities that are internal to the company. Such processes might also define interactions with external partners.

Public collaborative processes show the interaction between all involved businesses and organizations. Such processes models should be modeled from the general point of view, and should show interactions between the participants.

Process Design

The main activity in process design is the recording of the actual processes. The objective is to develop the as-is process model. To develop the as-is model, it is necessary to gather all knowledge about the process. This knowledge often exists only in the heads of the employees, who are involved in the process. Therefore, it is necessary to perform detailed interviews with all involved people. Often, process supervisors might think that they know exactly how the process is performed. However, after talking with those employees who really carry out the work, they see that the actual situation differs considerably. It is very important to gather all this information about the process, otherwise it will not be possible to develop a sound process model, that reflects the as-is state of the process.

The first question related to the as-is model is the business result that the process generates. Understanding the business result is crucial, as sometimes it may not be clearly articulated.

After the business result is identified, we should understand the process flow. The process flow consists of activities (or tasks) that are performed in a certain order. The process flow is modeled at various levels of abstraction. At the highest level of abstraction, the process flow shows only the most important activities (usually up to ten).

Each of the top-level activities are then decomposed into detailed flows. The process complexity, and the required level of detail, are the criteria that instruct us how deep we should decompose. To understand the process behavior completely, it makes sense to decompose until atomic activities (that is, activities that cannot be further decomposed) are reached.

When developing the as-is process model, one of the most important things to consider is the level of detail. In order to provide end-to-end support for business processes using SOA, detailed process modeling should be done. The difficulties often hide in the details!

In the process design, we should understand the detailed structure of the business process. Therefore, we should identify at least the following:

  • Process activities at various levels of detail
  • Roles responsible for carrying out each process activity
  • Events that trigger the process execution and events that interrupt the process flow
  • Documents exchanged within the process. This includes input documents and output documents
  • Business rules that are part of the process

We should design the usual (also called optimal) process flow and identify possible exception scenarios. Exceptions interrupt the usual process flow. Therefore, we need to specify how the exceptions will be handled.

The usual approach to the process design includes the following steps:

  1. Identifying the roles
  2. Identifying the activities
  3. Connecting activities to roles
  4. Defining the order of activities
  5. Adding events
  6. Adding documents

We should also understand the efficiency of the business process. This includes resource utilization, the time taken by involved employees, possible bottlenecks, and inefficiencies. This is the reason why we should also identify metrics that are used to measure the efficiency of the process. While some of these metrics may be KPIs, other metrics relevant to the process should also be identified.

We should identify if the process is compliant with standards or reference processes. In some industry domains, reference processes have been defined. An example is the telecommunications industry where the TMF (Telecom Management Forum) has defined NGOSS. Part of NGOSS is eTom (Enhanced Telecom Operations Map), which specifies compliant business processes for telecom companies. Other industries have also started to develop similar reference processes.

We should also identify the business goals to which the process contributes to. Business goals are the same as the process results. A business process should not only have at least one result, but should also contribute to at least one (preferably more than one) business goal. Here, we can look into the company strategy to identify the business goals.

We should also identify the events that can interrupt the process flow. Each process can be interrupted, and we should understand how this happens. If a process is interrupted, we might need to compensate those activities of the process that have already been successfully completed. Therefore, we should also specify the compensation logic related to different interruption events.

Finally, we should also understand the current software support for the business process. This is important because existing software may hide the details of process behavior. This information can also be re-used for end-to-end process support.

Once we have identified all of these artifacts, we will have gathered a good understanding of the process. Therefore, let us now look at the results of the process modeling.

Results of Process Modeling

The results of the process modeling phase are:

  • Process map, which shows the relationship between various business processes and the interactions between these processes.
  • Roles and relations structure diagram, which shows the roles involved in business processes, and the relationships between the roles.
  • An as-is process model model for each individual process. This describes in detail the existing business process, including the process flow, activities, roles, and documents (discussed later in this section). It can also contain the identified optimization points.

Process Map

The process map includes all business processes in the company. If the existing processes are redesigned, the process map is updated with the newly-identified processes. The process map gives an overview of all of the processes, and is very important for understanding the structure of processes in the company.

The process map also shows the relationship between business processes and their points of connection. Usually, business processes are not isolated, but interact with other processes. The connection points show where this interaction occurs.

The process map also shows the document flow. It shows which documents are consumed by each process, and which documents are generated by each process. This includes process-specific documents and general purpose documents such as standards, regulations, internal acts, and so on.

The following figure shows an example of a process map for project management:

Business Process Modeling

Roles and Relations Structure

The roles and relations structure diagram shows the roles and groups, and their relations. This is not a hierarchical diagram, such as an organizational diagram. Rather, it shows the relations in the style of network diagram. It shows relationships such as participations in a group, supervisions, communications, substitutions, and so on.

The following figure shows an example of a roles and relations structure:

Business Process Modeling

As-is Process Model

The as-is process model for each business process consists of the following:

  • Process environment diagram, which shows the relationship of this process to other processes.
  • Top level process model, which shows the high-level activities and the flow of these activities, along with the responsibilities of the roles involved in the process.
  • Detailed process maps for each high-level activity, with detailed representations of process activities. The detail process map may have several decomposition levels, depending on the complexity of each high-level activity.
  • Exception handling diagram. When modeling a business process, it is very important that we don't end up modeling only the optimal process flow. We must not forget to identify the possible exceptions that might occur, and specify how these exceptions are handled. An exception handling diagram shows exactly this.

In the following sections, we will describe the process environment diagram, top-level process modeling, detailed process maps, exception handling diagram, and responsibilities diagram.

Process Environment Diagram

The process environment diagram shows the highest-level process view, where the whole process is shown as a single activity. In this way, we look at the process as a black box. In the process environment diagram, we show:

  • Process trigger, which tells us how the process is triggered to start the execution
  • Necessary input information required in the process
  • Process result or results
  • Roles involved in the process or responsible for the process
  • Responsibilities of the roles within the process (such as 'responsible-for', 'executes', 'participates', 'supervises', and so on)
  • Metrics used for measuring process efficiency
  • Events that can interrupt the regular process flow, and the compensation logic required to handle these interruption events
  • Compliance with standards, or reference processes
  • The business goals a process contributes to

The following figure shows the general layout of the process environment:

Business Process Modeling

In a specific process, we define the process-specific information as shown in the following figure:

Business Process Modeling

The process environment diagram does not show the process flow details. This is shown in the process model, which is described in the next section.

Top-level Process Model

The top-level process model shows the highest-level view of the process activities. Usually, the top-level process model shows a limited number (for example, up to ten) of well-structured activities that represent the high-level process flow.

The top-level process model also shows the roles that participate in the process,the main decisions taken during execution of the process and the most important exceptions.

The following figure shows a general top-level process model:

Business Process Modeling

An example top-level process model for procurement business process is shown in the figure that follows:

Business Process Modeling

The top-level process model does not show the details of the process activities. These are shown on the detailed process maps.

Detailed Process Maps

Detailed process maps show the detailed process decomposition. (The top-level process activities included in the top-level process model are decomposed into detailed sub-processes.) The decomposition is done from the perspective of individual roles involved in the process.

For each top-level activity, a detailed process map is developed. (If a process is more complex, then these process maps are further decomposed into more detailed process maps, until the atomic activities are reached). Atomic activities are activities that do not need to be decomposed further. Atomic activities are well understood, and can be seen as distinct software operations, that will be implemented in order to provide end-to-end support for the process. Atomic activities can also be human tasks.

While modeling processes for SOA, it is very important to achieve the correct level of details. This means that the process should be decomposed to a low level of detail. This is important because the difficulties are often in the details. It is also important because, as developing SOA services we need to understand the details in order to implement them successfully.

The detailed process map also shows the conditions and the business rules. It is important to identify the business rules. In SOA, business rules are extracted and implemented within Business Rules Management Systems (BRMS). Identification of business rules should be done in their generic forms so that the business rules can be re-used in other processes. Therefore, we should strive to write down the generalized rules.

We should also identify the events that occur in the process. Events can interrupt the process flow. Events can also be generated by the process. It is important that we identify all relevant events.

When designing the detailed process flow, we put activities into swim-lanes to show the roles that are responsible for carrying-out specific activities. We also show which documents are inputs to certain activities, and which documents are generated by the activities.

The following figure shows an example of a detailed process map:

Business Process Modeling

Exception Handling Diagram

When designing the process, it is also particularly important that we should identify not just the regular process flow, but also the exception flow that each process has.

If an exception occurs, it should be handled. The exception handling diagram should show how to handle these exceptions. We should specify how exceptions are handled and by whom, and where the process goes on after the exception has been handled.

Often, exceptions require that we compensate activities of the process flow that have already been completed successfully. We might also want to compensate activities if an event interrupts the process flow.

The exception handling diagram is shown separately (separate from the regular process flow). The following example shows an exception in a process flow:

Business Process Modeling

The following exception handling diagram shows how to handle exceptions and compensate:

Business Process Modeling

Publishing and Communicating Process Models

An important part of business process modeling is communicating the models to all interested parties. This includes company management, unit management, supervisors, employees, quality assurance, and all other interested employees, all of whom can use the process model to better understand what is going on within the organization. They can also use the process model as work instructions.

Publishing the process model and communicating it to all interested employees is also important, because this way, we can gather feedback on the process and improve it even further. Publishing a process on the company's intranet is usually a good way to give visibility to process models.

Feedback on the process models can improve the quality, and can be a good source of ideas for improving and optimizing the process. This is the first step in building a continuous awareness about processes and their optimization among process owners and all others involved in the process.

Process Simulation

Process simulation is a useful feature that can help us verify an existing process model, identify bottlenecks, and prepare ideas for process optimization. Simulation is a proven approach to identifying possible bottlenecks, assessing the costs of running a process, and identifying potential problems with resources and their allocation.

The results of the simulation are used to define the optimizations in the process and to model the so-called to-be process, which will help the company to work more efficiently and produce better value.

For efficient simulation, we must have enough knowledge about the process itself, such as:

  • How many instances of the process are started in a certain period?
  • How are these distributed over the day, week, or month?
  • How long does it take, on average, to execute a particular activity?
  • How much cost (other than time) is incurred by the activity?
  • What quantity of which resources are utilized?
  • Is there any start-up cost or waiting cost for an activity?
  • How are the outcomes of decisions distributed (for example, if process behavior differs from the type of contract)?

Gathering this information can be time-consuming and can also lead to results that are not completely relevant. Sometimes, it is very difficult to assess the average execution time of a certain activity. This is particularly problematic if an activity takes a variable amount of time in the real world. If you ask an employee, he or she might not give you relevant information, because people simply don't measure the time it takes to complete an activity and do not calculate averages. In addition, there are many practical problems, for example, interruptions in the form of emails, phone calls, or a colleague knocking on the office door during the activity execution.

Most of the simulation-related problems are omitted in SOA because we can measure real quantitative data about process execution, calculate averages, and use such data in a simulation.

Tools for Simulating Processes

To make simulation efficient, we also need good tools, that can support simulation. Most SOA platforms such as Oracle, IBM, and BEA have built-in support for process simulation, which offers good capabilities and are likely to improve further in the future versions. In the market, we can also find several other tools, some of which are specialized in process simulation.

To identify the characteristics of a good tool, the following guidelines should be taken into account:

  • Ease of developing the process model: Ease of use allows people other than process analysts to be involved in the development of the process model and to make changes themselves.
  • Verification and correctness of the process model: Good tools should allow automatic verification of models to assess their validity.
  • Different perspectives and support for process patterns: A good tool should support process, resource, and data perspectives. The process perspective shows the process flow, the resource perspective shows the resource utilization, and the data perspective describes the documents used in the process.
  • Flexibility: Tools should provide means to specify the costs of activities, start-up costs, waiting costs, resource utilization, and all other relevant aspects. It should also provide support for distribution of incoming requests, support for queues, overload, and so on.
  • Animation: Graphical animation of simulations can be very useful and can give insights into how the process executes. Visualization can reveal bottlenecks and all other problems that might occur in the process.
  • Scenarios: Support for different scenarios within a simulation is useful. We can change the load patterns and the behavior patterns of activities while leaving the general flow of the process as it is. This can help simulate different real-world cases.
  • Results: A good tool should give various types of results, such as statistics. Results should be presented in an easy-to-understand format. Good tools also provide what-if analysis support and conclusion-making support.

Modeling Principles

When modeling business processes, our objective should be to develop sound process models. Soundness of the process models can be achieved if we follow some basic principles:

  • Syntax: Our model must have correct syntax as defined by the modeling notation. If we use BPMN, we should follow the BPMN syntax rules. Most tools can check the syntax.
  • Semantics: Our model should also be semantically correct. This means that we have included all relevant activities, decisions, events, documents, and other elements. This also means that the process flow is correct, and we have defined how to react to events, how to handle exceptions, and how to compensate, if necessary. We should also use the correct names for all elements. Achieving semantic correctness is more difficult than achieving syntactical correctness. Usually, it helps if we follow a selected method such as ARIS.
  • Relevance: We should model only those processes that are relevant to the problem domain. In modeling processes, we could easily get carried away because one process will typically relate to other processes. Sometimes, it is difficult to draw a line between what we should include and what we should not. The most basic principle is to include only those artifacts that are relevant from the perspective of the process and the problem domain we are focusing on. Too much modeling is a waste of time.
  • Cost versus benefit: We model processes to achieve specific benefits. We should therefore weigh the amount of effort against the anticipated benefits. Usually, the 80/20 rule applies here as well. 80% of the benefit comes from 20% of the effort, and vice versa. Therefore, it is important to know the level of detail and when it is better to stop modeling. The required level of detail can differ. If we are performing process modeling for quality assurance, a lower level of detail is required than if we are performing process modeling for an SOA implementation.
  • Usability: The model should be usable and understandable. Otherwise, the model is worth nothing. Business processes are complex. To achieve usability, we should decompose the model into various levels of detail. How we do the decomposition is important, as the parts should be understandable. We usually prefer simple models over more complex ones.
  • Standards: While modeling business processes, we should use and apply certain standards. First, we should use good practices and patterns. Second, we should use naming conventions. In some industries, standard or reference process models exist (such as eTom for Telecom operators). We should look for compliance, if it can add business value.
  • Integration: We should integrate different models that look at the same or similar process domains from different perspectives. The integrated model will reveal all aspects of the process. We should also design a process map, where all processes and relationships between them are listed.

Using these and some other more specific principles will help make our process models better, and more usable over a longer period of time. We should, however, be aware that modeling processes is not easy, although it might look easy at first sight. Therefore, in the next section of this article, we shall list common problems that we are likely to face.

Common Problems in Process Modeling

When modeling business processes, we will face several challenges. We have identified some of these in the following paragraphs.

Modeling business processes should be aligned with the overall business strategy. If the objective of process modeling is not related to some specific business goals, then it is a waste of time for all people involved. Therefore, it is crucial, that we define, from the beginning, what the goals of process modeling are. The goal can be, for example, to provide end-to-end IT support for a specific process. The goal can also be to improve the efficiency of the process. It is however important that we do not stick to such high-level goals. We should precisely articulate the specific goals of the company. We should know the exact process for which we want to develop end-to-end support for, where we want to improve the efficiency, and by how much. Without clearly defined goals with measurable outcomes, we should not start process modeling.

When we start process modeling, we should clearly define the responsibilities. In process modeling, people from different organizations participate. They must see value in participating, otherwise, they will not be willing to dedicate their time. Communicating the benefits of process modeling is therefore important. Even more important is to have support from the top-management. Only the top-management can order all employees to participate in the project.

We should define teams that will participate in the process modeling. Here is one possible structure of the team, which has proven to be efficient:

  • Process owner
  • Two persons to assist the process owner, coming from the same department
  • Process quality representative
  • Business process analyst (or analysts)
  • IT representative
  • Optionally, an external consultant

We also have to define measurable goals to assess whether process management has been done the right way, and what the benefits have been.

To be successful, we also need enough knowledge in process modeling. Business analyst should have multidisciplinary knowledge. They should be experts in the process modeling method and notation used. They also have to be familiar with the business domain. Otherwise, they will not be able to convert received information into process models.

Good knowledge about the existing process is also crucial. We should therefore be sure that we have included all of the people who can contribute:

  • People who have a detailed knowledge of the as-is model (existing process)
  • People with a vision for future development and optimization of the process
  • People who are aware of real limitations and resource restrictions
  • People who generate ideas

We should also not underestimate the effort required for process modeling. The number of processes in your company can be relatively high.

After processes are modeled, we should not just put the models into a drawer and forget about them. We should enforce the whole BPM cycle; otherwise, we will not realize the benefits related to continuous process optimization.

We should be aware that even with the best notation, such as BPMN, we cannot model all of the details, particularly the non-functional requirements such as security, costs, and so on.

When modeling processes, it is also crucial that in the first phase we stick to modeling the existing as-is state. It can easily happen that we start to model wishes. This way, we do not get a representative as-is model. Rather, we get a list of wishes that have not been verified in the real-world.


In this article, we had an overview of the role of business process modeling for SOA. We outlined the importance of BPM and had an overview of its life cycle. We saw process design phase, where we explained the ARIS methodology and BPMN notations, while discussing process simulation in brief. At the end, we discussed business process modeling principles. We saw that modeling business processes is not an easy task, and it can consume a lot of time and generate poor results if not handled the right way.

You've been reading an excerpt of:

Business Process Driven SOA using BPMN and BPEL

Explore Title