December 7, 2018 at 12:40Round table “Architect of the IT project”, September 2018
On September 5, Moscow hosted the Round Table “IT Project Architect” at the HSE. The organizer of the round table, Maxim Smirnov, is a blog about architecture and the Facebook channel .
I am very glad that such events are being held. Becoming a cool architect was and remains my dream. For a very long time I did not understand how architects generally get, how to develop and what directions to choose so that they lead to architecture, and, I think, such questions arise not only for me. It’s great that there is a community where you can come and ask architects questions.
At the round table, 4 reports of 15-20 minutes were presented, after which there were questions from the audience and discussion.
The reports were brief and to the point, and the discussion was very lively and extensive.
Further, my notes during the reports.
Report 1
Gennady Kruglov
Certified SOA Architect, CTN
As part of the presentation, the main stages of the architectural process were touched:
Highlights of the presentation:
It is advisable to make a prototype to show it to the business. Whenever possible, it is necessary to involve different parties when choosing an architectural style - developers, security, operation. When designing a sketch, you need to make different sections of the architecture - business, technology, security.
If possible, it is necessary to attract people who will then directly work with this part of the system.
After discussion with interested parties, a prototype is demonstrated. If the project starts, a more detailed study of each level of architecture is performed.
During development, synchronization with the architect is necessary to verify that the process is following the chosen path.
The skills that, according to the speaker, are needed by the architect:
Report 2
Dmitry Romanov, ITSK
Designing IT solutions, architectural support of projects, about 80 projects a year, about 50 architects are involved in the process.
The service of the chief IT architect determines the technical policy in the field of IT, which was implemented by IT project architects. Answering the question where the architect usually gathers the necessary expertise, Dmitry indicated the following sources:
Considering the need for the role of an architect in ITSK, Dmitry pointed out that the architect of an IT project is needed so that, for example, there is no situation where they did the project for 1 year, then worked for six months and realized that there was no scaling, and then redid it for 2 years. A clear understanding is important that the proposed architecture can be implemented. Depending on the project management methodology, in ITSK the architect either enters into the team (if it is agile) or enters into the project expert group.
Report 3
Ivan Lukyanov, Moscow Department of Information Technology, “Public Services and MFC” product
Professional biography of the speaker: developer at Diasoft, head of the development team (BSC Praha), leading consultant (Neoflex), head of the department of architecture and strategy at Alfa Bank, Head of the Department of Architecture Development (DIT).
Ivan recommends starting with a description of the existing architecture (as is), creating the target architecture (to be) and analyzing the difference between the points “where the organization is now” and “where the organization wants to go” describe the steps to bring the system to the target state.
The main focus of IT projects in architecture:
The company has now developed its own methodology, including templates used in the work of documents. The principles of TOGAF and Gartner were used .
The architectural principles were approved, the document “Architectural and technological solution” was developed, which describes the business requirements for solutions and the project for their implementation.
Features of the architect:
Architecture is not a motionless monument cast in granite, but a living, evolving view of what we want to achieve in terms of business support.
Report 4
Eugene Aslamov Aslamov , Lead Architect, SC Cheeks.
Eugene’s path to the role of architect: developer, analyst, project manager. During the short story, the author raised several issues related to the role of the architect in custom development: what surrounds him, what he does and how he does it.
In the opinion of Eugene, speaking about the architect in custom development, we are dependent on various factors - the timing, budget, team, complexity and volume of tasks. As a rule, in complex projects (several thousand user scenarios, integration with a couple of dozen systems, large data volumes, severe requirements for High Availability & Disaster Recovery), architectural tasks are closed by a group of architects. On more modest projects, one person can cope with these tasks and the architect is not always dedicated to the tasks - his role can be combined with other roles - the lead developer or analyst.
An architect, like any team member, works in a certain context. One outline of this context:
Customer
Command
the contract
As part of the context, an architect or group of architects does the following:
Answering the question “How does he do this?”, Eugene first of all touched upon the issue of developing architectural solutions. Several components were identified that help in this task:
Instead of a conclusion: one of the informal tasks of an architect, and of any specialist who loves his job, is to popularize knowledge, technologies, approaches, and skills that will allow the team to solve problems on a project more efficiently and with greater convenience.
Eugene's article on habr “ We are preparing a project at Sparx Enterprise Architect. Our recipe . "
Next was a section of questions and answers, the most remembered can be read below.
Gennady:
Software architects - former team lead or lead team or lead developers.
Dmitry:
Architects are taken from developers from consultants, with wide expertise.
The developer can speak and draw presentations - solution architect.
Eugene:
In general, from any part - from development, testing, project management, etc. But in any case, some technical specializations help - they do not have to be developed from scratch.
An example from personal experience: a student from the mechanics department of Moscow State University, an intelligent, sociable person without star disease, was taken to the Lanit company. He worked a little in analytics, development, communication with the customer. As a result, he became an applied architect in our company.
Ivan:
From the developers. If there is a good developer, then he can continue to delve into programming languages, develop deeper. But if, at the time, he was curious how the technical task was born, who analyzes, who makes the decision whether this should be done or not, then this is a signal that the specialist has embarked on the path of a novice architect. The next level of curiosity is how a solution is born as a whole, at the business level. How can you show the head of the organization that he needs it and what does not. Gregor Hohpe uses elevator metaphor to describe the role of an architect.. Each floor where the elevator stops is a certain level in the organization: the first floor - the machine room - these are developers, production; top floor - organization management. Bringing architecture to life, the architect communicates on each floor (from the first to the last) and on each floor he has to cope with various difficulties - technological, political, communication.
The architect is able to collect the necessary information and convey to each level. In fact, he acts as a mediator between the parties involved.
There must be a balance between authority. The authority of the architect lies in the technical part, and the project manager in the organizational part.
In the event that the balance is shifted towards the RP - you can get the project on time, but not working or not scalable. And, if towards the architect, then you can get a wonderful project when no one needs it. This is how to answer the questions "Who do you love more - mom or dad?"
Ivan:
In large organizations, more than 2,000 people make one corporate architecture and it is almost impossible to follow it. In DIT, a division is made into products (services), each product has its own technology stack, its own architecture. As for corporate architecture, shareholders need it more so that they understand where the organization is heading in terms of architecture development. For this purpose, the role of Chief IT architect is often highlighted in organizations, the main task of which is to determine the overall landscape of corporate architecture.
Communication is important. You need to build communication and just communicate. A project architect may not need knowledge of corporate architecture, but it is important to know who the integration will be with and what the impact will be. It is important to make architectural committees, it is possible to know there not only corporate architects, but also design ones.
You can look at it in terms of value - who brings more value. If the solutions work, then there is value. Enterprise architecture in itself does not bring value, but it brings value through a solution of architects who already implement specific tasks.
No one needs generalists — less and less are people who know nothing about everything. It is better to be able to answer specific questions, for example, is RabbitMQ enough here or is Kafka needed.
Are there any complex models that can be calculated, verified, etc.?
Eugene: we have an architectural repository, but there is no automation for calculating any metrics. The relations between the models and the models themselves allow us to consider architecture as something integral, rather than a set of pictures. One of the tasks of the repository is to provide impact analysis. On this basis, you can make an estimate of the value of the changes.
It's great that you can come and listen to the architects, get to know the community. Such meetings are always an opportunity for me to understand where to dig in order to find the necessary knowledge. In addition, you can discuss working cases and get a recommendation.
Thanks to Maxim Smirnov and HSE for organizing a round table of architects!
Also many thanks to the authors of the reports (Evgeny Aslamov, Gennady Kruglov, Ivan Lukyanov) for the preparation of this text , since the original notes were written during the reports and contained errors and inaccuracies that were corrected. Pictured is Chambord
Castle in France, they say, each owner built on his turret. Sometimes, the architecture of a project looks that way. In my opinion, an architect is needed so that everything is beautiful and as simple as possible, so that even with a bunch of towers in different styles, you would still get a beautiful castle.
I am very glad that such events are being held. Becoming a cool architect was and remains my dream. For a very long time I did not understand how architects generally get, how to develop and what directions to choose so that they lead to architecture, and, I think, such questions arise not only for me. It’s great that there is a community where you can come and ask architects questions.
At the round table, 4 reports of 15-20 minutes were presented, after which there were questions from the audience and discussion.
The reports were brief and to the point, and the discussion was very lively and extensive.
Further, my notes during the reports.
Report 1
Key Skills of a Solution Architect in Projects from the Ground Up
Gennady Kruglov
Certified SOA Architect, CTN
As part of the presentation, the main stages of the architectural process were touched:
- Business involvement.
- Engaging engineers.
- Prototyping.
- The choice of architectural style and technological stack (microservices, monolith, SOA).
- Development of draft architecture.
- Demonstration to the customer.
- Solution Design.
- Documenting arch solutions.
- Architectural supervision.
Highlights of the presentation:
It is advisable to make a prototype to show it to the business. Whenever possible, it is necessary to involve different parties when choosing an architectural style - developers, security, operation. When designing a sketch, you need to make different sections of the architecture - business, technology, security.
If possible, it is necessary to attract people who will then directly work with this part of the system.
After discussion with interested parties, a prototype is demonstrated. If the project starts, a more detailed study of each level of architecture is performed.
During development, synchronization with the architect is necessary to verify that the process is following the chosen path.
The skills that, according to the speaker, are needed by the architect:
- Communication skills (persuasion, negotiation)
- Presentations
- Brainstorming and workshops
- Knowledge of architectural styles
- Wide horizons of modern technology (it is important to understand the strengths and weaknesses)
- Design and Application Skills
- Development skills using different frameworks, products and programming languages
- Knowledge of decision documentation frameworks
- Understanding the different types of SDLC (systems development life cycle)
- Wide network of professional connections
- Skills in managing development teams
Report 2
Architectural support of IT projects
Dmitry Romanov, ITSK
Designing IT solutions, architectural support of projects, about 80 projects a year, about 50 architects are involved in the process.
The service of the chief IT architect determines the technical policy in the field of IT, which was implemented by IT project architects. Answering the question where the architect usually gathers the necessary expertise, Dmitry indicated the following sources:
- Experience - creating similar systems
- Colleagues - someone within the company or in other companies
- Vendor - consultations with developers
- Thematic Forums
- Technopark - approbations or sandbox on the basis of Technopark
Considering the need for the role of an architect in ITSK, Dmitry pointed out that the architect of an IT project is needed so that, for example, there is no situation where they did the project for 1 year, then worked for six months and realized that there was no scaling, and then redid it for 2 years. A clear understanding is important that the proposed architecture can be implemented. Depending on the project management methodology, in ITSK the architect either enters into the team (if it is agile) or enters into the project expert group.
Report 3
Architecture in IT Projects: Key Emphasis
Ivan Lukyanov, Moscow Department of Information Technology, “Public Services and MFC” product
Professional biography of the speaker: developer at Diasoft, head of the development team (BSC Praha), leading consultant (Neoflex), head of the department of architecture and strategy at Alfa Bank, Head of the Department of Architecture Development (DIT).
Ivan recommends starting with a description of the existing architecture (as is), creating the target architecture (to be) and analyzing the difference between the points “where the organization is now” and “where the organization wants to go” describe the steps to bring the system to the target state.
The main focus of IT projects in architecture:
- Statement of the business problem to be solved: the architect must ensure that the business task is well posed, described in a form suitable for design, agreed by the people responsible for the business
- Vision of the way: by the efforts of architects in the organization, the target architecture of the organization should be developed for the specific needs of the business. The target architecture should be broken down into concrete steps (projects) to achieve it.
- Design: all solutions are designed taking into account the developed target architecture. Target architecture is implemented incrementally from project to project. The architect approves the decision regarding architecture.
- Project implementation process: the organization should have a process that includes analysis and description of business tasks, development of the target architecture and the design process (development and operation were not covered in the report). The process should be agreed by all parties involved and supported by management.
- Methodological support for the project implementation process: very often it is the architect who becomes the figure on whose shoulders lies the development of a methodology for the implementation of IT projects in an organization, taking into account the formulation of a business task and design. As part of this work, adjustments can be made to the existing process of implementing IT projects in the organization (if there was one before) or the creation of a new process from scratch (if it did not exist). The result of the methodological work is the described process and the supporting documents, formalized in the form of templates.
The company has now developed its own methodology, including templates used in the work of documents. The principles of TOGAF and Gartner were used .
The architectural principles were approved, the document “Architectural and technological solution” was developed, which describes the business requirements for solutions and the project for their implementation.
Features of the architect:
- Sociability. Communication with management, with performers, with support, with managers and testers is important. The architect must play the role of a translator - translate from the language of business to technical and vice versa.
- A prerequisite is the experience of the developer (well, if also analytics).
- Respect for colleagues.
- Continuous development.
Architecture is not a motionless monument cast in granite, but a living, evolving view of what we want to achieve in terms of business support.
Report 4
IT project architect: one of the possible points of view
Eugene Aslamov Aslamov , Lead Architect, SC Cheeks.
Eugene’s path to the role of architect: developer, analyst, project manager. During the short story, the author raised several issues related to the role of the architect in custom development: what surrounds him, what he does and how he does it.
In the opinion of Eugene, speaking about the architect in custom development, we are dependent on various factors - the timing, budget, team, complexity and volume of tasks. As a rule, in complex projects (several thousand user scenarios, integration with a couple of dozen systems, large data volumes, severe requirements for High Availability & Disaster Recovery), architectural tasks are closed by a group of architects. On more modest projects, one person can cope with these tasks and the architect is not always dedicated to the tasks - his role can be combined with other roles - the lead developer or analyst.
An architect, like any team member, works in a certain context. One outline of this context:
Customer
- the highest (in any case, high enough for key decisions) management from the customer in charge of the project;
- customer committees (architectural, design, operation, etc. - it happens a lot);
- service or department of information security specialists;
- customer’s employees who need a system that “burn” the project;
- realities - a rather banal routine, human factor, procedural issues, minor disagreements, etc .;
Command
- Managers
- Analysts
- development;
- DevOps
- quality service;
the contract
- deadlines;
- budget;
- legal quotes;
- new technologies, approaches, chips that I really want to apply;
- traditions: it works and it’s good, everything is fine with us - what to change and the like.
As part of the context, an architect or group of architects does the following:
- It forms the boundaries for the team in which the project will develop and live. First of all, we are talking about boundaries arising from non-functional requirements.
- Forms, supports and updates architectural solutions taking into account the views of key stakeholders.
- Works as a interpreter - translates from technical into Russian and vice versa. Actual for both the customer and the team. The architect must understand all aspects of the project (along with leading analysts and the project manager) and be able to explain their relationship with the technical parts.
- Asks a lot of unpleasant questions. It just so happens that some decisions were made without the participation of one or another member of the team. This is normal. If something has been done and is affecting or may affect the architecture of the system, then you need to find out the reasons in order to figure out whether you need to change something now, provide for some measures for the future, or you can simply record and leave it until better times.
Answering the question “How does he do this?”, Eugene first of all touched upon the issue of developing architectural solutions. Several components were identified that help in this task:
- Experience and analogies. This is one of the most important assets of the architect. And it needs to be constantly increased - not to stagnate in one project, technology, etc.
- Horizon. You can not use your own experience - the experience of colleagues, the experience of communities, standards.
- Prototypes. In the case of using a new, untested or with visible risks, prototyping is necessary. At the same time, it is important to correctly and accurately formulate the questions that the prototype must answer, otherwise it can only worsen the situation.
- Protecting your decisions. Before the project team, before the architectural committee (yours or the customer's), in front of yourself. As one of the solutions can be the introduction (full or individual elements) of ATAM - Architecture Tradeoff Analysis Method . In a number of our projects, for example, decision protection is implemented as the presentation of key decisions to colleagues outside the project for alternative opinions and comments.
Instead of a conclusion: one of the informal tasks of an architect, and of any specialist who loves his job, is to popularize knowledge, technologies, approaches, and skills that will allow the team to solve problems on a project more efficiently and with greater convenience.
Eugene's article on habr “ We are preparing a project at Sparx Enterprise Architect. Our recipe . "
Questions and answers
Next was a section of questions and answers, the most remembered can be read below.
Where do architects come from?
Gennady:
Software architects - former team lead or lead team or lead developers.
Dmitry:
Architects are taken from developers from consultants, with wide expertise.
The developer can speak and draw presentations - solution architect.
Eugene:
In general, from any part - from development, testing, project management, etc. But in any case, some technical specializations help - they do not have to be developed from scratch.
An example from personal experience: a student from the mechanics department of Moscow State University, an intelligent, sociable person without star disease, was taken to the Lanit company. He worked a little in analytics, development, communication with the customer. As a result, he became an applied architect in our company.
Ivan:
From the developers. If there is a good developer, then he can continue to delve into programming languages, develop deeper. But if, at the time, he was curious how the technical task was born, who analyzes, who makes the decision whether this should be done or not, then this is a signal that the specialist has embarked on the path of a novice architect. The next level of curiosity is how a solution is born as a whole, at the business level. How can you show the head of the organization that he needs it and what does not. Gregor Hohpe uses elevator metaphor to describe the role of an architect.. Each floor where the elevator stops is a certain level in the organization: the first floor - the machine room - these are developers, production; top floor - organization management. Bringing architecture to life, the architect communicates on each floor (from the first to the last) and on each floor he has to cope with various difficulties - technological, political, communication.
The architect is able to collect the necessary information and convey to each level. In fact, he acts as a mediator between the parties involved.
How should authority be shared between the project manager and the architect?
There must be a balance between authority. The authority of the architect lies in the technical part, and the project manager in the organizational part.
In the event that the balance is shifted towards the RP - you can get the project on time, but not working or not scalable. And, if towards the architect, then you can get a wonderful project when no one needs it. This is how to answer the questions "Who do you love more - mom or dad?"
How to be corporate architects who have a large flow of different projects?
Ivan:
In large organizations, more than 2,000 people make one corporate architecture and it is almost impossible to follow it. In DIT, a division is made into products (services), each product has its own technology stack, its own architecture. As for corporate architecture, shareholders need it more so that they understand where the organization is heading in terms of architecture development. For this purpose, the role of Chief IT architect is often highlighted in organizations, the main task of which is to determine the overall landscape of corporate architecture.
How is the interaction between the project architect and the corporate architect built?
Communication is important. You need to build communication and just communicate. A project architect may not need knowledge of corporate architecture, but it is important to know who the integration will be with and what the impact will be. It is important to make architectural committees, it is possible to know there not only corporate architects, but also design ones.
You can look at it in terms of value - who brings more value. If the solutions work, then there is value. Enterprise architecture in itself does not bring value, but it brings value through a solution of architects who already implement specific tasks.
No one needs generalists — less and less are people who know nothing about everything. It is better to be able to answer specific questions, for example, is RabbitMQ enough here or is Kafka needed.
How are enterprise architectural repositories organized?
Are there any complex models that can be calculated, verified, etc.?
Eugene: we have an architectural repository, but there is no automation for calculating any metrics. The relations between the models and the models themselves allow us to consider architecture as something integral, rather than a set of pictures. One of the tasks of the repository is to provide impact analysis. On this basis, you can make an estimate of the value of the changes.
Afterword
It's great that you can come and listen to the architects, get to know the community. Such meetings are always an opportunity for me to understand where to dig in order to find the necessary knowledge. In addition, you can discuss working cases and get a recommendation.
Thanks to Maxim Smirnov and HSE for organizing a round table of architects!
Also many thanks to the authors of the reports (Evgeny Aslamov, Gennady Kruglov, Ivan Lukyanov) for the preparation of this text , since the original notes were written during the reports and contained errors and inaccuracies that were corrected. Pictured is Chambord
Castle in France, they say, each owner built on his turret. Sometimes, the architecture of a project looks that way. In my opinion, an architect is needed so that everything is beautiful and as simple as possible, so that even with a bunch of towers in different styles, you would still get a beautiful castle.