What is just in time rigorous architecture?

Introduction

When people begin using the Agile approach to software development, they are confronted with  the idea of incremental or just-in-time design. This feels strange to people who are familiar with the more traditional Big Design Up Front (BDUF) approach, where design work goes through a series of review gates. In an Agile culture, the design emerges as the work goes forward. Simply put, design is an activity and not an event. This activity starts at the beginning, and finishes at the end.  People often ask; how does this work in practice? How is it reviewed and governed to ensure confidence in the process? As an architect, what does this mean to me? How do I understand intentional and emergent designs?

Organisations and careers have been built around current practices. Some people belong to an organisation of architects which have career paths and training schemes. System Architecture may be described through a framework such as TOGAF or the 4+1 view model. In practice it can be less structured from pictures of whiteboards to documents describing what is wanted in some level of detail. In many ways architectural practice is personality driven.

We should ask why we even have an architecture for our system? This is always taken as needed and the design phase of systems is always planned for. But other than a document, what has architecture ever done for us? Let’s highlight what an architecture can give us.

• The views such as described in the 4+1 approach or other similar approach
• The structure of the application we are implementing
• A series of NFRs (Non functional Requirements) that need to be complied with
• A plan to build the system’s software
• A Vision for the system
• the dependencies for the architecture
• Business requirements and how they impact the architecture
• Various plans such as Test Plan, Security Plan, Release Plan and so on.

Traditionally these are reviewed and when they change in any way during the lifecycle of the project, they are updated under change control. “Design Reviewed”, is typically one of the gates in the lifecycle of projects and is even agreed as a payment milestone in some cases. But what does this approach not give us?

• Working software
• Demonstrable tests
• De-risking of the deliverable, in fact it increases the risk of a successful delivery in many cases.
• Collaboration between the people involved in building the system
• Feedback loops
• Prioritised Work
• etc

Ok so that is what we get in the old world and some of the things we don’t get. In an agile project, what we would like to have from an architecture or design is:

• A growing list of decisions made and why
• A map of the software so we can support the system later, if required
• Acceptance Tests, regression tests, integration tests with a leaning towards automated tests.
• How the Architecture supports the business processes (Dependency maps)
• How the software is actually built into components or other logical groupings, the system structure
• Audit trails around aspects of the system design such as impacts for DPA, GDPR or DO178, if required
• A record of the conversations that lead to the decisions if required
• Where required, an audit of the decisions made
• Proof of Concepts conducted and what we learned from them
• The stories for the architectural enablers

In general we should understand that the main use of the system architecture/design in an agile environment is:

• To collaborate on the way the system is built between teams building it
• To communicate the way the system is built for support reasons
• To document decisions that may need to be audited later (Safety, security, privacy), if required
• To describe those parts of the system other than business processing that need to be build. (Logging, Transactional Control, Messaging, Scaling, Resilience, development infrastructure etc, etc, etc)
• To share knowledge about the domain and technologies used within it, as required
• To learn and to capture the lessons as required
• To add value to the work
• To conduct experiments into the building of the system, if required

You may notice that the expression, “If Required” is used here. This relates to the configurable quality of ceremony.

Low Ceremony Little Documentation Light Process

High Ceremony Well Documented High Traceability

An agile approach asks that you decide on the level of formality you need with your ceremonies. Are you creating a mockup of you new website idea, or are you creating the safety control software for a nuclear reactor. The two require different levels of formality.