Are You an Architect?
Do you share this view of the definition of a software architect? Let us know in the comments.
Join the DZone community and get the full member experience.Join For Free
Over twenty five years ago, in 1992, at an OOPSLA workshop in Vancouver, Kent Beck, in answer to the question, "What is an architect?" said, according to Philippe Kruchten, that it is "a new pompous title that programmers demand to have on their business cards to justify their sumptuous emoluments." Not much has changed since then. There is a big difference between a smart programmer and a project architect. Here is a list of traits that I believe a good architect has.
She/He Is Loyal
Programmers come and go. They are, as I mentioned many times before, egoists with a strong focus on their personal profit. They change projects, they work on multiple projects at the same time, they have no personal attachments to any piece of code. They worry only about their individual tasks and feature branches. Is the branch merged? All bets are off. Professional developers are "polygamous" and disloyal.
An architect, however, is a different creature. She/He stays with the project even after it runs out of funds, loses the last programmer, and proves that the architecture is a total mess that can't handle even a fraction of the traffic it was supposed to work under. The architect stays and says "No worries, we'll get through no matter what!" How to find such a person and how to motivate her/him are different questions, maybe for another article.
She/He Is Disciplined
Design patterns, quality of code, static analysis, unit testing, high performance, reliability, security, and even maintainability are all very important things to worry about. However, a good architect knows that all these can be resolved and achieved by programmers if they are properly hired, motivated, organized, and controlled. How to hire, motivate, organize, and control them — that's what a good architect worries about.
She/He knows that process comes first, people next.
However, this is not what most software experts think. For example, according to Alistair Cockburn's articleAgile Software Development: The People Factor published in IEEE Computer in 2001: "If the people on the project are good enough, they can use almost any process and accomplish their assignment. If they are not good enough, no process will repair their inadequacy-'people trump process' is one way to say this." It is acceptable if a programmer thinks like that, but not an architect.
An architect puts discipline on top of everything else, constantly inventing new rules and enforcing them. Moreover, she/he is not only making others obey but also following the rules herself/himself. Here, for example, are the rules to enforce:
Each project has its own set of rules. The list above is a subset of what we have on our projects at Zerocracy. A good architect thinks about the rules first and about the architecture second.
I totally agree with Len Bass that "the architecture should be the product of a single architect," as he said in his book Software Architecture in Practice. The question, however, is how exactly the architect will create the product: either in solo mode, making all technical decisions alone, or letting the team contribute in an organized and disciplined manner. The former is easy but less effective, and the latter is way more difficult but leads to much stronger solutions and better team synergy (I hate this word, but here, it fits well).
She/He Is Strong
Matthew McBride said in his article, The Software Architect, published in CACM in 2007, that "Without strong supervision from the software architect, projects and attempted solutions tend to fall apart due to the weight of unmitigated complexity." The word strong is what is important to emphasize here.
What does strength mean in this context? An ability to stay in the office two days straight with just pizza and cola? An ability to multiply six-digit numbers in memory? An ability to memorize the purpose and design of all classes and methods? An ability to stay in a meeting with investors for three hours without checking Facebook even once? Not likely.
The strength of an architect is in the ability to say "No" when it's difficult to do so. For example:
- "No, I will not merge your pull request."
- "No, we will not implement this feature."
- "No, you do not deserve a promotion yet."
- "No, your code is not as good as we expect."
- "No, this build is not stable enough to be released."
- "No, you will not go on vacation this month."
There are many other instances of "No," which can easily turn an architect into a hated figure, but this is what her/his job is: to be the "bad guy." This is why she/he has to be strong — to handle it all calmly and continue leading the project forward, toward her/his own well-defined technical goals.
She/He Is Abstract
Abstract thinking is a very important positive trait of an architect. Programmers may lack that since they are mostly focused on their own isolated tasks. An architect must think globally and see the product as a whole. Details are less important. She/He must rely on her/his people when talking about details.
She/He Is Social
Software is a product of people. No matter how great the architect is, if she/he can't find the right people to implement her/his ideas and to bring back new ideas, she/he is doomed to fail. The key quality of the architect is the ability to work with people: recruit, motivate, and control their results. Social skills are what an architect needs in order to be successful in that, especially in finding new programmers and engaging them on the project. What exactly does this mean? Well, here are some examples:
- High visibility in social networks
- A long list of previous projects and teams
- Active membership in professional groups
- Publicity in the blogosphere
She/He Is Brave
A good architect says many times a day: "It is my fault." If an architect doesn't have a habit of saying that frequently, she/he is not a good architect. She/He is just a programmer who is afraid of responsibility and authority.
The golden rule of a good manager is: "Success is yours, faults are mine." This is the attitude a good architect has to express to her/his team. When they win, she/he will always find a way to celebrate and reward them. When they fail, she/he will take full responsibility for the failure. Because it's her/his team, she/he found them, she/he motivated them, she/he controlled them, and she/he didn't punish them properly. That's why they failed. First of all, it's her/his fault.
What will she/he do with this fault is a separate question. Maybe she/he will train and coach someone, maybe she'll/he'll enforce some rules more aggressively, maybe she/he will even give someone her/his card. It's up to the architect. But for the outside world, she/he will always be the guilty one and the team must know that. If they know that, they will do everything to not let the architect down.
She/He Is Simple
"Simplicity is a great virtue," said Edsger Dijkstra in 1984. For a programmer, it's a virtue, for an architect, it's a survival skill. An architect who can't explain her/his ideas in simple words, easily understood by other programmers, is not an architect. No matter how smart she/he is, no matter how bright her/his ideas are. If they can't be delivered in a simple form, they are worth nothing.
"If I don't understand you, it's your fault," said Yegor Bugayenko in 2015. A good architect remembers that.
She/He Is Coding
Anthony Langsworth in his piece Should Software Architects Write Code? argues in favor of code-writing architects and in particular says that "Understanding code means the architect can use his or her judgment more effectively rather than rely on which developer is more persuasive." Indeed, an architect that is only capable of talking and drawing is a weak architect that will sooner or later let the team and the project down.
How much code the architect has to write depends on the age of the project. When the project is young and is still in the phase of prototyping, the architect produces the majority of the code. Then, later, when the product matures, the architect steps away and mostly reviews the contribution of programmers. Eventually, when the project migrates into the maintenance phase, the architect may quit the project and transfer her/his responsibilities to one of the programmers.
She/He Is Ambitious
An architect does want to get something in addition to money. She/He wants to be the smartest person in the room, she/he wants to solve complex tasks nobody else has been able to solve before, and she/he wants to save the world. She/He wants all of that to be appreciated and rewarded. She/He wants to be number one. In most cases, she/he fails miserably, but she/he always gets back on her/his feet and tries again. Look for the person with ambitions if you want to hire an architect, not just another programmer.
Michael Keeling, in his recent book Design It!: From Programmer to Software Architect(worth reading), says: "On some teams, architect is an official team role. On other teams, there is no explicit role and teammates share the architect's responsibilities. Some teams say they don't have an architect, but if you look closely, someone is fulfilling the architect's duties without realizing it. If your team doesn't have an architect, congratulations, you've got the job!"
Michael's point is that the architect's position is rarely given to someone voluntarily. Instead, an architect has to fight for it and demand it. Sometimes even going straight ahead and saying, "I want to be the architect!"
What is important is that it will not sound like, "I want to architect this." That would be the voice of a programmer, not an architect. An architect wants to be a person of power, not just a smart technical engineer. So, it's way more about a title for her/him rather than just her/his actual responsibilities.
She/He Is Expensive
Yes, the money question again. A good architect is expensive. If she/he is not, she/he is not a good architect.
Published at DZone with permission of Yegor Bugayenko. See the original article here.
Opinions expressed by DZone contributors are their own.