Olly Shaw

Scale Principal
EE Life

March 6, 2024

Why defining architecture roles in organisations matters

One of the challenges in defining architecture roles is that there are so many different definitions of architecture.

We have found that each organisation has their own, slightly different approach to what architecture is, and how it should be approached. Recent discussions with our clients suggest there is a great deal of value in addressing this confusion, both internally and externally.

  • Internally: Having a clear definition of architecture and architecture roles makes it much easier to recruit the right people into the right roles. Our consultants can have more clarity before taking a role and it’s easier to identify gaps in existing engagements when we can spot roles that may be absent.
  • Externally: We’re better equipped to explain Equal Experts’ value proposition for architecture when we collectively understand what architecture is, and what it does. It also means that we have reliable, professional materials to draw on in conversations with clients.

What we did

I’ve been working with Stuart Gunter and Dave Sammut – who also co-authored this article with me – to identify the responsibilities typically fulfilled by three roles: tech lead, architect, and enterprise architect.

For each of these roles, we identified the actual stuff these people do every day and their scope of accountability (i.e. where their primary focus is). We validated our ideas by sharing them with a number of Equal Experts architects and engineers working in different roles with different clients. We also shared our thoughts with some of our clients for feedback.

Overwhelmingly, the feedback was positive and confirmed that we were heading in the right direction.

Here are the definitions we created:

What are the three key architecture-related roles?

  • The tech lead is involved with a specific engineering team on a daily basis, deeply involved with the technical details of the solution. They often act as a hands-on contributor to the team, and faces primarily inwards to the team and outward to immediate consumers/producers.
  • The architect is embedded within multiple teams within a domain, bringing a combination of deep and broad technical knowledge. They rarely commit code that goes to production, but may be involved in building prototypes and proof of concepts. They also bridges the technical art of designing and documenting solutions and the ‘softer’ side of navigating client architecture processes to gain buy-in and approval for designs. Some architects bring deep specialisation in a particular area (e.g. security, data, e-commerce). These are often referred to as solution architects.
  • The enterprise architect is primarily focused on ensuring the architecture function operates effectively, including alignment to broader business strategy, architecture governance, and creating a coherent architecture strategy spanning the entire organisation. They work closely with architects to execute the architecture strategy across the organisation.

In practice, you might see one person fulfil more than one of these roles. That’s okay! You may be at an organisation where the role names don’t match those here, either. That’s okay, too!

What does this help us with?

At Equal Experts, we see multiple multiple benefits to having a consistent position on what architecture means, including:

  • It allows us to talk to you. Understanding architecture enables us to confidently communicate to our customers – you – what we offer, and how this might be implemented in your organisation. For example, a tech lead may be providing all the architectural support needed for a team, without being called ‘architect’.
  • We can identify customer needs. For example, if there is a lot of repetition teams could benefit from an architect looking for service reuse across a domain.
  • We can identify anti-patterns and help guide clients to a solution. For example, a tech lead could be spending too much time on architecture governance and strategy, which means they’re unable to give enough attention to engineering.

Early observations

Drawing boundaries around roles can give a false impression of what people can or can’t do. However, we don’t see these boundaries as defining individual capabilities or limiting how we can contribute to our engagements. We’re fortunate that there are very talented people at Equal Experts who can perform a variety of these roles. We’re already finding this work helps us frame the needs of our clients more clearly.

This blog was co-authored by Olly Shaw, Stuart Gunter and Dave Sammut. We thank all the consultants and clients who contributed by offering feedback, suggestions, improvements and validation of the early iterations.

You may also like

Anyone Can Usability Test, Part 3: Making the Most of Your Findings

Blog

Anyone Can Usability Test, Part 3: Making the Most of Your Findings

Do we need roles in a cross functional team?

Blog

Do we need roles in a cross functional team?

Epic anchors – bringing epic stability to cross-functional teams

Blog

Epic anchors – bringing epic stability to cross-functional teams

Get in touch

Solving a complex business problem? You need experts by your side.

All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.

 

If you’d like to find out more about working with us – get in touch. We’d love to hear from you.