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.
So what’s the difference in a PDA? In a PDA business
processes are the driving force, if you want to change a business step, for
example adding a manual approval step for orders below a certain amount then you
modify your process definition, assuming you have designed your processes and
architecture in a way that makes it possible, meaning that the components
involved need to be able to interact with the BPM tool.
In a PDA you map each step in your processes to
some component/function performing the required operation.
Automated steps would be typically executed by
a process engine (sometimes called integration platform) handling the
interaction with the underlying systems.
And you’d probably need some kind of rules
engine/repository where the BPM can check the business rules and a process
engine could read process-specific rules from.
Slowly you are building a reference
architecture, where you have some component (the portal) for user interaction,
a BPM tool capable of exchanging information with other components, a process
engine, a rules engine and perhaps a catalogue service in order to manage
groups and control what information is presented in the portal or which steps
can be performed by whom in the BPM tool
and you suddenly realize that building in a process-centric manner/fashion is
indeed having a huge impact on your architecture.
In fact, PDA might be a very demanding
discipline, requiring a lot of tailoring in order to fit your specific needs.
Let’s do assume that you are going to use a portal for the user interactions in
your processes, then you need to be sure that all the components that require
user interaction can be exposed as a portlet (or at least can somehow ‘speak’
to the BPM) or else you’ll be stuck with a manual step that you cannot link to
the process itself creating process discontinuity. And of course you will have
your existing systems that might not be easily adaptable to a PDA making it
difficult to have effective, self containing processes, where self containing
means that the process orchestrates the whole flow from the beginning to the
end.
Beneath a PDA you might (and should) have a
SOA, with an ESB exposing services from a multitude of systems so that the BPM doesn’t
need to interact with them directly.
PDA and SOA complement each other pretty well,
SOA profits from having a good BPM strategy and PDA bridges the gap between BPM
and SOA.
Some mean that BPM is an integral part of SOA,
I assume that’s because controlling your processes makes it easier to identify
which business services are required to support them. Though I do think that
including BPM in SOA is stretching the definition quite a bit, I agree that BPM
is tightly related to SOA, for the above mentioned reasons. At the same time,
depending on what your definition of SOA is, BPM might be out of the scope,
especially if you are thinking of SOA in an infrastructure oriented way,
meaning that your focus is services and not business services.
So, to summarize, PDA is just an architectural
style where the business processes are not merely a model definition but rather
participate in the business itself, every step in your processes maps to a
system/component/action that should be implemented in your infrastructure and
when building your architecture it’s the business processes that set the guidelines
for which components you will need.
Though PDA does not try to address all aspects
of an architecture and is not a one-stop solution for your infrastructure
needs, it is a good approach when trying to identify which components are
required in order to support your business, especially if your business is
heavily processes-oriented.