Over a million developers have joined DZone.

Do You Have 'Terms of Reference' for the Software Architecture Role?

· Integration Zone

Learn how API management supports better integration in Achieving Enterprise Agility with Microservices and API Management, brought to you in partnership with 3scale

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 InfoQ.com.

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.

Unleash the power of your APIs with future-proof API management - Create your account and start your free trial today, brought to you in partnership with 3scale.


Published at DZone with permission of Simon Brown, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}