It may be that in the software development and engineering industry, some of the least well treated (and least well understood) concepts are those of a project’s architecture and the role of the software architect. In those areas, confusion, contradictory views, and a somewhat impractical vision often prevail.
In fact, the very concept of software architecture is interpreted in many ways (as many as the evolution of how projects are approached over the last few decades, I would say), which creates even more debate and a lack of clear consensus. The little literature that exists on the subject focuses more on architecture patterns than on the real role of an architect within an organization, when the work of one renowned author contradicts that of another equally praised one.
To make matters worse, there is also a naïve belief (encouraged by the flawed culture of many organizations) that being a software architect is a step up the corporate ladder (more prestige, better salary, etc.), which is why many developers react viscerally to accepting someone in that role when they understand that their work will be more or less conditioned, defined, and constrained from the ivory tower of an architect.
But it does not have to be that way.
In The Black Book of the Programmer, I dedicate a light chapter to this issue without going into much detail, under the title “The Misunderstood Role of the Software Architect”. Unfortunately, a significant part of my experience with architects has been rather a disaster, and I say that without negative intent or any desire to settle scores, because I have also taken on that role myself in recent years in the products I have led and the projects I have been in charge of.
It is a delicate and controversial topic because there is no formal definition. I encourage you to search for one; you will soon realize there are as many as there are personal opinions. So much so that in different organizations we can encounter this role with completely different responsibilities, or teams that call themselves agile and believe that no architectural vision is needed for the products and projects they design. Or we find the developer who has been promoted and, because of that, believes their decisions will be better than those of their former department colleagues.
On the other hand, I have to say that it is possible to be agile and, at the same time, need a defined architecture, and this is not a contradiction (at least not in the terms I am about to explain).
To complicate things further, old practices on how software development was approached decades ago still persist in the collective unconscious of the so-called architects. For many, anything related to architecture has to be associated with UML diagrams as thick as they are useless, which explain little, and structures in which all development must necessarily fit (just memories of a dinosaur era in which software was developed in a totally different way but which still remain), becoming more of an obstacle than a help. In other teams (and I have crossed paths with them at some point in my career), they simply ignore that the concept even exists: the software is developed monolithically and deployed however it can be, and that’s it. Sometimes design is even confused with architecture, which is also very common.
Perhaps precisely because of all this, I have not written much about it until now (or I have not dipped my toes into the issue, to be honest), because it is a concept very prone to misinterpretation and even capable of accumulating power in certain corporate environments. Nevertheless, below I am going to make some clarifications that I hope help provide a clearer idea of what, for me, a software architect is, and which I have been fortunate to see confirmed by authors with more experience than I, such as Simon Brown and George Fairbanks.
The software architect is not a position, but a role.
I have spent many years leading development teams, and I always say the same thing to my colleagues: I am not anyone’s boss; I simply have the role that corresponds to me, and my job is to help theirs be done as well as possible. In the same way, a software architect cannot hide behind a title, but must assume an active role with specific functions and responsibilities. This is why they are not a better professional simply because they hold that role than a developer. The only thing that matters is how they are valued within a company, but in my opinion the only things that should be measured economically are experience and the value of what they contribute.
A good architect does not live in an ivory tower, but also programs.
Software development is not like other professions; we cannot follow the analogy of building architect / foreman / bricklayer, etc., because an architect may never have touched a brick in their life. However, in software, an architect must have developed a lot of software throughout their career, and ideally in as many different projects as possible.
In fact, abandoning the role of developer and dedicating oneself only to architecture probably distances you from the place where you are most useful. For me, a good architect must necessarily remain involved at the code level in the project.
The architect knows the domain perfectly.
The architect must know perfectly what the client needs or the business universe that is going to be modeled by the system they intend to build. How else are the most important architectural decisions going to be made?
Risk management: an architecture is not always necessary.
The rule is simple: the larger a software project is and the longer its life cycle (years), the more necessary the architectural perspective becomes.
A small project does not need the role of an architect.
In other words, there is a direct relationship between risk management, project size, and long-term projection.
Deployment IT architecture is often confused with the architecture of a product or project.
In certain environments, I have seen these two things conflated. The architecture of a software system is not the same as the IT deployment architecture of the final system to be developed, although they are related, obviously. If we know the deployment will be done on an IT cloud infrastructure, or on a single server, the proposed architecture may change.
A bad architecture (or lack of one) can cost a lot of money.
I have seen this in practice on several occasions: design decisions that seem small at the beginning but end up costing a lot in maintenance, change of requirements, complex integrations, or fragile deployments. In projects that grow and evolve, a poor structural choice can turn the product into a high-operating-cost machine, with errors that are hard to debug and a greatly reduced ability to evolve.
There is no conflict between agility and defining an architecture at the beginning.
That is true. Read it again if this statement shocks you at this point. As I often tell myself, the virtue lies in the middle ground.
For some reason, perhaps because of the overuse in past years of anything that smells of architecture, teams that defend agility dogmatically see it as an aberration to propose one, believing incorrectly that it will emerge. What is not understood is that what emerges is, at best, the design, and that architecture goes far beyond defining boxes, drawing lines, and interactions between functional parts of the project.
Some points of the agile movement have been misinterpreted, I fear; from the perspective of the concept of architecture as the vision and structure of a software system, what emerges is the design of the components or software pieces that compose it, not that broader framework. Again, perspective is lost when one believes that a 10 KLOC project should be managed and grow the same way as one with 100 KLOCs.
Architecture also consists of identifying risks.
An architect guides, documents, proposes, helps the rest of the team, etc., but is also capable of identifying the risks that certain decisions may present: choice of technology, third-party licenses, single points of failure, etc.
UML is not essential to document an architecture.
The abuse of UML diagrams (costly to produce and, over time, proving to contribute little) has created a certain atmosphere against this modeling approach, or at least against the justification of unproductive work by those who create them; or the false belief that those diagrams directly reveal relationships between classes in a solution, and so on. Those of us who have been in this profession for several decades have likely lived with that burden and discovered that it is a very impractical approach.
Nevertheless, I am not saying they have no utility. What I am saying is that, from the perspective of the vision and structure of an architecture, the purpose is to communicate in the simplest possible way, not necessarily with pages and pages of use cases whose only purpose is not to help developers understand what needs to be done, but rather, I fear, to inflate the documentation.
Any diagram has a purpose: to communicate what is being modeled. In this context, simple diagrams with boxes and lines may be more than enough.
Architecture should be expressed simply: the C4 model.
Context, containers, components, and classes. The C4 method is a simple and eloquent approach for modeling practically the architecture of any software system, because what is a software system, in the end? It can always be modeled with those four concepts.
Note: by containers I do not mean anything related to Docker or similar technologies. We are talking about modeling architecture as the structure that supports everything else, not about defining workflows and use cases, etc.
We return, perhaps, to the vanity of some who consider themselves software architects: perhaps unconsciously, because they were educated to believe that architecture must be something very weighty, they try to make something simple more complex with pencil and paper to justify a position within the organization.
The main function of an architect must be, above all others, to communicate well to the rest of the team. End of story.
What, then, is the architecture of a software project, or what should the role of architect cover?
A good architecture only aims to communicate (I insist: communicate) in the simplest possible way the structure and vision of the system to be built so that all members of the team (developers, QA, testers, etc.) can share and understand it. Nothing is worse for a developer than not knowing why and for what they are doing what they do. And the same is true of locking in that vision and structure: it can also change over time, as the project advances and retrospectives are held.
So what is the difference between architecture and design? The first deals with structure and vision from a global perspective of the system and its big decisions (technologies to use, functional division, risk detection, homogeneity, etc.), while the second is tied to how the code is implemented.
To do that, a good software architect must have multidisciplinary experience to:
- Understand the objectives, challenges, universe or domain of what is to be built, the requirements (even if they change), and the constraints.
- Code: the architect must also be able to get involved in programming tasks, but not necessarily be the best developer.
- Design software: they must be able to understand design strategies based on good practices, design principles, and make them consistent throughout the project.
- Identify the risks of the decisions taken.
- Ensure quality: they must guide the rest of the team so that the desired quality parameters are maintained.
- Guide the team: they must have soft skills to communicate well, help, mentor, and even lead team members.
In other words, the architect must also be a guide, capable of transmitting the overall vision of the product and the project goals, because, as we know, software development is a highly collaborative activity.
In my opinion, only after covering the above can the architect suggest architecture patterns such as CQRS, Service Bus, event-driven systems, etc. All of these architecture patterns are ways of solving certain problems, but their simple choice is only a part of the role of the architect.