fantasies of colleagues and harsh reality
But what if an architect breaks into this system? What are its tasks? Go to the cut and I’ll tell you everything. And then send the post to your colleagues if they don’t yet understand what you do as a team.
It happens that an architect joins a new team and his colleagues greet him coolly. After all, they lived normally without him before. For example, my case: I tried to collect information about the system, but they refused to communicate with me: they were afraid that I would harm the project. I proposed solutions, set tasks, and my colleagues said that they knew the system and technology better, and they did not need someone new. Hours were spent explaining their role and defending their objectives. It took three months to get used to this team.
For the team to trust the new architect, the manager and fellow developers must understand the architect's role on the team. Next, I will analyze several opinions that I most often heard about my work.
Opinion 1: An architect is a technical writer. So, let him write down what they tell him
Opinion: “The main artifact that an architect produces is a document with text. If a person is new to the team, then he does not know the system. And he can only write down what is dictated to him. And if he writes for someone, then he is a technical writer.”
What it really is:
The whole point is in the content and purpose of architectural documents. An architect designs a new system based on what he has been told about an existing system. And he tries to smoothly and accurately integrate the “new function” house into the long-built and commissioned “existing functionality” block.
Nuances:
For example, the system already has a function for reading products available for purchase, implemented using one method. Let it be method 0. The system contains product identifiers, otherwise the method does not work: here we have bread, milk, apples. But the price of the product is not indicated, but according to the new requirements it should be. You need to make a decision:
Improve or change the existing method so that it takes the price from the database and displays it. Let's call this option method 1.
Release a new version of the method. We take all the code from the previous version, add a little new code – and voila! You are beautiful and the price is showing. Let's call this option method 2.
Develop a completely new method. Let him be method 3.
And there are also systems that use code to read information about a product with an identifier, that is, they work with method 0. For example, storefronts of an online store, application, marketplace. And they all need to be notified that the method has been finalized and they need to use it. But systems must learn to accept the response from the updated method.
If we received method 1 or method 3then everyone who contacted method 0 the systems will have to be improved. Otherwise, all these storefronts of the site or application simply will not know how to accept the changed response with the price. Then, instead of displaying the price tag, we will receive an error.
There is an easier option – release a new version of the old method, that is, get method 2. And, for example, some systems will be quickly improved and will begin to display the price, and some (for example, where there are not enough resources) will work on the old version. But none of them will make mistakes.
The architect chooses the simplest option with a version update. This means that we write in the documentation that we are developing a new version, justify the solution and explain how it differs from the old one. But to do this you need to find out what the old method looks like.
Result: the architect asks about existing system functions to ensure high-quality design of new functionality. And not at all in order to simply write down information for someone about what has already been implemented.
Opinion 2. If you don’t write code, don’t meddle in tasks
Opinion: “The architect will not be able to explain the problem to the developer, because he does not write the code himself.”
What it really is:
Let me give you a simple analogy: a wedding coordinator. Future newlyweds can figure out how to organize their wedding themselves: schedule the timing, set up a welcome zone, choose drinks, put together a playlist, and so on. But it is much easier to contact a coordinator: he will take into account the wishes, but will provide for nuances that the couple may not be aware of, and offer the best solutions, take care of the logistics, organization and supervise the performers himself. Newlyweds will not have to be distracted by several tasks at the same time, and they will be able to enjoy their holiday.
That is, the coordinator knows how best to organize the holiday, which team to use, how to distribute tasks and how to control them. At the same time, he does not have to take photographs of the guests himself, stand at the DJ console or pour cocktails for the guests – although it is quite possible that he can do all this. In general, an architect is the same as a wedding coordinator, only from the IT world.
For example, in the documentation, the architect describes the requirements that the developer must implement and decomposes them: he describes the desired result, the teams to implement the requirements, and so on. However, he does not say which lines of code to write, but indicates algorithms and methods. The specific implementation is the developer's task.
Nuances:
I will list a small part of the tasks that an architect performs:
Selects technologies and architectural approaches, especially if a new system is being developed. Clarifies a huge number of nuances. For example, are the selected technologies permitted by law, and do they allow for non-functional requirements? Microservices or monolith? Relational database or not? What is more important – fast reading or fast writing for this particular system and task? Is integration necessary, and if so, what kind?
Defines the categories of data that will be processed in the system. He needs to understand whether they are not regulated by law, whether additional integration with government information systems is required. For example, the architecture of systems that process personal data differs significantly from the architecture of a publicly accessible entertainment portal.
Selects approaches that ensure system availability and fault tolerance.
Defines contexts – external interactions with the designed system or new functionality.
To solve all these problems, design possible solutions and choose the optimal one, extensive programming experience is not needed. Although I myself wrote in different programming languages for many years.
What is important for an architect:
Be able to identify a problem. Question the customer, formulate, clarify whether this is really the problem. And it’s not without reason that they say that a well-formulated question is half the answer. There were cases when a customer described a problem with my help and understood how he could solve it without modifications. Another bonus from such communication: the author of the request understands that his problem is shared, and becomes more loyal.
Be able to make decisions. How? Let's imagine that we have a task. First, the architect looks for dozens of solutions – 15, 20, 40 – as many as possible. The most important thing is that all these decisions must be workable. Then he looks at the requirements and, from a variety of options, throws out those that are definitely not suitable. It rarely happens when a solution is perfect and clearly correct. The main criteria are the fulfillment of functional and non-functional requirements. For example, if information security requirements are not met, the option is immediately sent to the trash. And you can think about some requirements and look for compromises. As a rule, the person who makes the decision agrees with the disadvantages. Therefore, from the remaining conditionally suitable solutions, we must choose the one whose disadvantages we can live with.
Be able to justify a decision to the team. Talk about all the pros and cons, explain why this option is better than other 5-10-20. In 95% of cases the team agrees. And with the remaining 5% there are two ways. The first way is to simply accept that there are dissatisfied people. Especially if it doesn't influence your decision. And here we see another important quality of an architect: recognizing other people’s right to their opinion.
If these people can influence the decision, like, say, a cluster architect, then there is a second way – to try to defend their position. After all, it is the one who worked through the decision who is more immersed in it than anyone else. But if the arguments turned out to be powerless, then we resign ourselves to the fact that the decision was turned down and we need to choose another option. There were situations in my work when I thought that the chosen solution was complete nonsense. But let’s say the team has a tight deadline and will have to do it this way and not otherwise. I may grumble about this decision, but I accept it.
Have a broad range of technical knowledge and use it. Here are the basic design patterns and the technology stack – both within the company and outside, with competitors, and in the market as a whole. An architect must be erudite in terms of professional knowledge. And books, articles, specialized conferences, and meetups help with this. The most valuable source of information is colleagues and their experience. But it’s not enough to collect information—you also need to highlight the basis of the decision.
Let me give you an example from working with telecom architecture. I'm working on a service catalogue. Its task is to describe services. What is a description of services and why is it important, I talked about in my last article. So, if I just make a service catalog information system, it will describe the services fine, but it will not give the company anything. Because the company needs to sell these services, physically ensure the connection of these services to the equipment, and count the facts of consumption of this service from a specific minute, second.
The backbone of the solutionThe one we're looking at is:
To sell, we need to describe what we can sell.
We must be able to connect what we have described to the equipment.
We must be able to count what we have connected.
If we have done all this, the remaining functions can already be superimposed on the base, but not vice versa.
Result: You don't have to write the code yourself to design architecture.
Opinion 3. The architect should not care about what data the system will be filled with
Opinion: “Why does an architect need to know about the data that will fill the system? After all, there is no difference for him!”
What it really is:
Typically, knowledge about the data influences the architecture of the system. Especially if we are talking about personal data, medical information, banking information.
The architecture of the system processing personal data will be complex and secure, with authentication and authorization functions. A public site with stories doesn't need all this. And if the system being designed is a successor to another, then data migration needs to be worked out. And, if necessary, synchronization – if both the old and new systems work together for some time.
All this, of course, influences architecture.
Nuances:
In this option, absolutely all users are allowed everything: any data can be changed, deleted, added. You can introduce yourself as anyone and do whatever you want, no proof of identity is required. These are usually useless applications with garbage data and poorly thought out architecture.
But in this option you will have to go through authentication, enter a password and prove that “I am me.” Although, as you know, “there are different selves.”
Users have their own roles and, accordingly, accesses. For example, only the operator writes data, but everyone reads it. And you won’t be able to pretend to be another user – unless, of course, you know someone else’s login and password.
In this version of the system, a message broker appears. One system notifies another that its data has changed.
I'll explain with an example. There is a directory of units of measurement within the company. If each branch maintains its own separate directory, the information may not match. For example, in one directory SMS are indicated in units, and in another – in SMS, megabytes are indicated somewhere as MB, somewhere – MB or MB. And one branch maintains a directory in the form of a table in Excel, another – in a commodity accounting system, a third – somewhere else. This makes it difficult to find information. To ensure that data is recorded equally everywhere, there are general company directories. And they are filled in, for example, by one department in the master system. And as soon as something has changed in this universal directory, the master system, through a message broker, transmits information to branches, and directories are updated everywhere.
Result:
The architecture directly depends on the data processed in the system. When a newly arrived architect asks about the data model, processes with it, security categories, he clarifies the “foundation” on which new functions will subsequently rest.
Opinion 4. Architect = analyst
Opinion: “An architect and an analyst do the same thing.” I won’t say that they are 100% wrong, but there is one nuance. I'll explain now.
What it really is:
The analyst is responsible for functional requirements. He says what needs to be done. And the architect, in turn, describes the implementation of functions in the form of requirements and tasks in technical language. He explains how to fulfill functional requirements without forgetting about non-functional ones: to ensure reliability, availability, and system performance.
Both an analyst and an architect can assign tasks to a variety of teams: developers, devops, testers, technical writers.
Nuances:
Let me give you a simple abstract example that illustrates the difference between analytics and architecture.
The analyst writes a requirement:
Provide in the form on the website the ability to enter a surname consisting of Russian letters.
The architect studies and sets the following tasks:
DevOPS: Configure the network accesses required to use the database. Without network access, the code will not work because it will not be able to connect to the database.
Development:
a. Create a database schema and a table for entering last names with a “last name” column. There should be no logic or triggers in the database.
b. Write a method for checking that a surname consists only of Russian letters. If you enter any other characters, the error message “Something went wrong” will be displayed.
c. Implement a setting that disables the functionality from step b. We usually make a switch in case we change our minds about using it or an accident occurs after launching the function. In both cases, no additional development or code editing is required to remove a feature and quickly roll back to a stable version.
Testing:
a. Test the ability to enter any non-Russian characters.
b. Test the ability to enter special characters when entering a last name.Technical Writer:
a. Prepare/modify a user guide for entering last names.
Before setting all these tasks, the architect (if necessary) selects a database – the one that reads the data faster, or the one into which this data can be written faster – and the technology for implementing the logic and forms of working with the surname. The form checks what characters are entered into the field. If the characters are incorrect (wrong layout, numbers, special characters), the form reports an error.
Result:
In the development of any systems, descriptions from the analyst and the architect are equally important. The analyst clearly formulates the requirements and the image of the result, that is, the customer understands the analytics. The work of an architect will help formulate tasks that are understandable to teams and get results.
What to do with all this
To summarize, I would like to give some advice to managers and architects from my experience. I hope they will help bring a new employee into the team quickly and painlessly for everyone.
Supervisor must prepare colleagues in advance. Explain what tasks will be assigned to the architect, how this will help, how this will improve the product. Explain that the new person will be doing things that are usually not interesting to others: performance calculations, working with information security requirements, documenting system architecture and other “boring” tasks. This helps reduce resistance.
Hold retro meetings, where the whole team will discuss work problems and solutions. In one of my teams, I directly said that we want to develop the product, but we do not carry out tasks from the architect. And in response I heard that someone didn’t like the solution or found it strange and complicated from a code point of view. And they were right in such situations. We discussed and looked for a compromise. Literally half an hour of dialogue – and the task goes to work without unnecessary negativity.
I can advise an architect communicate honestly and openly with colleagues. You may need to explain all decisions at first. Discuss them, consult. And help developers understand that you are not their enemy who wants to complicate life.
Both the manager and the architect must convey to their colleagues that the architect will not replace other team members, but will only complement them. His work helps make the overall product better, safer and more convenient for the customer. This means that each team member can do what they love, leaving the rest (very important for the company and the client) to the architect.
Share your stories and ask questions in the comments!
