Categories
Software Architect

Prefer principles, axioms and analogies to opinion and taste

When creating your architecture you should explicitly use principles, axioms and analogies to guide the creation. This gives the architecture a number of benefits that are not present if you simply create by implicitly leveraging your experience, opinions and tastes.

Documenting your architecture will be easier. You can start by describing the principles that were followed. This is much easier than trying to communicate your opinions and experience. The principles will then provide a convenient handle for those tasked with understanding and implementing the architecture. It will also be invaluable for subsequent or inexperienced architects who need to work with the architecture.

An architecture with clear principles is an architecture that frees its architect from reviewing everything and being everywhere. It gives architects greater leverage and influence. You will not need to be an omniscient workaholic to ensure that others can consistently:

  • implement and adapt the architecture;
  • extend the architecture into related domains;
  • re-implement the architecture using newer technologies;
  • work out the detailed edge cases.

Disagreements about opinion and taste invariably turn into political arguments in which authority is used to win. However, disagreements where the foundation principles are clear provide a way for more reasoned discussion to occur without issues being personalised. It also allows the disagreements to be resolved without reference to the architect at all.

Principles and axioms also give an architecture consistency throughout its implementation and across time. Consistency is often a problem, especially in large systems that span multiple technologies and will exist for many years. Clear architectural principles allow those unfamiliar with a particular technology or component to reason about and more readily understand the unfamiliar technology.

'Coz sharing is caring
Categories
Software Architect

Prepare to pick two

Sometimes accepting a constraint or giving up on a property can lead to a better architecture, one that is easier and less expensive to build and run. Like buses, desirable properties tend to come in threes and trying to define and build a system that supports all three can result in system that does nothing especially well.

A famous example is Brewer’s conjecture, also know as Consistency, Availability, and Partitioning (CAP), which states that there are three properties that are commonly desired in a distributed system – consistency, availability, and partition tolerance, and that it is impossible to achieve all three. Trying to have all three is going drastically increase the engineering costs and typically increase complexity without actually achieving the desired effect or business goal. If you data must be available and distributed, achieving consistency becomes increasingly expensive and eventually impossible Likewise if the system must be distributed and consistent, ensuring consistency will lead at first to latency and performance problems and eventually to unavailability as the system cannot be exposed as it tries to reaches agreement.

It’s often the case that one or more properties are considered inviolate – data cannot be duplicated, all writes must be transactional, the system must be 100% available, calls must be asynchronous, there must be no single point of failure, everything must be extensible, and so on. Apart from being naive, treating properties as religious artifacts will stop you thinking about the problem at hand. We start to talk about architectural deviation instead of principled design and we confuse dogmatism with good governance. Instead we should ask, why must these properties hold? What benefit is to had by doing so? When are these properties desirable? How can we break the sustem up to achieve a better result? Be ever the skeptic, because architectural dogma typically tends to undermine delivery. The inevitability of such tradeoffs is one of the most difficult things to accept in software development, not just as architect, but also as developers and stakeholders. But we should cherish them as it’s far better than having limitless choice and accepting tradeoffs often induces a creative and inventive result.

'Coz sharing is caring