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):
- 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.
- 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.
- Details for individual components, often focusing on the interfaces between them as mentioned above.
- 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.