Many software architects work in an environment where they are not leading a single software development team but instead are responsible for the overall design and technical integrity of a multisystem environment which supports the operations of part of an organization, or perhaps is a large software-intensive product. Each of the teams working on the individual systems that make up the whole will work fairly independently, and in many cases, some of the teams are likely to adopt an “agile” approach to software development.

Software architects in this position sometimes find it difficult to work effectively with their development teams, even though everyone wants to deliver a great system for the stakeholders. The reasons for this can be complex, but this article outlines some of the ways in which software architects can direct their efforts to overcome these problems. First though, let’s consider why there can be tensions between software architects and agile teams.

While architects and agile teams both want to deliver good systems in a timely manner, they tend to disagree about the best way to achieve this. Some of the reasons for this are:

  • When to design - Architects tend to want make the big decisions as early as possible. Agile teams often want to do it later and let the design emerge. The software architect’s approach is driven by the desire to avoid risk and rework and to ensure a degree of commonality right across the environment. The agile teams are driven by a desire to deliver the simplest system possible and so to avoid design work that isn’t immediately required.
  • Design artifacts - By the very nature of their work, software architects tend to produce documents and prototype implementations, whereas agile teams want to focus almost entirely on running production code and may not value architecture deliverables that take other forms. Architects must make sure that their work is packaged and presented in ways that the development teams will find immediately valuable, rather than expecting them to accept long abstract documents containing their words of wisdom.
  • Development process - Some architects favor high(er) ceremony processes because they feel that gives them better visibility over the software being developed, whereas agile teams prefer simpler processes that are often less formally defined and are specific to the individual development team.
  • Time horizon - Architects typically design with a view to the long term and think about return on investment over a multiyear time horizon, whereas agile teams tend to focus on the current iteration and what will provide immediate value to the end users of the system. A balance needs to be struck between the proverbial “five-year plan” that becomes irrelevant two years later and a very short-term approach that ignores obvious needs in the near future.
  • Breadth of focus - Part of the role of an architect is to be aware of a wide range of stakeholders across the organization and to make sure that the needs of those with a valid interest in the system are met. On the other hand, agile teams stress the need to focus on the “customer” of their system which is typically interpreted to be the end user. However, end users often don’t value factors such as disaster recovery, regulatory compliance or ease of inter-system integration, which are important to other groups of people. So when the architect is accused of introducing unnecessary complexity they are often simply responding to requirements from outside the end-user community.
  • Large programs versus single system - architects in a multisystem environment are concerned with changes across multiple systems, whereas a development team understandably wants to focus on their system and its regular iterative release cycle. However, the realities of a large change programs mean that some give-and-take is required to ensure that the deliveries from the individual system development teams line up to deliver a useful whole.

Can we bridge the gap between these two sets of different priorities? Agile teams aim to organize their work using the principles of the Agile Manifesto. Can these principles help architects to organize their work too? The principles are:

  • Valuing individuals and interactions over processes and tools.
  • Valuing working software over comprehensive documentation.
  • Prioritizing customer collaboration over contact negotiations.
  • Responding to change over following a plan.

There is nothing in the principles that most software architects would disagree with. So how can we apply these principles to our software architecture work?

People over Processes

  • Work directly with the development teams; don’t expect to work separately (in your “ivory tower”!). Hand the results to the teams as large documents to be followed. Work directly with the teams as you develop your ideas. This helps to validate the ideas as they develop and reduces resistance to their implementation as there is a sense of shared ownership about them.
  • Keep your backlog visible to make sure that people know what you’re working on, its priority and its likely delivery date. Make this easily available (e.g., via a Wiki and via email updates) and encourage people to comment on what they want done and when. This helps you to focus on what people find valuable and allows people to influence the architectural activities undertaken.

Software over Documents

  • Create “good enough” models and documents rather than aiming for polished presentation. Producing polished documents often means spending a large amount of time on presentation rather than design decisions and content. The remedy for this is to stop developing a document or model when it is good enough to be valuable to its intended audience, rather than continuing until it meets some abstract concept of completeness or quality. Of course the corollary of this principle is that the models and documents produced do actually need to be good enough to use, rather than just being unfinished because someone has lost interest in them!

  • Regularly deliver something executable, don’t just produce static documents or models. Executable artifacts such as spreadsheets, simulations and prototypes are much more compelling and credible and make it much easier to engage people in order to get them to use what you deliver. An executable deliverable is more likely to be used because people can interact with it and get value from it in their design activity rather than simply using it as a static information source like a document.
  • Provide detailed practical solutions for system qualities like high availability, security, data recovery and so on. Many development teams find it challenging to provide these system qualities, and for an agile team there is the additional disincentive that end users often don’t care very much about them. However, architects do care about these qualities, and a valuable architectural deliverable is a set of practical solutions for these problems that teams can apply. The benefits of doing this include making the teams more productive, increasing commonality across the different systems and increasing the likelihood that the systems actually exhibit these important qualities.
  • Create proof-of-concept implementations regularly, to keep you in touch with the technology that is in use, keep your practical development skills up to date and to validate the assumptions you’re making about your designs. Doing this sort of practical exercise regularly makes it much easier to keep your architecture work relevant to the development teams (and doesn’t do any harm to your personal credibility with them either!)


  • Identify minimal principles and share them effectively, rather than trying to define every detail of every design factor that you have an opinion on. Work out what you really need to have some influence over and work with the development teams to develop sets of practical, focused and comprehensible architectural principles to guide decisions in these areas. This balances your legitimate need for some control over critical design factors with the understandable desire of the teams to be left to make their own decisions.

  • Store all architectural information online because people generally won’t spend long looking for it, so it needs to be readily accessible. Make sure the information can be referenced using short readable URLs and post these URLs, everywhere they’re relevant. Also make sure that the information is in a form that people can access and understand (so, for example, publish models from your modeling tools to Web sites rather than expecting people to use the modeling tool to access them).
  • Focus on cross-system concerns rather than on the concerns that are the responsibility of a single system. This increases the chance of a productive relationship with the development teams because they have a clear responsibility for the design of their systems whereas you have a clear responsibility for the concerns that affect more than one system.

Responding to Change

  • Deliver incrementally to ensure that you’re delivering value. Things change all the time, so make sure that you deliver your work in useful small steps to allow you to validate the usefulness of what you’re doing and to allow you to respond to changing circumstances and priorities.

  • Allow for reprioritization of your work because in any fast moving environment, it’s inevitable anyway. The longer-term focus of software architecture work often results in architects trying to deliver long-term change across an extended period, and so constant reprioritization can be very disruptive. However, we need to allow for reprioritisation in order to respond to changing needs, and so we should take this into account as we plan and execute our work.
  • Identify clear system responsibilities in order to make change easier. The challenge with most large architectural changes is understanding what needs to be changed, which systems are affected, and then coordinating these changes. This is much easier if you clearly and formally define the responsibilities of each system in your environment.

While none of these practices are particularly sophisticated, using them to help to align our work with the principles of the Agile Manifesto can help us to increase the effectiveness of our work and so to collaborate effectively with the system development teams that we work with. 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access