What Makes A Software Architect?

Many roles in software development tend to be mislabeled as “architects.” Although these roles are just as vital, using incorrect definitions can lead to miscommunication and unrealistic expectations.

As I work with companies on their digital transformation initiatives, I engage with many software architects, both in those companies and within GlobalLogic. I see many people with the title “architect” who are not what I would call an architect—they actually perform other, distinct, functions. Many of those functions are vital, and saying these people are “not architects” is in no way meant to disparage them or their role. But if everyone is called an “architect,” it certainly makes things confusing.

This confusion is wide-spread. If you search for “software architect definition,” you will see many alternatives that I believe are useless or, at the least, very confusing. Many of these definitions involve creating technical standards, planning projects, and doing other activities that are, in my view, not at all central to architecture itself. It’s not that architects can’t do these things, but you can still be an architect and not do them at all. Let’s take a look at a pragmatic definition of an architect.

In my view, a software architect is a person who figures out how to solve a business or technical problem by creatively using technology. That’s it. Under this definition, many people perform architectural activities, including individual software engineers. In my opinion, engineers are indeed doing architecture when they sit down and think about how they will solve a particular problem, before they start work on actually solving it. It may be “low level” (i.e., tactical) architecture as opposed to “big picture / high-level” architecture, but it’s still architecture.

The difference between an engineer and an architect is their focus: an architect spends the bulk of their time thinking about “how” to solve problems, while the engineer spends most of their time implementing solutions. Being a software architect is not necessarily a question of capability; it’s a question of focus and role.

Traits of a Software Architect

Solves Problems

The most important characteristic of an architect is the ability to solve problems. The wider and deeper the range of these problems, the more senior the architect (in terms of skill—not necessarily years). Some architects focus on network issues, physical deployments, business domain decomposition and “big picture” architecture, integration with existing systems, or even all of the above. But regardless of their focus, the principle task of an architect is to determine a good solution to a problem. It’s not to supply information, coordinate other people, or do research—it’s to describe the solution. The output of an architect is a description or roadmap saying how to solve a problem.

Focuses on “How”

Smart people often have an aversion or even disdain for spending very much time on thinking about “how” to solve a problem. Instead, they want to jump immediately into solving it. This is either because the solution seems obvious to them or because they don’t realize there is value in focusing first on “how.” I remember having this attitude myself in grad school when I was asked for a “plan of work” to solve a particular physics or math problem. I would generally solve the problem first, and then afterwards explain how I did it, presenting my reverse-engineered activity list as the “plan.”

Either because my brain has slowed down, or I’m more experienced, or I’m dealing with more complex problems now—or maybe some combination of all three—I’ve come to value the “how.” In software, there are always many ways to solve a given problem. Of those possible solutions, more than one will generally be a “good” solution. The reason that we separate the “how” from the implementation itself is to give us space to craft and choose among these good solutions, and to examine and reject the bad ones.

Thinks Holistically

To deliver a good solution, an architect must first holistically understand the problem. Problems always have business impact, although frequently they are positioned as purely technical problems. An architect needs to understand the context of the problem they are solving before they can provide a good solution. This requires drawing people out, often for information they don’t necessarily realize they even have or need.

A good architect needs to be a good listener and relentless in tracking down not just what the problems are, but also “why” something is a problem or an opportunity. Since the non-technical side of the company may have little insight into the business impact of a technical decision, it falls to the architect to assess and communicate these impacts in order to choose a good solution.

Uses Technology Creatively

Not every good architecture is novel. In fact, a solid, tried-and-true solution to a standard, recurring technical problem is nearly always better overall (in terms of development and maintenance costs.) than a “creative” approach that is different for its own sake.

That being said, after working with literally hundreds of system architectures over my career, I can’t think of a single one that does not have at least some novel features. This is because the combination of the current situation and constraints, the business requirements, and the technology options available to us at any given moment in time form a large and evolving set. In fact, the number of variables is large enough that their values are rarely the same twice. This gives ample room—and need—for creativity, even when you are not setting out with a goal to be novel.

Architects within established companies have the additional challenge of being thoroughly familiar with their existing system(s). This can naturally incline them toward an evolutionary approach. In their case, the need for creativity often involves the ability to see their current business with fresh eyes; in particular, applying novel techniques to current problems and opportunities, in cases where these approaches provide genuine business or technical value.

Makes Decisions

A primary hallmark of a software architect is their ability to make a decision about which solution is the best fit for a specific business or technical problem (even if that recommendation is ultimately not accepted). While sometimes the ultimate decision-maker does have the title “Chief Architect,” they can often hold the title of “VP/SVP/EVP of Engineering,” “Chief Product Officer,” or some other executive nomenclature. There is nothing wrong with this as long as the person making the decision realizes that they are now acting in an architectural role, not in a purely management / political role. Considering the cost, feasibility, and team preferences and skillsets of a given choice is indeed an architectural function — and can be a good way of deciding between alternatives when they are comparable technically.

Where executives get into trouble as architectural decision-makers is when they choose or introduce a technology that is not technically suitable to the solution of the problem, or that is not nearly as good as the architect-recommended options. For example, I once witnessed an executive override the recommendations of his architects and choose a totally inappropriate technology because he had already paid a lot of money for it. This executive did not appreciate the fact that the success of his project required him to play an architectural role, not a political or managerial one, when making this technology decision. The implementation of his program suffered accordingly as the team tried to work around the limits of an unsuitable technology.

Roles Mislabeled as “Architect”

While architects play a key and often pivotal role in software development, there are many other essential roles to software development. However, I would assert that calling those other essential functions “architects” leads to a lot of confusion and mis-set expectations. Here are some of the other roles who are often labeled as architects but who, in my opinion, often perform non-architect roles.

Researcher

This person surveys the available technologies and approaches within a given area and becomes very knowledgeable about the alternatives through online and offline research, conferences, and vendor presentations. While architects definitely spend time doing research, the fundamental difference between a researcher and an architect is that the architect decides. Researchers provide an essential function, but unless they apply the outcome of their research to a specific situation and ultimately make a specific recommendation as a result, they are not acting in an architectural role.

Evaluator or Analyst

An evaluator / analyst takes the results of research and compares the leading candidates to each other. He or she produces a list of pros and cons for the various alternatives, in the context of the current business or technical problem. Evaluation is also an activity that architects sometimes perform and are even more frequently called on to organize. Again, however, the key differentiator between an evaluator / analyst and an architect is that the architect ultimately makes a choice or single recommendation as a result of these evaluations.

Technical Expert

This person may be a researcher, an evaluator / analyst, or a combination of the two. They are extremely knowledgeable about the range of options available in a particular domain or technology, as well as the pros and cons of each. This particular skillset is often termed a “solution architect,” although again I would assert the word “architect” for this skillset is a misnomer. Knowledge of a given range of solutions or technologies does not in itself make someone an architect. It is the ability to apply such knowledge to a specific situation and to craft a good solution that characterizes an architect. Even with full knowledge of the available options, the ability to make good choices from them is a different skillset (and is rarer than at first it might appear).

Technical experts are extremely valuable, and they may indeed also be architects. However, there are many cases where technical experts are not architects, even if they have that title. This can be quite confusing, and can show itself as “churn” with no clear outcomes and decisions being made despite a high degree of knowledge in the room.

Knowledge Orchestrator

An important function in a complex project is “knowing who knows what” — that is, identifying the right people and getting them plugged into the right places. These people might be architects, researchers, analysts, technical experts, or any of the myriad technical roles that make a software initiative successful.

It’s sometimes hard to distinguish between a “knowledge orchestrator” and an architect because both have decision-making roles. The key distinction is that the knowledge orchestrator is not the originator of the technical ideas (i.e., they are not the person proposing the solutions to the various technical problems). Rather, they are a clearinghouse for information and perhaps also selects and synthesizes the information provided. In other words, they are the “critic” rather than the “author” of the work.

Performing knowledge orchestration successfully requires a high degree of technical skill, the ability to make clear and sometimes tough choices, and the ability to explain and defend those choices. However, I would argue that this role is distinct from an architecture role. As we discussed above, an architect is the person who originates a proposed solution; the knowledge orchestrator role serves as an editor and critic of the proposed ideas.

Architects often play a knowledge orchestration role over more junior or more specialized architects. The distinction here is whether they also initiates novel solutions. There is a Scrum parable that talks about a pig and a chicken who together decide to make a breakfast of ham and eggs. The pig turns to the chicken and says “If we do this, I am committed. You, on the other hand, are merely involved.” In terms of architecture, the knowledge orchestrator is “involved,” while the architects are “committed”.

Conclusion

There are many non-architect roles in software development (e.g., project managers, developers, testers, product owners), but these do not tend to be mislabeled as “architects.” There is, of course, nothing wrong with not being an architect. I myself often play the role of a “knowledge orchestrator” instead of—or in combination with—acting as an architect. I also act as a knowledge provider from time-to-time. In no way do I feel “inferior” in any of these roles than I do when working as a hands-on architect. The roles are simply different. In this essay, I am simply challenging the labels, not the value.

Note also that architecture itself is a “team sport.” It’s very rare in business that a single architect owns every decision unchallenged. Almost invariably an architect works with others and must persuade them—as well as management—of the correctness of their choices. This dynamic is generally healthy, and it often results in a better outcome than any single individual could accomplish unaided. The need to “sell” their choices in no way diminishes the imperative for an architect to make a choice. In fact, a strongly reasoned position that is defended vigorously (but impersonally) often leads to the best outcome. Without these opinionated selections, a person is acting as an information resource, not as an architect.

Architects tend to be exceptional people, but so can people cast in other roles. The best architects are smart, good listeners, not afraid to take risks, not afraid to be “wrong,” and always seeking to learn. Whether you are an architect or play any other part in the software development process, these are traits that all of us can seek to emulate.