Я провел 6 Unified Assessment сессий на Солюшен Архитектора (SA) в этом году и несколько в прошлом (что это такое смотрите в конце сообщения). И я вижу большую проблему с пониманием того, кто такой Архитектор, его роль и обязанности. Большинство кандидатов и их руководителей не понимают кто такой SA, что он должен делать, и чем он отличается от разработчика. Кроме того, у всех отсутствует системный подход к созданию архитектуры.

Эта проблема давно известна, и ее решением ЕПАМ активно занимается. Для этих целей, например, была создана год назад Architecture Excellence Initiative. Но неделю назад у нас была очень печальная сессия. Мы даже не начали разговаривать на темы относящиеся к архитектуре. Это было как разговор на разных языках. Причем я знаю этого человека как очень толкового и ответственного технического специалиста и, уверен, если ему дать реализовать часть системы (прямоугольник на диаграмме), он выполнит эту задачу очень и очень хорошо. Но он даже не знает, что делать, какие вопросы задавать и как спроектировать результат, о котором мы спрашиваем.

Подход к решению

Это проблема, которую нужно исправлять. Как я говорил над ней сейчас работают многие люди в ЕПАМ. Должность SA возникла не на пустом месте, есть требование бизнеса и стратегии развития компании, в которой SA играют ключевую роль (тот самый пресловутый PDS 2.0 и Digital Engagement). Я не претендую на полное покрытие функций SA, но я хочу показать, чем же солюшен архитектор отличается от других ролей. В презентации, которая дается в ЕПАМ, это крутой девелопер + BA +PM + Sales + … Это все круто, но тут нет ничего специфичного для SA, хотя оно есть. И все это знают. Например, почему SA не может быть в narrow stack (чистый Mobile development, Front-End development), и мы всех заворачиваем на Асэсменте и говорим: нам нужны сервера, базы данных и прочее.

То что отличает SA от остальных – это, как минимум, умение задизайнить солюшен. И вот этот процесс дизайна я хочу показать. Показать в виде серии тренингов и вэбинаров для AEI, а так же внедрения практики вайтбординга.

В следующей статье я покажу, как анализировать требования и перейти от них к логическому представлению системы в виде диаграммы (а от нее уже к остальным видам диаграмм). Подход не полный и упрощенный, но, ИМО, он дает представление о том, что архитектура не появляется на пустом месте. Каждый элемент на диаграмме должен решать конкретную задачу и отражать какое-либо требование.

Результаты

Я опробовал этот подход на встрече Архитектурного комьюнити, и он показал себя отлично. Мы не успели за час разобрать все аспекты системы и требования (продолжим в следующий раз), но у нас получился отличный результат, который уже сейчас можно использовать.

Кейс для вайтбординга:

Customer is a government who wants to provide fines history for their citizens (road tickets, police fines, etc.). Customer provided you with following requirements:

• Solution should include web application, backend and data storage
• Web application should support different browsers and client devices with the adjusted view for each device.
• Backend should provide high performance, for thousands of users.
• Application should support scale-out approach
• Continuous Delivery
• Zero-downtime deployment
• Detailed Monitor across multiple components
• Logs analysis and errors detection

P.S. Что такое Unified Assessment. В EPAM, получить следующий тайтл можно только через Unified Assessment комитет, в котором участвуют специалисты того же уровня, на который ты претендуешь или выше. Например, архитектором может стать только человек, которого одобрили 3 или более архитектора из 3х разных стран.