Architectural Decisions

These are regularly taken by architects to solve a particular problem. There is a thin line between architectural decision and design decision. Should the architect also take a design decision? Ideally not, but as we know it all depends. Design decisions should be taken by the architect in collaboration with the tech leads and senior developers, but the architect should take the back seat. One example of this is choosing a framework. Tech leads and senior developers know best in depth the candidates, the only thing the architect should do here is to make sure the design respects the architectural decision. An architect is focused on breadth whilst a tech lead/senior developer is focused on depth.

Coming back to architectural decisions let’s focus on an example.

Architecture Kata – All Stuff, No Cruft

Conference organizer needs a management system for the conferences he runs for both speakers and attendees

• Users: hundreds of speakers, dozens of event staff, thousands of attendees
• Requirements:
  • attendees can access speaking schedule online, including room assignments
  • speakers can manage talks (enter, edit, modify)
  • attendees ‘vote up/down’ talks
  • organizer can notify attendees of schedule changes up-to-the-minute (if attendees opt in)
  • each conference (being a different subject) can be branded independently
  • speaker slides are accessible online only to attendees
  • evaluation system via web page, email, SMS, or phone
• Additional Context:
  • Conference runs across the US.
  • Very small support staff.
  • ‘Bursty’ traffic: extremely busy when conference is occurring.
  • Conference organizer wants to easily ‘skin’ the site for different technology offerings.

What type of architecture might suit better for this? First of all let’s extract some architecture characteristics(*ilities).

hundreds of speakers, dozens of event staff, thousands of attendees. This indicates how much load we need to support, so scalability is definitely on the cards. Bursty traffic tells us which type of scalability we need, and in this case is a variable one and that is called elasticity. Very small support staff tell us that the system should be available and fault-tolerant. So availability and resiliency. speaker slides are accessible online only to attendees indicates some kind of level of security, but nothing out of the ordinary. Of course nobody will use a system that is lagging when the presentation is being held. One implicit characteristic is performance. evaluation system via web page, email, SMS, or phone; each conference (being a different subject) can be branded independently; Conference organizer wants to easily ‘skin’ the site for different technology offerings This gives us some hints in terms of customisability. Some of these may not necessary suggest an architecture characteristics. The ones related to branding/skin suggest more a design problem. web page, email, SMS, or phone suggest that we need to be aware that multiple protocols may be involved (SMS) and we should take into consideration when creating the architecture.

Now remember that everything is a trade-off. Probably we cannot satisfy all these to a degree which we would be satisfied. So we need to focus on some rather than all. In this particular case we identify elasticity, availability, performance and fault-tolerant as critical. What type of architecture is best suited for this scenario? The answer lies in the requirements: organizer can notify attendees. So the architect in this case finds that event-driven architecture might be the best candidate. In this kata events are first-class citizen.

Since we decided on it it’s time to write it down explaining why we chose this. It’s time for our first architectural decision. In order to document it we can use npryce/adr-tools

adr init doc/architecture/decisions
adr new Event driven architecture type

After this use you favourite editor and update the markdown document. Of course you don’t actually need this script for doing this. But it’s pretty useful as you can link ADRs

adr link 2 Amends 1 "Amended by"

superseed ADRs

adr new -s 2 Brand New Decision

list ADRs

adr list
doc/architecture/decisions/0001-record-architecture-decisions.md
doc/architecture/decisions/0002-Event-driven-architecture-type.md

generate summary

adr generate toc
# Architecture Decision Records

* [1. Record architecture decisions](0001-record-architecture-decisions.md)
* [2. Event driven architecture type](0002-Event-driven-architecture-type.md)

The end result should be as follows.

You can version these for historical purposes, but they should be visible for everyone in some kind of wiki.