Blackboard Architecture

Imagine a school class solving a difficult puzzle together. In the middle stands a large blackboard. Whoever has a partial solution writes it down. Everyone else reads along and builds on it. This is exactly how the blackboard architecture works in software: a shared storage area, the blackboard, holds all the intermediate results so far. Several separate program parts look into it and contribute their knowledge. None of these parts knows the solution alone, and none communicates directly with the others.

Why one approaches problems without a fixed solution path this way

For many tasks, the calculation path is known in advance exactly. A tax calculation, for example, always runs in the same order. For other problems, this is not known. When a program is supposed to understand spoken language, it depends on the audio signal which step makes sense next. Sometimes grammar helps, sometimes acoustic analysis.

It was precisely for such cases that the blackboard model was developed in the 1970s. The best-known example is Hearsay-II, a speech recognition system from Carnegie Mellon University. It broke the task down into levels: signal, phonemes, syllables, words, sentences. Each level had its own specialized modules. Together they worked their way up from unclear sound waves to a meaningful sentence.

The practical advantage is loose coupling. The modules do not depend on each other, only on the shared storage. One can swap out a module or add a new one without rebuilding the rest. This makes such systems extensible, but also hard to predict: which path to the solution is taken is only decided at runtime.

Blackboard, knowledge sources, and referee

Such a system consists of three components. The blackboard is the shared data store containing all intermediate results. The knowledge sources are the specialized program parts, often separated by area of expertise. The control mechanism is a kind of referee that decides who gets to write next.

The process repeats in rounds. Each knowledge source checks whether the current blackboard content is relevant to it. If so, it signals that it is ready to act. If several signal at the same time, the control mechanism selects one, for example based on urgency or expected benefit. The selected knowledge source computes and writes its result to the blackboard. Then the next round begins with a changed blackboard state.

It is important that entries need not be final. A knowledge source may record a hypothesis, that is, a reasoned guess with a confidence value. Later modules can support or discard this guess. In this way the system approaches the solution gradually, rather than computing it in one go. A common misconception is to regard the blackboard as a mere database. The difference lies in the control mechanism: it actively drives the process forward.

From Hearsay-II to today’s agent systems

In its classic form, the blackboard architecture has become rare. But its idea lives on. Robots use it to merge camera images, distance sensors, and map data into a picture of their surroundings. Similar setups also appear in signal analysis, for instance in the monitoring of ship movements.

Notable is the closeness to current multi-agent systems. There, several AI programs work on a task, often with different roles. Many of these systems use a shared working memory into which all agents write their intermediate steps. In technical articles, the word blackboard regularly reappears for this. The term is thus over forty years old and yet still present in current debates.

Anyone developing software also encounters this pattern in software architecture textbooks. There it stands alongside better-known designs such as the layered architecture. One deliberately chooses it when there is no fixed process and many different areas of expertise must work together.