In an agile team, who is responsible for making high-level architecture and design decisions that affect the entire system, not just the work being done in the current sprint?

Maybe product owner, scrum master, the scrum team or someone else?

enter image description here

  • 10
    This... makes no sense...
    – Telastyn
    Commented Oct 16, 2014 at 20:22
  • 3
    The presence of Product and Sprint backlogs don't affect who is responsible for software architecture. A better question might be: In an Agile Environment, who is responsible for software architecture?
    – ChargerIIC
    Commented Oct 16, 2014 at 20:24
  • I've tried to update the question so that it at least can be understood. Not 100% sure if I got it right... Commented Oct 16, 2014 at 21:05
  • related (possible duplicate): How is architectural design done in an agile environment?
    – gnat
    Commented Jan 4, 2017 at 8:51

8 Answers 8


"The software architecture is performed by the entire team. This practice does not remove the need for a software architect, it just means that the architect contributes to the discussion with a broader and probably more experienced perspective, nevertheless all members of the team contribute towards the architecture of the software."

  • 5
    Pure Agile tends to reject traditional top-down roles like "project manager" and "system architect," instead preferring to refactor those roles and distribute their traditional responsibilities throughout the team. Commented Oct 16, 2014 at 21:32
  • 6
    @JonathanEunice: How can this be practically feasible? Not every developer is also a good architect.
    – Giorgio
    Commented Oct 16, 2014 at 21:54
  • 2
    @JonathanEunice: So the question asked DWD does make sense after all. I do not understand all the downvotes.
    – Giorgio
    Commented Oct 17, 2014 at 7:30
  • 4
    @DaveHillier: Maybe these projects are large but the architecture is simple enough: the developers only have to fill in the pieces in a rather simple, repetitive schema (e.g. write hundreds of similar forms in a web-based application with an existing domain model). On the other hand, I know that as soon as an application gets sufficiently complex, you need someone to take care of the architecture (often upfront) otherwise you are going to end up with a huge mess.
    – Giorgio
    Commented Oct 21, 2014 at 4:59
  • 7
    "Big Upfront Design" is the typical agile argument to draw the conclusion that there should be no upfront design at all: an approach is taken to the extreme, the extreme proven wrong, and the opposite extreme is proposed as a solution. I agree that a big upfront design is rarely a good approach, but some fundamental architectural decisions must be taken upfront in order to avoid huge refactoring or complete rewriting later. This is not an activity that can be improvised "when one gets the feeling the code is getting too messy and needs refactoring". Experience helps to find a good balance.
    – Giorgio
    Commented Oct 21, 2014 at 18:32

Architects, of course, but perhaps not the traditional kinds of architects.

I don't mean the lead-surgeon kind of architect who does all the thinking and then leaves the monkeys to do all the typing. I mean an experienced lead programmer who understands the cost/benefit tradeoffs of difficult-to-reverse decisions and who advises teams on what to do.

Effective architects are hard to find, but it can be a fantastic position, and so you probably have at least one experienced, thoughtful programmer who could do it well. Such a person needs to

  • Make good architecture decisions, of course, but also
  • Know how to give advice effectively, so that others feel comfortable taking it, and also
  • Slowly delegate architecture decisions to the teams

This last point trips a lot of people up. When well-meaning agilists say things like "The team owns the architecture", they have that "right", but I find the advice almost completely meaningless in its application. If you trusted teams to take responsibility for their own architecture, then you wouldn't be asking the question in the first place, now would you?! I therefore assume that you ask the question because there is some concern either that

  • Nobody will take responsibility and we'll have a poor architecture, or
  • The wrong people will take responsibility and we'll have a poor architecture, or
  • Whoever takes responsibility will become a scapegoat and you're hoping to avoid that

If you need someone to take responsibility, then give it to whoever wants to accept it. Seriously. That person at least cares. Give that person the resources they need to do the job and help them when they need it. It probably doesn't matter how competent the person is, because if they care, then they'll try to learn what they need to learn. Naturally, such a person needs support in the form of good books to read and a community of peers and mentors whom they can ask for help and advice.

If you worry that the wrong person is about the take responsibility, then I hope you know who "the right person" is, and will fight to install them as an architect. A book like The New Strategic Selling will help you learn the sales techniques to make that happen.

If you just need a scapegoat, then quietly nudge others to give the responsibility to whomever's career you'd most like to destroy or impair. At least be honest about it.

Getting back to an effective architect's work, they can think of their job as a management position, rather than merely a decision-making position. If they don't delegate at least the most routine decisions to the teams, then they will become a bottleneck and slow down the entire organisation. Adding more architects at the top does not make that go faster. Cultivating better architecture decisions from the ground up will. The delegation board technique will help your architect become more comfortable over time delegating more and more decisions to the teams as those teams earn trust by showing competence.

I think of a great architect as someone who helps me understand how to design my systems better, who will advise me patiently when I ask for it, and who will occasionally stop me from making a very poor decision. Such an architect acts like a leader in the truest sense of the word: someone that others voluntarily follow.

I know that was a lot.


Miller, The New Strategic Selling. This book includes a model for understanding why you failed to close a specific sale. I find this invaluable in understanding why coworkers won't do the obviously wonderful thing I'm suggesting.

Weinberg, Becoming a Technical Leader. This book helped me learn how to do the non-architect part of the effective architect's job.

Appelo, Delegation Boards and Delegation Poker. Don't underestimate how hard delegation is and how much we suck at it. Learn do it more effectively and more comfortably.

  • 1
    Is your 'h' key dodgy? ;) Commented Oct 21, 2014 at 18:40
  • 3
    No, Dave. I used Spivak (gender-neutral) pronouns. Commented Oct 21, 2014 at 20:49
  • Because of the questions like @DaveHillier poses, I tend to use "s/he"... (Thanks for this great answer by the way, puts reality back into the "the team is/does/has/owns ..." cliches) Commented Nov 7, 2014 at 19:40
  • 1
    @jdl134679 Version control to the rescue: softwareengineering.stackexchange.com/posts/260541/revisions Commented Feb 13, 2017 at 0:32
  • 1
    @Walfrat After more thought, I decided to clarify this point a little further. A person who cares will try to learn what they need to learn, but likely needs support, such as a mentor. Commented Nov 3, 2018 at 19:58

The best architectures, requirements, and designs emerge from self-organizing teams

-- Agile Manifesto

So the team self-organizes to make architectural decisions in whatever way it sees fit. There's no hard and fast rule, it can range from consensus to a "council" of the most senior members, to designating one particular member as the architecture authority, to letting the architect choose if there is a member with such a job title...

  • 10
    I like Agile, but this is one great weakness - the architecture often gets neglected or cobbled together.
    – user949300
    Commented Oct 17, 2014 at 20:09
  • 1
    @user949300 "Agile" as in the manifesto says very little about architecture. What exact methods are you drawing this conclusion on? XP would encourage you to refactor mercilessly. Are you in favour of BUFD? Commented Oct 21, 2014 at 18:20
  • "XP would encourage you to refactor mercilessly": Until you spend more time refactoring than writing new code. I think the best solution is to find a balance between fundamental architectural decisions you take upfront after a careful analysis, and smaller design decisions you implement along the way through refactoring.
    – Giorgio
    Commented Oct 21, 2014 at 18:41
  • @user949300 that's because the team is not self-organizing, if they were they would be in frequent communication with the rest of the team whenever an architecture decision needs to be made and properly document/argue/discuss those ideas.
    – user7433
    Commented Feb 12, 2017 at 17:04

I feel that the answer to ""who is responsible for making high-level architecture and design decisions?" depends on the size and number of teams.

For one or two teams with 3-7 on each team then the self-organized team can do with lead from the senior members.

For 3 or more teams the increased complexity leads to the need for an architecture team that can see if the various sub-teams are doing work that will interface with the other teams. In my experience that point is reached when there are approximately 8 teams or at about 50 people.


There are some great resources from the Scaled Agile Framework (SAFe) team on their site.

It essentially helps you scale out agile across your organization, going above a single release and into portfolio and program planning. Their documentation shows suggestions on how to involve your Enterprise and System Architects in the process to introduce architectural epics into the release train.

Edit for clarity to address the question more directly:

In a scaled agile environment there are multiple tiers of ownership over the architecture. The agile implementation team will own the low-level emerging architecture by refactoring as needed to continue their implementation of their backlogs. Higher-level architectural decisions (supported operating systems, browsers, platforms, libraries) are under the responsibility of your system and enterprise architects. They will make the business cases for when these changes need to occur and will recommend for these architectural changes be added to the release train for the implementation teams.

So, in regards to the high-level architecture decisions that go beyond the sprint, you will usually have these made at a level above the team. These professionals traditionally have an 'architect' role within the enterprise already.

  • 2
    how does this answer the question asked, "who is responsible for making high-level architecture and design decisions"?
    – gnat
    Commented Oct 17, 2014 at 14:10
  • 1
    Thank you gnat, I have tried to edit it to make it more clear as to what my intention had been for responding to the question. I made a few leaps in my head, but forgot to write them down :)
    – Jay S
    Commented Oct 21, 2014 at 13:37

I think most of the other answers are thinking about this from the perspective of being inside a project.

If that is the only level of architecture in an organisation the result will frankly be chaos. I have witnessed this chaos first hand, sadly it happens.

According to TOGAF, the Enterprise Architecture Department makes high level plans for and with the business to create and replace the IT environment. The Enterprise Architect will have defined architectural principles and got them signed off at the highest levels of the organisation and will help create the high level architecture and requirements for each project. Each project is initiated to provide an architectural building block in that high level architecture.

So, at the project level, the Solution Architect will create the project architecture (possibly iteratively) and will get sign-off from the Enterprise Architect.

Now, to focus on an agile project. An agile project has requirements. They aren't in the form of a massive "Requirements Document" but instead are epic and stories. These Epics still require planning. You don't send a team of developers off on a few sprints into the unknown. You know at a high level what the system needs to do, what other systems it needs to interact with and what hardware / Operating System / Language constraints the organisation has and this guides and constrains the architectural choices open to the Solution Architect. For example, if you are committed to .NET and SQL server, you would have to make an extremely compelling case to implement an e-commerce site based on Magento using PHP and MySQL because of the costs involved in supporting two DBs, two languages, two webservers etc. Alternatively, one project could choose to use a completely different library or a different look and feel and this could have implications to all other in-flight projects. It is essential to have the oversight of an Enterprise Architect to prevent this sort of "Architectural Debt" from happening.


Depends on the organizational design of the organization and if the product is in a portfolio. Larger, role-oriented organizations are may appoint senior architects to lead these type of activities.

Generally an senior architect will facilitate and guide design decisions as they don't just affect a product backlog, they may affect several products in a portfolio of products.

Smaller, agile companies may rely on developers that are system experts to lead the development team to align on architectural design.

Ultimately, architectural decisions need to be agreed upon by the delivery team that works on the product. Experienced Architects and tech leads will be more focused on facilitating the discussion around what the design should look like, rather than dictating the design.


I think most answers already highlight that the team not a single person should take these decisions.

What they do not touch is another Agile principle:

Simplicity--the art of maximizing the amount of work not done--is essential.

Thinking about high-level architectures & design decisions are often not taken with simplicity in mind, possibly leading to wasting a lot of effort and adding unnecessary complexity that could make things harder to extend.

Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design

During your current iteration you should make architecture & design decisions for your current needs. Instead of looking ahead to a future that might never become, focus just on what you need now. Probably YAGNI a well thought-out architecture now, let the team handle it bit by bit.

Other reads:

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