Newsletter 111

Home Resources Newsletter Archive Newsletter 111

Cookie policy

Number 111

Welcome to the April 2012 issue of Precision Matters – the Precision Design Technology (PDT) Newsletter.

The Benefits and Uses of Business Models

Last month, I talked about business modelling: its definition and purpose, activities and rules, and the value of effective models. At the end of that Newsletter, I promised to talk about the benefits and uses of business models.

I have recently returned from a short skiing holiday, where the activities are well recognised and the rules moderately evident. The activities include staying at a local hotel, buying a ski-lift pass, renting ski equipment, coming down the slope at relatively high speed, and returning to the top by ski-lift somewhat more slowly. I have omitted the “après-ski” activities. The rules include not using the ski-lift without presenting a valid pass, returning rented equipment at the end of the rental period, and accepting Newton’s Laws of Motion while coming down the slope - as well as at other times!

I suggested last month that we link activities by rules: the rules provide not only controlled dataflow but also enforce constraints on the activities in the business model, thereby ensuring the model exhibits the correct behaviour.

The Benefits of Business Models

One major benefit of a business model is that it enhances specification. Many software projects suffer from inadequate specifications, so we should welcome any assistance. Even if you have no model checking tools, building the model will greatly increase your understanding of the system you are about to build. If you do have tools, then you can check your model for errors and perhaps exercise its behaviour. You might even find later that the model becomes the specification.

A second major benefit of a business model is that it improves communication. A specification may be a very large and detailed document and it may use notations well known in the software community but unknown elsewhere. These are hard to explain to non-technical people. In contrast, a diagram using only two elements is easy to explain, even if it is quite large; many people will need to understand only their part of the system and its immediate interfaces.

You achieve the ultimate benefit of a business model when you exercise it. You might achieve this through prototyping, if you can guarantee the prototype to match the model exactly, though prototyping is sometimes superficial, showing screens but including little functionality. You might possibly achieve this through building executable specifications, though expertise in such languages is rare. There are also a few toolsets built specially for this purpose.

The benefit comes because users see some form of the deliverable system, possibly lacking in performance or reliability but illustrating the functionality. For a start, exercising a model will verify the specification. My experience with this approach is that users are far quicker to identify problems and issues when we exercise a model than when they read a (possibly boring – to them) specification.

As an example, we once modelled an airline ticketing system, for which the stated requirement was to issue tickets “from anywhere to anywhere”. The first modelling exercise issued a ticket from Heathrow to Heathrow. The client then stated that when he said “from anywhere to anywhere” what he actually meant was “from anywhere to anywhere else”. He assumed we knew that; whether we did or not, we delivered what he asked for. But now that we knew that there was a problem, we could discuss the problem with the client; had we asked him to read through a large specification, he would probably not have discovered the missing “else” because he would have assumed that we had the same understanding as he did.

One small problem, inevitably associated with business models is that we need a more than usually detailed and precise specification. I said earlier that many projects suffer from inadequate specification, so this should not be a major problem, but some people may criticise an approach that appears to spend a lot of time getting the specification right rather than developing code to an inadequate specification. After all, the specification is not a deliverable, whereas the code is – but delivering to an inadequate specification is to court disaster.

Uses of Business Models

The first use of a business model is to communicate. Given that the specification represented by the business model is precise enough to exercise, and that these various exercises have revealed a “correct” system (the one the client wanted), you can explain the business processes in the model to others, with selected exercises as illustrations to show what will happen.

The second use of a business model is to communicate. Given the conditions I have just laid down, you can test the interfaces to other models and systems and you can talk to the representatives of those models and systems with precision and confidence. In both these situations, we correct any errors that may become apparent simply by amending the business model (specification).

The ultimate use of a business model is to communicate – to a code generator, when everything is correct and as the client requires. This allows you to translate the business model immediately into executable code. If the code generator is error-free, then the executable code will form the delivered system and should take only minutes or hours to generate. It will logically match the specification, embodied in the business model, because there has been no error-prone human interpretation. And you can guarantee that the delivered system will be free from all human-introduced errors, because there will have been no human involved in system code production.

The Newsletter Archive

If you want to review any of the previous Newsletters, they are all available at the Newsletter Archive page

Want to reproduce this article?

Yes you can, so long as you accredit it to Robin Oldman, Precision Design Technology Ltd. and attach the following biography to the article at the bottom:

Precision Design Technology, (PDT), the IT systems experts, provides world-class consultancy and solutions for IT information systems to help its customers develop affordable, high integrity software for business. Normally high-integrity software is prohibitively expensive - PDT provides a solution at a price business can afford.

EUR ING Robin Oldman, COO at PDT, writes and blogs on behalf of the company. Robin also manages the development of the user interface for the SPECIFY4IT tool-set that bridges the gap between the client user and the system supplier. The SPECIFY4IT tool-set is capable of delivering high-integrity business software faster and more cheaply than conventional development methods.