Transcription
Ah. Ah, everyone, hello to everyone who has come and who is watching, will watch the recordings. I am glad to welcome you to another round table from Harsov Skill. Today we have a very interesting topic. We will talk about how architecture is done in projects without an architect. Architecture exists everywhere. Architects do not exist everywhere. Often, the architectural function is taken over by developers, tech leads, team leads, those who are not lazy. So, let's begin. I will introduce myself. My name is Anton Dvornikov. I am an architect, a solution architect. I am a lecturer for the solution architecture course at Harsov Skill. Today, I will be assisted. I am the host of this meeting. The main speakers today will be two successful graduates of Harsov Skill. Great guys, Artem and Vyacheslav. They will tell, based on their own example, within the limits of what is possible, how it happens in their companies, on their projects, and will try to provide answers to the questions stated in the program. Specifically, where engineering ends and architecture begins, how tasks are distributed, what hinders and helps an engineer perform the architectural function. At what cost all this is achieved, with what risks, with what side effects? How does the team, your former colleagues (in quotes), react to the fact that you suddenly became an architect? Was there any resistance on this path? And in the end, how important is it to have a dedicated architect role, rather than trying to share your time with main tasks, and, in fact, what should happen in the product, in the project, in the team, in the company, in people, to arrive at this, well, a separate role. And with this, I will probably finish the introductory part, right? And who shall we give the floor to first? >> Artem, let's go. To you. >> Thank you, Anton. Good evening again, everyone. My name is Artem Zhiltsov. I've been in IT for 20 years. I started with industrial automation. Then for some time I worked, well, for a provider, an internet provider, where I dealt with billing, but for the last 15 years, I've been working in fintech, dealing with banking automation, development, and also architectural tasks. I think Vyacheslav can introduce himself now. >> Yes, hello everyone again. My name is Vyacheslav. I've been in IT for a bit less time, 15 years. I also started with industrial automation, was a software engineer, and also took on the role of an analyst and team lead. Now I am the head of development for design and analysis directions. I've had the opportunity to work in the energy, telecommunications, fintech, and insurance domains. >> Ah, yes, guys, thank you for introducing yourselves. And let's, well, then, get to the topic of our meeting today about how architecture is done without architects in your companies. Well, let me start, I'll try to outline the picture. Well, I work in a fairly large bank. It's an organization of, well, of a corporate, well, of a corporate size. We have about 200 departments, and among them, there is a product called "New," and probably several dozen, about 20, departments that are directly involved in IT, that are engaged in the development and support of systems. Accordingly, well, one of these departments is the IT Architecture department. Enterprise architects work there. They define IT strategy, tech radar, roadmaps, and are involved in modernization programs. The next architectural level is department architects. For example, I work in the Corporate Business Platforms Development department. That is, we develop products for legal entities, and also develop back-office systems. Accordingly, we have a department architect. Well, a department usually has a whole zoo of systems. Well, a zoo is somewhere around ten to twenty. Accordingly, the department architect manages this whole zoo, that is, defines the IT strategy of the department, the department's roadmap, and so on. However, in the department where I work, which has about 800 people, there is no architectural department or management. And, accordingly, the work is structured in such a way that when a new project opens, for example, for creating a new scheme or modernization, one developer is appointed from the engineers, from the developers, who will perform the functions of a solution architect for a specific project for a specific task. At the same time, the main tasks, well, like development, are not removed. That is, the person actually performs two functions: a developer, as in my case, and a Solution Architect. At the same time, I can say that the functions of the department architect and the solution architect overlap, but do not coincide. I would divide it as follows. So, as I said, the department architect deals with higher-level tasks, such as defining architectural strategy. Within a project, the department architect creates, for example, a system specification. This is the highest-level, general document without which a project cannot be opened. The department architect can also be involved in creating and maintaining high-level documentation, what we call HLD. Well, they can also go down to a lower level, work with requirements, with non-functional requirements. Whereas the Solution Architect works at the project and task level, that is, working with the same functional and non-functional requirements, creating proofs of concept, prototypes, creating and maintaining high-level documentation, as well as maintaining a registry of architectural solutions. Accordingly, this is my area of work. Serious decisions are coordinated with the department architect. Something more low-level can be done without their supervision. I also wanted to talk about how we organize work with high-level documentation. If possible, well, our HLD is called OTAR - Organizational-Technological Architectural Solution. This is a document with a fairly strict structure. Without this document, infrastructure for a project is not created. That is, servers are not deployed, network connections are not organized. Accordingly, this document contains general information about the project, goals, objectives, description of business processes, and information architecture. It describes what information objects exist in the system or systems, and what data flows. Then application architecture, well, that is, components and corresponding diagrams, deployment diagrams, and network connection diagrams, and information security solutions. Accordingly, any project begins with the creation of this document. And, well, after the document is approved, it is coordinated with information security and, well, the infrastructure department. And if everything is okay, then the deployment of the infrastructure and development begins. In addition, this document is then defended at the architectural committee. Accordingly, my responsibilities include creating, well, either the whole or parts of this document, coordinating with security, well, under the supervision of the department architect, and, accordingly, defending it at the architectural committee. Well, the department architect does that. So, that's the topic. Well, I also wanted to note that after the project starts, well, we are responsible for maintaining this document in an up-to-date state. And, accordingly, changes that affect the infrastructure must be reflected in it. Whereas decisions that do not affect the infrastructure are not reflected in this document; they are simply kept in the registry of architectural solutions. We use Confluence for this. Well, in general, that's all. Probably for now. >> Yes, that's all. Can I clarify a few points? You are not a full-time architect, right? You have other activities, and you take on architectural tasks, so to speak, as needed. Does this architectural function hinder you from performing your main work, or how do you manage to find a balance between that work and architectural tasks so that they don't compete with each other, or is there no such problem for you at all? >> Well, actually, it's worth noting that when architectural tasks arise, they, well, you need to change your work paradigm, right? So, it's one thing when you're developing something, or managing development. It's another thing when you need to switch and look at it all from a different perspective. And here I sometimes feel some internal conflict in the sense that, well, this is one of the questions for discussion today, that a developer becomes biased, in the sense that they, well, I, yes, I experience it, that I will develop solutions that are convenient for me. And what risks do I see here? The risks are that this solution may not be optimal, it may generate technical debt, it may not correspond to the long-term IT strategy and long-term business goals, because as a developer, I want to solve a task quickly and cheaply. And here this conflict of interest occurs, and you have to force yourself to look at the big picture, to look from the business side, to force yourself to think strategically in such moments. Well, this is about the internal conflict. >> Right. And does your circle of communication change significantly when you switch to architectural tasks? >> It varies. So, sometimes architectural tasks are solved within the team, then the role simply changes a bit, right? I have to call meetings, invite people, lead something, manage the agenda, take minutes. And in the end, a decision document is sometimes born. Well, sometimes it involves external stakeholders, so to speak, if they are employees of other departments. Sometimes they are quite reluctant to make contact. Well, they don't always want to work, right? Well, what helps in such situations? Well, first of all, yes, if you've been working for a long time, it's personal connections, knowledge of corporate culture, how to communicate, how to schedule a meeting, and so on. Knowledge of the IT landscape helps. But yes, and ultimately, if none of this helps, you can escalate the issue, and managers can help build the right communication between structural units. >> Ah, yes, thank you. You know, I've just thought of a tricky question to ask you. I'll try to make it impersonal and averaged. What do you think, you and your colleagues who also combine architectural activities with non-architectural ones, on average, is there enough technical expertise to do architecture, or is some specific technical knowledge required? Do you and your colleagues have enough soft skills, in your opinion, for effective communication with stakeholders who often, well, not often, but sometimes are reluctant to cooperate, right? And do you have enough understanding of why all this is being done, awareness, business motivation, to make the right decisions that will functionally and non-functionally align with business strategies? What do you think, it's a difficult question? >> It's a difficult, quite extensive question. Well, I'll go back a bit to the question of this internal conflict, because, well, you mentioned soft skills, right? And the requirements for soft skills at the developer level and at the architect or tech lead level are different. And when I'm in the role of a developer, I have a different paradigm of communication with stakeholders. If I'm a developer, they distract me, right? I tell them: "Well, like, leave me alone," I'm in the developer paradigm, I'm reluctant to make any contact. But when dealing with architecture and tech leadership, for example, you need to change your attitude, right? Because people who come to you, they rely on you, they come to you not because they were forced or something, but they expect help from you. And this must be taken into account. You can't just dismiss them. In my opinion, this is very important. And if, well, if you don't know something, but you listen, you'll say: "We'll think about it." And they will be grateful. And I, for example, often experience this, when there is some problem, well, there was a recent example, where a task was given by a very high-level manager, and it was unclear. And the people, there was a development team with a leader, an analyst, developers, and they simply didn't know what to do, how to approach it. And in the end, I listened to them. It was a task for me, it was somewhat outside my scope, right? I had an internal resistance, like, damn, why do I need this, why should I deal with this now? I don't want to, I don't understand. But, well, I have to, right? And by overcoming myself, organizing several meetings, we developed a solution. And these people were simply happy, they said, "Thank you. Now we see how we need to proceed," and then we defended this solution to the manager. And he approved it. So, this is a collective success. And therefore, of course, soft skills are very important. And this kind of responsiveness, perhaps. As for technical expertise, of course, not everything. Well, despite some long experience, you haven't managed to study all technologies, you haven't worked with all aspects. And of course, well, I rely on the team, on the developers, and decisions are made through discussion. I hope I haven't forgotten anything from the question. >> Yes, thank you for the honest answer. It would probably be difficult for me to answer like that, actually. Thank you. You know, do you see any prerequisites within your activities for becoming a full-time architect, or what needs to happen? Some technical, architectural, organizational changes, problems, for you to become a full-time architect, not a part-timer? >> Well, at my current position, I don't think there are any prerequisites, because that's how it's organized, right? These projects and this documentation are done according to a template, right? And this architectural work starts at the beginning of the project and takes, well, a couple of weeks, a month. Then it ends. And, accordingly, one architect can manage all this. Well, to be responsible for it. And therefore, at my current place, I don't think there is a need in our department, as it is currently organized, for an architectural department, and so on. So, I think only a change in the organization or department could help me, but I actually don't suffer from this, right? I enjoy doing development, and architectural tasks. Because I can say that architectural tasks are not so much about the documentation itself, but more about the discussion. And, well, you can be a developer, but if you have competencies in this organization, people come to you and ask, "How do you do this? How do we do that?" And because I've been working for a long time, I've worked on dozens of projects in the organization, I know all the integrations. Accordingly, this expertise helps to perform this work without being distracted from development, for example. >> Mm, yes, I understand. Thank you for the answer. We have a few questions in the chat. The first one is about diagrams. Yes, I'll answer. Diagrams are usually part of the architectural artifacts that the architect delivers at the end. In any case, diagrams can be different, everyone needs their own. This is a topic for a separate discussion. And Artem, a question for you. How does it work for you? Are the hours spent on architecture counted separately, or is it all lumped together? >> Sometimes separate tasks are created. Well, in Jira, for example, for architecture. Well, if, for example, a document needs to be created, then it's taken into account, but if it's about developing a solution, then it's, well, say, five hours a week, for example, then it's accounted for within other tasks. >> Uh-huh. And the second question is quite tricky. It's understandable that there is no ideal architecture. Everyone makes mistakes. And when you find time to fix architectural mistakes, they are rare, of course, but they happen. >> Well, I don't know how to answer that. Well, mistakes do happen, and sometimes, in my experience, there have been mistakes that required rebuilding the infrastructure. Well, I don't know, by 50%, to shut down 50% of servers, redo all network schemes, network connections, it took, for example, two weeks, we redid all those OTARs. But most often, mistakes are corrected, in my opinion, with little effort, by changing the database structure, for example, or rewriting some service. Well, a day is allocated for this, for example, development is stopped. Well, not the development of all developers, right, and time is allocated. Well, by the force of error, yes, in principle, everyone understands, well, managers understand that there are errors, yes, especially now we are working on a project, and it is quite risky because a new database is being used, which is also being developed based on the errors we identify. So, this is direct online interaction with the developers of Sud. And, accordingly, there are many risks. And architectural problems constantly arise. And, accordingly, well, I don't like this mode of operation, but I wasn't the architect on this project. I tried to influence it, I wrote documents, but strategically, the management decided otherwise. And, accordingly, the project deadlines, with great risks, are shifted, but the managers understand that these risks were there from the beginning, well, the management accepted these risks for themselves, and if something needs to be rewritten, then, well, okay, how much time is needed, they ask, how much time? A week. Okay, a week. >> Ah, yes, I understand. I'll just clarify. So, if any incidents occur, or if product business metrics, technical metrics decline, and the cause is of a certain nature, then a task is simply created, and you do it according to the queue and priority. Great. There are also questions in the chat, apart from, well, probably except for KPIs, that's a separate topic for us later, right, about KPIs for an architect in measuring work efficiency. You can probably answer in the chat, but I have one last question for you. Well, when you negotiate as a developer, you talk to developers. When you negotiate as an architect, you talk to stakeholders, to the business, to people who have power. Well, in the direct sense of the word, they have power, they can pressure, they have their own interests, conflicts of interest arise at those levels. What helps you smooth out these conflicts, bring everyone to one opinion and to a common result? Well, I don't often encounter high-level managers and conflicts, but I do resort to the help of the department architect and the department head. So, he is usually our main arbitrator. So, I can probably only answer like this. You attract supporters to your side who have expertise, who have roughly the same power, so that they push this train together with you. >> Well, yes. So, you need to, well, you need to sell the solution to someone, right? Get a powerful supporter, and then you can go and break through the skins. >> Right. >> Ah, great. Yes, thank you very much for sharing. Guys, I suggest you ask Artem questions in the chat. And yes, thank you again. And let's hand over the word to Slava. And then we'll return to the questions you asked during registration, and spend some time on them. Yes, Slava, glory to you. >> I work in a product company. It's not as large as Artem's. We don't have departments, so to speak. We've just gone through a transformation stage, and the IT department has been divided into units. The units have been divided by products. And, accordingly, the architectural function arises in two ways here. The first architectural function is within the product. And this function is fully transferred to the team, to the team lead, to the team, and to the development team. The second architectural function arises when there are some inter-unit interactions. And then I get involved here, in solving design issues, coordinating some solutions. So, we don't have formal architects. Informally, this role is distributed among the team leads of teams or tech leads of teams. And by me, if there are any inter-unit interactions. What risks, what problems do we face here? We did have a tool like an architectural committee. And for product development, as experience has shown, it's not a very convenient tool. Because this architectural committee includes developers, tech leads, and product managers from various units, from various products. And we constantly had some disputes that greatly slowed down decision-making. Because products need it here and now, they live for the current day. They need to deliver features urgently, quickly, release often, but they don't see the problems in the long run, for example. And when it comes to the long run, we have a communication breakdown. So, we've put this tool on hold for now. Well, perhaps we'll return to it, but in a different form. Further, we also have internal development, that is, a back-office system, which is our legacy. And here we've realized that we need to involve an architect, because many systems and vendors are involved in the back-office system. And the developers are not coping. And we've just started a project to re-engineer the back-office system. And here, the role of a Solution Architect has been allocated, and this task has been assigned to me, it's assigned to me. So, our system can assign such tasks. Well, that's a brief overview. Perhaps you have some leading questions. >> Yes, of course. You said that someone wasn't coping, and therefore they decided to allocate a separate architect. What were the prerequisites, who wasn't coping, and can you generalize? >> Well, here it's most likely related to the development processes themselves and the interaction of the back-office development team with the products of this internal product. So, you could call it chaotic development, right? A product manager comes up with some ideas, simply assigns tasks, the developer starts doing them without thinking, and this snowball has been accumulating for years. And we already understand that this system is very difficult to maintain, and any development becomes difficult. And the decision was made to allocate the role of an architect who will be responsible for designing the target solution for the back-office system. Abandoning old technologies, moving to the cloud, designing a modular architecture, let's say, not microservices, but simply modularity, introducing modularity. So, that's it. >> Uh-huh. Yes, I'll still clarify further. Look, we're talking about the fact that there's no architect in the company, but the product exists and is developing because someone, a DevOps, I don't know, a tech lead, performs the architectural function, right? Provides answers to questions, deals with compromises, all that stuff. But why did you decide that you couldn't allocate someone part-time to this position, like Artem, but a full-time one? Like, the product has stalled so much that you don't believe it can be done without a full-time person? >> Well, essentially, I am performing this role full-time now. It takes up all my working time. >> Aha.
And the masters also heard. And it also turns out that a product in which architectural decisions were made, well, unconsciously, yes, such an emergent story, like, well, as it went, so it went. No one thought about rational motivation there. This product has been stopped all this time and requires the architect's supportive participation. So, I would say that this product requires the implementation of systematic decision-making processes, yes, and this task can be completed with the help of an architect, >> right? >> Uh-huh. prepare the architecture, the transition from the current state to some target state, perhaps, using a transit architecture. >> Understood. Well, I made a slightly exaggerated conclusion, of course. Uh, maybe you can clarify what the prerequisites are, what to pay attention to, what markers can be there in development, yes, and signal to the CTO, the chief engineer, well, high-level specialists, that it's time to engage professionally and take a systematic approach, of course, and think about the architecture seriously, not on the fly. Ah, well, the markers, the markers for me are, as it were, the process itself, yes, the process of delivering value, yes, and developing a specific system, yes, the approach itself adopted in development. That is, you can develop, as I already said, by resorting, for example, to a product, yes, with some idea, they just give it to the developer, and the developer just takes it and does it. as best he can, as he knows, yes, he doesn't think about the consequences in the long run. Here, this is already a marker, because, conditionally, in a few years, the system will become unmanageable. >> Listen, how do you understand that the developer isn't thinking? Maybe he sincerely sits in the evening and thinks: "I can do it this way, I can do it that way, I can do it this way." This solution will have these consequences, this one has these risks, this one has these compromises. Maybe he makes the decision consciously, and not just implements the first idea that comes to mind. How do you know that it was unconscious and risky? Ah, well, I would say that the absence of documentation, that is, there is no record of the decisions made, yes, by the developer. This also indicates that, most likely, some alternatives were not considered. >> Uh-huh. Uh. And what do you think could help the developer, well, in such circumstances without a dedicated architect, to think, yes, and weigh some processes, perhaps regulations, or is it all up to the person as usual. Does he think about it or not? Well, I think that a certain RFC process can be introduced, yes, when the developer describes his solution, that is, to highlight some mandatory sections, yes, a description of the solution, some alternatives that he considered, maybe some sketches, I don't know, data structures, uh, database choice, migration plan, if there is a database change. request for And what to do next? It will need to be requested then, right? To involve some other developers. That is, well, the balls are this decision in other heads, yes? Maybe something will be suggested. Maybe at this stage, some incorrect decision will be made. >> Uh-huh. And how do you think developers will be willing to engage in thinking about motivation and then defending, uh, these decisions? Well, this is a provocative question. Developers don't like to do it. Well, as we know, they don't like to do it, they don't like to write documentation, they don't like to think about solutions for a long time. I think here, as it were, a culture of development needs to be introduced. in that chat, I wanted to joke, sorry to interrupt, that they already don't like writing documentation, but they like it when other developers write it, yes >> well, they also like it when analysts write it for them >> I'll interrupt you with something, sorry please >> well, the introduction of a development culture, including as one of the processes of this culture, is this RFC. Uh-huh. Uh-huh. Uh-huh. Understood. Perhaps someone has questions for Slava, for his experience. Yes, they are asking here, is the salary for an architect and a developer the same or different? Or for a developer, when he is working on code and when he is working on architecture, is his hourly rate the same or different? >> Unfortunately, it's the same. >> There's no hazard pay. Ah, let me share my experience a little then. I've seen several projects that have developed. Ah, Slava, yes, thank you very much. for your story, your company, your project, and your processes and the path to the architect. I've seen a couple of projects recently that have developed, large projects, with money, everything is fine with money, but they developed without explicit architectural supervision, yes, without the function of description, without the function of, as it were, instilling an architectural culture. And who did the architecture there, of course, it was done by the tech leads, yes, they solved local problems, somewhere something slowed down, somewhere something was unavailable, using available tools, they squeezed the maximum out of the systems, they did it locally. No one thought about the global benefit, yes, like you can solve the problem in different ways. Different tactics are applicable in different places. They influenced locally, caring about the local extreme, and this did not lead, according to effective thinking, to the optimization of the entire system as a whole. And the patterns that were used, of course, were low-hanging fruits, yes, which could be implemented quickly and clearly, but their use on such a scale led to more global problems. And these problems accumulated, they were masked by horizontal scaling, paying for large infrastructures, pouring money, until at some point the business came and asked, like, why are we spending more and more money, although there are no particular prerequisites for this. And strangely enough, these tech leads gave one answer. What? Well, we don't have an architecture, we did what we could. We weren't paid for it, we weren't trained. That's the answer they gave. And the business got a false impression that the problem was indeed that there is no architect. If we hire this architect now, all our problems will be solved at once. But when you interview these people and ask what exactly your problems are, how it impacted the business, and so on, no one can clearly outline the scope of these problems, yes? And this is a super complex task with a maximum degree of uncertainty. If people who have been working in this for years, even decades, cannot clearly explain what the matter is. And all the explanation ends with words like: "Well, everything is bad there." They literally say: "Everything is bad there." So, of course, it sounds very naive and utopian that we will now find an architect, he will fix everything, and we will fly into some cosmic space. This is a small story about how, perhaps, if there is no systematic approach and we care about small local goals, without thinking about global strategies and what will happen in a year, two, or three. Unfortunately, this happens. With all due respect to the tech leads, they do their job well. But something is missing so that the business doesn't come to such conclusions, yes. And we don't urgently look for architects later. And if, if in this part, no one has any questions, no one wants to clarify anything, we will check the chat again. Knowledge base is too vague, Evgeny, your question sounds. And Andrey, Andrey Chernetsov, hello. Vyacheslav, a question for you. If architects were hired from outside, who would interview them, evaluate candidates, if all architectural knowledge in the team is scattered among the tech leads? Good question, by the way. >> Well, I would definitely talk to him and one of the tech leads. That's >> Yes, thank you. By the way, this is one of the reasons why architects are often grown within the company, hired internally, rather than from the market, because there is no possibility and no internal expertise to properly evaluate a candidate, and it's easier to grow a person whom you know well, whom you trust, who has some trust. >> So, I would like to answer a couple of questions. So, let me find them. Ah, well, here's a question from Alexey Alexeevich. How long did you work in the company before you were offered to do architecture? Why you specifically? In my case, the situation was, well, I'll say that I've been working in the company for 12 years now. Well. Well, naturally, by all accounts, this is a very long time. Well. Well, yes, I tried to quit, well, but I was lucky in the sense that projects changed, systems changed, stacks changed. That is, it was like going to a new job. Well, and accordingly, this allowed me to stay and not lose interest. How I started doing architecture, I took on, well, it turned out that way, yes, that I have such a, well, I don't know, maybe such a disposition, that I didn't delve much into business stuff, yes? That is, we were developing some product, I was more involved in some things, well, in the core, in system things. And therefore, as it were, I didn't really know the business side of things. Well. And I took on any job. That is, I needed to integrate with someone or deal with support, development of data formats, yes, for example, or interact with some vendors on these formats, on integration. And I took on these integration tasks, on the development of integration mechanisms, applications for integration. Well. And with all sorts of different ones, there was integration, for example, with regulators, encryption, electronic signatures. Well, for these, well, conditionally speaking, for about 7 years, for example, I touched almost the entire IT landscape. Well, I knew how things worked, where, well, who to call, who to ask, how to write a memo, get it approved, how to allocate servers. In short. Well. That is, this internal outlook and knowledge of the IT landscape led to people simply starting to come and ask themselves. There's a task, they go to Artyom, ask him to look at it or something. Well, accordingly, that's how it happened. Ah, well, I hope I answered. Well, there were mistakes, there were blunders, nothing like that. We survived, well. And as for what else I wanted to answer. Ah, about the knowledge base. Well, we use Confluence. Well, it's a powerful enough tool, but I don't really like it in the sense that, ah, that is, we keep documentation for the system, for example, now it's in Markdown format. And Confluence doesn't support Markdown, and architectural decisions in Confluence. And, in short, the problem is that sometimes you have to rewrite what you've written in Markdown. And, as it were, and vice versa. But yes, we keep ADRs in Confluence and, well, all the project documentation. Well. And then everything seems to be answered. Thank you, Artyom. Thank you. Uh, I'll quickly jump into the questions that were asked separately. I'll start in a different order, yes. There was a question about how, such a difficult question, actually, uh, how a developer can influence a wrong architect. A tricky story. And I planned that we would reveal a lot now about how to influence. But it turns out that besides the fact that you have to be proactive, ask the right questions to the right people, yes, want to develop somewhere, and not just frame someone and show that someone is incompetent. Without this, probably nothing will work. Well, most likely, such an architect will look negatively at all these initiatives. Ah, if they don't have, first of all, of course, a rational component. I don't know what kind of architect, what kind of example. Well, guys, what do you think? >> Well, I'll try. Well, it's a difficult question, indeed, but I think that here you need to, well, of course, be technically competent or come up with proposals when, well, I don't know, a prototype or proof of concept has been made and some metrics have been shown, that this particular architecture will work. And the alternative has its corresponding disadvantages. And of course, you need to try to make it so, well, formulate thoughts so that they seem beneficial to the opponent, so to speak, yes, if it is an opponent, you need to try to speak in business terms. Well, for example, that if we do this, it will be cheaper for us, the business will be happy, we will get traction, for example. Well, that is, you need to win over the opponent, probably. Well. [music] Yes, listen, you are absolutely right that any architectural decision should pursue business goals. If a developer can show that this option hits some super cool, hits a business driver, then it would look very strange if this initiative was not supported, yes, on the one hand. On the other hand, architects will always lead the conversation to higher-level topics, terms, they will talk about non-functional properties. Which a developer is usually very weak at, and the developer's position can crumble. Therefore, unfortunately, if a developer wants to compete with an architect on some issues, they need to understand these issues very well. Well, not unfortunately, but fortunately, this is a path, a path of development, in fact. Ah, Slav, do you have anything to add? >> Well, I agree, yes, that you need to justify through metrics, plus build communication with the architect. Ah, well, the context of the question is not very clear, what does it mean, architect, not architectural. >> You can. >> I once had an experience in one company. The architect was not a solution architect. I now understand that it was a software architect. His activity was not particularly visible to me, except for the code review process, yes, when the whole development team gathered in the meeting room, the projector was turned on, and he tore apart every pull request and everyone dreamed of getting rid of this architect as soon as possible. He was a super toxic character. I didn't see much benefit from it, of course, when it was presented that way, being a developer at the time. Perhaps the business was happy, but I was just indignant to the maximum every Wednesday, when this happened. And let's move on to the next question. What guide would you recommend to become an architect? >> Yes, it's clear that we all start from different points, yes. Someone is an engineer, a developer, someone is a tester, someone is a business analyst, someone is, I don't know, who else. Guide. Guys, what do you say about a guide? What recommendations will you give? >> Well, let me start. Well, as I said, yes, if you've been in the organization for a long time, yes, then you need to, of course, expand this internal outlook within the organization, yes, that is, understand how things work. Well, communication is very important, yes, that is, personal relationships are important. Oh, it's very important, as it were, how you communicate with stakeholders. Well. Because, well, business, for example, well, and it's very important to gain trust, yes, from the business. Then the business will ask: "Give us him, because we know him, he helped us." Well. That is, you need to show these soft skills. Well. Ah, well, naturally, you need to be interested in architecture, read literature, watch videos, attend courses, for example. That is, well, for me, for example, in my, well, as it were, in my case, it was like this: I was doing architecture without knowing that I was doing architecture. And then, when I started to realize, yes, that there is something around, that there is some strategy, that we are bringing benefit to the business, I started to be interested in it. Well, I'll deviate a little more, yes, that is, I was involved in development, and I always thought, what will I do next? I thought I could only go into management, but I didn't want to. Well. And for a long time I worried, like: "Well, what should I do?" Well. And then I found that here is architecture, it's a whole layer of, as it were, work, as it were, work direction. Well, and I started to do it, read books. Well. And, accordingly, now I see that this is exactly my path, thanks to, well, including colleagues from Harden Soft. >> Yes, thank you. Ah, let me tell you about my guide. Well, my guide will be based on my own story. I started doing architecture. Well, because everyone else refused this work. No one understood what needed to be done, no one particularly understood what it was for, but someone had to take responsibility. And I was young then, young, inexperienced, and decided that I could handle it, and got involved in the architectural story. Yes, I had to read a lot. There are a huge number of books now. If even half of these books were available in Russian, including, if at least half of these books existed 6 years, 7 years ago, I would have probably taken a different path. It would have been faster, more effective, like for any of you, in fact. But now there is plenty of literature. Otherwise, it's books, of course. There are plenty of videos on the internet. Any concept can be broken down into details, step by step, to understand if it suits you, or not. Well, of course, courses, trainings, seminars help a lot. Ah, and now there are many of them, many different ones exist. Yes, I won't advertise, but you understand where I would recommend you to go. Well, definitely. In short, I became one because life forced me to. Well. I wasn't looking for career growth. Well. But it happened in a natural way, yes. And if you are asking about specific educational institutions where you can study architecture, I only know of them in the USA, but you can take them remotely from anywhere in the world. And it doesn't matter what your previous education was. Well. Slav, will you tell us something about the guide? >> Well, I have a similar guide. I just took tasks and did them. That's all. No one else took on these tasks. Developers didn't want to take responsibility. I was simply given tasks, I took them and did them. And that's how it happened. Then there were courses, books. Well. And so gradually I reached such tasks. Here, as it were, you just need to show your initiative, study different domains. Yes, you see, different domains are a super, super overpowered tip, yes, but it's hard to study a domain without being inside. In other domains, all the information you can get will be quite superficial. There won't be proper immersion. And then it turns out that yes, in one domain you can grow super, and you will be super effective in this domain. Having a systematic approach, you can work well in any domain, in fact, applying different techniques from architectural frameworks, but with experience in a specific domain, your effectiveness will grow exponentially. This is my conviction. I am ready to defend it, prove it, and provide examples from experience. Well. Let's move on then. Yes, thank you, guys, let's move on to the next question. [music] The question will be: "What should an architect do with what VIP vibe-raisers have created? Refactoring cannot be done as is, you can't even put a comma." I know that Artyom has some fresh example on this account. Over to you. >> Yes, thank you. Uh, yes, I wanted to share about this question. In general, I was called to look at one project, well, a kind of >> taboo, so to speak. Well. And there, you know, a person implemented an MVP. That is, he got requirements from a partner, well, and implemented an MVP. And he said: "Listen, look, what do we have here, where is something wrong? Maybe you can program something?" Well, let's see. Well. And, accordingly, yes, the person was, well, he was without strong experience, well, much experience in development. Well, he implemented a web service, well, using neural networks. Well, he's a smart person, yes, he wrote a lot of code, a beautiful interface, yes, huge functionality. Well. The point is that, as it were, some load is expected, well, conditionally speaking, 2 million records need to be saved somehow. First of all, yes, then they need to be statistically processed. Well. And I looked and said: "Well, have you tried to upload even a million records there, and then, as it were, download or analyze them?" "No," he says, "I haven't tried." Well. And, accordingly, well, we quickly realized that it wouldn't work. Well. And, well, that is, I said that the choice of a document-oriented database is most likely incorrect. Well. Because there is quite a, well, uh, relational model should be used, because there are many entities with relationships, integrity needs to be maintained. Well. And besides, querying documents from a document database by some attributes at a very deep level in extensive documents quickly, it will not work very well. Well. And, accordingly, I said: "Well, have you tried to upload, as it were, download all this?" I said, "No, I haven't tried." Well, in the end, we found out that it's impossible to work with it. Well. And, as it were, we rewrote it. Well, that is, we would have saved time if the task had been set in advance, and it would have been immediately possible to assume, well, at least the volume and structure, well, the logical model, yes, to discuss it, and it would have been clear at the early stages. Moreover, well, in my understanding and experience, relational databases, well, that is, it's better to start with relational ones. Well. And, accordingly, yes, refactor. >> My answer was. Thank you. Ah, listen, and if it was already in production and there was client traffic, the business was already making money on everything, can this story be postponed, yes? What to do? Refactor, throw away, rewrite, or accept and live with it? Show. >> Well, I think the refactoring would just be different. Here we just have some MVP in production, the partner went on vacation for 2 weeks. We took it, rewrote everything, and that's it. He came back, everything works. Well. But yes, if it was production, well, we would have to decide something, yes, we would, well, with the database, we would have created some additional collections, stored the data differently. Well. Well. That is, refactoring would have been required, but I think it would have been more difficult to live with it later, of course, and to maintain integrity, and so on. >> Yes, that's why I added my own piece, because it's obvious that the contexts can be different, and your answers and advice can also be different. Yes, yes, of course. Well, if the author of the question is here, they can clarify in the chat. Well, we'll figure something out quickly, [music] and the question remains, which is actually very, very trendy now. I've heard it a lot. In short, it sounds like this: What are the metrics for evaluating the effectiveness of an architect's work? Well, I know that Artyom also wants to share an answer. But before that, I want to draw attention to what a metric is as such. There is a law called Goodhart's Law, which sounds approximately like: when a metric becomes a goal, it ceases to be a good metric. This means that if we aim for a metric, we start making decisions, designing systems to optimize this metric. And these actions, these system decisions often start to go in parallel with business goals. This is a trap. Therefore, metrics should be chosen in a balanced way, yes? Each metric should have a counter-metric that will check if there are negative side effects. And by considering metrics together, you can understand whether it was a metric hack, or whether we are truly moving in the right direction. And regarding architectural metrics. I don't want to steal someone's bread, yes. And here's the moment for Slava's words. But you can look at frameworks like TOGAF Safe, there's a lot about effectiveness. You can look at Well-Architected, there's Azure and AWS, there's also about the effectiveness of architectural solutions. Ah, yes, the information is actually available, there is a lot of it, you just need to know how or want to find it. Yes, Artyom, now, yes, the floor is yours in detail, please. >> Well, it's not that I prepared a lot, but I was personally interested. Well. Well, in our organization, there are no direct metrics tied to architects, for which they would then, I don't know, at the end of the month, for example, reduce their sprint. Well. Ah, in our department, such a culture has developed that our main metric, yes, it, well,
This is satisfaction, as it were, a project manager's, business satisfaction. Here. But how to really evaluate it, if you want to count something, yes, something there, I don't know, compare periods? Well, and so I, well, that is, here you need to highlight different aspects. There are technical aspects, there are strategic aspects, there is efficiency, uh - uh, something else. Here. And, accordingly, among the technical aspects, one can highlight the quality of the solution, how to measure it. Well, here are a few options, for example, the number of architecture revisions. Here's such a metric, yes, in solutions. The next metric can be the amount of technical debt. This is probably the percentage of time spent on working with technical debt. You can also simply measure the reliability and performance of the system and the number of defects. Here. Uh, well, you can calculate, for example, the percentage of incidents related to the architecture. Here. And, well, in my opinion, this number of defects is, well, such a metric that we are quite, well, how to say, we are close to it, yes, that is, even if not explicitly, we look at it, because in production systems in the bank, yes, incidents there are, well, as everywhere, probably, it's a serious thing, because it's losses of customer money, it's losses of the financial organization, it's fines from the regulator and so on. That is, these incidents can directly affect, well, immediately, the financial indicators. Here. And, accordingly, well, there is no practice that if an incident occurs, for example, and the bank pays, then, conditionally speaking, the manager deducts this money from the salary. There is no such thing, naturally. Here. But if incidents accumulate and are not fixed, and these are incidents related to the architecture, then the manager, naturally, comes and says: "Okay, what's happening, why isn't this working?" That is, these financial losses do not affect directly, but in the end, everything can turn out very badly. Here. And in fact, I even participated in, well, as it were, I made a decision when, well, as it were, there were losses. Here. But they were not only my fault, but also the fault of, well, there, Rocky, well, in short, they found out late, uh, about changes from the regulator. A lot of programming was needed. Here. And, accordingly, we were a week late. Here. And, accordingly, there were fines. Here. But everything worked out in the end. So, yes, incidents are tracked daily. And, well, for production systems, there are meetings every day, and all incidents are discussed, and the cause is determined and how to deal with them. So yes, I think that defects are, of course, a good metric, but architecture revisions, well, I don't know, well, they revised it, well, they programmed it, for example. So further. These were technical aspects, uh, strategic aspects, yes, it's alignment with business goals, for example. How to measure? This is, for example, the percentage of solutions that correspond to long-term business goals and or IT strategy. That is, probably, you need to count solutions that do not generate technical debt, but on the contrary, they improve the business, yes, and the second metric is business benefits. For example, launching a new product or improving customer experience. Here. Well, improving customer experience can be measured, probably, yes, it's how many, I don't know, I don't know, orders customers, uh, are lost or what else. Here. The next strategic aspect is innovation, yes, it's the introduction of new technologies, patterns, or platforms, for example, or also what innovations, uh, patent registration relates to. Here. And we, by the way, have an interesting story, as it were, on the current project, we are developing a platform, and we have filed an application for patent registration. So this is an interesting story. And the next aspect is efficiency. What metrics can be here? It's time to market. That is, well, our solution can reduce time to market or reduce costs, for example, total cost of ownership, uh, infrastructure, or just costs. In some business processes. Uh, this is, well, these are the aspects that I wanted, well, that I highlighted for myself. There are also aspects related to company culture, to mentoring, uh, to collaboration, between departments, but I somehow, well, didn't have time to figure it out. Here's an example, as we recently discussed an architectural decision, well, the task was, you need to synchronize caches between instances, yes, so, uh, well, it's quite an obvious solution to deploy a distributed cache, for example. Here. So all developers, yes, yes, well, that's great. So, well, I'm for it too, as it were, yes, but on one of the projects in production, we encountered the fact that DevOps competencies are not important. If we now include a certain cache in the system's perimeter, it will most likely lead to incidents, worsen, uh, as it were, I don't know, complicate the infrastructure, and something will not work somewhere, increase the number of incidents. Here. But at the same time, we could sacrifice consistency. Here. And therefore, we just refused. And we, uh, well, as it were, accepted that the caches would be inconsistent for a while, and we would live like this, specifically on this project, well, as it were, on one of them, yes, because we don't want to complicate the infrastructure, we don't want to deploy additional ones, well, here's such a story. An example. >> Ah, yes, thank you. Good classification. But, you know, what I want to add? You mentioned time to architecture decision, yes? Like the time it takes to make an architectural decision, that it slows down time to market. All this story. Of course, if you set such a metric, the architect can start to rush, yes, so that architectural decisions pass through them as quickly as possible. Naturally, the first thing that will fall victim to this optimization is the quality of these decisions. Therefore, a counter-metric is definitely needed, like the number of architectural rework for this decision without changes in business context, for example, yes. If the second metric goes in the wrong direction, it means the architect has cheated. Well, in general, this applies not only to architects in the development cycle, take any specialization, it will be approximately the same with its specifics. Only in our chat, of course, there is Artyom, thank you very much for your answer. In the chat, of course, there are never any questions about technical debt. For an architect, if developers are directly subordinate to the architect, well, if the technical lead performs the architectural function, then all developers will be directly subordinate to him, even in matrix conditions they will be with him, he can use them if it's an architect. Architect. I haven't seen such stories, unless it's some force majeure, some initiative for which a separate team is assembled, perhaps such a story will happen. But, as a rule, it's not practiced. What resources are used to cover technical debt? M, very interesting topic. I wouldn't want to start it at all, because we only have 4 minutes left. The recommendation that I always give to everyone, yes, make the business a participant in the creation of this technical debt. If a developer thinks that telling the product owner that I will do technical debt here, but we will release to production at the end of the sprint, this is enough for the business to be aware, this is not enough. Products, well, people who are close to development, they often have their own motivation, their own KPIs, and they may not be working at the company in six months, and in six months, technical debt will have to be dealt with. And you need to be sure that the decision that we are doing technical debt, yes, and not doing everything beautifully, is really made by the business. Literally, that they signed off that we are compromising with ourselves here, and we will have to pay off this technical debt. Here. And therefore, when there is a strategic session, when the product backlog for the next year is formed, yes, it can be well aligned with the technical or architectural backlog, roadmap, yes, and clear connections will be tracked, yes, for example, in order to implement some function, we need to solve technical problems. All this is also reflected in business indicators. And everyone is happy. There are other methods, technologies, but I, honestly, don't like them, like combining product work with paying off technical debt. For me, this is a big risk, it's dragging on, and so on. In any case, technical debt should always be dealt with carefully. It can be managed or unmanaged. As a rule, it turns out to be unmanaged. Here. Therefore, resources, resources must be taken from the business to resolve technical debt. If we are talking about architectural debt, architectural debt is technical debt that has architectural implications. The history is similar, a little different, but similar. It's easier for the architect. Because you don't need to prove the inefficiency of the code, for example, yes, to prove the inefficiency of the code, the presence of a direct advantage for the developer. There are approaches, they are also described in books. And if you want to extract resources from the business for this, you can provide direct evidence that the code needs to be reworked in numbers, linked to money. All this can be done. Again, information on how to do this is publicly available. Someone wants to add something about technical debt? I hope not. But if you really want to, then let's. Ah, yes, purely technical story. CP and passwords will never be canceled. Eight misconceptions about asking, no one will ever cancel. These tasks will always be before the architecture, and you will always have to ask stakeholders the right questions. What is more important to us? Divide services by criticality classes, treat them differently. Somewhere consistency of the cache will be important, and somewhere consistency will be unimportant within reasonable limits, but availability will be super important. Therefore, the era is such that you should treat each case carefully and not generalize. That's all I have. The questions seem to be over. I hope we answered as best we could. We could have done quite well, yes. Thank you all very much.