Making a model

Category: Daniel Hinderink

By: Daniel Hinderink

In a previous post of 2006, I wrote about the need to make the client understand the logic of what the information system you are building is about. This time I give some suggestions on how it's done.

back when models were beautiful

The basic building block of any IT is that of systems. Systems are functional entities consisting of modules that bring about their own internal logic. Think of TYPO3 and of it's many functions that make sense in a certain context of usage, but that are inhibitting other uses at the same time. Mostly those can be overcome through extensions and Xclassing (phew!) existing functions, as long as the change isn't too far from what the system can be bent to do, to become too expensive.

Now that system is already pretty complex and it seems futile to build a model describing all functional parts of it even from a technical stand point (e.g. with UML).

What does make sense is to look at all the actual information processes in any given real-world project and describe them one by one, as building-blocks of the model.

At this point it doesn't matter if those processes already exist, or if they work well. It just matters to catch all of the important ones and to get someone with enough Karma on board to make sure they are aware and willing to sign for any organisational changes those processes might entail.

For example the process to write news items about the trade fairs that a given customer is having his show room at.

The start of that process is ideally the moment the date and location and the customers attendance is fixed. Then this date goes into the editor's agenda, with four phases for, say, three news items: #1 announcement of the customers presence with product highlights to be presented, #2 invitation shortly before the trade fair and an #3 after-show summary with photos. Each of those has a research, an editing, a publishing and an archiving phase, according to the content lifecycle.

Now it takes some ground work to ask all the questions and get concise answers what happens in those phases and where information and decisions come from. What that gets you is a process diagramme with all the phases and a timeline with arrows designating information flows going to and back to any of those sources, where a source might be composed of roles as well as storage devices. While recording, designing and sketching those processes, make sure to define as many measurable factors for quality, throughput and satisfaction of the people involved as seems attainable.

The whole of those processes will start to evolve into a web of interdependencies and eventually into a model, that offers several benefits to any client that wants to know what it means to do things right:

• adding (measured!) resources needed for any step offers a controlling and optimizing tool for the whole
• comparing them with gauges on a dashboard that measure quality, customer satisfaction and throughput for each deliverable puts the use of those resources into perspective with the clients goals
• those two components constitute a "master control", a strategically valuable tool for self-regulation and self-organisation of the clients communication apparatus.
• based on the companies strategy, concepts can be applied and translated into the model, regardless of the underlying technology, to describe requirements based on those existing processes.

Want to know more? Here are some links to get started:

Edward Tufte, the godfather of graphic information representation: www.edwardtufte.com/tufte/

Information Dashboard Design by Steven Few: www.amazon.com/Information-Dashboard-Design-Effective-Communication/dp/0596100167

Pentaho Open Source Business Intelligence Platform: www.pentaho.com

Value Based Management: a register of management models for inspiration: www.valuebasedmanagement.net