What is a software architect?

What is a software architect? This can be a confusing question, for plenty of reasons. One complication is that architects often operate in environments where they do not have the proper authority. Architects in these environments will then understandably tend to focus on the problems over which they have some direct control. As they continue to do this, the commonplace definition of an architect changes, such that you will find architects who begin to believe their role is entirely isolated to the abstract.

The truth however is that while an architect must produce an abstract system design, they must also have a role in the events that occur both before and after this design. Before the design, an architect needs to be involved in requirements selection. I rarely see this occur, but it is incredibly important.

Since an architect’s primary role is to develop the abstract system design, they are in the best position to quickly assess the feasibility of any requirement. Even more importantly, the architect is in the best position to observe the synergistic or conflicting technical nature of multiple requirements. If two requirements both require building the same underlying subsystem, then the cost of developing both is less than the sum of the cost of developing both separately.

After, production of the abstract system design, an architect needs to be directly involved in the realization of those designs through several means. The most basic is through continued guidance in technical implementation and refinement of the abstract system design. An architect should be prepared to field questions from developers, and assist in decision-making, when asked to do so.

An architect also in my opinion should be involved in the development of the architecture. To me, the architecture is not the abstract system design, but the expression of that design. It is not as big as the entire system, but it is an integral and inseparable part of it. Much as all buildings have an architecture, so does every application even if not formally designed. It is however ordinary to call the architecture design, “the architecture”.

Therefore, when I say the architect should be involved in the development of the architecture, I mean he should actually create some of the code for it. Unlike every other activity of an architect, the purpose of coding, as an architect, is not to support the developers, but to support the design. Interacting with your design by implementing and utilizing it will always provide useful feedback.

I often see the argument that building architects do not build buildings used to refute this statement. I have three issues with this argument. One is that while a skyscraper architect may not ever build even part of a skyscraper, I think you would find almost all architects have physically built things of a smaller scale. The process of building, even at a smaller scale gives the architect an insight into the actual process of building.

The second issue is that a building architect will usually inspect a building as it is being constructed, and again afterwards. This process provides valuable feedback which when combined with experience with building smaller objects, comes close to the experience of actual participation.

The third issue is the demands and principles of building architecture are far more stable than software architecture. Thus for a building architect, experience with other projects is more lasting, and feedback from the current project while critical, is less so.

So yes, in the software world it is possible for an architect to get similar experience by coding outside the scope of the project, and by inspecting the system. There are however complications to this approach.

Because the underlying demands and principles change more often, it is necessary to insure that coding endeavors are relevant to the current project. Proofs of concept projects are one method to do this outside of a project, but working within the project will do an even better job of ensuring relevance, so long as the architect focuses on architecturally significant parts of the project, and not minutiae.

In addition, while it is possible to inspect the system code, this is a large part of the overall investment in coding, leaving little gain from not participating.

Another role of an architect is the resolution of technical conflicts that arise between two developers, between developers and requirements, and between developers and design. This is where the issue of authority comes into play, and is an area I have found to be lacking. Except for the area of conflicts between development and requirements, the architect is the individual in the best position to weigh all the trade-offs. When requirements are involved, architects still have a key role, in assessing overall technical impacts.

For conflicts between two developers or a developer and design, the architect ought to have authority. Roles in the best position to weigh trade-offs and choose the best option should be the roles with authority in any given situation. Authority naturally leads to responsibility. Responsibility could be defined as the person you blame, but it really should be the person who exercised authority. It is also important to note the difference between having authority and exercising authority. Choosing not to act is itself exercising authority, by denying it to others, but it is fully possible to be denied the opportunity to exercise authority, while legitimately having a right to.

Somewhat related is the difference of governance and authority. While partially synonymous, governance and authority have different connotations. Governance can be the act of exercising control, and generally implies this, whereas authority is the right to. Since control is such an important topic, these small differences can have surprisingly large impacts. Governance efforts usually attempt to uniformly and consistently exercise control, even when unnecessary. It is much more common to find that individuals or organizations granted authority, exercise that authority much more judiciously.

Architects should strive for this. With a good initial design and a good development team, conflicts that require an architect to exercise authority, should be uncommon. Over application of authority will devalue the efforts of others without positive effect.

As well, application of authority based upon insufficiently complete information will lead to poor decisions. However, when conflicts occur decisions are required, preferably quickly. When data is less complete, the data should be a guide, or tool, rather than the deciding factor. Strict governance based upon strict rules will rarely exceed the performance of heuristic evaluation unless a very complete and descriptive set of data and rules exist. Attempting to lock-in the result of rule-based analysis prematurely is a formula for disaster. The results of rule-based analysis however can provide great benefit in the form of suggestions, if lock-in is avoided, even when data is of low quality. Since as a general rule we are very far from complete measurement, I prefer to avoid strict governance.

So to sum up, for me an architect is an individual who creates and maintains the abstract system design. An architect also must provide guidance based upon that design, both before fully detailing it, and after. Lastly, when conflicts arise that are subjective only to the constraints of the system design, it should be the architect who has the authority to give resolution.