Architecture Repository/Process/Heuristics

‎

Wikimedia Architecture Repository
Home | Artifacts | Process | Patterns

Heuristics

In the context of systems architecture, heuristics are trusted, time-tested guidelines for problem solving.

Last updated: 2023-06-14 by APaskulin (WMF)
Status: v1 published October 2020

Heuristics has a Greek origin, heuriskein, a word meaning "to find a way" or "to guide" in the sense of piloting a boat through treacherous shoals. Architecting is a form of piloting. Its rocks and shoals are the risks and changes of technology, construction, and operational environment that characterize complex systems. Its safe harbors are client acceptance and safe, dependable, long life. Heuristics are guides along the way—channel markings, direction signs, alerts, warnings, and anchorages—tools in the larger sense.

—Maier and Rechtin, The Art of Systems Architecting (2nd ed.) p26

Index

Heuristic: Fix both

Heuristic: Build trust

Heuristic: Practice collective reasoning

Heuristic: Use common language

Heuristic: Frame problems holistically

Heuristic: Design component independence

Fix both

Heuristic: Fix both

Conway’s Law says that “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” Two parts of a system can’t communicate effectively unless the two teams designing and implementing the parts can communicate effectively.

Conversely, whenever there are gaps or "faults" in the technosystem, they are mirrored in the sociosystem. Gaps and faults are the result of the sociotechnical system. To create reliable change, whenever there is a problem: Fix both.

Build trust

Heuristic: Build trust

Quality system design depends on effective communication and effective communication depends on trust. A cohesive culture of trust will honor, respect, and distribute information. Trust building is key to ensuring cooperation and sound decision making. “A collaborative system exists because the partially independent elements decide to collaborate. The designer must consider why they will choose to collaborate and foster those reasons in the design.”

Practice collective reasoning

Heuristic: Practice collective reasoning

Formal logic implemented in code, configuration, and infrastructure preexists as critical thinking activities between people in daily life (informal logic). We think, collectively, then we act. Collective reasoning is the processes by which we decide to take action despite uncertainty. (There is always uncertainty.)

Wherever the informal logic is weak, the implementation will also be weak. Strengthening our ability to effectively engage in collective reasoning strengthens our outcomes. Improving this process is, in fact, the most valuable investment we can make if we hope to improve system design. Architectural artifacts, which construct systems design, are products delivered through this process.

Use common language

Heuristic: Use common language

Whenever people discuss their system and the capabilities that facilitate essential activities, use familiar language. Avoid unnecessary jargon that silos domain expertise into groups who can’t and don’t understand each other. Develop the ability to speak across roles.

Frame problems holistically

Heuristic: Frame problems holistically

Don’t fixate on details of a problem while ignoring the context in which the problem exists. Speak for the system to ensure solutions maintain conceptual integrity–they fit well into the overall design and create cohesive value.

Do what's right for the system not the tooling by designing, first, for humans. Understand how low-level problems are scaling into system-level behaviors. The biggest problem is often, simply, the constant repetition of the smallest problem.

When solving challenges, remember that in systems, hierarchies exist to serve the bottom layers.

Design component independence

Heuristic: Design component independence

“Choose components so that each can be implemented independently of the internal implementation of all others.” This pattern is true in the sociotechnical sense, enabling both components and teams with the right interdependence. The responsibility of architecture is the architecture of responsibility.