How should I design my process?

When I run my training courses, one of the main discussion points that come up is what level of granularity should you use when you are building a Workflow process.  This is particularly important if you are working with a non-technical business analyst – what appears on a Visio diagram as a simple two step process might well expand into a ten stage workflow process.

Here’s an example that I have used in the past which I’ll share here.  A business analyst produces a business process flow about how to search the database for records matching a certain criteria.  Once the search has been complete, there are some post-searching functions which need to be undertaken.  At the simplest level, here’s the Workflow process:

Bad design!
Bad design!

Whilst there is nothing wrong with the process at the most simple level, there is nothing right about it either!  Let’s make the process a bit more complex by adding some extra business rules.  Firstly, a date range is provided which may cover data that has been captured within the database or not – the search routine should validate this.  Secondly, there are different types of search which need to be performed, based on the inbound parameters.  Thirdly, if the search cannot be completed automatically, then the search will need to be performed manually.  Finally, there needs to be some external processing after the search, which needs to be communicated by updating a record in the database.

So, how best to implement the new business rules – in the existing code, or expand the process to accommodate the new logic?

No prizes for guessing what I’m going to suggest here – you should extend the Workflow process and separate the business logic into separate Workflow activities.  Workflow is designed for this – including complex (or even simple) logic within the process makes more sense than embedding it hidden in PL/SQL.  Here are a few reasons for doing it this way rather than in PL/SQL:

  • Reduced complexity of the solution
  • Easier to develop separate activities than one large procedure
  • Easier to expand the process in the future by changing th Workflow rather than PL/SQL
  • Easier to change the order of processing in a Workflow than in PL/SQL
  • Changes to the Workflow require less testing than in PL/SQL, since the flow is obvious
  • More visible solution to provide an overview of the business process

There are more reasons than these, but the main ones are the first and last – the lower complexity solution, which provides the best visibility of the process has to be the best solution.  So here’s an example of the same process expanded:

Good Design
Good Design

Just to go back to the start of the article, I’ll reiterate – conceptually speaking, there is nothing wrong with building a workflow in the manner of the first diagram.  However, it completely defeats the object of using a Workflow engine (why bother with the “complexity” of three activities – why not just have one if you want to simplify the process?  Indeed why use a workflow engine at all, if this is the approach you want to take when building the solution???)

In addition to this article, you should read the entry on storing information in item attributes here .

By continuing to use the site, you agree to the use of cookies. more information

In common with almost all professionally run websites, this website logs the IP address of each visitor in order to keep it running reliably. This is also essential for protecting the website and its visitors from malicious attacks, including infection with malware.

This website provides information as a service to visitors such as yourself, and to do this reliably and efficiently, it sometimes places small amounts of information on your computer or device (e.g. mobile phone). This includes small files known as cookies. The cookies stored by this website cannot be used to identify you personally.

We use cookies to understand what pages and information visitors find useful, and to detect problems such as broken links, or pages which are taking a long time to load.

We sometimes use cookies to remember a choice you make on one page, when you have moved to another page if that information can be used to make the website work better. For example:
- avoiding the need to ask for the same information several times during a session (e.g. when filling in forms), or
- remembering that you have logged in, so that you don’t have to re-enter your username and password on every page.

You can prevent the setting of cookies by adjusting the settings on your browser (see your browser Help for how to do this). Be aware that disabling cookies will affect the functionality of this and many other websites that you visit.