In this series

Essay

Systematism Beyond Design Systems 01.2020

Introduction

This is the first essay of a two part series about systematism. These essays will adopt a broader point of view to examine why we create systems, what they are most suitable for and the value they deliver in the process.

In this series, I will speak of system from an higher level of abstraction as "entities that serve a [one or more] purpose[s]". I am intentionally stepping back from the particular dynamics of design systems, so that the points made herein can be interpreted and adapted to a broader set of circumstances.

Do I need a system?

A popular axiom in current discourse around systems states: “we are all already using systems without being aware of it“.
While on the rise, this opinion is far from nascent. Almost 50 years ago, in his book Systemantics , John Gall began discussing how large organizations that control governments and religions, operate as systems we all participate in, whether we are conscious of it or not.

So what can we learn from the systems we currently use in our life, that we can apply to our work? We certainly have all experienced the frustration of systems that do not work well (notoriously, the DMV for example), so why do systems fail and when should we seek to create one?

As seductive as living in a world in which every task corresponds to a system might sound, most workflows are better suited without a system. Let's examine some characteristics a task (or the input of a system) must have to be suitable candidates for a systematic approach.

Systems perform incredibly well for a certain type of task . These workflows have three common traits: repetition (high-volume), longevity (medium to long lifespan), and a finite set of use cases (high-confidence), that can be iterated against programmatically (automation). Let's examine each in more detail.

Repetition & longevity

Like any investment, systems are subject to economic rules. In particular, they suffer from high marginal costs in the short term, which taper off in the medium and long periods, and they reach financial viability only after their marginal returns surpass their marginal cost.
Systems which have too short of a lifespan never reach economic maturity and therefore are not a convenient solution to the task they are set out to solve.

Finiteness & automation

Systems process their work through on a set of rules defined by their creator. By design, systems are simple computational machines which do not deal well with uncertainty: if a case is unknown, the system will not know how to react and will stop processing. A simple set of rules is exceptionally important for a system to operate fast and efficiently. Looser rules allow for quicker computational speed and for more flexibility in handling edge cases, as seen in the case of abstract systems.
Highly efficient systems rely on automation to process information faster and more accurately. A system with a high number of strictly defined rules is more likely to “jam” than a system with a few, more flexible mandates.

While the above is true for most cases, emerging technology is developing systems which are explicitly built to deal with uncertainty. These open-ended systems can take any input from a certain domain and make a judgment call in regards to the output, even in absence of instructions which contemplate that particular use case. For example, they are able to analyze photos or videos and return a multiplicity of information.

Efficiency ≥ consistency

Efficiency and consistency are often discussed together in the context of a system. While there can be a strong correlation between the two, it is important to understand that this relationship is unidirectional.

Efficiency addresses how a task should be performed, while consistency describes the standardized outcome of the task. If consistency becomes the sole concern of a system, actors tend to optimize for the output of the task in opposition to finding shared efficiencies.
This context produces consistent results through divergent processes but in the long term is not more cost effective than not having a system at all.

From that point of view, a system is firstly concerned with enabling the capabilities for deploying large scale solutions at high speed, and only secondarily about whether the outcome of these solutions is coherent with one another.

Efficiency

The lion's share of a systematic investment lies in its underlying infrastructure. Depending on what the system is hired to do, these initiatives can span a number of different areas, but they naturally tend to act as accelerators for information to be transmitted with higher efficiency along the production line.

A systems' infrastructure is about enabling a number of different possibilities at scale, without increasing the marginal cost of any of these changes.
When multiple products share the same infrastructure, it enables the whole portfolio to support a number of [design] system's outputs, and to propagate these changes to users faster.

Consistency

Valerie Gordon is a pastry chef who recreates lost recipes through research and heuristics. She is able to reproduce a result equal to the one created by bakeries in the 1950's by using processes and tools which might not have been available at the time the recipe was created. Her systemic approach achieves the same result by employing different methods.

As more and more companies begin to utilize systems to streamline their workflow, design teams look at systems as a way to improve product coherence. They focus on the system end-user and on the tangible outcome the system produces for them. Systems are then employed only as a mean to create consistent result and act as policy enforcers. We've discussed before how information always aspires to be free and how systems are particularly efficient at propelling information.

These circumstances put stress on systems that act purely as a regulatory tool. In Gall's words, "systems run best when designed to run downhill". His view sustains that systematism should not be a censorship mechanism and highlights the importance of "working with human nature rather than against them".

As a product evolves, features are added and new markets are discovered. The output of the system needs to adapt to these new circumstances. This doesn’t mean updating the system itself, but employing the same system to perform new jobs. This is particularly true of distributed systems, or systems that serve different product groups across organizations, where the system offers a playbook with a set of rules outlining how a problem should be solved for operationally, but is required to leave some latitude to what the outcome will look like.

Abstracted systems

In one of his axioms, John Gall mentions that "loose systems last longer and function better" .
Abstracted systems are systems which optimize for repetition and longevity as opposed to finiteness and automation. As they define a broader ruleset than standard applied systems, this type of constructs fit a broader set of use cases and can become extremely economical and have a lifespan of hundreds of years.

In an earlier essay, we've discussed governance models that can be conceptually abstracted to governing models that have existed for thousands of years. Similarly, Gall uses the Family System as the exemplary case of a system with a small set of loosely defined rules. In his praise of the Familial System, Gall describes that a family is exceptionally flexible construct, which can adapt to many permutations and is so resilient because of its extremely simple structure and its "strong alignment with [our] basic primate motivations" .

As they are divorced from a particular application method, abstracted systems affect mostly the strategic and operational layer. In the next essay "Separation of Concerns in Systematic Design", we will explore the subject in further detail.

References

1. Quoteresearch. (2019, January 14). To Cut Down a Tree in Five Minutes Spend Three Minutes Sharpening Your Axe. ↩︎
2. Gall, John. (1977). Systemantics. ↩︎
3. Microsoft. AI Demos. ↩︎
4. DeBeasi, Paul. (2019, February 14). Training versus Inference. ↩︎
5. Training, validation, and test sets. (2019, December 14).
6. Koehrsen, Will. (2018, November 15). Modeling: Teaching a Machine Learning Algorithm to Deliver Business Value.
7. Kholmatova, Alla. (2017). Design Systems. Freiburg: Smashing Media AG. ↩︎