II Architects
This part of the book focusses on the software architecture role; including what it is, what sort of skills you need, and why coding, coaching and collaboration are important.
5. The software architecture role
The line between being a software developer and being a software architect is a tricky one. Some people will tell you that it doesn’t exist, with architecture just being an extension of the design process undertaken by developers. Others will tell you that it’s a massive gaping chasm, which can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky real-world implementation details. As always, there’s a pragmatic balance somewhere in between, but it does raise the interesting question of how you move from one side to the other, and therefore how you progress in your career as a software developer.
As we learnt in chapter 1, software architecture is about a number of different things; ranging from the organisation of code through to having a holistic view of the software system being built from a number of different perspectives, and making the appropriate significant design decisions to ensure success. This definition is necessarily broad, but it doesn’t really describe what software architects do, and how a software developer moves into a software architecture role. It also doesn’t help in identifying who will make a good software architect, and how you go about finding them if you’re hiring.
Becoming a software architect isn’t something that happens overnight or with a promotion. It’s a role, not a rank. It’s the result of an evolutionary process where you’ll gradually gain the experience and confidence that you need to undertake the role. While the term “software developer” is relatively well-understood, “software architect” isn’t. A simple way to think about the software architecture role is that it’s about the “big picture” and, sometimes, this means stepping away from the code.
Here are the things I consider to make up the software architecture role, with the summary being that the role is about providing technical leadership and being responsible for the technical success of the project/product. Notice that I said “role” here; it’s something that can be performed by a single person or shared amongst the team, but we’ll talk about that later.
1. Architectural drivers
The first part of the role is about understanding, and managing, the architectural drivers - the functional requirements, quality attributes, constraints and principles, as we saw in the previous chapter. These driving forces have a huge influence on the resulting software architecture, so explicitly including them as a part of the software architecture role helps to ensure that they are proactively considered, and taken into account.
2. Designing software
It should come as no surprise that the process of designing software is a key part of the software architecture role. This is about understanding how you’re going to solve the problems posed by the architectural drivers, creating the overall structure of the software system, and creating a vision for the delivery. Despite how agile you to strive to be, as we’ll see later, you probably do need some time to explicitly think about how your architecture is going to solve the problems set out by the various stakeholders.
A key part of designing software is technology selection, which is typically a fun exercise, but it does have its fair set of challenges. For example, some organisations have a list of approved technologies that you are “encouraged” to choose from, while others have rules in place that don’t allow open source technology with a specific licence to be used. Then you have all of the other factors such as cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments, and so on. The sum of these factors can often make a simple decision of choosing something like a framework into a complete nightmare. Somebody needs to take ownership of the technology selection and evaluation process, and this falls squarely within the remit of the software architecture role.
3. Technical risks
What we’ve looked at so far will help you focus on building a good solution, but it doesn’t guarantee success. Simply throwing together the best designs and technologies doesn’t necessary mean that the overall architecture will be successful. There’s also the question of whether the technology choices you’ve made will actually work. Many teams get burnt because they believe the hype on vendor websites, or described by sales executives while spending a few hours together on the golf course. I always find it surprising how few people seem to ask whether a technology actually works the way it is supposed to, evaluating the technology where needed to prove that this is the case. Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty, and introducing risk where there are benefits to be gained. All technology decisions need to be made by taking many factors into account, and all technology decisions need to be reviewed and evaluated.
The key question that you need to ask yourself is whether your architecture “works”. For me, an architecture works if it satisfies the architectural drivers, provides the necessary foundations for the rest of the code, and works as the platform for solving the underlying business problem. Software is complicated and abstract, which means that it’s hard to visualise the runtime characteristics of a piece of software from a collection of diagrams, or even the code itself. Furthermore, I don’t always trust myself to get it right first time.
Throughout the software development life cycle, we undertake a number of different types of testing in order to give us confidence that the system we are building will work when delivered. So why don’t we do the same for our architecture? If we can test our architecture, we can prove that it works. And if we can do this as early as possible, we can reduce the overall risk of project/product failure. Like good chefs, architects should taste what they are producing. In a nutshell, the software architecture role is about proactively identifying, mitigating, and owning the high priority technical risks so that your project doesn’t get cancelled, and you don’t get fired.
4. Technical leadership
Whatever software architecture you create needs to be taken care of. Somebody needs to look after it, evolving it throughout the delivery in the face of changing requirements and feedback from the team. If a software architect has created an architecture, they should own and evolve that architecture throughout the rest of the delivery too. This is about continuous technical leadership rather than simply being involved at the start of the life cycle and hoping for the best.
5. Quality assurance
Even with the best architecture in the world, poor delivery can cause an otherwise successful software project to fail. Quality assurance should be a part of the software architecture role, but it’s more than just doing code reviews. You need a baseline to assure against, which could mean the introduction of standards and working practices such as coding standards, design principles and tools. Quality assurance also includes ensuring that the architecture is being implemented consistently across the team. Whether you call this architectural compliance, conformance or whatever is up to you, but any technical vision created by the people performing the software architecture role needs to be understood and followed by the rest of the team.
It’s safe to say that most projects don’t do enough quality assurance, and therefore you need to figure out what’s important to make sure that it’s sufficiently assured. A good starting point is to identify anything that is architecturally significant, business critical, complicated, or highly visible. You need to be pragmatic though, and realise that you can’t necessarily assure everything given the typical budgetary and time constraints we are subjected to.
Software architecture is a role, not a rank
The software architecture role is essentially about introducing technical leadership into a software team, and it’s worth repeating that what I’m talking about here is a role rather than a rank. Large organisations often use the job title of “Architect” as a reward for long service or because somebody wants a salary increase. And that’s fine if the person on the receiving end of the title is capable of undertaking the role, but this isn’t always the case. If you’ve ever subscribed to software architecture discussion groups on LinkedIn or Stack Overflow, you might have seen questions like this.
Hi, I’ve just been promoted to be a software architect but I’m not sure what I should be doing. Help! Which books should I read?
Although I can’t stop organisations promoting people to roles above their capability (often referred to as the Peter principle), I can describe what my view of the software architecture role is, and help people achieve it.
Create your own definition of the role
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. In my experience, although many software teams do understand the need for the software architecture role, they often don’t have a well-defined understanding (e.g. a “terms of reference”) for it. Without this, you run the risk of the role not being performed in part or in whole. I regularly ask software teams whether they have a definition of 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.
Regardless of what you call it (e.g. Architect, Tech Lead, Principal Designer, etc), my advice is simple. If you don’t have something that you can point at and say, “this is what we expect of our software architects”, take some time to create something. Start by agreeing what is expected of the software architecture role on your team, and then move to standardise it across your organisation if you see benefit in doing so.