Working within the field of enterprise architecture, my team and I sadly encounter the disease ‘model sickness’ or see evidence of being ‘model sick’ all too often! This serious, yet curable condition can strike not just when modellers go bad, but when intelligent and experienced modellers simply forget who the end audience is or more importantly what the primary purpose of a model is…
Lorne Clark, Head of Consulting, MEGA International
Where does model sickness strike?
The condition can normally be found where a ‘flat file’ style model is being used – i.e. diagrams without an underpinning database or clever way of storing other dimensions of information. However this sad condition can occur even when database based systems are in action.
How do I recognise model sickness?
- A diagram that needs such a complex key of symbols used that you have to read it more than once and still find yourself confused
- A diagram that only one ‘special’ person knows how to maintain and explain
- A series of shapes where the shape itself is made up of many dimensions such that you have to have a sub key for each type of shape
- A reluctance of the modeller to make changes as it’s so time consuming
- Users that avoid trying to use the model sick at all costs
How to avoid and treat model sickness…
To avoid model sickness here are three points that are worth bearing in mind:
1. Who is the end audience which the diagram/model is aimed at? If it’s for more than one audience then are you quite sure that a single type of diagram is the best vehicle? A plumber uses a very different diagram to an electrician – it’s the same house, but different notation…
2. If you’re finding that a larger and larger page is required then are you sure that you’re capturing the right level of information and in a digestible format? London underground deliberately ignore distance in their tube map to allow all of the main stations to be seen in a single concise page…
3. Does the diagram/model continually seem to be out of date? Are you quite sure the model is still of use and/or value for the end users? A model which isn’t maintained for a reason or has slipped out of date is sometimes worse than no model at all… How many times has a road changed compared to our satnavs and led us to stress and frustration?
Model sickness can be a serious condition but the good news is it is easy to avoid by simply remembering that a model by definition is aimed to show a simplified representation of the real world and not rebuilding the world’s information in a different way! As much as models are essential, ultimately what matters is the endgame – that is meeting the needs of the business and their expected business outcomes.
Lorne Clark, Head of Consulting, MEGA International
Lorne has worked for MEGA International for over 9 years as both a Senior Consultant and has run the UK Consulting team for the last 4. Lorne started his career in GEC Marconi where he worked on both civilian and military engagements. Throughout his career Lorne has used modelling tools, techniques and methodologies to enable the delivery of success projects. Lorne can be contacted at LClark@mega.com
Comments
The design sickness is, unfortunately, is the rule today when no two definitions for EA, capabilities, processes, functions ets are the same. It comes form the lack of an enterprise modelling framework. That may also mean that there are no design conventions or constraints, no component repository, no proper metamodel… etc.
1. Audience: it is the whole enterprise. The EA consists of a set of linked models. There must be a view for everyone in that EA.
2. Larger than a page: an one page architecture is good, but EA, as above, consists of a hierarchy of linked models, each displayable on one page.
3. One of the reasons the models are not kept up to date is that the tool is not simple enough or good enough to propagate or at least require the change of dependencies.
If the car or airplane manufacturers would utilise only simple models we wouldn’t want to drive or fly their products. The end game is to document the enterprise to the level of detail needed by every stakeholder from the strategist to the low level solution designer.