Round Table "IT Project Architect", September 2018

On September 5, a round table “IT Project Architect” was held in Moscow at the HSE. The organizer of the round table, Maxim Smirnov, keeps a blog about architecture and a channel on Facebook .

I am very glad that such events are held. Becoming a cool architect was and remains my dream. For a very long time it was not clear to me how they generally get into architects, how to develop and what directions to choose, so that they lead to architecture, and I think that such questions arise not only from me. It is great that there is a community where you can come and ask questions to the architects.

At the round table 4 reports were presented for 15-20 minutes, after which there were questions from the audience and discussion.
')
The reports were brief and to the point, and the discussion is very lively and detailed.



Further my notes in the course of reports.

Report 1
Key skills for decision architect in projects from scratch

Gennady Kruglov
Certified SOA Architect, ctn

The presentation covered the main stages of the architectural process:

1. Business engagement
2. Engaging engineers.
3. Prototyping
4. The choice of architectural style and technology stack (microservices, monolith, SOA).
5. Development draft architecture.
6. Demonstration to the customer.
7. Solution design.
8. Documenting arch decisions.
9. Architectural supervision.

Highlights:

It is advisable to make a prototype to show it to the business. When choosing an architectural style, if possible, you need to involve different parties - developers, security, operation. When developing a sketch, you need to make different sections of the architecture - business, technology, security.

If possible, it is necessary to involve people who will then directly work with this part of the system.

After discussion with stakeholders, a prototype is demonstrated. If the project starts, a more detailed study of each level of architecture is performed.
When developing, synchronization with the architect is necessary in order to verify that the process follows the chosen path.

Skills, which according to the speaker, the architect needs:

• Communication skills (persuasion, negotiation)
• Presentations
• Works of brainstorming and workshops
• Knowledge of architectural styles
• Wide outlook of modern technologies (it is important to understand the strengths and weaknesses)
• Solution and Application Design Skills
• Development skills using different frameworks, products and programming languages
• Knowledge of decision documentation frameworks
• Understanding different types of SDLC (systems development life cycle)
• A 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 per year, about 50 architects participate in the process.

The Chief IT Architect service determines the technical IT policy that was performed by IT project architects. Answering the question where the architect usually gains the necessary expertise, Dmitry pointed out the following sources:

1. Experience - creating similar systems
2. Colleagues - someone within the company or in other companies
3. Vendor - consulting with developers
4. Subject Forums
5. Technopark - approbation or sandbox on the basis of Technopark

Considering the need for the role of the architect in ITSK, Dmitry pointed out that the IT project architect is needed so that, for example, there is no situation when they did the project for 1 year, then worked for six months and realized that there was no scaling, and then they remade it for 2 years. It is important to have a clear understanding that the proposed architecture can be implemented. Depending on the project management methodology, the ITSK architect either enters the team (if it is agile), or enters the project expert group.

Report 3
Architecture in the organization's IT projects: main accents

Ivan Lukyanov, Moscow Department of Information Technology, product “Government services and the MFC”

Professional biography of the speaker: developer in Diasoft, head of the development team (BSC Praha), lead consultant (Neoflex), head of the direction 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), forming a 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 into a target state.
The main emphasis of IT projects in terms of architecture:

• Setting the business problem to be solved: the architect must ensure that the business problem is well-defined, described in a manner acceptable for design, agreed by the people responsible for the business
• Vision of the way: the efforts of the architects in the organization should develop the target architecture of the organization for the specific needs of the business. The target architecture should be broken down into specific steps (projects) to achieve it.
• Design: all solutions are designed taking into account the developed target architecture. The target architecture is implemented incrementally from project to project. The architect approves the decision in terms of architecture.
• Project implementation process: the organization should have a process that includes the analysis and description of business tasks, the development of the target architecture and the design process (development and operation were not covered by the report). The process must be agreed by all parties involved and supported by management.
• Methodological support of the project implementation process: very often it is the architect who becomes the figure on whose shoulders the development of a methodology for implementing IT projects in an organization falls, taking into account the formulation of a business problem and design. As part of this work, adjustments can be made to the already existing process of implementing IT projects in the organization (if there was one before) or creating a new process from scratch (if it was not there). The result of the methodological work is the described process and its supporting documents, formalized in the form of templates.

The company has now developed its own methodology, including templates for documents used in the work. The principles of TOGAF and Gartner were used.

Architectural principles were approved, a document “Architectural and technological solution” was developed, which describes business requirements for solutions and a project for their implementation.

Architect traits:

• Sociability. Communication with the management, with executors, with support, with managers and testers is important. The architect must play the role of translator - translate from business to technical language and vice versa.
• Mandatory requirement - the experience of the developer (well, if you also analyst).
• Respect for colleagues.
• Continuous development.

Architecture is not a fixed 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 Possible Point of View

Evgeniy Aslamov Aslamov, leading architect, GK Lanit.

Eugene's path to the role of the architect: developer, analyst, project manager. During the brief 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 Evgeny’s view, speaking of the architect in customized development, we become dependent on various factors — timing, budget, team, complexity, and scope of tasks. As a rule, in complex projects (several thousand user scenarios, integration with a couple of dozens of systems, large amounts of data, and stringent requirements for High Availability & Disaster Recovery), architectural tasks are closed by a team of architects. On more modest projects, one person can cope with these tasks and the architect who is not always allocated for the tasks - his role can be combined with other roles - the lead developer or analyst.

An architect, like any team member, works in some context. One of the sketches of this context:

Customer

• higher (in any case, high enough for making key decisions) guidance from the customer, supervising the project;
• customer committees (architectural, design, operation, etc. - there are many different ones);
• service or department of information security specialists;
• Customer’s employees who need a system that “burns” with a project;
• realities - a rather commonplace routine, human factor, procedural issue, minor disagreements, etc .;

Team

• managers;
• analysts;
• development;
• DevOps;
• quality service;

the contract

• deadlines;
• budget;
• legal habits;
• New technologies, approaches, chips, which really want to apply;
• traditions: it works and well, everything is fine with us - what to change and so on.

Within the context, an architect or group of architects does the following:

• 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.
• Generates, maintains and updates architectural solutions, taking into account the views of key stakeholders.
• Works interpreter - translates from technical to 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 so happens that some decisions were made without the participation of one or another team member. This is normal. If something has been done and is affecting or can affect the system architecture, then you need to find out the reasons in order to figure out whether you need to change something now, provide some measures for the future, or you can simply write down and leave for better times.

Answering the question "How does he do it?", Eugene touched first of all the question 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 must be constantly increased - not to stagnate in one project, technology, etc.
• Horizon. You can use not your own experience - the experience of colleagues, the experience of communities, standards.
• Prototypes In the case of using 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 should answer, otherwise it can only worsen the situation.
• Protect your decisions. Before the project team, before the architectural committee (their own or the customer), before themselves. As one of the solutions, the implementation can be (full or individual elements) of ATAM - Architecture Tradeoff Analysis Method . In a number of our projects, for example, decision protection is implemented as a presentation of key decisions to colleagues outside the project in order to obtain alternative opinions and comments.

Instead of a conclusion: one of the informal tasks of the architect, and any specialist who loves his job is to popularize the knowledge, technologies, approaches, skills that will allow the team to solve tasks on a project more efficiently and with greater convenience.

Eugene's article on habr “ Preparing a project in Sparx Enterprise Architect. Our recipe .

Questions and answers

Next was the question and answer section, the most memorable can be read below.

Where do architects come from?

Gennady:
Software architects - former team leads or those leads or leading developers.
Dmitriy:
Architects are taken from developers from consultants with extensive expertise.
The developer can speak and draw presentations - a 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 Faculty of Mechanics and Mathematics of Moscow State University, an intelligent, sociable person without star disease, was taken to the Lanit company. A little work 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, to develop further. But if, in his time, he was curious how a technical task is born, who analyzes, who decides whether or not to do it, then this is a signal that a specialist has started on the path of a novice architect. The next level of curiosity is how a decision 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. When describing the role of architect Gregory Hopp (Gregor Hohpe) uses the elevator metaphor . Each floor where the elevator stops is a certain level in the organization: the first floor - the computer room - these are the developers, the production; the last floor is the management of the organization. Embodying architecture into life, the architect communicates on each of the floors (from first to last) and on each floors he must 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 the authority be shared between the project manager and the architect?

There must be a balance between powers. The authority of the architect lies in the technical part, and the project manager in the organizational part.

If the balance is biased towards the RP - you can get the project on time, but not working or not scalable. And, if in the direction of the architect, then you can get a great 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. DIT made a division into products (services), each product has its own technology stack, its own architecture. As for the corporate architecture, shareholders need it more so that they understand where the organization is moving in terms of the development of architecture. For this purpose, organizations often distinguish the role of Chief IT architect, whose main task is to determine the overall landscape of corporate architecture.

How is the interaction between the project architect and the corporate architect?

Communication is important. It is necessary to build communication and just communicate. A project architect may not need a knowledge of corporate architecture, but it is important to know with whom the integration will be 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 project ones.

You can look at it in terms of value - who brings more value. If solutions work, then there is value. Enterprise architecture itself does not bring value, but it brings value through solution architects who are already implementing specific tasks.

Nobody needs generalists - people who know nothing about everything are less and less needed. It is better to be able to answer specific questions, for example, is RabbitMQ enough here or is Kafka needed.

How are architectural repositories organized?

Are there any complex models that you can shortcut, check, etc.?

Eugene: we have an architectural repository, but there is no automation for calculating any metrics. The links between the models and the models themselves allow us to consider the architecture as something holistic, and not a set of pictures. One of the tasks of the repository is to provide an impact analysis. On this basis, you can make an estimate of the cost of changes.

Afterword

It's great that you can come and listen to architects, get to know the community. Such meetings are always an opportunity for me to understand where to dig 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 roundtable 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.

In the photo is the Chambord castle in France , they say, each owner attached his turret. Sometimes, the project architecture looks like this. In my opinion, an architect is needed so that everything is beautiful and, if possible, just so that even with a bunch of turrets in a different style, you would still get a beautiful castle.