Many businesses are focusing on capturing their business processes, and are trying to understand what is the best tool set and methodology. This article compares several of the common approaches, showing the advantages of building a process model. It also demonstrates how IBM® WebSphere Business Modeler® (hereafter called Modeler) is a powerful tool for creating process models.


Marc Fasbinder, Consulting I/T Specialist, WebSphere Software Technical Sales, IBM

Photo of Marc FasbinderMarc Fasbinder is an I/T Specialist at IBM with the WebSphere Technical Sales team in Southfield, Michigan.

30 May 2007

Also available in Chinese


Companies are finding many reasons to capture their business processes. Companies who have merged want to examine processes across their lines of business to discover which one is the best of breed. Other companies are looking to improve their existing processes, or even to automate them. In some countries, government regulations require that business processes be properly documented. For example, the Sarbanes-Oxley act in the United States regulates that certain processes must be well documented. These are among the many drivers in the business world today that are making companies take a closer look at their processes.

In general, business process drivers can be summarized into three major categories:

  • Documentation. Companies need to capture business processes so that others can understand how they work, who is involved, and how activities flow from beginning to end. Typically a business analyst who understands how the processes work models these processes.
  • Redesign. Many businesses want to improve their business processes to reduce inefficiencies, drive down costs, and respond faster to customer requests. A process cannot be redesigned before it is understood, so it must first be captured. Redesign can only come after you have properly documented the process. Typically a technical analyst, or perhaps an I/T liaison to the business who understands both the business needs, and the I/T systems models these processes.
  • Execution. In most cases, the best way to improve the efficiency of a business process is to apply automation to it. If you can reduce or eliminate manual work, the process can be performed faster and at a lower cost. To apply process automation, the business’s I/T staff or a consultant must write code or use a middleware product. It would not be advisable to automate an inefficient process. For this reason, this phase should only occur after you have redesigned the process.

Other types of modeling are out of the scope of this article, for example UML modeling performed by a software architect as part of the code development cycle, or enterprise modeling used in impact analysis. This article focuses on business modeling, and you only need conceptual product knowledge.


To capture any business process, no matter what the goal, you need to use a tool. In general, the three most common tools are:

  • Text-based document. You could use a word processor such as IBM Lotus® Word Pro to create a document containing information about the process.
  • Drawing tool. You could use a graphic tool such as IBM Lotus Freelance Graphics to create pictures to represent the process flow. Typically the picture is combined with a text document that contains further details.
  • Business modeling tool. You could use a tool such as WebSphere Business Modeler to create a model of the business process. A model is graphic in nature, yet it is far more than just a picture.

This article examines the usage of these tools across the three business reasons for capturing the business process.

Text based documents

One of the simplest tools to document a process is a text-based document processor. Text documents have been used for many years to capture business processes. Their advantage is that virtually every business already has a word processing tool.


  • Some concepts are difficult to express with just words. For example, in a complex flow where there are nested subprocesses, or branching decisions with six different outputs, it can be difficult to understand the process flow if it is just described with words. A picture can express these concepts more easily, while words alone cause confusion. Multinational corporations face language barriers when using just text for documentation.
  • Text is good at expressing what is done in a single step of in a business process. However, the overall end-to-end scenario can be difficult to envision.
  • If you change the process, it is difficult to determine all of the places in the document that need to be updated. For example, if three steps are to be combined into a subprocess, and reused again later in the high level process, it’s very difficult to know all of the places where text needs to be altered. This means that the document would become less accurate over time, as the process changes.
  • Only one person at a time can work on a document, because it is just a simple file. Collaborative development is not possible.


  • Other than documenting what the business process actually is, a text based document does nothing to aid in the redesign of a process.


  • I/T uses a technical tool set to build the automated business process. Everything the analyst documented must by re-entered into the technical tool set. This can take a considerable amount of time.
  • Business analysts and I/T professionals have different semantics and different ways to express concepts. What seems clear and concise to an analyst might be ambiguous to an I/T resource.

Text-based documents recommendation

Use a text-based tool to document use cases, but not the overall business process. Even when documenting use cases, tools such as IBM Rational® ClearCase offer many advantages over a plain text document. A document processor is not the optimal tool for capturing a business process.

Drawing tool

Businesses have used flowcharts and other graphics for years for one simple reason: a picture can often express something quickly and simply, which would take thousands of words in a document. A flowchart is good at showing the big picture, instead of bogging you down in the details like a text document can.


  • A flowchart picture is just a picture. It alone cannot describe the details behind each step in a process. The drawing spaces just doesn’t provide enough room to include every detail. A separate text document is required as well, to hold the details missing from the picture. Now you must keep the picture and the document in sync whenever a change is made to either one. This is not a trivial task, especially for a large complex process.
  • The flowchart, being a drawing, is very static. You cannot look at different aspects of it. For example, you cannot click a button to show the flow by organization or by role. What you see is what you get; it is just a picture.
  • Most drawing tools have a large library of shapes and graphic icons that you can use in the picture. This allows flexibility, but it also means that it is very easy to create a picture that is ambiguous. A circle can be used as a decision, or a diamond, or a square, or any shape for that matter. When someone other than the author examines the picture, there is an opportunity for miscommunication.
  • If an organization sets standards for which shapes are to represent different objects in a process, there is no way to error check to be sure that the shapes are used correctly. It is up to each author to enforce the rules.
  • Only one person at a time can work on a drawing, because it is editing a simple document. Collaborative development is not possible.


  • A simple picture cannot represent any of the dynamic aspects of a business process. For this reason, other than documentation, a drawing tool does nothing to aid in the redesign of a business process.


  • I/T would still need to reenter all of the information from the flowchart as well as the accompanying text document into their own tool set. Pictures alone cannot produce useful I/T artifacts. This manual work takes considerable time, with ample chance for miscommunication.
  • I/T could build something that does not match the expectations of the business users, which could lead to costly iterations reworking the code until they meet the expectations of the business.
  • A drawing tool does not help drive reuse. It cannot consume Web Service Definition Language (WSDL), XML Schema Definition (XSD) or other standards-based artifacts. A drawing tool cannot query a registry, such as IBM WebSphere Services Registry & Repository, to see if a reusable service already exists. All of this work is left to I/T, adding time to the development cycle.

Drawing tool recommendation

Drawing tools alone cannot express a business process. To capture the details you to use them along with a word processing tool. In addition, the two documents must be kept in sync. Together they work better than either one does alone, but they still fall short of being an optimal solution for any of the three business drivers for capturing a process.

Business Modeling tool

Using a modeling tool such as WebSphere Business Modeler has all of the advantages of a flowchart picture, since it includes a visual representation of the process. However, it also has the advantages of a text document, since each object in the model can include attributes like comments and documentation.


  • Like a drawing tool, a model presents a visual image of the business process. But it is more than just a picture: each of the elements in a model has attributes you can use for documentation. It combines both the visual and textual aspects of the process in one single entity: the model.
  • A model is more than just a picture. The view on the screen is just one aspect of the model. For example you can switch from a free-form flowchart to a swimlane (line of visibility) view at any time.
  • A modeling tool such uses a consistent set of objects to represent the business process. For example, a decision is always a diamond. The model precisely represents vital aspects of the business process.
  • A modeling tool can import standards-based artifacts such as XSD and WSDL, or search for them in a registry. This not only means it can help encourage reuse of existing assets, but I/T does not have to re-enter or recreate information, saving time and ensuring accuracy.


  • Many business modeling tools enable you to simulate a process model -- something which could never be done with just a simple picture! Simulation enables the user to understand the dynamic behavior of the business process. Where are the times in the process? Where are the costs? Where are the bottlenecks? Are there resource shortages? These questions help in the effort to redesign the business process.
  • When a process has been redesigned, it too can be simulated. The as-is (current state) process can be compared with the to-be (future state) process, to verify the impact of the process redesign.
  • These capabilities enable a business to perform the redesign themselves, rather than having to hire expensive consultants.


  • Business modeling tools can transform the business model into useful artifacts for I/T. This reduces or eliminates the need for I/T to re-enter information into their technical tool set. The artifacts themselves are usually based on runtime standards such as WS-BPEL.

It could be argued that modeling for execution can be performed by a technical tool designed for the runtime environment, such as using WebSphere Integration Developer to create WS-BPEL. There are several disadvantages to creating the technical WS-BPEL model directly, without first using a business modeling tool:

  • Technical modeling tools cannot perform simulations to ensure that the process is efficient before it is deployed.
  • Using a technical modeling tool without a business modeling tool means that I/T needs to create a model from scratch, based on drawings or paper documents. As previously discussed, this can lead to miscommunication and tends to slow down the development cycle.

For these reasons, modeling for execution is best performed with a business modeling tool before working with a technical modeling tool.

Modeling tool recommendation

These capabilities of modeling tools go well beyond anything you could do with a simple drawing tool and/or a word processing tool. The process can be captured in greater detail, with a higher degree of accuracy. Reuse of existing resources is encouraged. Simulation enables process redesign, and useful artifacts can be generated for I/T developers. A picture is just a picture, but a model is a plan for how to build something.

These capabilities make Business Modeler an ideal tool, whether the goal is modeling for documentation, redesign, or execution.

WebSphere Business Modeler as a business modeling tool

A business modeling tool is clearly the best solution. WebSphere Business Modeler is an industry-leading tool in the business modeling space. For all three of the reasons for modeling, Business Modeler has many useful features and functions.


In addition to the basic documentation capabilities of any modeling tool, Business Modeler has these additional capabilities:

  • A non-technical business analyst does not want to see the technical details in a model. An I/T resource does want to see them. Business Modeler has different modes to enable this: basic, intermediate, advanced, and WebSphere Process Server. The more technical users can view technical attributes that are hidden from the business user. Yet they are still part of the model, even if the business user cannot view them.
  • Swimlanes in Business Modeler can be based on more than just job role. You can also use individual resource definition, bulk resource definition, classifier, organization unit, or location. You can create your own classifiers, which enables you to organize your swimlanes based on any attribute you may define.
  • Business Modeler uses a model instead of a simple drawing file. This allows multiple users to collaborate, using a repository such as IBM Rational ClearCase for check-in/check-out, version control, and locking resources.
  • Business Modeler can publish models using IBM WebSphere Publishing Server, so that authorized users can view the model using just a Web browser. Users can also offer comments and feedback. This enables a broader spectrum of users in a business to collaborate and offer their input on the process being modeled, which helps ensure that it is correct and complete.
  • Business Modeler captures more than just the process itself. It can capture information on organizations, roles, resources, qualifications, and more. These aspects of the business process are vital for the understanding of the environment in which the process runs.
  • Business Modeler can generate reports on the static parts of the business process, or produce queries across the entire process catalog.


  • The simulation engine in Business Modeler includes many advanced features that enable you to accurately simulation your process. If a simulation is not accurate, the generated reports are also not accurate, or useful. To more accurately simulate real-workd process behavior, you can use distributions, steady state simulation, business item instances and other capabilities.
  • Dynamic analysis in Business Modeler includes many reports, which enable you to understand the results of the simulation. You can also create your own custom reports, if there is something you want to show that is not in any of the standard reports. You can also export report results to delimited files for further offline analysis.


  • When the redesign of the process has been proven out through simulation, I/T can add additional technical details to the model. You can then export the model, creating useful artifacts for I/T using standards such as WS-BPEL, XSD and WSDL.
  • You can also reuse the business model in IBM Rational Software Architect, enabling the software architects to create UML models based on the information captured by the business analysts.
  • The technology modes of Business Modeler perform deeper error checking on the model. For example, WebSphere Process Server mode checks the model to ensure that the generated WS-BPEL will be correct.

Case Studies

The following cases are examples of the ambiguity of a drawing tool versus the precision of a modeling tool. In each case, something that could be left open to interpretation from a drawing is better defined in a model.

Ambiguous flow

Our first case (Figure 1) shows how a drawing tool typically handles flow diagrams, which can be very ambiguous. Does the flow from review request go into one of the following steps? Does it flow into both steps in parallel? The drawing tool does not give enough information to know this.

Figure 1. Ambiguous flow drawing
Figure 1. Ambiguous flow drawing

Compare Figure 1 with Figure 2. Business Modeler uses a fork to clearly indicate that the two steps are performed in parallel. The model is unambiguous, while the picture in Figure 1 is open to interpretation.

Figure 2. Unambiguous Flow model
Figure 2. Unambiguous Flow model

No indication of flow direction

Figure 3 shows a common diagram style with no indication of the flow direction. Does the flow being with verify address? Does the flow being with verify part numbers? It all depends on the interpretation of the person viewing the picture.

Figure 3. Flow direction drawing
Figure 3. Flow direction drawing

Compare Figure 3 with Figure 4. Connectors in Business Modeler always show the direction of the flow. There can be no question as to which task is first.

Figure 4. Flow direction model
Figure 4. Flow direction model

Inconsistent use of shapes

Figure 5 uses a circle as a decision point, as well as a diamond. Another viewer might interpret the circle as a node for a parallel branch. There is no way in a drawing tool to enforce the proper usage of the different shapes.

Figure 5. Inconsistent shapes in a drawing
Figure 5. Inconsistent shapes in a drawing

In Business Modeler, a decision is always a diamond. The process model enforces consistency. Note that the merge activity brings the two paths down into one single path. Decisions also show information as to how often the business analyst thinks each branch will be taken.

Figure 6. Consistent shapes in a model
Figure 6. Consistent shapes in a model

Ambiguous graphics

Figure 7 shows confusing graphics from a drawing tool. What does the stick figure man in the diagram represent? In addition, for multinational corporations, a graphic figure might mean different things to different cultures.

Figure 7. Ambiguous graphics in a drawing
Figure 7. Ambiguous graphics in a drawing

In Business Modeler, you use swimlanes to indicate the resources required for each step, as Figure 8 shows. Rather than using the stick figure, it is clear now that the verify address step is performed by a person with the role of verifier.

Figure 8. Swimlanes clarify required resources
Figure 8. Swimlanes clarify required resources

As an alternative, you can add labels to tasks, displaying the role information, as in Figure 9:

Figure 9. Task labels in the model
Figure 9. Task labels in the model

Number references

Because of the need to tie the picture from a drawing tool to a document with the details in text form, it is common to use numbers for each step. Over time as the process is updated, numbering could become confusing, for example:

  • The process in Figure 10 originally had steps 1.0, 1.1, 1.2 and 1.3.
  • At a later time, a subprocess step was added between 1.1 and 1.2, labeled 1.11
  • At an even later time, step 1.2 was eliminated.

Now the process flow looks as if it could be missing a step. If a step needs to be added between 1.1 and 1.11, the resulting number could further add to the confusion.

Number references in a drawing
Number references in a drawing

In Business Modeler, each of the objects in the process has attributes to describe it, so there’s no need to maintain an external document for the step. Without the need for the external document, you no longer need numbers for the steps.

Business Modeler uses a different icon to show that update request is a subprocess, whereas the drawing tool allowed a rectangle to be used for both the subprocess and a task. Lastly, the business model also shows the flow of data, which is missing from the drawing.

Figure 10. Number references in a model
Figure 10. Number references in a model

References to other processes

In a drawing tool, when you refer to a different process you have to describe it in words, as Figure 11 shows:

Figure 11. Textual references to other processes in a drawing
Figure 11. Textual references to other processes in a drawing

In Business Modeler, you can right-click the global process then select Launch Global Process Editor to automatically open the process, as Figure 12 shows. The user does not have to track down the additional documentation. The process model has a link to the global process. This makes management of the model far easier than managing a set of pictures.

Figure 12. Automatic process links in a model
Figure 12. Automatic process links in a model

Lack of error checking

In a drawing tool, there is no error checking or enforcement of rules. Figure 13 shows a process with a yes/no decision, but no output condition for a “no” decision.

Figure 13. No error checking in a drawing
Figure 13. No error checking in a drawing

In Business Modeler, I/T can use technology modes such as WebSphere Process Server mode. It flags errors ranging from unconnected links, to undefined conditions or other missing attributes. This ensures that the model will be complete and correct.

Figure 14. Error checking in a model
Figure 14. Error checking in a model

Ambiguous logic

Often times the domain expert who creates a drawing knows their area. To such an expert, the drawing is clear and complete. To another person without the domain knowledge, the drawing might seem confusing or ambiguous.

Figure 15. Ambiguous logic in a drawing
Figure 15. Ambiguous logic in a drawing

Business Modeler clearly shows each of the paths and the logic. The model is clear and unambiguous, even to someone who is not a domain expert.

Figure 16. Unambiguous logic in a model
Figure 16. Unambiguous logic in a model


This article showed why modeling is important to a business, and how WebSphere Business Modeler can help whether modeling for documentation, redesign or execution.



Get products and technologies


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Why model business processes?