The new book "Improving Enterprise Business Process Management Systems", authored by Alexander Samarin, addresses the architectural and development framework covering different aspects of BPM starting with the BPM discipline and going via BMP software suites into BPM System solutions.
The author believes into strong coupling between BPM and SOA, and, when defining term 'process', adds:
"some operations of a service can be implemented as a process, and a process includes services in its implementation."
So, when you read about processes in this book, you may mean services.
One of the exceptional features of this book is an extended vocabulary defining basic terms. This gives the reader ability to agree with the author's terminology or establish appropriate translations instead of guessing what's what. This does not mean that you must agree with everything. For example, I do not share the definition of SOA as "an architectural approach for constructing software-intensive systems" or definition of an operation as a "distinct function" in all cases.
The book meticulously describes modern view on step-by-step approach and realisation of BPM systems. The latter is explained as a "portfolio of the business processes as well as practices and tools for governing the design, execution and evolution of this portfolio". Along this way, Alexander has constructed a nice symbolic language describing opinions of the stakeholders on the BPM system from the strategic, business and IT viewpoints. For example, if the stakeholders agree with the BPM architect on enterprise architecture, line management, business users, solution architecture and development while they allow the BPM architect to do whatever he/she wants in the area of management just to make the managers' life easier and the solution does not require to do anything extra in operational support, "there is the synergy between the business and IT". However, if the top management says it dos not know how to improve the BPM system and opinions of the stakeholders in all other areas - strategy, business and IT - are unknown, this situation is qualified as an opportunity for the BPM architect.
Another interesting topic discussed in the book is flexibility of BPM systems. Considering that a business process is inflexible by definition, i.e. it tends to maximise robustness and minimise changes because a change in the process' business logic results in another process, flexibility of process management is about flexibility in the management of the process supplies. To find how this problem is resolved, you need to read the book. Actually, it is not huge and very illustrative having 135 figures for 189 pages.
At the end, I would like to outline that the author has shared his rich experience in the BPM area and described 24 BPM patterns with recommendations when they may to be useful. I think the book worth reading, at least, for this information alone.
Thanks Michael,
I would like to add a recent example about flexibility of processes from a tender for an MIS for a governmental agency. Some parameters of this tender:
• High level of flexibility explicitly required
• Budget 4,5 MCHF
• About 10 offers
Some contenders:
• Classic development – 17 MCHF
• ERP hidden under workflow – 4 MCHF
• BPM-based – 2,5 MCHF
The latter has demonstrated a simple prototype and that helped to win the tender. Of course, to calm down the internal IT department, the winner has to do an extra “feasibility” step -- quickly demonstrate a very advanced prototype, which works at the client’s IT environment.
Thanks,
AS