A framework for design modelling

The following ideas form the basis of this design framework, in a nutshell.

1. Modelling

A model is a simplified representation of a system or process to understand its behaviour.
Simplified because a model is per definition at least one level of abstraction up from the system being modelled.

The upsides of modelling are that it enables one to look at things in generic terms, which helps in analysis and communication.
That is if the models are correct.

The downside is that going up levels of abstraction means losing some of the detailed information of the system which is being modelled. A model is an approximation of reality, the map is not the world.

Modelling has a width and depth about it too. Any system which requires modelling is usually not very simple. And complex systems may require separate models to cover its main aspects, rather than trying to fit everything into one.

The depth of it is the number of levels of abstraction applied to any of these aspects. This can be one to many, and determines how easy it is to traverse between levels. As an example : the data aspects of a system may be expressed as a conceptual datamodel, a logical data model, a physical data model, a schema or a database, in descending order of abstraction.
Compressing these layers too much, like going from a conceptual data model to a running database in one go, may result in many attempts to get it right. If at all.

Using modelling to describe a business, or part thereof, and to use it to generate apps, must therefore take these limits into account.

The only framework I know which handles aspect-models and levels of abstraction well is the Zachman framework. Zachman describes a universally applicable 'floorplan' of any system or domain in 6 levels of abstraction. By analogy these are sometimes referred to as ‘client’, ‘architect’, ‘designer’, ‘builder’, ‘tradesman’ and ‘user’ (or words to that effect) using the analogy of a construction project. These archetypes are pointers to more verbose descriptions within his framework, with the purpose of focussing the user to think on these levels of abstraction.

Furthermore, it describes 6 ‘points of view’ for each level, corresponding to the ‘w’-questions kids like to ask a lot (why, what, who, where, when and how).

This framework gives therefore a 6x6 matrix or 36 lenses to look at any problem or situation.
Below the framework applied to the IT domain.

2. How to use

Zachman and similar frameworks like Togaf are usually placed in the realm of Enterprise Architecture, where they assist in describing or modelling business aspects in particular ways.

This is not about Enterprise Architecture.

The aim here is to provide a method for creating well-defined aspect-models and use these to generate supporting apps. The way to do this is to

A) cover all aspects.
Building on the above, the conclusion is that app requirements can be expressed in 6 separate models :

  01 Process model (how)
  02 Workflow model (who)
  03 Data model (what)
  04 Events model (when)
  05 Processor, c/s model (where)
  06 Goals / objectives model (why)

And to complete the picture, these aspect-models are positioned under an overarching domain model. The domain being the width and breath (and depth) of the modelling exercise.

B) traverse a suitable number of levels of abstraction.
App developers usually operate as programmer, developer or designer (corresponding to the 5th, 4th and 3rd row in the image above). This framework includes the role of architect too (2nd row).

This all doesn't help much though if tools to help traversing these levels are absent or too cumbersome to use. It only works if they are intuitive and cover multiple levels in one go.

C) use Domain Specific Languages (DSL)
A Domain Specific Language is a language with a higher level of abstraction optimised for a specific class of problems. As such it fits the idea that models should address design-aspects a level up from what is being modelled. Also well-designed DSL's use the concepts, rules, nomenclature etc from the field or domain. It therefore aligns more with the world of end-users than with the world of programmers and developers.

The design modelling framework

Information from all models provided is used to generate an application. There is no separation between design and build, a developer can at any time press the generate button and the result depends on the amount of information available in these models.

Just to make a point, not all applications require all models. It is perfectly feasible to generate a static web-page using no model at all by just using the included form builder.
More intricate apps where roles and responsibilities of users play a role, or where multiple overlapping workflows are involved, require a partial or full array of models.