BPM mapping tools – integrating data?

As I was shifting through my usual amount of mails this morning, I spotted a google alert regarding an article titled “BPM must integrate people, documents”. Now I thought that’s a tad obvious, and promptly went to read the article thinking I had missed something….And basically I hadn’t…

A good point was raised though, that most BPM software targets business analysts and project managers. There are usually options to utilise SDKs but these are often a low priority as the main selling point is almost always “out of the box” demonstrations aimed at business analysts. However, am I the only one that sees a flaw in this?

BPM design tools. Are they flawed?

Now putting together demonstrations and targeting analysts are all good things to a degree, however in the world of BPM I still maintain that too much is done to show a great demo, allow analysts to “model” processes and not enough is done to provide real integration and back end flexibility. What do I mean by this? Well, systems integration in the “real world” often require a lot more work than simply setting up some connectors with common integration points. Often you need to call functions from other systems, pull in data from more than just a single source, carry out some complex processing, update multiple systems etc all within a single step. Can you really do all this from a fancy modelling tool….My guess is no.

Modelling tools give power to the business

This is so very true. Business can make tweaks to their processes and make them happen immediately, which is great. Many BPM solutions almost live and die by their modelling tools / facilities and spend vast amounts of time, effort and money in making these better and more flexibile. There are so many benefits which many other articles will and have talked about. But again, in my experience, many larger systems aren’t just “out of the box”, nor are many smaller systems. They have applications written in .NET for example, that use the process map for guidelines and routing business rules. The application itself then contains its own “business layer” (if written well) which contains certain inbuilt business rules – typically regarding calculations and integration with other LOBs.

I have worked on numerous BPM projects that work in this way, providing lots of applications for different steps within the process map, using the process map for merely setting statuses and routing information. The application itself holds all the business logic and integration code. Even on the more complex solutions, an application was delivered in place of any out of the box front end components. Business rules were built into the application to interpret the process map, which in theory did give back more power to the process map, regarding statuses, routing, cooling off periods etc.

In this case you can see that the modelling tool gives power to the business on when and where to route work for example. Even such things as options the user can select, cooling down processes, awaiting other tasks etc. However, the real integration and bringing people / data together, happens in the business application, written by developers specifically for that client requirement.

But what happens if the business analyst wants to make a change to the process that involves carrying out additional calculations at a particular step or pulling in more content / data from other platforms. He can make the changes as he sees fit in the map, but what about the actual rules etc? More often than not a “change request” is raised and someone in the development team has to make a modification to the code of the application, which then obviously needs to be tested in a model office environment before being released. So even though the business feels like it has ownership of the process map, it doesn’t really have great ownership over how the map actually works as a process for the business. In this scenario the actual time taken to make the change is quite lengthy. Let’s break it down:

1. Business identifies the need for change
2. Business analyst is involved and investigates the options
3. Business analyst provides a new solution
4. Business analyst updates / creates a new business process map
5. Change request is made and passed on to the software developer
6. Business analyst updates the process map
7. Software developer makes the required changes
8. Process map is then tested (UNIT test)
9. Software is then tested against the new map (UNIT test)
10. Software is then sent back to a testing environment
11. Testing environment tests the new map and all the related applications / scenarios
12. New process map and application is released to the live environment

As you can see that’s quite a list of things that must happen.

What’s the answer?

It’s simple. Let’s let people do the jobs they are supposed to do, and let’s let software provide us with what it is designed to do, nothing more and nothing less.

So with this in mind. imagine a business analyst who models the business process. He / she put together a complete map with users, groups, security, calculations identified, function calls to other LOBs etc. They then model this in Visio for example with some accompanying documentation.

Once this is all complete, let’s move this over to the actual BPM software, which should allow all these things to be included into the “map”, even execution of complex code, calculations and integration etc. Please note, the BPM engine shouldn’t be confused with the BPM front end at this stage. The user will never see the “engine” as such. So our BPM specialist (which is more than likely at this level to be a developer), makes the changes to the BPM map, codes the required calculations and integrations and completes the map. This is then “tested” before being published. Please note, no application code has changed, there is no need to test the applications etc, rather just the map itself.

The last part of our solution is our front end. This should be written to only present data to the user and allow them to interact with that data, people or other systems depending on the BPM map (which holds all the rules / calculations etc). Because map changes are made in the map and are completely separate from other deliverable code, namely our actual application / front end, the whole process of making a change to the process map and having it made live is far shorter, less likely to fail, far more flexible and in the end, much cheaper.

Let’s review:

1. Business identifies the need for change
2. Business analyst is involved and investigates the options
3. Business analyst provides a new solution
4. Software developer updates / provides a new map
5. Process map is then tested (UNIT)
6. Process map is sent to testing environment
7. Process map is made live

We could even add in: 8. Full testing of the process map and application; and we are still 4 points shorter in our list of things to do. In addition, each point in this second implementation is not as time consuming as those in the previous list…

The downside

Because this type of BPM system / solution doesn’t display a great map for business analysts with lots of feature rich BA tools, it doesn’t really quickly and easily demonstrate BPM. A system like this won’t allow a BA to make a change to the process map and have it published immediately. All of this means that this kind of system, though in many ways far superior, may be viewed in a demonstration as a simpler tool with fewer capabilities.

Conclusion

When choosing your BPM platform, really focus on your actual requirements. Have more than just a rough idea of your processes and desired outcomes. If you have an in-house IT department, make sure you bring along a senior member of that team to any demonstrations / meetings.

Remember, a demonstration is not the same as a solution and don’t fall for the statement, “we have an SDK you can use to integrate”. This almost always means you need to build those more “complex rules and calculations” into your own application / step processor, not in the process itself.

BPM mapping tools are great; they deliver a powerful and rich environment that is fantastic for demonstrations. But make sure the BPM map itself has the capabilities and flexibility to meet your requirements without the need for you to build essentially what should be process rules into your own step processor / front end application…

Even with BPM there is still a process that you must follow to get your BPM system to work for your needs…