Disclaimer: I am an architect in an agile environment but, as Helmuth von Moltke the Elder says, "No battle plan survives contact with the enemy". In other words, practicalities mean that the exact letter of the guidelines cannot always be followed.

Most of the points raised above are followed as best the team can. However, principle 1 (The teams that code the system design the system) is really hard to follow when the team consists of tens (or hundreds) of developers split across different continents and time zones. This is nothing to do with the developers' skills or attitudes, more the logistical problem of them all being present to gather requirements from customers and understand existing complex systems.

So, how is the system design done? Using UML? Or a document that defines interfaces and major blocks? Maybe something else?

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 project to project within the organization. This design done before the team starts coding or as early as possible and usually contains (and is not a complete list):

1. Expanded requirements and scope definition. These include use cases or user stories that flesh out the higher level business requirements. I personally like to use RFC 2119 for non-functional requirements. Design is based on and traced back to these. Although it may not fit the common definition of design, these are often just as important.
2. An overview consisting of a high level network or component diagram and a page of text. This is for a very wide audience, from upper management down to dev and QA. This rarely uses UML or a defined notation due to the wide audience.
3. 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.
4. 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 exactly the same as one in a traditional waterfall process. However, in agile environments, less of the design is done upfront and more of it is delegated to component teams. The key is determining how deep to go initially, which decisions to defer and identifying when decisions need to be made.

After the initial design is created, the architect works with each of the teams and reviews their designs. If additional design or design changes are required for a unit of work (such as a scrum sprint), the architect aims to have it available by the time that unit of work starts. The architect is also responsible for communicating any changes to affected teams or stakeholders.

Disclaimer: I am an architect in an agile environment but, as Helmuth von Moltke the Elder says, "No battle plan survives contact with the enemy". In other words, practicalities mean that the exact letter of the guidelines cannot always be followed.

Most of the points raised above are followed as best the team can. However, principle 1 (The teams that code the system design the system) is really hard to follow when the team consists of tens (or hundreds) of developers split across different continents and time zones. This is nothing to do with the developers' skills or attitudes, more the logistical problem of them all being present to gather requirements from customers and understand existing complex systems.

So, how is the system design done? Using UML? Or a document that defines interfaces and major blocks? Maybe something else?

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 project to project within the organization. This design done before the team starts coding or as early as possible and usually contains (and is not a complete list):

1. Expanded requirements and scope definition. These include use cases or user stories that flesh out the higher level business requirements. I personally like to use RFC 2119 for non-functional requirements. Design is based on and traced back to these. Although it may not fit the common definition of design, these are often just as important.
2. An overview consisting of a high level network or component diagram and a page of text. This is for a very wide audience, from upper management down to dev and QA. This rarely uses UML or a defined notation due to the wide audience.
3. 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.
4. 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 exactly the same as one in a traditional waterfall process. However, in agile environments, less of the design is done upfront and more of it is delegated to component 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 development 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 works with each of the teams and reviews their designs. If additional design or design changes are required for a unit of work (such as a scrum sprint), the architect aims to have it available by the time that unit of work starts. The architect is also responsible for communicating any changes to affected teams or stakeholders.

Disclaimer: I am an architect in an agile environment but, as Helmuth von Moltke the Elder says, "No battle plan survives contact with the enemy". In other words, practicalities mean that the exact letter of the guidelines cannot always be followed.

Most of the points raised above are followed as best the team can. However, principle 1 (The teams that code the system design the system) is really hard to follow when the team consists of tens (or hundreds) of developers split across different continents and time zones. This is nothing to do with the developers' skills or attitudes, more the logistical problem of them all being present to gather requirements from customers and understand existing complex systems.

So, how is the system design done? Using UML? Or a document that defines interfaces and major blocks? Maybe something else?

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 project to project within the organization. This is done before the team starts coding or as early as possible and usually contains (and is not a complete list):

1. Expanded requirements and scope definition. These may be use cases or user stories that flesh out the higher level business requirements or non-functional requirements. I personally like to use RFC 2119 for these.
2. An overview consisting of a high level network or component diagram and a page of text. This is for a very wide audience, from upper management down to dev and QA.
3. Details for individual components, often focusing on the interfaces between them as mentioned above.
4. A list of architectural risks and their mitigations, if known.

Afterwards, the architect works with each of the teams and reviews their designs. If additional design or design changes are required for a unit of work (such as a scrum sprint), the architect aims to have it available by the time that unit of work starts. The architect is also responsible for communicating any changes to affected teams or stakeholders.

Disclaimer: I am an architect in an agile environment but, as Helmuth von Moltke the Elder says, "No battle plan survives contact with the enemy". In other words, practicalities mean that the exact letter of the guidelines cannot always be followed.

Most of the points raised above are followed as best the team can. However, principle 1 (The teams that code the system design the system) is really hard to follow when the team consists of tens (or hundreds) of developers split across different continents and time zones. This is nothing to do with the developers' skills or attitudes, more the logistical problem of them all being present to gather requirements from customers and understand existing complex systems.

So, how is the system design done? Using UML? Or a document that defines interfaces and major blocks? Maybe something else?

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 project to project within the organization. This design done before the team starts coding or as early as possible and usually contains (and is not a complete list):

1. Expanded requirements and scope definition. These include use cases or user stories that flesh out the higher level business requirements. I personally like to use RFC 2119 for non-functional requirements. Design is based on and traced back to these. Although it may not fit the common definition of design, these are often just as important.
2. An overview consisting of a high level network or component diagram and a page of text. This is for a very wide audience, from upper management down to dev and QA. This rarely uses UML or a defined notation due to the wide audience.
3. 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.
4. 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 exactly the same as one in a traditional waterfall process. However, in agile environments, less of the design is done upfront and more of it is delegated to component teams. The key is determining how deep to go initially, which decisions to defer and identifying when decisions need to be made.

After the initial design is created, the architect works with each of the teams and reviews their designs. If additional design or design changes are required for a unit of work (such as a scrum sprint), the architect aims to have it available by the time that unit of work starts. The architect is also responsible for communicating any changes to affected teams or stakeholders.