I am putting together an architecture for a mid sized company who want to introduce a BPM (Business Process Management) tool. I understand that this would be helpful and want to introduce it but stuggle to find its appropriate place within the architecture.
I want to know when and how you should use a BPM tool, how do you differentiate Business Process from Application Workflow?
Why do you want to introduce a BPM tool? Is it buzzword compliance? If you are struggling to find a place in the architecture, then I would suspect that the tool isn't going to bring a big win (at least not with your current understanding).
Application workflow tools typically concern themselves with modeling a specific process and giving semi-technical process designers the ability to show the steps and interactions, while allowing programmers to flesh the skeleton out with code that implements the pieces. Personally, I have found that the overhead of training semi-technical process leads can offset the promised gains in effective communication and turnaround, but in large organizations it can ensure the the process "owner" has the illusion of control necessary for buyoff on plans. I say illusion, because at the end of the day it is the IT staff that regenerates the code that implements the process, and often suggested changes get reverted due to problems on the technical side (such tools often make changes easier to suggest than to implement).
Some Business Process Management tools are little more than Application Workflow tools with higher price tags. Some take a higher view and incorporate the manual flows and other non-IT processes into the architecture (although obviously such steps are really nothing more than stubs or gatekeepers for exiting and re-entering the IT flow). I have no idea what you are calling a mid sized company, but at a 160 man aerospace engineering firm, we found BPM tools that we evaluated overkill.
Sadly, this is one of those questions where only subjected answers can be given, even with all the facts (different System Analysts will give different opinions). I hope that a quick overview is at least of some help. Just beware sales hype: I find such tools to be of value only in specific organizations with specific process flows and a hindrance in others.
If a company has processes in place that handle most cases of how things should flow through, then it can be time to introduce BPM tools for examining the current processes. In a sense this reminds me of the "Is BPM in your mind?" question that was asked a while back.
I've found more useful and rewarding to introduce BPM in companies that already have some formal business process established already-
Application workflows are more in the line to automate user interaction only ( documents, authorizations, signatures etc. ) . But when it comes to user/systems interaction, BPM comes very handy.
It is not only the final user can see and understand the real flow of the app ( for they won't move a finger to make any changes that's fine ) But to avoid repeating task, or complex interaction between systems.
Of course you may code this in an app starting from 0 but it does not makes sense or scale when a Business process may actually be used for other process as a service. BPM suites let you do this in a couple of hours ( actually couple of click but don't tell the customer )
So going back to your question and depending on the BPM tool capacities, if there is already a business process and that process requires interaction among users of different ( this is important ) areas and different systems it is worth to introduce the BPM.
If the interaction is more "human oriented" ( documents, approvals, etc ) App Workflow will do ( or BPM used as workflow if they already have the tool )
If the interaction is amog users of the same area, or the data is relatively easy to consume and nobody cares about the Business Process ( ie. who's turn to go for sodas ) , you can create a web/desk app from scratch.
"When & how should you use a BPM tool"
Oscar Reyes makes the point directly in the first sentence of his post. You need process vision.
A BPM tool (strictly speaking), is a tool that's supposed to manage business processes. The warning in Godeke's post above is also right. Not all BPM tools are created equal. In fact, I challenge you can't get anyone to agree on what BPM actually is. The term has been usurped by various parties including software vendors, consultants, analysts, and news organizations (to name a few).
But to answer directly, a BPM tool is appropriate when a business wants to automate a portion or all of a business process. Note... all businesses have business processes. It's just that not all businesses document or manage by them.
'How' to implement a BPM tool is context dependent because there are different 'types' of BPM solutions. Broadly speaking (and this is fodder for debate), you can break down BPM into transactional and human-centric processes. Transactional BPM is targeted at automating system-level processes - mostly integration. You'll see lots here about SOA. Human-centric BPM is targeted (obviously) at processes that involve human interaction - mostly document or structured/unstructured data management.
"differentiate Business Process from Application Workflow"
See above. This is a very generic discussion. And much needs to be done up front to adequately identify a BPM project.
The first question to ask is, "Does our company currently manage its business by process or does it want to?". The answer to this question should come from the top. My experience has been that without the executive-level commitment to process-centric business management, a BPM project will likely fail to meet its objectives. Not that you won't be able to install a BPM tool and get it to integrate systems or manage electronic documents, but that the ROI of the project will likely be missed or lost.
Bottom line, a BPM project will require a process-centric business vision, and with that, you will be in a much better position to define an appropriate architecture to support that vision.