We all are aware of the importance of  BPM (where ‘M’ stands for modeling) for good business governance. BPM is the discipline of describing business processes in a uniform and ordered fashion. Documenting your business processes allows you to easily review them, share them and get control over them. Standardizing on one BPM tool makes it easier for the business to work with the models making them understandable to everyone. Once you have a good understanding of what your business processes look like you can improve them, modify them etc.

But having a BPM tool does not automatically give you a process driven solution.

There's a substantial difference between writing down your processes and having a business that truly focuses on business processes.

Let's say that you realize that you need to take control over your business processes, what you’d do is use some BPM solution where you start documenting the way you work. That's great, and it should be a priority for any company.

Once you’ve done that you have a much better understanding of the way things work (or don’t work) and why. Still you will feel that your processes are not ‘alive’; whenever your business changes you modify your process definitions to mirror those changes, your models are therefore somehow passive. Furthermore, having processes written down doesn’t mean that that’s the way they actually look like.

So how do you make sure that what you see is what you get?

Appointing a process owner is mandatory if you want to have some kind of governance but still the (business) process definitions you’ve created and the physical process implementations live in two separate worlds, the first a very abstract one and the latter very concrete.

The key is moving the focus towards the processes.

Because of the gap between definition and implementation the processes are not really driving the business, rather following it, if that. That’s where PDA (Process Driven Architecture), or POA (Process Oriented Architecture), comes into the picture. In a PDA you focus on the processes themselves as the starting point for (parts of) your architecture. As the representation of the business itself, processes reflect what your business wants and therefore it’s a good idea to treat them with respect.

‘A’ as in ‘Architecture’ might sound overdriven in PDA, but thinking process oriented does indeed affect the way you build your infrastructure.

Shifting focus to business processes means that you make sure that the infrastructure fully supports them. If a process requires manual interaction then you need to have some kind of user interface where you easily can implement the required functionality. If you have or want to have automated steps in a business process then you need a process engine to handle the execution and perhaps a rules engine in order to decouple the process logic from the business logic.

Furthermore, and that’s probably the most important aspect, all these components need to be able to interact with the BPM tool orchestrating them, directly or by using an intermediate ESB in case you have a SOA.

Traditional business processes consist of a number of people, systems and components that know little or nothing about each other and that don’t interact with the process definition itself.