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.