Several years ago a major software consultancy built a Pega solution for a client and within two years of deploying it, the client was having to rebuild it themselves. It’s not an uncommon scenario.
The client brought me in to take a look at the business architecture underlying the original solution and that is where I spotted the problems, which were almost entirely about the business’s inability to properly understand and articulate the nature of the things it cares about and the relationships between them. In other words, their inability to model their own data. This is a common issue which comes down to the following:
‘The language of experience is not the language of classification’ John Ciardi
The fact that a person is an expert in operating a business does not automatically make them expert in articulating the nature of that business or how it operates. In fact, their experience may even blind them to how that business should be operating.
Business subject matter experts (SMEs) often speak directly to software developers (or to requirements stenographers) using the language of experience, which is usually imprecise and inconsistent. However, computers operate using ones and zeroes. There is no room in binary code for: ‘You know what I mean’ (which I have actually heard clients say during analysis workshops).
For example, on the project I mentioned above, I spotted that two intimately related, but quite different, business concepts were modelled as a single class in Pega. I challenged this and the main business SME’s response was that they modelled them the same because the business treats them the same. I needed to explain that the nature of a thing (data definition) and the way in which you treat it (process definition) were not the same and, moreover, defining things as different allows flexibility while still allowing them to be treated the same way.
I used the following analogy: Imagine you make fruit pies using both apples and pears. Two different, although similar, types of fruit, each with its own characteristics. However, they are treated the same way. They are washed the same way, peeled the same way, sliced the same way and put into the same pie. Because of this, you simply define them as “fruit”, with no distinction as to their taxonomy. Then one day there is a fungal epidemic which dramatically reduces the pear crop among your suppliers and the price of pears doubles. You need to know how this is going to impact the cost of producing your pies. However, you cannot say because you don’t know how many pears you buy versus apples, because you record it all under “fruit”.
On the other hand, taking care to define apples as apples and pears as pears gives you more control of the information about them while still allowing you to put them into the same, or even different, pies. You can now report that because of the ratio of apple to pear in your pie, the production cost will go up by 30%.
By the way, the corrollary is also true. Things are not different just because you treat them differently. A pear is still a pear whether you put it in a pie or a pudding or throw it at someone’s head.
To swing away from the analogy and back to the language of business architecture, this problem stems partly from the fact that a lot of people who work on BPM projects only understand the world in terms of process and everything is seen only through that lens. Separation of concerns is needed. The classification of a thing belongs to a separate domain to the activities that you can perform on that thing, or the decisions you can make about that thing, or the events that affect that thing.
Learn to see things for what they are and not just for how you treat them.
Kind regards.
Declan Chellar
Source: http://www.chellar.com/AnalysisFu/?p=2340
