Architecture Repository/Architecture practice/Heuristics

From mediawiki.org
Jump to navigation Jump to search

Wikimedia logo Wikimedia Architecture Repository
Practice | Strategy | Domain | Systems | Components

Heuristics[edit]

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

Last updated: 2021-07-29 by Clump
Status: v1 released October 20, 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[edit]

Heuristic: Fix both

Heuristic: Build trust

Heuristic: Practice collective reasoning

Heuristic: Use common language

Heuristic: Frame problems holistically

Heuristic: Design component independence

Fix both[edit]

Heuristic: Fix both

Conway’s Law[1] 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[2] system. To create reliable change, whenever there is a problem: Fix both.

Build trust[edit]

Heuristic: Build trust

Quality system design depends on effective communication and effective communication depends on trust[3]. A cohesive culture of trust will honor, respect, and distribute information[4]. 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.”[5]

Practice collective reasoning[edit]

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.[6])

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[edit]

Heuristic: Use common language

Whenever people discuss their system and the capabilities that facilitate essential activities, use familiar language.[7] 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[edit]

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[8]–they fit well into the overall design and create cohesive value.

Do what's right for the system not the tooling[9] 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[edit]

Heuristic: Design component independence

“Choose components so that each can be implemented independently of the internal implementation of all others.”[10] 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.[11]

References[edit]

  1. Conway's Law
  2. Socio-technics and beyond: an approach to organisation studies and design in the second machine age
  3. Building trust in high-performing teams
  4. Thinking in Systems by Donella Meadows, pg. 174
  5. The Art of Systems Architecting (2nd ed.) by Maier and Rechtin, pg. 135
  6. Thinking in Systems by Donella Meadows, "Celebrate complexity." pg. 181
  7. Ubiquitous Language
  8. “Conceptual integrity is the most important consideration in system design.” The Mythical Man Month by Fred Brooks
  9. Thinking in Systems by Donella Meadows, "Defy the Disciplines." pg. 183
  10. The Art of Systems Architecting (2nd ed.) by Maier and Rechtin pg. 115
  11. Ruth Malan