The (Human) Architect

These days, who needs an architect? Really. With the Agile movement, the importance of an experienced software architect in a software development team has continuously declined. Or so it seems. Software developers are big boys (and girls sometimes!) who do not need to be told what to do, how to do it, etc., right? Plus these architects tend to cost a lot… and they are difficult to find… so why bother? Why not reassign the tasks that a good architect normally performs (more on this below) to other members of the software development team and forget about it?

The value of having an architect on the team, working with the team

Notice I wrote on the team, and not in some ivory tower, unaware of what the development team is actually doing, the challenges it is facing, the constraints it is living with each day. I also wrote with the team, meaning co-located, ideally, coding alongside the team – up to a certain level – so that the architect remains humble (and relevant!). In such cases, architects can act as true mentors to junior team members; they can help the more senior ones see things from a different angle, motivate them, even inspire them. “OK,” you think, “this seems interesting, but what else?” I mentioned above that it might not be the best idea to reassign the tasks typically performed by an architect to other team members. But that leads directly to THE question I face most often…

What does a software architect do?

I have been asked this question many times during the course of my career as an architect, and sometimes by senior developers. They seemed to believe that I was doing nothing important, since I was doing far less coding than I wanted to, and what developers typically value most is coding. Here is what I believe are the most important contributions an architect can make in a software development project. A good architect should:

• Clarify the complete overall system context to both management teams and development teams
  • Why are we developing this software? For whom? What is the business goal?
  • What are the external constraints that need to be respected? What are the external systems that will interact with this software, and what mechanisms will be used?
• Help define the system’s boundaries, meaning, what role will be played by each of the systems’ parts?
• Help break down the system’s parts into smaller components that will often be developed by different teams, possibly not co-located, and define the role played by each of the system’s components
• Help define the system’s interfaces with external systems and between identified components within the system, more importantly, the ones implemented by different development teams
• Identify the riskiest elements of the planned development, conducting analysis whenever there is uncertainty that could impact the viability/profitability of the project
• Focus on all the non-functional requirements, and define them when non existent (and believe me, it happens more often that you can imagine!).
• Ensure the team communicates what it develops and develops what it communicates. This is more important than we can think, but with the increase in the complexity of software systems, it is common that the approach used to develop a software has to change during the course of its creation. Those choices need to be communicated and validated to ensure that the business goals remain attainable, even after the approach is changed.

Support team members

Architects should do this while supporting the development team to deliver all the functional requirements. After all, this is what customers primarily want. But functional requirements, properly implemented, without all the qualities that accompany non-functional requirements lead to inefficient software for your customers. It is the summation of both that provides true value. You are better off delivering fewer capabilities, but capabilities that are easy to use, that work all the time, that are secure, and that are a pleasure to interact with.

Support management

In agile teams, the architect should support the Product Owner in working with managers and stakeholders, in defining the sprints and ensuring that enough non-functional elements are put into each sprint. By doing so, we avoid the creation of technical debt, which could be difficult to reimburse later. It also plays a key role in supporting the SCRUM Master, in that he can help with the removal of impediments to sprints, when technically related.

The importance of Technical Practices in Agile and cultural changes

But what does an architect really do?

I always thought that changing an organization’s culture required not only the adoption of agile values but also that of agile-related technical practices. As shown in the above picture, changing culture involves adopting both. Practices should reflect your values. Your culture should emerge from your values and practices.

Here’s an interesting related link on InfoQ, The Importance of Technical Practices in Agile. I especially like the original article, directly from Uncle Bob where he says that

You can’t have a culture without practices; and the practices you follow identify your culture.

He mentions that by simply observing what practices are adopted by teams, you can tell if they are agile or not. He describes practices such as Continuous Integration, Test Driven Development, etc. as true indications of an Agile team. He also points out that after a while, teams following the right practices might do it out of habit and lose sight of the underlying values of those practices (what he calls ritualism; the catch being that the practices become rituals, the original values are forgotten, and the rituals become the values). Agile can be corrupted due to a loss of technical practices. Still from uncle Bob:

The biggest problem I have seen within the Agile movement is the elimination of the practices. One by one, over the years, the practices have been de-emphasized, or even stripped away. This loss of practice has diluted and changed the Agile culture into something that I don’t recognize as Agile any more. It has been a shift away from excellence towards mediocrity, away from hard realities, towards feel-good platitudes.

The danger, as pointed out in the article, is that the loss of technical practices causes developers to abandon the Agile movement while at same time, managers are adopting Agile as a process-only solution. As a result the gulf between developers and managers widens. And when the distance between development teams and managers increases, the potential for software development success decreases dramatically! I see the main role of an architect as ensuring that this does not happen by working at promoting technical practices, thus ensuring that the distance between development team and management is minimized.

Here are some examples from Dilbert depicting this distance between management and technical personnel:

and also how practices were somehow eliminated:

So now, who in your team takes care of promoting technical practices? Of the non-functional requirements?

In my opinion, no one will take non-functional requirements or technical practices into account more than an experienced software architect. All other roles – developers, product owners, managers – will always focus naturally on the functional requirements of your software products. But unless you dedicate someone to the practices – to the non-functional requirements – chances are the focus on those will be low. Without promotion and adoption of technical practices that embody true agile values, without solid management of the non-functional requirements, it is possible that your next software product will not be a lot of fun for your customers to use, not as useful as it could be, and more difficult to maintain over time, thereby affecting profitability directly.

Consider this for your next important software product: a focus on non-functional requirements and use of the best technical practices are like an investment in your software. An experienced software architect might actually be cheaper than you think, and the other team members might indeed love working with a good one! At least, personally, I always love working with good developers and good software managers.

OK, but what is with the title of this blog post? The (Human) Architect?

The architect, as we have seen above, plays a variety of roles, but I think I did not present his biggest contribution to a software development project: to act as a human interface between development team members and managers so they can all together create invaluable software for their users, while promoting the adoption of technical practices to developers and working with management to shrink the gap with the development team: The Human Architect!