Do we need a software architect in our agile team?

Table of contents

• First of all, what is software architecture?
• What do agile frameworks say about the role of the software architect in agile teams?
• Conclusion and my experience

First of all, what is software architecture?

Before we can turn to the role of the software architect, we need to take a look at the definition of software architecture. There are a variety of definitions for software architecture.

Let us start with an official definition from ISO-IEC 42010:

Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

I assume that other software engineers probably reacted the same way. So in the software engineering community, various dev celebrities have created their own definition of software architecture.

Let us start with Martin Fowler, chief scientist at ThoughtWorks. He said that software architecture is:

the set of design decisions that must be made early
the decisions that you wish you could get right early
the decisions that are hard to change

Eoin Woods, CTO of Endava, defines software architecture as follows :

I define software architecture as the design decisions that are hard to change in a software system, which usually means trading off between different stakeholder needs and making sure the system achieves an acceptable set of quality attributes – again a set of tradeoffs.

Paul Preiss is the CEO and Founder of the Iasa, one of the largest Enterprise and IT architect associations in the world. He defines software architecture as follows:

The art and science of delivering valuable software.

From these three statements, I conclude that software architecture is primarily about clarifying and deciding important architecture issues according to stakeholder needs, communicating them, and developing the techniques to deliver valuable software.

After this personal summary, I come to the crucial question:

Who is responsible for the following activities in the team?

• Translate business requirements into technical solutions
• Develop non-functional requirements, translate them into quality scenarios and communicate them within the team
• Bring about, document, and communicate technology, architecture, and design decisions
• Communicate with product stakeholders to find the trade-off between possible technical solutions and various stakeholder needs
• Implement technologies and techniques to deliver high quality software
• Manage and help to prioritise technical debt

Is it the team? Is it a single person? Is it the Software Architect on the team?

What do agile frameworks say about the role of the software architect in agile teams?

I looked at several agile methodologies and frameworks and asked myself the question:

Do the following agile methods and frameworks answer the question about the software architect on the team?

• Manifesto for Agile Software Development
• Scrum
• LeSS Framework
• SAFe
• DSDM Agile Project Framework
• Disciplined Agile

What do say the Manifesto for Agile Software Development?

Let us take a look at the principles of the agile manifesto in relation to software architecture.

The best architectures, requirements, and designs
emerge from self-organizing teams - One principle of the Agile Manifesto

This statement implies that the team organises itself on this issue.

Take a look at the Scrum Guide

If you read the Scrum Guide, it is quite simple: The Scrum Guide knows the following three roles:

• Product Owner
• Scrum Master
• Developers

Scrum does not explicitly know the role 'Software Architect'. But if you look a little deeper, you will find this general statement:

As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included. - Scrum Guide

They simplify potential specific roles into a general 'developer' notion. So the role of software architect is probably not explicitly excluded. It depends.

Architecture and design @ LeSS

LeSS promotes a big focus on 'Technical Excellence'.

Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design - LeSS

The following statements on the Architecture & Design page in the chapter "Technical Excellence" shape their opinion about software architects:

• The sum of all the source code is the true design blueprint or software architecture.
• The real software architecture evolves (better or worse) every day of the product, as people do programming .
• The real living architecture needs to be grown every day through acts of programming by master programmers .
• A software architect who is not in touch with the evolving source code of the product is out of touch with reality.
• Every programmer is some kind of architect–whether wanted or not. Every act of programming is some kind of architectural act–good or bad, small or large, intended or not .

LeSS promotes the idea that architects (and system engineers) are regular ( feature ) team members. They should participate in hands-on engineering- and especially mentoring during design workshops, multi-team design workshops, pair programming, and agile SAD workshops.

LeSS warns against architecture astronauts (a.k.a. PowerPoint architects):

These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about the architecture… They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.

Agile Architecture in SAFe

SAFe recognises the following architecture roles on the Agile Architecture page:

• Enterprise Architects (across all value streams)
• Solution Architect (across systems)
• System Architect (single system)

These architects work in different architecture domains: Business, Information, Application, and Technical Architecture.

I think that system architect is also a synonym for "software architect" as stated on the SAFe website:

"System Architects communicate the technical path through the Architectural Runway, Non-Functional Requirements, and the design and support of the Continuous Delivery Pipeline (CD pipeline)."

Architects are not part of the software, hardware, IT, operations, and other technology-oriented teams. Teams must collaborate with these architects (see under Agile Teams).

Roles and responsibilities in DSDM Agile Project Framework

The DSDM Agile Project Framework recognises the role of a Technical Coordinator who supports the team but is not part of the team.

"Technical Coordinator ensures that the solution/technical roles work in a consistent way, that the project is technically coherent and meets the desired technical standards. This role provides the glue that holds the technical aspects of the project together while advising on technical decisions and innovation."

All role descriptions can be found in Chapter 7 Roles and Responsibilities.

Although this role is only "supporting" and surprisingly not part of the solution development team, the technical coordinator has a variety of tasks (only architecture-related tasks are listed):

• Agreeing and controlling the technical architecture
• Advising on and coordinating each team’s technical activities
• Identifying and owning architectural and other technically based risks
• Advising on the achievability of non-functional requirements
• Working with the Business Analyst to evaluate the technical options and decide the best way to turn the high-level business requirements into a technical solution
• Advising on and coordinating each team’s approach to estimating, to reflect technical best practice and current technical understanding
• Promoting appropriate standards of technical best practice
• Controlling the technical configuration of the solution
• Approving the solution as technically fit for purpose prior to deployment
• Managing technical aspects of the transition of the solution into live use
• Empowering the technical roles within the Solution Development Team to appropriate levels within their responsibilities
• Acting as the final arbiter of technical differences between Solution Development Team members

The Architecture Owner in Disciplined Agile

Disciplined Agile distinguishes between primary roles (team roles, constant) and supporting roles (temporary).

According to DA, there is a primary role called "Architecture Owner". This primary role is responsible for the architecture as a project risk.

Architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk. - DA

DA describes the Architecture Owner as follows:

• The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.
• [...] it should be noted that this is not a hierarchical position into which other team members report. He or she is just like any other team member and is expected to sign-up and deliver work related to tasks like any other team member. Architecture owners should have a technical background and a solid understanding of the business domain.

DA goes into detail about the role of the Architecture owner role in this blog post.

There is also a supporting role of the "Technical Expert":

• Technical experts are brought in on an as-needed, temporary basis to help the team overcome a difficult problem and to transfer their skills to one or more developers on the team. Technical experts are often working on other teams that are responsible for enterprise-level technical concerns or are simply specialists on loan to your team from other delivery teams.

However, this role is not identical to the software architect role. There may be supporting activities, such as technically specific software design issues, that a technical expert can help with.

Conclusion and my experience

Software architecture activities are critical to product development because these activities strongly influence the success of a product.

But is the software architect necessary in person on the team?

I would say it depends. It depends on the people involved, the underlying organisation and its culture, because software architecture has a lot to do with teamwork, ownership and taking responsibility.

Software architecture work is teamwork

I like the idea of self-organising teams. The team is constantly defining what it needs to create a better product and become more effective. If the team needs a software architect, define that. If not, you do not need a person with the specific title of software architect.

Most important, however, is that every developer on the team collaborates on software architecture, because Software architecture work is team work.

A person who cares about architecture decisions

But I often experience that there should be one person in the team who takes care of the architectural decisions. Caring means that a single person is responsible for documenting and communicating architecture decisions within and outside the team. Often, this person has good communication skills to elaborate and communicate architecture decisions. In addition, such a person can facilitate architecture workshops to achieve uniform and consistent architecture decisions that are also transparent, understandable and comprehensible in the end.

A problematic scenario can be that no one is responsible for the architecture decisions and each developer brings his own technologies and frameworks into the system without any communication, consultation and agreement with the team. This can result into Hype Driven Development. For more details see my blog post about Hype Driven Development 👇

Technical Debt Scenario #4: Hype Driven Development

The development team is always on the hunt for the latest technology hype. Currently, there are more than two front-end frameworks used for the product and the time to launch new features is getting longer and longer. What would you do?

workingsoftware.devPatrick Roos

Everyone needs to do developer work - do not create architecture astronauts

Another anti-pattern is the hard distinction between software developer and software architect, also known as "Powerpoint", "Confluence" or how LeSS says "architecture astronauts". These types of people just draw PowerPoint slides or Confluence pages and communicate the next fancy solution to higher management.

If someone holds the role of a software architect in the team, he or she must also be a developer.

If this is not the case, it is definitely an anti-pattern and there will probably always be a gap between the sold architecture to the management and the actual solution and, even worse, the real problems will not be properly addressed.

Important cross-team architecture & tech exchange

If you have more than one product or feature team in your organisation, it is often good to have regular architecture-specific exchanges between product teams. This architecture group (often called a guild, center of excellence, or whatever it is called) needs to ensure that potential synergies related to architecture and technology decisions are identified and possible actions are initiated.

Concluded answers to my questions above

Let's say we have an organisation that trust their employees and supports agile and self-organising teams. Then here my really opinionated conclusion to my questions above:

Who is responsible for the following activities in the team?

📌 Translate business requirements into technical solutions

Every team member should be translate business requirements into technical solutions. That means beside the coding also (and probably more important!) the collaborating with the customer to understand the needs and work out the best solution.

A good solution is here to co-work on features and not to separate developers on single requirements.

📌 Develop non-functional requirements, translate them into quality scenarios and communicate them within the team

Often this activity is not the most popular task of all developers. In my opinion, this kind of work is also the work of a software architect.

📌 Bring about, document, and communicate technology, architecture decisions

In my experience, it is often good to have someone in charge of architectural decisions. That way there is a point of contact for all team members and other interested parties. As a result, someone is responsible for documenting the architectural decisions made in an understandable way.

📌 Communicate with product stakeholders to find the trade-off between possible technical solutions and various stakeholder needs

Every developer on the team should be able to do this. As described, I prefer the co-working approach here.

📌 Implement technologies and techniques to deliver high quality software

Every developer. The retrospective helps here to define effective action points.

📌 Manage and help to prioritise technical debt

This can be continuously part of a retrospective that is done in the team.

Is it the team? Is it a single person? Is it the Software Architect on the team?

It depends.

However, software architecture work should always be a team effort.