Who needs an architect?

Disclaimer: Article by Martin Fowler was published in 2003

in the IEEE Software magazine. In the network (but not on Habré) there is a wonderful translation of five years ago by Sergey Teplyakov ( SergeyT ).

Recently, I met a clearly irritated colleague, Dave Rice, in the hallway. My introductory question caused a sharp statement: "We need to ignore any candidate who has the item" Architect "in the resume." It was embarrassing in this strange phrase that we ourselves, as a rule, present Dave as one of our leading architects.

The reason for his “title psychosis” was the fact that by the standards of even our industry, the meaning of the words “architect” and “architecture” is extremely overvalued. To many, it seems that the term “software architect” is perfectly suited to that smug and all controlling image from the final scenes of “The Matrix: Reboot”. But even in companies with great contempt for such a display, it doesn’t matter that there is a vital role of a technical leader, essentially an architect, such as Dave himself.

What is architecture?

When I was tormenting myself about the title of the book “Architecture of corporate software applications” (Patterns of Enterprise Application Architecture Addison-Wesley, 2002) , each of our reviewers agreed that “architecture” was right in the title. However, we all had difficulties with trying to define this word. Since this was my book, I felt I had to get rid of this concept.

The first impulse to get away from the ambiguity was to hit the cynicism. In a sense, I defined architecture as a word that we use when we want to discuss design, trying, at the same time, to give it more importance. (Yes, the same can be applied to architects). As it often happens, however, a drop of truth is found in any spill of cynicism. Understanding came to me after reading a message from Ralph Johnson from the Extreme Programming mailing list. The correspondence was so good that I will bring it here completely.
')
The previous message said:

RUP, based on the IEEE definition, describes the architecture as “the highest level concept of a system within its environment. The architecture of a software system (at a given point in time) is its organization or structure of important components that interact through interfaces, where each component is assembled, in turn, from even smaller components and interfaces. ”

Johnson replied:

I was a reviewer of the IEEE standard mentioned, and argued, to no avail, that it was entirely a fake definition. There is no high level system concept. Users have their own vision of the system, which differs from the way the developers operate. Users generally do not care about the structure of important components. Yes, perhaps architecture is the highest-level view of the developers about the system within the environment. But let's forget about those developers who have access to understanding only a small area. Architecture is the highest-level representation of a system by expert developers. What makes a particular component important? It is important because the expert said so.

Thus, the best definition could be: “In the most successful software development projects, the most highly skilled developers working on this project have the same idea about the design of the system. Such a joint understanding is called “architecture”. This understanding includes how the system is divided into components and how these components interact with each other through interfaces. These components are usually composed of smaller parts, but the architecture includes only those components and interfaces that are immediately clear to all developers. ”

Such a definition could be better because it becomes clear that architecture is a social construct (yes, the software itself, too, but the architecture is even more so), because it depends not only on software, but on which parts of software are recognized important as a result of the group’s agreed views.

There is another way to define an architecture, like this: “architecture is a set of decisions that must be made at an early stage of a project”. I also criticized this option, pointing out that the architecture is the decisions that you would like to make right at the very beginning of the project, despite the fact that it’s not a fact that they will be more successful than any other.

In any case, by the second definition, for most projects, the programming language will be part of the architecture, but not by the first.

Whether anything is part of the architecture depends entirely on whether it is regarded as important by the developers. People who create "corporate" applications consider persistence critical. When they begin to outline the architecture, they immediately receive three levels. Mention something like "we use Oracle as our database and create our own storage layer to display objects in it". But a medical imaging application can include Oracle technologies without considering them from an architectural point of view. This is because the greatest difficulties for them are in image processing, and not in storage. Receiving and saving images is provided only by a small part of the application and most developers simply ignore it.

This is what makes it difficult for people to explain how to describe architecture. "Tell us what's important here." Architecture is about important things. To under them is not meant.

The role of the architect

So, if architecture is about important things, then an architect is a person (or group of people) who cares about important things. And here we come to the essence of the difference in the type of architect from "The Matrix: Reset" with the style that is represented in the person of Dave Rice.

Architectus Reloadus is a character who makes all the important decisions. The architect does this because a unified view is needed to ensure a conceptually coherent system, and perhaps because the architect does not consider team members sufficiently qualified to make such decisions. Often, such decisions need to be made at the earliest stages so that everyone else has a plan to follow.

Architectus Oryzus is a different beast (if you can't guess, try archives.nd.edu/latgramm.htm ). This type of architect must be very attentive to what is happening in the project, looking for important issues and solving them before they become serious problems. When I observe an architect of this kind - I see that the most visible part of his work is intensive cooperation. In the mornings, such an architect programs together with the developers, looking for the most common “locking” code. During the day, this architect participates in requirements definition meetings, helping explain requirements technical implications of some of their ideas through non-technical concepts, such as development costs, for example.

In many ways, the most important occupation of Architasus Oriusus is mentoring for the team, raising it to a level where it can solve more complex issues. Increasing the team’s ability gives the architect a much stronger lever than the position of a single manager, which in turn helps to avoid the danger of becoming a project’s architectural jam. This brings us to a rule of thumb: the value of an architect is inversely proportional to the number of decisions he or she makes.

At a recent ThoughtWorks retreat, I discussed the topic of architects with some of my colleagues. It seemed to me interesting that we quickly came to a consensus about the nature of the position, bearing in mind Architectus Orizus, but now it was not easy to pick up the name for him. Arkitektus Rilaudus is too familiar to us to be counted as “architects”, and, moreover, is based on an incorrect metaphor (see here ). Mike Two (Mike Two) suggested the best name I’ve heard: conductor , in a climbing sense. The conductor is a more experienced and skillful team member who teaches the rest of the group to cope with the dangers on their own, and at the same time, always turns out to be close by in especially difficult cases.

Getting rid of software architecture

I like to write provoking headlines, the best of which, as in this case, contain an important, but not always obvious from the beginning, meaning. Recall the second definition from Johnson: "Architecture is the decisions that you would like to make without mistakes in the early stages of a project." Why do people think that some moments need to be solved correctly at the very beginning of the project? The bottom line is that they obviously find these items too complex to change in the future. Those. as a result, we can rephrase the definition of architecture as "elements that people find difficult to change in the future."

Common in building an enterprise application, for example, is considered the need to determine the database schema from the very beginning. Because it is really difficult to change the base scheme, especially if the application is already in use. In one of our projects, the database administrator Pramod Sadalaj (Pramod Sadalage) came up with a system that allowed us to change the scheme (and transfer data) without problems (see here , and here is the translation ). Having done this, he eliminated the database scheme of their discharge of architectural elements. I find this solution wonderful, as it allowed us to better cope with the changes.

The economist Enrico Zaninotto (Enrico Zaninotto), in a delightful speech at the XP2002 conference, presented the main ideas behind the idea of ​​agile in manufacturing and in software development. One point that seemed particularly interesting to me was his comment that irreversibility was one of the primary factors that led to complexity. He considered agile methods in the industry and software development industry as a paradigm shift in the search for ways to combat irreversibility, as opposed to trying to get rid of other prerequisites that lead to entanglement. I believe that one of the main tasks of the architect is to get rid of architecture, finding ways to prevent irreversibility in software design.

And back to Johnson, this time I give the answer to my letter:

One of the differences between building architecture and software architecture is that many building solutions are very difficult to change. It is difficult, although still possible, to return to the beginning and change the basement.

There are no theoretically justified reasons for considering anything difficult to change in software. If you select any particular aspect of the software, it’s easy to change, but the difficulty is that we don’t know how to make it easily fixable all at once. Attempts to make something easily changeable complicate the whole system a little, and attempts to make everything changeable cause the whole system to become very complex. Confusion is what complicates software changes. This is a duplication.

The essence of my remark about Aspect-oriented programming is that we already have fairly good ways of isolating aspects of programs, we have, but we do not use. I do not think that the real problem will be solved at the expense of the best techniques of highlighting aspects. We do not know which aspects should be distinguished, we do not know when they are worth a separate consideration, and when not.

The software is not limited to the physical laws of the world as the same buildings. It is limited by imagination, design, organization. In short - it is limited to human properties, not the characteristics of the world. "We met the enemy, and he turned out to be us."

Martin Fowler, Lead Scientist at ThoughtWorks