Do you have a terms of reference for the software architecture role?

Most teams don't ... but they should

Most of the roles that we associate with software development teams are relatively well understood ... developers, testers, ScrumMasters, Product Owners, business analysts, project managers, etc. The software architecture role? Not so much. I regularly ask software teams whether they have a defined terms of reference for the software architecture role and the usual answer is along the lines of "no" or "yes, but we don't use it". Often people working for the *same team* will answer the question differently.

Although the need for thinking about software architecture is usually acknowledged, the responsibilities of the software architecture role often aren't clear. In my experience, this can lead to a situation where there is nobody undertaking the role, or where somebody is assigned the role but doesn't really understand how they should undertake it. If the role isn't understood, it's not going to get done and we have little hope of growing the software architects of tomorrow.

Regardless of what you call it (e.g. architect, tech lead, etc), my advice is simple. If you don't have a shared understanding of the role, start by doing this for the role within your team. Here's a simple starting point for what the role could look like. The role is also described in my book and here on

Software architecture role

Another approach is to define it collaboratively using a workshop or game storming techniques. Here are some photos from a tutorial I did at QCcon London 2012 called "Are you a software architect?".

Ideas for the software architecture role

Make sure that you base any role definition on your own context to ground the role in reality. Then, once you understand what the role should look like on a team, you can start thinking about whether to achieve consistency across your organisation. This may or may not be necessary/desirable.


Creating a shared understanding of the role will help to avoid questions like this and situations where software architecture falls between the gaps.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see for information about his speaking schedule, videos from past conferences and software architecture training.

Re: Do you have a terms of reference for the software architecture role?

Great post, Simon. The one thing I'd suggest is expanding the description of Architecture Evolution to read "Ownership of the architecture throughout the delivery/product lifecycle". For in-house IT (and ISVs, for that matter), a focus on the product versus the project is something I consider critical. The architect role is best positioned to plan for future changes that will be imposed on the product by its environment/major dependencies (OS, DBMS, etc.) in addition to those that will come from the evolution of the product's feature set.

Add a comment Send a TrackBack