Friday, 30 May 2008

BPMN and Executable Businesses: When Will We Learn

Bookmark and Share

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 21st 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.

2 comments:

R Welke said...

Mark in this blog offers an interesting analog between data design and process design. The question is, does it hold up? Data design (being over simplistic) is the progressive canonicalization of data from "views" initially captured by business analysts, through various layers of abstraction, down to the as-implemented physical design, with the caveat that the initial business-level data views can be constructed as sub-schemas from the resulting database physcial schema. This is a form of "checks and balances" between what was initially required at the business level and what was delivered at the data management execution level. We'll set aside here issues of ontology and the like.

If we now turn to capturing busines processes, the equivalent question would be whether a higher-level (more abstract) modeling approach than, say, BPMN can be used and still capture what the business needs and expects? For example, can events be eliminated from such a model (one significant difference between BPMN and other more abstract business process modeling approaches) and still deliver what the business is seeking in a functional process description? Most process analysts I'm familiar with will readily state that it's the exceptions (and their handling) that makes/breaks a process. That's at least one thing event-ing is good for. Another aspect is rules (admittedly not part of BPMN) and how they're specified and accomodated in the model. And, of course, there is the data (business object model) itself which, of course, BPMN is silent on.

As it's not clear from the blog what Mark *is* advocating, I would offer that at the business model (business analyst) level, there needs to be some way to capture and communicate to downstream "de-abstracters" that which is captured by BPMN 1.1 plus rules and the associated business object model (both the persistent and transactional bits).

Anonymous said...

Good post.

BUT

As a Business Analyst, you use tools specific to your role - like ProVision, CaseWise and ARIS. These tools are high value and have a level of sophistication relevant to your expertise............you can use BPMN inside, I agree with that.

Any business does not give these tools to everyone – which are needed to map your organisations existing, new and emerging processes.

Your general user population cannot use these BA tools; cost and expertise requirements are the limits.

So you need a tool that anyone in the business could use?

A tool that could produce models useable in your BA tool, BPMN compliant. A tool that any business user could use to get their knowledge into a pad that produces great process maps from plain text, and great process documentation for you to critique.

I would also give them a tool that allows them to view the process maps from your BA tool in such a way that they could comment on them, change them if allowed, and interact with your internal best practice library within set permission levels. A video of what I mean is on www.processmaster.com