I stayed around for the 2nd half of the Microsoft session to hear about their BPM customer success story with Mario Cataldo, CIO of FirstAgain, an online lender.
They are doing loan origination, funding and loan servicing processes in support of their online lending operations, including credit modeling and underwriting, but also administrative processes such as invoice generation and email templates.
They’ve made heavy use of business rules within their business processes, looking for ways to minimize IT involvement when business rules change by identifying the areas of frequent change. Since their applications are essentially built in code (rather than, I am assuming, a graphical model), this is an essential contributor to their agility, and he spent quite a bit of his presentation discussing how business rules improve their processes and their selection methodology, which led to their selection of InRule.
They initially started with an unnamed third-party workflow product, but after Microsoft released .Net 3.0 and Workflow Foundation (and after they had already deployed the other product), they switched away from their selected workflow product to Microsoft WF. Since they were already in production with the other tool since 2006, they’ve been stripping that out and replacing it, and plan to go into production soon with the Microsoft WF solution. They converted to the Microsoft product because it gave them better extensibility, performance and scalability, and reduced their costs since WF is included in .Net 3.0.
This is a much more code-intensive type of implementation than what you would see with most BPM suites, since it’s really a workflow extension to a development environment rather than anything like a BPM suite. Having to build your own workflow administration, for example, puts off a lot of people.
There are some good use cases for this mode of implementation, however: one is small software shops with a group of highly capable developers and a limited budget who are more likely to spend money on talent than someone else’s code, such as a startup; this is exactly FirstAgain’s situation. Although they tried out a more full-featured workflow product, it didn’t have the scalability that they needed, and ultimately they preferred to build it themselves. Coming from a software development background, I understand this mindset: if you have a talented team, you can likely build something better for your specific needs right now. The problems come as your requirements shift, or as the BPM market changes, and new functionality offered by full-featured vendors isn’t available to you since you’d have to build it yourself. Realistically, there are many parts of a full BPM suite that you’re just not going to build if you do it yourself on the shoestring budget model; you need to consider if those are important to you or not.