BPMN and Executable Businesses: When Will We Learn

A quick look around the blogs and latest articles reveals a lot of discussion (again!) about BPMN and what it is and should be used for. We seem to have endless debates about why and how it is easy for business people vs. why it is not, now we are seeing increasing debate about whether it is the right notation/approach for Business Analysts – I think it is perhaps time for us to remember whose role is what in the organization and what they are supposed to be able to bring to the party, then we can consider what tools, notations etc. might be appropriate.

For the purpose of this post I want to draw the parallel with data modeling, a field that is well established and in which everybody has their part to play. At the lowest level we have our Database Administrator (DBA), they live in the land of "Physical Models" and know that they have to fine tune them, breaking some rules and adding others, so as to ensure that the "Database" performs at its optimal speed. So from a BPMS point of view we can see that there is a definite role for a BPM Administrator, someone who is very familiar with the engine and knows how to find tune the "Execution pr Physical Model" so that the system performs at its peak – For these people BPMN makes sense as a notation as it is very closely tied from the model/code/execute perspective. So I contend that BPMN is the right approach for these people.

Then stepping up a level we have our Data Analyst, these people live in the realm of "Logical Models", they take the inputs from Business and System Analysts and look at the business problems and system requirements from a data perspective and create the logical models from the conceptual models. They know that nobody would expect to implement an efficient database purely from their model and that it requires work and tuning in order to create the optimum physical model from the logical models they create, whether they use Chen, Bachman or UML for notation the Business or Systems Analysts don't really care, for that is the role and domain of the Data Analyst. Could BPMN be used in this area, yes it probably could and we could have BPMS Process Analysts to carry out this role. Again a specialist knowledge is required to ensure that the model is complete and consistent, helped of course by an appropriate modeling tool with model rules being enforced (A point worth noting is that for years many Data Analyst resisted using tools that forced rigor on them, with the result that hundreds and thousands of man hours were wasted building inconsistent models that could not be used to generate good physical models and databases).

Then we come up to our Systems Analysts, whose role was always to look at the business requirements and translate those that required systemizing into specifications that could be implemented, these are the people who also start to take into account hardware platforms, software applications and corporate standards for databases etc. It is their job to help to create and put together the systems that will solve the business problems at hand. As inputs they may well have the "Conceptual Data Model" among other things. But, we know that the conceptual model was just that a collection of "things" that the business saw as relevant data with lines that indicated there was some kind of relationship between them, though not what the relationship was. So we would indeed need a similar role for our BPMS world a BPMS Systems Analyst.

Then we come up to the Business Analyst, whose role is to help the business in identifying and solving business problems which may or may not require systems or systemization. If we really think that we should be turning them into low level implementers then take a look at the IIBA website (www.theiiba.org) and review their Body of Knowledge. I have just finished reviewing the soon to be released version 2.0 and you will see that our Business Analysts has more than enough on their plate already, they have to learn a vast array of skills in order to be effective at what they do, to my mind the last thing they need to be expected to learn is another low level notation, just because some IT people find it too hard to learn the language that the business speaks.

So if we want to have an effective debate about modeling and notations for Business Process I suggest that we talk with true Business Analysts to see what sort of simple "Conceptual" approach makes the most sense for them. Then we can look at what the best way of creating "Logical" models is for our systems analysts and finally we can allow our BPMS Administrators to play till their hearts are content with the BPMN notation that is created and designed for them and for whom it is ideally suited.

Another group of people who I have not yet mentioned are "Architects", a group who are popping up increasingly, either from an Application, Software or Enterprise perspective, but most of whom seem to exist under the wing of the CIO. The business belongs to the business, the Chief Enterprise Architect role is already occupied in business, it is the CEO and contrary to what one senior enterprise architect told me recently – he suggested that I am too old fashioned and that I should just get used to the fact that process would all be automated and businesses would just do without people, that the 21^st century business model was a) Enterprise Architecture b) Business Architecture (using OMG MDA) c) Business Process Models (Using BPMN) and D) Automated Processes; without involving people – an executable business – it is people who will use the systems, it is people who own and run businesses and it is people that systems in the main are supposed to support. So a little more time speaking with people to find out what their problems are will make live a whole lot easier for people to get budget and resource to build and implement systems. If this thinking makes me old fashioned then so be it, but if we truly believe that we are moving to a world of pure system executable businesses without human intervention then it is a sad day for the human race (and one that poses some even more interesting change management issues and barriers)

Of course these are just my opinions and I am sure that there are many who will disagree, but for those that chose to do so, please don't write to me about the origins and purpose of BPMN, I was at the original meeting where the idea was first muted by two people from two vendors in the UK over a beer in London many years ago. I understand exactly why BPMN as originally created – I also accept that it has come a long way since then.