I have read Principles for the Agile Architect, where they defined next principles :

Principle #1 The teams that code the system design the system.
Principle #2 Build the simplest architecture that can possibly work.
Principle #3 When in doubt, code it out.
Principle #4 They build it, they test it.
Principle #5 The bigger the system, the longer the runway.
Principle #6 System architecture is a role collaboration.
Principle #7 There is no monopoly on innovation.

The paper says that most of the architecture design is done during the coding phase, and only system design before that. That is fine.

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

  • 11
    You don't "do the design" in UML. You do the design, and then you use UML to write it down or communicate it.
    – tdammers
    Commented Sep 24, 2012 at 19:24
  • 4
    @tdammers: to be precise, you try to use UML to write it down and notice that UML is not sufficient.
    – Doc Brown
    Commented Mar 23, 2013 at 22:30

3 Answers 3


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.

  • 3
    This is a great answer to what the role of an Architect in an Agile team should be, however it really doesn't answer the question about What the System Design is before sprint development starts and best practices to do it.
    – maple_shaft
    Commented Sep 24, 2012 at 11:48
  • @maple_shaft I have expanded my answer to focus more in the design.
    – akton
    Commented Sep 24, 2012 at 12:05
  • 3
    For what it's worth, as another architect who's worked in agile environments for several years in major multinational settings, this is spot-on.
    – Rex M
    Commented Sep 24, 2012 at 13:48

Disclaimer: I am not an agile coach/architect - this is what I've seen in agile projects that I've worked on and I think it works well.

I don't think it's quite defined by Agile how you do architecture - agile focusses on development methodologies and practices. UML on the other hand is just a language to communicate your architecture which is beyond agile (you use it if it fits your project and your team).

One of the principles of architecture that really applies, is take the decision at the last possible responsible moment - meaning its fine if you haven't taken all the decisions at the beginning of the project, especially since you have least information at this stage. Over time, you may take decisions that "evolve" the architecture. Yes, this might look like some rework, but this is also due to the fact that you have learnt new things about the environment, the requirements, what is possible what is not, etc.

The main thing that you would like to avoid is architecture rot - where the code is not really conforming to any particular architecture and is just a tangled mess. The main difference compared to evolving an architecture, is that in the latter, you take concious decisions periodically and document them with clear reasons, and then follow through to make sure your code follows it.


When doing test driven development you create testcode that tests your modules in isolation (= as independant of other modules as possible )

To ease the creation of testingcode you introduce interfaces to other moduls that can be easily mocked away.

This way as a side affect you automatically get an architecture where the coupling between the modules is as small as possible.

In my opinion tdd is also architectural work.

  • Yes, TDD is an architectural work, but on a software components. My question is really how the architecture of a large scale project is created using agile principles. Commented Sep 25, 2012 at 6:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.