Architecture and Architects
The software industry has always held a basic assumption that architecture is important. By association, the role of architect has always been esteemed important. But unfortunately, it isn’t always clear what architecture is or what an architect’s job should be.
Are architects even needed, or can you just have great development teams? If they are needed, what should they be doing? Do they need to sit in ivory towers? If you don’t have people with the title “architect” do you still need people effectively doing that job? In order to answer these questions, we need to get clear on what architecture is.
What Is Software Architecture?
There are a number of definitions, but I like a pair that Martin Fowler has written and spoken about:
The important stuff. Whatever that is.
and
A common understanding of how the thing works.
The important stuff might be things like code, domain/business understanding, or system interactions. It could include things at high levels of abstraction; perhaps the details of how multiple microservices interact. Or it might be at low levels, such as a particular data algorithm that is critical to your business. This fuzziness makes it hard to be exact on what architecture is, but if you ask the senior technical people on the project, they will definitely have an answer.
However, if that knowledge of the important stuff isn’t shared across the team members, then the intended architecture becomes hidden over time and is in danger of being supplanted. If the majority of the developers believe that something else is more important, that becomes the de-facto architecture. Or worse, if there is no common understanding then things devolve into anarchy and the system becomes a tangled mess.
A common understanding of how things work could come from clean code, documentation, or other types of communication. It can be difficult to keep system understanding all in your head, so this explains why architecture diagrams and other documents are so often created to share understanding across team members.
If we combine the definitions and say that software architecture is “a common understanding of how the important stuff works,” then it follows that the architecture impacts every developer (and likely others as well, such as operations and security) and they impact it in return. So are all developers architects then? Not necessarily.
The Role of an Architect
Given the above definition, an architect needs to be someone who can correctly identify the important stuff, be able to explain it, and evangelize it. Technical skills are critical, but not sufficient. An architect’s role includes understanding business value, systems thinking & design, and communication.
Business Value
The elegance or creativity of an architecture is irrelevant if it does not enable value. In the context of a company, does the architecture help the company meet its goals? Does it keep costs down and enable the changes that drive revenue? In the context of an open-source project, does the architecture enable the software to be able to meet its goals? An architect needs to be engaged with the business to be able to understand these goals.
Gregor Hohpe writes that “architecture is rarely good or bad - it’s either fit or unfit for purpose.” He posits that an architect needs to be interacting with leadership and presenting architecture as “selling options.” How will the architecture (especially at a high level) be good for the business? Or are the technologists just doing what they think is neat or blindly following after the strategy of other companies? The article also says, “Companies should invest more in architecture that allows them to defer decisions.”
At Pluralsight, our architects have taken “a principled approach to architecture.” This approach starts with identifying strategic goals such as delivering amazing experiences quickly, being data-driven, and security. Next, decide what principles support those goals, like cross-functional teams, cloud infrastructure, or small codebases. Then list what practices go along with those principles; things like continuous delivery, test-driven development, or minimizing coupling between teams. This approach helps you align your architectural goals to business value.
Systems Thinking & Design
An architect needs to be able to understand and design the important stuff. This is possibly the best-understood aspect of an architect’s role.
An architect should be able to describe the architecture and explain what the strengths and weaknesses are. This is important, because there is no one right answer for how something should work. There are always tradeoffs, and the architect needs to be able to explain why decisions were made and which qualities were selected for.
As systems grow, they become more complex and new behaviors can emerge. Architects need to have systems thinking skills that allow them to predict and plan for change. Is the architecture flexible, making it easy to continue to grow and change? Or is it rigid and prone to slow the business down?
Communication
Going back to the aspect of a “common understanding” being part of architecture, it’s critical that an architect is able to help others understand the important parts as well as the reasons behind them.
The bigger a development organization gets, the harder and more important this job gets. If teams are not aligned to the architecture, then they are likely to deviate from the course and introduce new complexities. One of the best ways to help teams stay aligned is for the architect to spend time coding with them and coaching them. Instead of handing down instructions like commandments from on high, the architect should be open to collaboration and ideas from those who are closest to the problems.
In an article about architects in Enterprise organizations Kevin Hickey says that when you’re working across multiple teams, “Your role is no longer to make choices, but to help others make the right choice and then radiate that information.” I don’t believe that means an architect is not responsible for making any choices, but that their choices should generally be at higher levels of abstraction (outside a team’s area of work) and that they should not be imposing on teams. Let the teams do their job and shoulder their own responsibility for it. Instead, the architect job is about influence. It’s about promoting a vision, building bridges, and facilitating education.
A sign that an architect has done their job well is that teams understand how they fit into the big picture, and they can do their work independently without negatively impacting the system.
At Pluralsight, one of the ways we facilitate a common understanding is through a weekly “Architecture Guild” meeting. Anyone is welcome to attend and we encourage every team to send at least one representative. During the meeting we have presentations and discuss issues relating to the greater system for the development and ops teams.
Architecture Affects Everyone
Given that we’ve defined architecture in terms of understanding the important aspects of a system, then the architect role is indeed a key role for a software organization. Without that role we leave ourselves open to risks of not meeting business needs or having people pull in opposing directions.
That doesn’t necessarily mean that there has to be somebody with the title of Architect, but someone should be filling that role. Many of the good developers I know definitely share some of the skills of an architect. In some cases, I’d argue that they are architects, though usually for a subsystem, like in the case of Pluralsight’s bounded contexts. It’s OK (preferable even) to have architects at different levels of abstraction.
Every system has an architecture, whether it is intentional or not. If you don’t want yours to become a haphazard mess — or you want it to recover from being one — then you need good architects and people committed to driving that shared understanding forward.