Intelligent BPM maps

14 01 2010

I have posted about BPM maps hindering flexibility and capabilities to some extent before (regarding systems integration). See:

However, in this post I want to take this further by looking at how BPM maps (I use the term map loosely here) can become intelligent and hold much more than just business process routing rules…

The role of the map

For many this is the “definition” if you like of a business process, shown in a graphical map format. This is great, and it’s true to some extent. However, I believe the primary role of a workflow system is to deliver systems integration, not a predefined diagram of a process.  BPM and workflow only works well when it brings together systems, people and data to maximise the efficiency of a business requirement (or process if you like).

So what is the role of the map? Well it is there to provide business rules for a cross section of applications to deliver a solution that allows users to do their work effectively. (Not easy to read that sentence). This work is shown as a process. For me, I prefer to see processes graphically, but not in my BPM system, well not used to define the rules etc within my BPM solution. Graphical representations are great for identifying the business requirement, and should be done by a BA. But process maps should be used as a “specification” if you like for a developer to build my intelligent process map…

Using a developer to implement my business rules

I know that many of us want to have a nice mapping tool that allows a business analyst (BA) to create and modify maps / business processes. However, in the real world, this means you have a couple of restrictions / issues.

  1. You can’t easily integrate with other LOBs and data required for a particular step
  2. You can be limited to other business rules / factors (that are outside the scope of your map)
  3. Automated steps often require “Robot” type step applications to be written (specifically for your requirement)
  4. Much more emphasis is placed on developers for the actual implementation / front end of much of the system (if you require intelligent integration / more complicated system integration)

As mapping tools get more powerful you still have these issues, mainly because a BA is just that, not a technical person who wants or should be bogged down in the technicalities / functions / calculations etc required for the business.

By using a developer to take your map and build business rules into a BPM system (if your BPM architecture allows this type of process definition), you open up a world of systems integration and flexibility. Effectively your business rules / map can now become intelligent.

Intelligent maps

An intelligent map is more than just business processing rules. It contains actual business processing logic, it has the capabilities to bring in data from third party software, carry out complex calculations and functions, raises events and triggers and does all of this within the map itself.

 Most BPM maps cannot provide this level of integration or capabilities to execute / carryout processing functions. Many times these types of functions are provided in the form of “Robot” applications or step processors. These are background applications or services written by developers to include business rules and functionality into the process map, because the map itself cannot support this level of intelligence. The outcome is a solution that requires much more processing power, requires greater input from developers and one that is harder and more costly to maintain.

By shifting emphasis of functions and rules to an intelligent map, you provide a BPM solution that delivers greater out of the box functionality, keeps initial costs far lower and requires less development work / bespoke step processors to be written. In addition, when your business needs to adapt and change, updating processes are far easier and quicker. Since the map itself contains the business rules of your processes (as well as the definition of that process), you need only modify one thing, your intelligent map. There are no background processors that need modification, no new application changes to be made etc. Because the business intelligence is all stored in a singular place…

Quick example…

A good example of a BPM platform that works in this way is workFile BPM. It has been architected to ensure the “map” holds all the business rules as well as having the capabilities to integrate with other LOBs and execute functions, triggers etc within the map. Developers have to build the map in this case, based on information provided by BA’s.  

The out of the box user interface is in most cases the only interface you need, simply because of the intelligence available at the map level. However, there will always be occasions when “bespoke” processors are required, and the workFile BPM platform provides a complete XML Web Service API in which developers can build on the intelligence provided in their maps within workFile BPM…

Conclusion: System integrator or process definer…

I see the main aim of BPM and workflow to raise the efficiency of businesses by making it easier for users, and the business, to complete work. Defining processes allows us to visualise this work, however, the BPM platform brings together everything that is required to complete the work. So a BPM platform should be a systems integrator first and foremost, this is the real beauty of BPM and workflow…



11 responses

14 01 2010
Intelligent BPM maps « Andrew One Degree's Blog | Drakz Business Online Service

[…] rest is here: Intelligent BPM maps « Andrew One Degree's Blog Share and […]

15 01 2010
Tweets that mention Intelligent BPM maps « Andrew One Degree’s Blog --

[…] This post was mentioned on Twitter by Andrew Smith, Andrew Smith. Andrew Smith said: Intelligent BPM maps ensure BPM is a true systems integrator. If you into BPM read this #BPM #integration […]

15 01 2010

Interesting article, Andrew – I must confess to having had only very peripheral involvement with BPM, and none in the technology arena, so not really qualified to comment. I would just say though, for what it’s worth, that whilst I agree with the point of raising efficiency, I do sometimes wonder how often that raised efficiency is only of benefit internally, and does not result in raising standards of customer experience?

Phil (@procphil)

15 01 2010
Andrew Smith @onedegree

I think many people feel, if you simply raise the efficiency and accuracy internally of a process, this automatically results in improved SLAs and customer experiences. This is true to some extent…Though saying this, this obviously isnt the rule. An extreamly efficient process may well be poor for customer experience or standards. This though is the failing of the business and business process rather than the technology put in place. In such cases the businesses must look at how they go about their work and ways in which they can improve the customer experience first, then see where in the process changes need to be made, even if this means the process becomes less efficient…At the end of the day, without your customers you dont have a process to run, or a business for that fact…

Thanks for your comment

15 01 2010
2010 BPM Predictions « Business Bytes

[…] – a thin client solution is better here as it easier to administer the changes centrally. As Andrew’s blog details, this is also where an intelligent map comes in. An intelligent map is more than just […]

17 01 2010
Mark Norton

Hi Andrew, Your proposal for Intelligent Maps within BPM is a natural extension of BPM provided that you are working within the context of traditional systems. At Idiom we prefer to think that Decisioning (ie ‘actual business processing logic’) is content that plugs in to a process. The process and decisioning are increasingly (in our experiance) developed by different disciplines in different domains by different parties and have different life-cycles, making one ‘map’ difficult to envisage. This article discusses some of the background to this concept

18 01 2010
Andrew Smith @onedegree

Thanks for this, I think we are singing from the same hymn sheet. When I talk about the business map holding business logic, I mean the business logic required for that process and additional business logic that is not currently sitting in another LOB application. So yes, business logic for calculations, or whatever you like is “plugged” into the map (if it can be). My point is that the map is the “thing” that brings everything together – its the systems integrator. The map is intelligent becuase it can bring all this plug in content and data into a single place, and also hold its own business logic and processing logic if required. There is no need to farm out functions to bespoke built applications (custom step processors) to be able to complete the process. So if your LOB has business rules in it for, lets say a calculation, then the map can simply pull in the result. If however, you need to do something with that result and you dont have something that already does this, then your map should have the capabilities to execute it (even if sending it off to an external dll or web service) without needing to send it off to a bespoke written background application (or custom step processor).

For me, far too much “process logic” and actual functions, end up in bespoke process based components. This isnt good. This is different though to pulling in data and results or triggering off calculations etc in third party software. As I said, I see the maps role as the systems integrator, plugging and pulling in data, business rules, content from LOB applications that are required to complete your process…

18 01 2010
Mark Norton

Thanks Andrew, I agree with the point and purpose of the map as the ‘integrator’. An exciting trend we are now seeing is that the map is integrating components from multiple parties within one contiguous process – it seems self evident that value can only be realized when a process involves more than one party, so this new breed of processes is going to unleash a wave of value creation. Regards,

18 01 2010
Sanooj Kutty

Hi Andrew,

You have a key point there.

Fur sure Business Rules need to be “mapped” and from what I infer, you state that “By using a developer to take your map and build business rules into a BPM system (if your BPM architecture allows this type of process definition), you open up a world of systems integration and flexibility”. This to me is at the later stage of BPM implementation. If I logically structure Business Process Management into the 3 separate elements of
1. Business
2. Process
3. Management

Then first and foremost is “Business” and here a clear process objective for the Business is needed. For example, if it is ‘order processing’ , then objective could be to process the order within 2 days.

Then next obvious element is in defining the “Process” that will be the right set of activities as per a logical sequence to achieve this objective. Here, the “Map” is from the perspective of a Business Analyst and is quite crucial.

But when you have Business Process, you definitely need to manage this. The “Management” element surely includes creation and maintenance of the Business Process and here the developer kicks in when using a BPM system. If a BPM system is used, you surely do need a “Map” at the level of the developer to manage the Business Process because as you have identified ‘systems integration’ is key.

But above all, my major area of concern is the knowledge of the Business Processes. How would one manage there is a seamless transition of Business Process knowledge between a BA and developer? Both view the same Business Process from different perspectives and we all know in an IT environment, these perspectives can be the difference between success and failure. So in short my question is, How to connect or correlate a BA “Map” with a developer “Map”?

18 01 2010
Andrew Smith @onedegree

Thats a great question…

The BA map is king in this case, obviously, and for sure requires an actual graphical representation of the process (along with some good documentation). The key though is good communications between BA and Developer (I know this can be hard). However, this scenario is no different to one in which the BA map is used to drive the system.

Due to the limitations of a BA map driving the system, you find you rely on developers interpritations and developers in general far more, after all they have to start building “process logic” and functions into actual bespoke applications / services that run as “components” of a map. This is far more dangerous in the actual delivery of the process correctly…

6 04 2010

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: