Often the architect identifies the major components then defines the interfaces between them (including nonfunctional requirements like security, speed and reliability) and delegates the internal design of the components to individual teams. This is a good compromise between letting the teams design their own components without requiring everyone to know everything about the system.

Every organization has its own set of standards for architectural designs and this sometimes varies from program to program within the organization. However, to ensure readiness for Big Room Planning, this design is done during the Technical Scoping stage of Progressive Elaboration:

  1. Expanded Epics and scope definition. These include Features that flesh out the higher-level business requirements.
  1. An overview consisting of a high-level network or component diagram and a page of text. This is for a very wide audience, from leadership down to implementation teams.
  2. Details for individual components, often focusing on the interfaces or APIs between them as mentioned above. Interfaces may be specified as method signatures in the target language with precondition and postcondition details. Components may have network diagrams, such as showing the layout of VMs in a cloud or data center and their networking arrangements. Relational databases will usually have Entity-Relationship diagrams.
  3. A list of architectural risks and their mitigations, if known. Like requirements, these demonstrate design decisions and trade-offs.

In short, the design of a system in an agile process is similar but leaner and less than one in a traditional waterfall process. Also, in agile environments, less of the design is done upfront and more of it is delegated to the Implementation Teams. The key is determining how deep to go initially, which decisions to defer and identifying when decisions need to be made. Decisions that impact multiple Implementation teams should be made earlier, especially scalability and security. Decisions like adding additional languages to an already internationalized product can be deferred until very late.

After the initial design is created, the architect/leads works with each of the Implementation Teams and reviews their designs. If additional design or design changes are required for a unit of work, the architect/leads aim to have it available by the time that unit of work starts. The architect/lead is also responsible for communicating any changes to affected Implementation Teams or stakeholders.

Product Managers should meet with the Architects and Leads initially to discuss what supporting technical documentation should be created to support the prioritized Epics, and then have a follow up meeting to discuss and provide feedback.

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level, AM is a collection of best practices, depicted in the pattern language map below (click on the practice for information). The Agile Axiom Framework embraces Agile Modeling as an effective method to do High Level and Low Level Documentation of your Software System and/or Product.

Agile Axiom Framework

Click on Requirements Envisioning, Architecture Envisioning, and Multiple Models for examples of High Level Technical Designs.