Construction principles for the information professional (9): Apply standard patterns without deviations

By: Rutger Gooszen

In this series of blogs, I reflect on the still valid information science construction principles that guarantee better “information constructs.” This last blog in the series on information science principles is actually also a bridge to the continuation of this series with some computer science principles (for the distinction, see my starting blog). Indeed, standard patterns exist in both information science and computer science.

The elegant thing about a standard pattern is ... that it is a standard. But in practice, there appears to be a reason to deviate a bit each time. The result is a user who no longer understands the user interface or a no longer interoperable concept, lower maintainability of a system and loss of time.

Why standard patterns?

Theory and practice show the benefits of setting things up the same way. For example, it improves manageability in an organization if you keep organizational parts uniform. People are more easily interchangeable due to shorter learning time. To govern, a model must be available of the governed system, and this is quicker to develop if it uses standard patterns that are recognizable.

In information science, standard patterns help in the unambiguous documentation of information and recognition of information (partly through an agreed syntax). In this way, for example, reading the user manual and also operating devices automatically becomes logical, just think of color use and position of certain controls. If the stop button is suddenly green and the start button red then we get accidents!

Standard patterns often grow into officially recognized standards. Deviation is not allowed and if something changes it applies to all applications.

Standard patterns are typically a “design” aspect.

Examples of good and bad default patterns

Some bad default patterns have to do with ergonomics design. Just read Jasper van Kuijk's column in the Volkskrant (thinking errors in contemporary design).

A well-known good collaboration pattern is the agreement pattern in DEMO by Dietz that provides for structured handling of service buyer and service provider transactions [1].

Another good example is the pattern of “publish-subscribe” versus “request-response,” both at the information sharing level and at the technical level.

For all patterns, they are suitable for specific requirements. Such as decoupling actors or components, limiting dependencies, requirements for scalability, independent of a chosen language or protocol and asynchronous or synchronous. If the chosen pattern (no matter how good) does not fit the intended application, deviations and workarounds often arise that remove the benefits of the pattern and suddenly make it a bad pattern in that context.

Well-known infrastructure patterns are client-server, client-broker-server, master-slave or layered architecture and these have proven their worth. And with integration patterns, everyone recognizes the success of the application-programming interface as the standard.

However, it is important to recognize that the logical pattern is not a standard between systems until a technical standard is also agreed upon! One API is not the other!

[1] Source Wikipedia

Application of standard patterns in construction

Jaap van Rees [2] mentions two target groups here:

End users
Designers of systems.

For end users, applying standard patterns is an obvious advantage. An end user learns to recognize standard patterns for operation. Think of the unambiguous user interface for smartphones or your Internet browser. Here, a market standard from Google has emerged as the winner. Deviation is punished by users dropping out. Without knowing how the underlying technology works, the standard user interface allows the system to meet the user's expectation because the behavior conforms to the model of the standard pattern; the common interpretation scheme. Anything that deviates from this causes learning time, wasted time or errors, and at worst frustration or accidents. Just think of the time you went from an MS Windows computer to an Apple!

For designers, standard patterns (or structures) help save time because you no longer have to invent the design yourself. It also increases the portability of a design to designers who also know the standard and prevents teething problems/errors. Testing thus takes less time and incorporating standard modules becomes easier. All in all, the biggest gain is better maintainability because a standard model of the information system is available and you can therefore get to the bottom of the system much faster.

Maar als de voordelen zo evident zijn waarom wordt er dan toch steeds afgeweken van de standaard?

[2] De informatiearchitect, van Rees en Wisse, Kluwer, 1995.

Standard patterns and creative freedom

Standards conflict with the creative design process. Standard patterns must be converted into standard ways of thinking, and that takes time. Design decisions are framed by prescribed standard patterns. In a standard, an architecture or end-user requirements.

So introducing and enforcing standards is a culture change, one that evokes resistance. Every designer or end user will try to demonstrate that their problem does not fit into the standard. And then the temptation to deviate is great. But standards lose their value when it becomes clear that it is allowed to deviate from them! With Comply or explain as a well-known adage in these cases, the explain should not be taken lightly. Permission to deviate must be reserved for the highest authority.

This does not mean that a standard pattern cannot change. But a change must then be implemented everywhere or it must lead to a new version of the standard for which there really is sufficient ground (many similar problems).

The constant struggle between creative freedom and standard patterns requires a steadfast information architect who can always indicate why a pattern has been applied and what benefits will be nullified in case of deviations.

Read the other information science principles here: