I was once loosely attached to team who has been given the job of modeling a particular industry. Lets say it was Insurance.

They were given some money and some offices, and told to go away and create a industry model, which could be used as the basis for customer solutions. One model for all aspects of the industry – think of the time it would save in creating solutions, and even more in integrating them together.

The first time I saw the model, it was going OK. They had 200-ish domain model classes, with things like Premiums and Customers, Policies and Payments, but lots of gaps which they just hadn’t had time to fill.

Second time, a few months later, it was up to 600+. This model was now was much more comprehensive, at least in the view of those who more about the industry than me. Had all the stuff from the first version, and a whole lot more. They looked to be nearly finished

Final time, several months later, they had only just finished, and the model was visibly smaller. The pile of paper, which was the printout of the model, was a fraction of the last time. Back  to fewer than 200 classes. What happened?

We looked at the detail. We looked for Policy – the heart of any insurance system. No sign. We looked again, at about where it was the last time we looked. There was something unintelligible, called maybe Entity_Offering_Link. Which if the Entity is a Customer, and the Offering is ‘Insurance’, then maybe is a policy.

So what had they done? They’d started out by modelling the terms they heard the experts used, then, like good modellers do, looked for common abstractions to make things simpler. And went on and on, finding ever more abstract ideas, to ‘simplify’ the model. Until the ‘Insurance-ness’ disappeared altogether. Entity-Offering_Link could equally be an airline ticket, or a order placed at McDonalds. And links between things no longer had real names. all the ‘stuff’ was connected though a generic class, where the purpose of the link was soft-coded as a variable in the link. Super flexible. Super abstract.

Melting the Pan

If you’ve ever made stock for cooking, you know that you start out with all the ingredients, and a whole lot of water. What you want is the concentrated flavour, so you start to boil the mixture.

Gradually the water boils away, and you get to a rich, highly flavoured liquid, which has the concentrated essence of the initial ingredients. Then you stop boiling.

Because if you carry on, what happens is the liquid gets think and gunky, and eventually goes dry, and finally you start to melt the pan. This isn’t concentrated anything. Its a fire hazard.

So be aware when you do your solemn duty as a modeller, and make abstractions. Don’t get so cute that the essence of the model goes away, It must still have the ‘stuff’ which makes it an insurance or an airline or a restaurant model. It should not need a modelling expert to explain it to a domain expert.

So if you’re managing such a team, beware of letting them model too long. And get the model reviewed frequently, but people who know the area but not the modelling style. They get it reviewed for style by a modelling expert, before it’s too late, and your stock tastes of melted metal.

About the Author Ian Mitchell

Ian Mitchell is a business analyst and software developer. He's been using UML since before it was UML, and has managed teams of BAs all over the place. He also teaches UML and BPMN, and writes the eaDocX document generator for the Sparx EA tool.
%d bloggers like this: