Why Processes

This means to be a sequel of my previous post, where we started discussing the benefits of writing rules. I intend to do a similar thing, but now centred on the concept of Business Processes. As with last time, this post is oriented to people just getting started with the concept of processes, who are still getting into it. Processes are a simpler concept to grasp if you compare it to rules, but I still think we should start with a basic description.

What is a process?

The simplest explanation of a process I can come up with is “a sequence of steps to achieve something”. Actually, I wasn’t able to come up with it, it is a dictionary definition. But it is as simple as that, just a sequence of actions that need to be taken, by either systems or people, to achieve a goal. If we talk about a business process, we just need to add a little more definition to it and say it is a sequence of steps on a specific domain, performed by systems or people, to achieve a specific business objective.

If you come from the developer end you might be thinking “so? any code I ever wrote is a sequence of steps towards something!”. And you’re right! Code itself follows a sequence. It also has a purpose. If it reads inputs from a specific source, it can interact with systems or people, depending if the source is a specific integration component or a user interface. There are, however, several advantages that process definitions provide over plain code. We’ll cover some of them in this post

Diagramming structure

The first and most user friendly feature is the possibility of seeing the process definition as a diagram. We won’t need to see the process as an obscure list of method invocations, but as an image like this:

If defined in the BPMN2 standard (the current most accepted standard for defining executable processes), all the diagramming information is available in the process definition itself, so the same information used to determine which is the next step to follow will also define the structure for visualizing the process. This is very helpful for business users who probably don’t know about a specific technology, but they have a very clear understanding of the what needs to be done at what time. Which leads to the next advantage.

Process definition as a collaborative tool

Once you have a diagram, non-technical people can understand each step of what is happening. Thanks to process editors provided by each implementation of BPM, people with no specific development background can also edit the content to match the real world scenario. This makes the process definition the centre of our development effort. It not only provides itself as a documentation thanks to the diagram, but it also works as a connection point between business analysts and technical people. Business Analysts need to worry only about the specifics of the process completion (that it should match the specific objectives, what order should the steps in the process be following, who should be in charge of what human task, etc), and technical people need to worry about integrating the process with any other existing service. Which leads to another advantage

Business users take care of business. Development takes care of integration

This leads to an eventual freedom from the development side, from having to worry about making each component to follow ever changing processes. Developers, in this paradigm, only need to worry about providing the necessary connectors to different systems and people. By connectors, we mean system invokers that can be called from the process, components that will be able to invoke or signal a process, and forms for people to be able to do human tasks. From a developer’s perspective, the process will be something like this:

Where you will only need to worry about connecting processes with other systems and providing a UI for new forms. In a way, it releases developers from having the complete responsibility of defining the structure of the system, allowing more people to collaborate in the definition of how things are done, and letting developers concentrate on connecting those definitions with other systems.

Scalability

Since development efforts on the process definition side will decrease over time, people in the development area can start working on what they really know to do best. Better connectors, and better environment configurations. Eventually, as process execution demand starts growing, you can start working on the scalability of your BPM systems. And since all activities move around the same structures (the process executions), you can concentrate on making ways for processes to take as little time executing steps as possible, managing signals in distributed ways, and managing responses from the connectors in a way that more than one node could be able to receive them.

This leads to not only better running systems, but also a more manageable scalability of them. As all core processes of the company start moving to BPM systems instead of legacy applications, high availability and scalability of systems starts becoming an ubiquitous feature.

A company as a process (composed of other processes)

The final stage of this endeavour is getting more and more processes of the company working inside a BPM system. Since processes can invoke other processes inside them (called sub-processes), you can make a hierarchy of components which can be as broad as desired, to cover as many operations of your company. An ideal point in this stage will be reaching the main process of the company, where usually client or service request are the input, and the objectives of the company are the output. Inside that process (which, beleive it or not, could be quite a simple diagram), you will invoke every other process you define for each specific case in a hierarchy of processes invocations.

Summing up

Processes become a great way to involve as many parts of the company in the definition of the steps needed to perform a task. Nobody knows better how to do a specific task than the operation teams, and nobody understands better the objectives of a company than the managers. Also, nobody understand better how to accomplish those tasks in an automated way than the developer teams. With process definitions, each one of them can collaborate on the same component, all working together the same goal: improving the objectives of a company.

Also, process engines should take care of two things: Coordinating tasks between other systems and people, and taking care of storing the state of current active processes. It is like this because it should let other systems with other objectives do what they do best. Web Services should be in charge of services. Rules should be in charge of complex decisions. In general, a good process engine should try to be something like the following description (which I like to read with De Niro’s voice in this scene of “Men of Honor” 🙂 ):

A process engine isn’t a monolithic system, it’s an integration platform. If it should be done by someone else, it invokes it. If it needs a person, it notifies him. If many tasks need to be done at the same time, it synchronizes them. If it is lucky, it will execute for a few milliseconds for a process that should run over a full year, for that is the closest it will ever get to being considered efficient.

And please stay tuned for the next post, where we will be discussing the power of putting rules and processes together!