Software Architects and Autonomous Teams

DZone 's Guide to

Software Architects and Autonomous Teams

Take a detailed look at how the Software Architect role can fit into a modern engineering organisation and why you might want to have one.

· Agile Zone ·
Free Resource

In recent years I have been working as a Software Architect in multiple organizations including technology companies and high-growth startups, working as both an individual contributor and a manager of an architecture team. What I've learned is that the Software Architect role is one of the most diverse and one of the least well-understood roles. Let's see what the industry believes a Software Architect is.

"A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms." – Wikipedia

The most common understanding is that an architect is a person who takes action and dictates decisions. In the understanding of many people, this doesn't go in line with many other modern principles of software engineering such as autonomous cross-functional teams, independent microservices or software ownership by teams (you build it, you run it). In addition, there is a concept of the Platform Team which cares about common ground and a reasonable set of common standards. So, why then in a modern engineering organization would someone make a decision instead of the team? This is an awesome question.

A Software Architect should never make a decision that the team can effectively make on their own.

A Software Architect is needed for the situations when the team can't make an optimal decision by themselves. And it's not about technical expertise; the Architect is not the smartest engineer in the room. While the Software Architect should be indeed a senior and knowledgeable person, extraordinary technical expertise is not the reason for having Software Architects. The main reason is the knowledge of the big picture and wide focus. Here are the key benefits I see in the Software Architect role.

Replicate Success Stories

Different teams usually do not share codebases now. Moreover, microservices promotes teams being more flexible, independent and move faster. As a result, teams know less about the work of others, especially in bigger companies where people are geographically distributed. One team might be struggling to solve an issue which another team is an expert in. By working with multiple teams, a Software Architect can help find and replicate successful decisions. Two teams might be working on a similar problem and not recognize this, but the person who works with both of them would. I have seen multiple times teams planning to work on some functionality that another team has implemented already: resiliency solutions, platform upgrades, or even microservices.

Identify Strategic Improvements

The system is as strong as it's the weakest link. In every organization, there is a function that is less strong than others. By identifying and improving the weakest link we dramatically improve the whole system. It might be system resilience, domain isolation, DevOps maturity, or performance. Each team should work on technical excellence, but if they work in different directions results might have a less noticeable impact than if the whole organization will take one direction as a priority. An architect can identify and highlight the weakest link in the system and help other teams define the most noticeable improvements.

Keep Decisions Pragmatic

Good engineers like their jobs. Also, they like learning new stuff. And when you have a hammer in your hand each problem might start looking like a nail. Architects should definitely contribute to the codebase but they don't spend as much time writing code as developers do. As a result, architects are less emotionally attached to technical decisions. Also, architects understand the organization well and are more focused on budget impact since usually, they know global infrastructure costs and global picture. This helps them stay pragmatic and not overengineer. Don't mix up being pragmatic with cutting corners. Being pragmatic is mostly about not doing something, not about doing something in a non-maintainable way. At the same, a measure of reasonable experimentation and learning should always be in place.

Focus on Technical Excellence

Engineering teams are usually domain- and feature-oriented. This means they focus on delivering customer value. Architects usually are not a part of the feature team. Instead, they can focus and promote technical excellence and be a counter-force to the product team and delivery pressure. This helps to find the right balance in the organization between technical excellence, delivery, and scalability. While it's everybody's duty to follow established Agile processes, there could be a Scrum Master who moderates it all. Similarly, while it's everyone's duty to keep long-term system maintainability, a Software Architect could facilitate that.

Attract, Promote and Grow Talents

The Software Architect role attracts strong engineers who like to have a system-wide focus and work with other people. Software Architect is a role that allows applying soft skills more than the Software Engineer role but without the people management duty that not everyone likes. Many Software Architects would not trade this role for being a Software Engineer or Engineering Manager because they are exceptionally good at what they do as Software Architects. This role attracts senior technical talents to the company who otherwise might not have applied. Also, it is a good option to keep your experienced engineers even more engaged. Playing an architect role is indeed a great professional development step.

agile, collaboration, roles, software architect, technical experts

Published at DZone with permission of Grygoriy Gonchar , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}