Workflow is a part of every business process application. When you define an application, you seek to understand the:
- Business objects you need to define and manage,
- Processes that create and modify and manage those objects,
- User interfaces that people need to use your application effectively, and
- Reports that users and admins will require.
In the list above, the 2nd item is associated with the potential need to either build your own workflows or to buy an embeddable workflow design and execution engine from another company. I have been through the process of deciding whether to build or buy 3 times and here were the considerations the make buy decision turned on each time:
6 Considerations For Your Workflow Make Buy Decision
- Complexity: do the processes that we want to program require looping and branching, sub-workflows, error handling, integration with other applications, many conditions, etc.?
- Change: will your processes change enough to make keeping up with complexity difficult if you hard-code or need to add additional functionality to your workflow?
- Development and Testing: are you prepared to dedicate much or all of one or more resources to building and maintaining workflow through its many iterations so as to guarantee your users that it works while OS and browsers and development environments change?
- Focus: do you want workflow to be your business focus?
- Cost: do the development and testing costs, with attendant risks, more than balance licensing costs?
- Capability: do you have the experience and capability to build the functionality and features needed by your process?
15 years ago, we chose to build our own workflow: we had an application wherein we wanted users to be able to build serial workflows (not complex,) we were willing to spend too much money (times were good,) and we had the people with the experience to build something that we thought would work (we did, but it was painful.)
13 years ago, we decided to license a 3rd party’s workflow and use it with applications that we built. The processes were complex because our clients’ processes were complex supply chain or regulatory processes. We were certain that our clients’ processes would change frequently, and underlying workflow functionality would need to grow with our needs. We chose one of the three vendors available at the time and it was a good relationship. Until their upgrade path proved to involve serious backwards compatibility issues and this presented untenable risks for our business.
4 years ago, we decided to take our experience and build a fully-functioning workflow that met our needs and the needs we thought the market as a whole would have. It was important to meet complex technical and business challenges, cope with change in a way that would not impact customers, and to offer workflow that users could afford. We made workflow a core focus for our company because we wanted to do it right.
These six considerations are based on our own make buy decision experiences and are intended to share the lessons learned along both make buy decision paths. We welcome the opportunity to discuss your own workflow engine requirements and specific make buy decision criterion.
A small sampling of the Workflow Technology for BPM Solutions contained within our cDevWorkflow product offering can be found here: Workflow Technology That Works.
Learn more about our Process Automation & IT, QA Services or Software Development products and solutions on the Web! Visit us at: Innovative Process Solutions