architecture-handbook

< Back

Day to day Behaviours

Continually visualise the technical architecture

Perhaps the most visible aspect of the architect’s role is ensuring that the technical architecture documentation is up to date and reflects the current state of the system. This involves maintaining a living set of diagrams that evolve alongside the software.

We recommend the C4 Model for visualising architecture at different levels of abstraction (Context, Container, Component, and Code). These diagrams should not be static; they must be updated as the design matures.

Visualising the architecture is only half the battle; you also need to visualise the delivery of that architecture using tools like Gantt charts to communicate progress and dependencies to stakeholders.

For more in-depth information, see the Visualising Architecture learning path, which includes:

Read more here

Keeping documentation close to code

Read more here

Identifying ‘non functional’ requirements

Quality Attributes or Non Functional Requirements need to be considered and balanced as they are normally a trade off, examples could be:

Managing risk

Risk Storming

Communicating into the future

Read more here

< Back