Unlike other legacy BPM vendors, Decisions has a very comprehensive web service layer and other integration capabilities. This includes an integration wizard for web services and databases that automatically generates workflow steps for third party systems to be re-used inside Decisions design environment. Decisions also provides a very straightforward .NET SDK to add your own custom flow steps, rule verbs, form controls and other components for designers to use that might also fetch or push data to other systems. Because of our contemporary service oriented architecture, we often face the question:

“Should we use Decisions or an ESB?”

Unfortunately this is one of those, “it depends” questions. But hopefully this case summary can provide some principles that might help guide your decision.

We already have an ESB, what is the boundary between ESB and BPM?

We’ve worked with customers who already have an ESB and from Decisions perspective this can make BPM implementation much easier. A generally accepted paradigm for a service oriented architecture is a three layered system in which something like an ESB and a BPM solution become co-dependent.

In this model the BPM solves the problem of helping non-developers design, deploy, and optimize business processes that are defined by state and tend to be long-running. While ESB solves the problem of service orchestration or complex system integration with generally stateless short-lived transaction profiles.

With a contemporary BPM like Decisions there may be some cases where it is just as effective and potentially faster to design a back end batch process, or scheduled jobs that monitor SFTP sites than it would be in some ESBs.

We don’t have an established ESB, do I need both ESB and BPM?

Again, this very much depends on the use case. We would encourage you to start with BPM first to understand what the true data requirements are for your high priority business processes so you can work down the stack towards your system of record to understand what value an ESB might provide. There may be situations where the BPM has tooling out of the box to support the data in flight requirements. We’d be happy to provide a recommendation for ESB level solutions once they understand the situation.

In summary, I think it is important to understand that while the feature sets of ESB and BPM may share a boundary when it comes to data integrations – they are still fundamentally different tools with unique value propositions that are centered around different users. Decisions target user group is in the business – folks who don’t need to know how to code to design and optimize business logic. While ESBs tooling and user experience is getting dramatically better with tools like MuleSoft or other products – their target user is still in IT. 

For additional information about the Decisions Platform or the solutions its team has delivered, please contact sales@decisions.com.