Blogs

(Original creator: bolarotibi)

By Ian Murphy, Principal Analyst and Bola Rotibi, Research Director, Creative Intellect Consulting

As a relatively new engineering discipline, software development has been looking for a way to improve the quality and cut the cost of what it does. There are good reasons for this, multi-tier, computing systems can take hundreds of man years of effort and cost tens of millions of dollars to build. These systems have multiple points of integration with other pieces of software. Being able to model this complexity helps architects, developers and system engineers to examine the application before they start and make decisions as to how to approach the project.

The use of models in engineering disciplines has been going on for millennia. At a high level, models provide a view that abstract unnecessary detail to deliver an uncluttered picture of a solution for respective stakeholder audiences. Models are used to create a proof of concept that allows architects and engineers to study complex problems before time and money are committed to construction. For example, modelling a bridge over a canyon would enable architects to see how the bridge would look and highlight any issues with the materials used and the terrain.

There are of course varying levels of detail that different model layers will then go onto present that depict all relevant artefacts, along with their relationship to and dependencies on, each other.

You might think, therefore, that the use of modelling inside IT departments would be rife with significant attention and investment paid to its use. Sadly this is not always the case for too many organisations. Yes, lots of teams will use models and modelling in some aspects of the development and delivery process, but it will not be consistently applied or formally implemented.  Despite efforts to drive wider use of modelling in software development, the number of companies that actually do modelling as a core and formal function of their development and delivery processes are few and far between. So why is that?

Common modelling failures

There are three common failures of modelling that lead to them being dismissed as unusable:

• The first is that the model offers too simplistic a view for the different stakeholders involved. It doesn't provide the right level of basic information for the various viewpoints required with the result that little to no understanding of any problems can be ascertained from it.
• The second is that the model is too detailed making it hard to abstract the relevant information for a particular viewpoint, easily and quickly, and making it hard to understand problems from a higher perspective. It might seem that when modelling something as complex as a multi-tier CRM product, there is no such thing as too much detail, but there is.
• The third is the incompleteness of models to allow for automatic transformation of the visual representation into executable working code.

Modelling 101: 5 points of effectiveness  

Ultimately, the main objective of a model is to communicate a design more clearly: allowing stakeholders to see the bigger picture i.e. the whole system; assess different options, costs and risks before embarking on actual construction.  To achieve these there are five key characteristics that a model must look to convey:

• Abstraction: A model must allow you to abstract the problem into simple meaningful representation. If you look at architectural building models, they use blocks to represent buildings. In an IT sense, the initial model will simply show connections between systems but not the underlying coding detail.
• Understanding: Having abstracted the problem, what the model must then convey is sufficient information and detail in a way that is easy to understand for the different audiences concerned.
• Accuracy: If a model is not an accurate representation of the problem then it is useless. A model would provide a useful start point to get a common view.
• Alert for prediction: A model alone cannot necessarily provide all the key details of a problem. In modelling a banking system there would be a requirement to use additional tools to predict workload and throughput. This would have to be done in order to select the right hardware, design the correct network architecture and ensure that the software can scale to the predicted capacity demand. One common failure of many IT systems is that they are often under-scaled. If properly modelled with a clear prediction step, this problem would be reduced.
• Implementation and execution cost: Models need to be cheap to produce and easy to change, especially in comparison to the cost of the product or solution delivered by the model.