What we generally see when we look at tools for business modelling is an attempt to visualise the flow of activities in an organisation. I once heard a consultant from a workflow tool vendor proudly say that:
“Now finally the managing director understood what was really happening in his organisation!”
We don’t want to argue that this consultant was entirely wrong. In fact, workflow modelling has helped many organisations to finally get a grip on their processes, and took important steps toward a more controlled and repeatable process. Especially for QA and CMM this has had a positive effect. But I beg to question whether the managing director “really” had a better understanding.
In the 80’s an important contribution to management science came from the publication of Hammer & Champy’s book on business engineering: Reengineering the Corporation: A Manifesto for Business Revolution (Collins Business Essentials)
This had a profound impact on the need for organisations to “know what was really happening”, in other words: modelling.
The interesting observation could be made that there were really not many tools to model organisations. Generally not more than an organisation chart was available. There arose a need for tools, and what happened was interesting from a sociological point of view: the tools were borrowed from the leading scientific metaphor of the day (see my article on The Importance of Metaphors): information theory, a term first coined by Claude Shannon.
The fact that information technology was itself having grave problems coping with the complexity of its work did not impede people from the almost as immature scientific community of management science to adopt many of the IT metaphors in vogue at the time. IT was sexy, it was cool. The exponents of the new community of automation experts were seen almost as supernatural beings.
The most important IT metaphor was dataflow modelling. Based on data modelling it tried to capture the many ways in which this data could be manipulated, moved and changed. So the intriguing observation could be made that management sessions to decide upon strategic issues were facilitated using IT techniques such as dataflow modelling!
Of course this was only whispered behind the back of executives.
For some reason or another this approach to business modelling is the approach taken by almost every company that provides services in this area. The terms used are “business processes”, “workflow management”, “use case driven”, etc. If we look at tools like Arena or Aris they basically offer facilities to model processes and flows. This is now re-emerging in all kinds of approaches like BPMN, BPEL etc.
In most cases these approaches are anything but object-oriented, and therefore they suffer from the same shortcomings as traditional modelling techniques in software engineering: models become too complex to manage, they are difficult to adapt to changing requirements, they are hard to communicate about with users and customers, etc.
My most important criticism is that these models are so badly suited for “active systems” that is systems that are able to reason about themselves, take initiative, are self-healing and can be delegated responsibilities to. This is amazing in itself, because these problems in software engineering were detected many years ago!
What’s even more amazing is that the proponents of these approaches use the very same problems to “sell” their approach and say that it in fact is “more flexible, business people understand it better” etc.! It is understandable however; the problem is not that the approach is “wrong”, but the problem, and one that is a bit hard to understand at first sight, is that it does not scale.
This makes it hard to see at first sight, because the examples you use to introduce the subject, cannot but be simple. And in simple models the process approach is simpler to understand than the object-oriented approach.
In fact object-orientation is not new: the first object-oriented software ran on an object-oriented operating system (something we still haven’t seen in the commercial field?) in the year 1972. This was the first Smalltalk system, in Xerox PARC. For an excellent article on the design principles behind this system, read http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
OK, so maybe we want to model businesses the object-oriented way. Fine. The question remains: why are so few doing this? We have seen many companies offering support for modelling, be it software modelling or other kinds of modelling, and mentioning object-orientation in some way or another. Of course it may be that they try to harvest from the hype surrounding object-orientation, although that is slowing down a bit recently, but I think that is not the only reason. Another reason may well be the fact that object-orientation is much more difficult than most people thought. In fact I have always said that OO is easy, that is aligns better with our “natural way of thinking”. However in the course of the past ten years I slowly had to accept the fact that people using OO in practice had many problems doing so in a successful manner.
I have coached development teams and given courses in OO to many hundreds of people, and have had to reluctantly admit to myself that only a small percentage of these students really grasped what I always considered to be the simple essence of OO and modelling. This “essence of OO” is an important enough subject on its own, so I will reserve an article for the subject. Here I will only summarise two of the most important aspects of “good” OO modelling, that is: (1) the active/passive rule, and (2) demand-chain processes.
