Agile focuses on developing workable codes from small user stories. Pair programming encourage developers to pair up, actively engage with one another to come up with the best solution for the problem. Design and code are actively reviewed, refined, until it reaches a state where everyone is confident that the software is maintainable and robust for the customers.

Agile transforms the command and control mechanism, where architects dictate what the design should be, into a democratic process that gives everyone the autonomy for designing the system. This leads to the question, is a software architect still relevant in Agile? Does Agile slowly transform the role of an architect into something else?


8 Answers 8


Great question and definitely something that doesn't seem to be addressed very well in the standard material that is out there. I won't pretend to have all the answers as we are still struggling with this ourselves, but there is definitely still the need for an architect role in an agile environment. It is almost definitely different than the typical role in a more waterfall approach, but still there. It seems that, in an agile environment, the architect role gets much more involved in the backlog grooming portion. They are a prime candidate to do rapid prototyping and other research to help with breaking large user stories down into smaller ones that will fit into a sprint. Being a product owner, there are many times that I have a user story that is too large to fit into a sprint but isn't clear from a business perspective how to break it down. This is where it seems to be very beneficial to get the delivery team involved to help. During team backlog grooming meetings there will be discussion about potential ways to approach the problem and many times more research on these alternatives or some prototyping will need to be performed before a decision can be made. This seems to be where the architect role fits best in agile.

In a multi-team environment where there is a lot of shared code, this could be enough load to warrant a dedicated architect working with the product owner team to help provide this sort of feedback ensuring consistency across the teams. In any case, as always, the goal of the prototyping and research is to gain just enough knowledge to be able to make a decision and move forward. Any code from that effort should be discarded and the knowledge shared in another way. This could be some light weight documentation, it could be some simple diagrams, it could simply be a conversation. Generally speaking, if it was complicated enough to warrant the research, it is probably complicated enough to warrant some level of documentation, as long as that isn't used as a hand-off and accompanies a discussion.

  • 2
    Agile is about doing something minimal that can work, so it does make sense for asking the architect to do rapid prototyping instead of creating thick design documents that may not work. Thank you for the answer =) Jun 14, 2011 at 7:03

Yes, architecture is vital and Yes to your entire - and very well stated - second paragraph, it changes the relationships and the role.

When a software architect tries to pull rank or maintain status over a good agile team, the team gets frustrated, even annoyed. The architect may feel threatened by the team wanting to do architecture, not have it thrown over the wall to them. They may be more capable than he. One way forwards is for the architect to trust that better architectures really will emerge from a team effort and do architecture with the team. Her/his role then moves more to consultancy than delivery of architecture.

  • Concerning the technical architecture

All systems have architecture. The tools, frameworks and previous projects may do 80% of the architecture without you realising, but ignorance is not bliss. Rapid, agile delivery is sustainable not just for a few sprints but over months even years if and only if the right kind of architecture underpins the design.

Systems don't get rewritten because of failing functionally. They are rewritten because of failure in the software qualities (NFRs) - performance or security or maintainability or other." In other words, because of architectural failure. (I think the quote's from Bass, Clements,Kazman, "Software Architecture in Practise").

  • How should architecture evolve in the light of Agile?

is still an open and lengthy question. Here are 3 people's efforts:

  1. http://www.slideshare.net/makabee/aduf-adaptable-design-up-front

  2. https://leanpub.com/software-architecture-for-developers

  3. http://www.slideshare.net/ChrisCarroll2/presentations (mine)

  • Slideshare is good for this - browsing round slideshare for agile architecture will pretty much give you the 'state of the art' at the moment Oct 17, 2013 at 17:08

I think Software Architecture involves planning the Components working together. Agile projects need planing too, without this I can't see a successful end.

I think in Agile way, this planning doesn't need to generate excessive documents. But planning the architecture is still necessary.


The question, I believe, is really two fold. How does the concept of architecture fit into agile and is there a need for a dedicated or assigned role to perform the work.

I strongly believe that for complex projects, architecture planning and definition is critical for long term success. There are cross functional aspects, like performance, that are difficult to add afterwards in an iterative fashion with a sprint by sprint only view.

The role of architect seems to vary company to company, but common responsibilities are usually much deeper than defining the architecture of a single project. They insure best practices are being followed, consistency between projects, insuring a project fits within the bigger picture within an organization and so forth.

So does an architect need to exist ? Depends on your company/business. If you have a complex infrastructure with a lot of projects that need to coexist and be supported over the long term, an architect or architectural team is probably needed. If you are a small company with a limited number of development projects, maybe there is much less of a need.

Just like any other specialty skill on a team, is there enough work to justify a dedicated resource or just spread out the work and live without the focus of a specialist.


I think this could also be phrased as "does design fit into Agile?"

As you develop a product, the architecture, design and implementation change each release. How much depends on the needs of the project and the ability of the team to understand the scope of the overall solution. You only build an architectural component or change the design based on needs, not "what ifs" So, while you may have planned to have an abstracted, data driven business rule component as part of your architecture, you don't build it till you need it. That way, if the scope changes, or not adding that in provides enough value to ship, then you have the option to ship.

In my experience, Agile project benefit -much- more from having strong, very experienced architects as part of the project so they can make more informed decisions about "when" things are needed and "what can be cut to make things simpler but still functional" Also, having developers with strong inherent design skills and experience can work with the uncertainty around the changing and ever morphing design in an Agile project.

Having a "single architect" make the decision drops away. Some teams discuss "is this needed yet" and having some experienced folks provide context and some inexperienced folks to challenge implicit assumptions seems to provide a good mix.

So, I don't think it transforms SW Architecture as a discipline or a practice :-)


I believe that design is still essential, regardless of the mechanism used to deliver the solution. There must be boundaries, especially in terms of defining the extent of a solution, and particularly around interfaces, integration, and simply avoiding straying into the space that other projects are attempting to cover - otherwise a strong PM / product manager could take the development in a direction that is completely wrong for the organisation or enterprise that is needing the solution.

A simple example may clarify what I mean. Consider a company that has a well designed, integrated, management reporting system based on a recognised tool, that works with industry standard databases. Within that company there is a small development that uses a different database, different data standards, and duplicates some of the functionality of other enterprise applications (including some management information). Not a problem... for the project team. But it is a problem for the organisation, as it now has multiple versions of the "truth", and no-one knows for sure which one is right, because they will never be perfectly aligned. Why has this happened? - because there was no-one validating the design or setting parameters for the developers to remain within.

So yes, software architecture is very relevant in Agile, especially in integrated, complex, enterprise-sized environments. But I would also argue for proper design in any development, as there is always merit in keeping at least one eye on the prize that you're shooting for, as well as creating the code for your next iteration.


Continuous attention to technical excellence and good design enhances agility.

Architecture is an element of technical excellence. It's a large part of design.

For example, architectures such as Hexagonal/Ports-and-Adapters and Clean Architecture ensure that critical application logic isn't mixed together with implementation details. They keep business rules centralized, not scattered wherever they may seem convenient. They help to make such logic testable, and encourage writing those tests.

That's just an example, not an endorsement of any architecture for a specific application.

Having and following an architecture keeps our work sustainable. It should also help us respond more quickly to changing requirements. So yes, it's very relevant. I'll go a step further: I don't see how a team can be Agile without some sort of deliberate architecture.

One of the greatest problems with the adoption of Agile is that we tend to forget that it's not general principles for doing all sorts of work. It's about developing software, and it doesn't yield good results if we minimize or neglect the technical aspects that are specific to software.

  • Agile frameworks don't discount architecture. They just usually postpone architectural decisions until the last responsible moment since the requirements may change over the life of the project. It also moves architectural discussions into just-in-time planning within the team rather than big, upfront development from external sources. So while I agree that not all projects are suited to agility, I strongly disagree that properly-implemented agile frameworks and practices deprecate or delegitimize the value of architectural planning.
    – Todd A. Jacobs
    Nov 17, 2022 at 4:40
  • There was nothing about Agile frameworks in the question or in my answer, so I'm not sure what you disagree with. There is however a tendency for "Agile" to focus excessively on stories, sprints, etc. and leave out the technical details having to do with software. I've had to show people that the Agile Manifesto refers repeatedly to software and developers., They didn't know that Agile was about developing software. Nov 17, 2022 at 13:44
  • You specifically say: One of the greatest problems with the adoption of Agile is that we tend to forget that it's not general principles for doing all sorts of work. The OP is asking about architecture and architects in agile frameworks, and you discuss agile adoption. While it's true that the Agile Manifesto is largely about software, many agile frameworks are not software-centric. The Toyota Production System (TPS) is a great causa exemplum. So, depending on what you meant by "deliberate architecture", it seems unclear what you're really trying to say if it isn't "BUFD for the win!"
    – Todd A. Jacobs
    Nov 18, 2022 at 1:36
  • I did specifically say that thing which has nothing to do with frameworks in response to the question that's not about frameworks. Nov 18, 2022 at 3:11


This is an old question, but is still attracting attention more than a decade later. As such, it's worth giving it an answer updated based on 11 additional years of agile adoption in the industry.

The original question posits that agility and agile frameworks somehow obviate the need for either architectural planning or an architect's skill set within a software project. It does so by conflating command-and-control management with the practice of sending requirements "downstream" from architects to developers. One is a (badly outdated) style, while the other is a (just as badly outdated) practice.

The question also presupposes that agile frameworks that encourage cross-functional teams, tighter collaboration, and emergent design through practices like just-in-time planning and leaving design decisions until the last responsible moment are orthogonal to the practice or profession of a systems/software architect.

None of the assumptions above are true. However, the notion of what architectural design should look like and who is responsible for doing it requires frame-shifting the question. Architects and architecture still exist; in many domains, they just function better as members of modern agile teams.

Agility Isn't Orthogonal to Architecture

Agile frameworks don't discount architecture. They just usually postpone architectural decisions until the last responsible moment since the requirements may change over the life of the project. Three key principles behind the Agile Manifesto state:

  • Welcome changing requirements, even late in development.
  • Simplicity—the art of maximizing the amount of work not done—is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

So, the goal of agility isn't to ignore architecture or design, but rather to acknowledge that "big, upfront design" is generally waste (in the Lean sense) because requirements and designs are likely to change over the term of the project. The old adage:

Plan the work, then work the plan.

is largely at odds with any framework or methodology that embraces continuous change.

Emergent design and limiting architectural work to "just enough" for near-term planning (SAFe calls this Architectural Runway) basically converts architectural discussions into just-in-time planning within the team rather than big, upfront plans received from external sources. So while I agree that not all projects are suited to agility, I strongly disagree that properly-implemented agile frameworks and practices deprecate or delegitimize the value of architectural planning.

Autocratic Architects are Obsolete; Architectural Skills Aren't

By definition, a cross-functional team contains all the skills necessary to deliver the current increment of development. Most agile frameworks therefore have a bias towards T-shaped people rather than overly-focused roles, but that doesn't mean that teams never leverage I-shaped people for specific tasks or externalize resource dependencies.

Probably the most accurate thing to say is that in frameworks like Scrum, there are likely people on the team who are stronger in some areas than others. However, since architectural decisions often impact everyone on the team, everyone gets a voice in making near-term architectural decisions with the active collaboration of those with more knowledge of architecture.

For example, a given architecture is likely to impact testers, programmers, database administrators, network administrators, DevOps pipeline administrators, and so on. Since the paradigm is all about collaboration, any architectural decisions that don't consider the impact of those decisions on each of the team members and the areas for which they are most often responsible typically creates a lack of cohesion and a potentially non-unified increment.

So each iteration, an agile team considers what the optimum level of architectural planning should be for the next iteration or two, and makes that part of their iterative or incremental planning. They limit that planning to what is currently in scope, or likely to be in scope shortly; this prevents a great deal of wasted effort in the event that the project pivots, requirements change, or better ways of accomplishing the objective are discovered.

This Applies to UI/UX Skills, Too

Similar questions about how to integrate user interface and user experience design into agile workflows comes up often on this site. The basis of those questions are largely the same, although the questions are often more about how to integrate the people and activities rather than whether or not they have value.

If you search this site for UI/UX questions, many of the answers about how to integrate those people and skills into an agile team will apply to software architects, too. In short, they should be part of the team, should be collaborative, and should be collaborating on the current deliverable increment rather than working ahead of the rest of the team.

A Parting Caveat

There are certainly some problem domains, types of projects, and corporate cultures where agility is neither appropriate nor desirable. As examples, space missions are not well-suited to empirical design on a per-mission basis; pacemakers aren't good candidates for adaptive or incremental improvements to quality control; and large wars aren't ideal situations for just-in-time resource allocation.

Nevertheless, while any given agile framework is not universally appropriate, agility in general is now the de facto standard in many sectors precisely because it encourages adaptability, transparency, and close collaboration. Validated learning and continuous improvement are at the heart of properly-implemented agility. If you are a software or systems architect, that generally means you need to drink the agile Kool-Aid or look for the rare opportunities where agile inspect-and-adapt feedback loops aren't appropriate or valued.

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