Как дорасти до уровня Solution Architect

Меня зовут Роман Шрамков, я занимаю позицию Technology Director в компании EPAM. Одна из моих зон ответственности — растить архитекторов, которые могут решать любые архитектурные задачи и самостоятельно находить свежие решения для наших заказчиков.

В статье я расскажу, в чем заключается роль Solution Architect, какие ключевые задачи выполняет такой специалист и как разработчику дорасти до этого уровня.

Выступление Романа Шрамкова на одном из Java Meet-up

Роль архитектора

Я бы начал с того, кем не является Solution Architect. Часто думают, что это самый квалифицированный разработчик или эксперт, который лучше всех знает технологический стек проекта. Это не совсем так. Безусловно, архитектор должен хорошо разбираться в технологиях проекта и понимать, что такое хороший код. Но у него есть и особенная функция, которую не выполняют разработчики и эксперты: он отвечает за формирование, документирование и коммуникацию общего технического решения для всей системы.

Чтобы было более понятно, что я имею в виду, рассмотрим аналогии из других индустрий. Например, в чем заключается роль архитектора в строительной сфере, чем он отличается от прораба, каменщика или штукатура? Посмотрим на это глазами клиента. Я как заказчик буду привлекать к работе архитектора в том случае, если мне надо что-то построить, а я сам не являюсь экспертом в строительстве и понимаю, что не могу сам продумать все детали на профессиональном уровне.

При этом я обращусь к архитектору на самом первом этапе проекта, когда я еще не начал что-то строить и даже закладывать фундамент. У меня есть идея — к примеру, построить спортивный стадион. И мне интересно, можно ли вообще реализовать мой проект так, как я задумал, и если можно, то каким образом.

Придя к такому профессионалу, я ожидаю, что он задаст мне правильные вопросы: «Что именно вы строите? Для каких целей?». Потому что, например, стадион для футбола и арена для соревнований по легкой атлетике будут иметь разную форму и разные функциональные зоны. Идем дальше: если это футбольный стадион, то кто там будет играть, национальная сборная или школьная команда? От этого зависит размер площадки, количество посадочных мест для болельщиков.

Когда архитектор выяснил ключевые функциональные и нефункциональные требования к проекту, он разрабатывает концепцию решения и делает эскиз будущей постройки. Затем — презентует решение заказчику, чтобы тот убедился, что это действительно то, что нужно. Это высокоуровневая (то есть общая, не детализированная) архитектура решения. На этом же этапе, как правило, обсуждают бюджет: архитектор дает примерные оценки стоимости проекта.

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

В IT распределение ролей аналогичное, хотя и имеет свои особенности. Solution Architect выясняет потребности заказчика, разрабатывает концепцию программного решения, а затем передает проект тимлидам разных направлений для технической реализации.

Ключевая разница заключается в том, что процесс, который я описал выше, — очень вотерфольный. В строительной сфере сначала создают полную проектную документацию и только после этого приступают к возведению объекта. В IT мы подходим к разработке софта гибко, часто сделать финальную архитектуру сходу слишком сложно. Архитектор вместе с командой двигается итеративно, сопровождая проект на этапе реализации, постоянно уточняя требования и внося необходимые элементы в архитектуру, помогает команде решать технические сложности, возникающие по мере движения.

Ключевые задачи Solution Architect

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

Технологическое исследование и прототипирование. Обычно на старте проекта архитектору могут быть неизвестны некоторые нюансы применения необходимых технологий, поэтому возникает необходимость глубже изучить и разобраться в возможностях и ограничениях тех или иных решений. Для этого он разрабатывает прототипы — маленькие части системы, которые нужны для того, чтобы убедиться, что те идеи, которые придумывает архитектор, действительно являются рабочими.

Архитектура конечного продукта. Сформировав техническое решение, Solution Architect презентует его заказчику и согласовывает все детали. На этом этапе архитектор подготавливает описание высокоуровневой архитектуры или каких то ее частей, находящихся в проработке.

Детальную документацию по низкоуровневому дизайну в современном IT делают не так часто. Связано это с тем, что Solution Architect в гибких проектах плотно коммуницирует с командой, объясняет архитектуру, ее идеи, возможности и ограничения. Низкоуровневый дизайн делается по ходу разработки и сразу попадает в код. В свою очередь, команда дает обратную связь об архитектуре, все ли получается реализовать и какие есть сложности.

Общий контекст (helicopter view). В большинстве проектов каждая команда работает над своей частью решения, и для крупных систем должен быть кто-то, кто понимает картину архитектуры в целом, общие принципы и соглашения.

Именно Solution Architect — тот человек, который смотрит на разработку системы как бы сверху. У него есть четкая картина архитектуры будущего продукта и всех ее частей, которую он «прорисовывает» в виде различных схем, диаграмм и представлений.

Конечно, один человек не может детально разбираться во всем. Главная задача архитектора — видеть общий контекст и правильно координировать работу различных технических направлений. Например, если при миграции нужно будет учесть какие-то рекомендации специалиста по безопасности, то архитектор проекта должен проконтролировать, что об этом не забыли.

Выступление Евгения Моспана из Java Competence Centre, EPAM и Alex Lomov, Cybergizer, Cloud Foundry Engineer на SEC 2018

Как стать архитектором

Solution Architect — естественная следующая ступенька для сегодняшних senior разработчиков или тимлидов, которые хотят развиваться как инженеры. Как правило на этих ролях люди уже имеют глубокое знание хотя бы одного технологического стека, они вовлечены в низкоуровневый дизайн компонентов и понимают, что вывод в прод и эксплуатация системы требуют намного больше, чем просто написание кода, который запускается.

Для подготовки таких специалистов есть курсы (у EPAM курсы двух уровней — Solution Architecture School и Solution Architecture University). Можно найти опытного архитектора и советоваться с ним в вопросах архитектуры и развития. Также можно присоединиться к комьюнити архитекторов, чтобы узнавать о новых технологиях, участвовать в architecture katas (упражнение на дизайн решений) и других полезных мероприятиях.

Если вы развиваетесь самостоятельно, то следующие шаги помогут вам вырасти в архитектора решений:

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

2. Работайте с бизнесом и менеджментом. Участвуйте в обсуждениях бизнес-целей и проблем клиентов, смотрите на задачи не только с точки зрения кода и технологий, но и с точки зрения проекта в целом. Привносите в проектные и бизнес-обсуждения техническую точку зрения, но делайте это с пониманием интересов и проблем других участников проекта.

3. Прокачивайте навыки коммуникации и презентации. В отличие от тимлидов, фокус которых — технологии и разработка, архитектор — одна из ключевых фигур в общении с заказчиком и проектным менеджментом. В его зоне ответственности — переговоры и презентация технических решений от идеи до конечной реализации. Этот специалист должен уметь хорошо объяснять и отстаивать свою точку зрения, а также слушать и понимать собеседника. Конечно, это не получится без хорошего уровня английского.

4. Разберитесь с базовыми практиками в архитектуре. Архитектура — не новая дисциплина, по ней написано много книг. Обязательно познакомьтесь с ними и возьмите на заметку определенные подходы: работа с функциональными и нефункциональными требованиями, рисование понятных диаграмм, грамотное составление технической документации проекта.

Необходимые знания также можно почерпнуть из ряда фундаментальных книг об архитектуре:

Если вы нацелены на построение архитектуры сложных энтерпрайз-проектов, я советую получить сертификацию от американского SEI или европейского Iasa. Тут важна не столько сама «корочка», сколько процесс подготовки — он поможет систематизировать знания. Кстати, у SEI есть целая серия книг, которые описывают ключевые практики, — их тоже можно использовать как базу.

Хочу отметить, что рост в архитектора доступен не только для разработчиков. Например, QA у нас могут развиваться в направлении QA Architect, которые строят систему оценки качества для продукта; DevOps — могут развиваться в System Architects, которые проектируют CICD и различную автоматизацию; бизнес-аналитики могут расти в Product Managers, а проектные менеджеры, которые не против углубиться в техническую часть, — в Delivery Managers.

Каким был мой путь

Конечно же, никто из нас одним прекрасным утром вдруг не просыпается архитектором — развитие происходит постепенно. Человек нарабатывает опыт на разных проектах, учится смотреть на систему и технологии максимально широко, не зацикливаясь на одном стеке или инструменте.

В нашей компании однажды пришли к тому, что для того, чтобы получить хороший проект нужно давать заказчику не просто экспертизу разработчиков, которые умеют писать код, а консультантов, которые смогут посоветовать определенные решения исходя из потребности бизнеса. Мне было интересно вовлекаться в эти активности и принимать участие в формировании первоначальной концепции будущего решения на старте.

Постепенно я понял, что уже могу сам решать большинство вопросов при проектировании будущей системы. Кроме этого, я научился вовлекать других людей в решение технических задач по более узким направлениям, строить архитектурные команды на проектах. Так после 10 лет работы только с кодом у меня появился новый вызов, взять на себя обязанности Software Architect и затем — Solution Architect.

Сейчас я занимаю позицию Director of Technology: выступаю в роли посредника между бизнесом клиентов и техническими командами, но уже не в одном проекте, а на уровне компании. Подробнее об этом я рассказывал в рубрике «Как я работаю» на DOU.

Перспективы карьерного развития

В каждой компании могут быть разные карьерные пути. Сперва расскажу на примере EPAM. У нас есть три карьерных уровня:

  • A-track — это разработчики, девопсы, тестировщики и другие технические специалисты;
  • B-track — менеджмент, в том числе и Solution Architect как «технический менеджер» проекта;
  • C-track — топ-менеджеры, которые выполняют ключевые функции на уровне компании.

Сама по себе позиция Solution Architect — это уже отличный карьерный шаг для инженера: вы попадаете в B-track, где от вас ожидается определенный уровень зрелости и где вас ждет соответствующий уровень задач.

В свою очередь, карьерный путь архитектора состоит из пяти ступенек:

  • SA-1 знает базовые практики по архитектуре и имеет высокую экспертизу как минимум в одном технологическом стеке;
  • SA-2 имеет практический опыт работы архитектором, работает уже в нескольких технологических стеках, может самостоятельно вести средние по размеру проекты;
  • SA-3, или Senior Solution Architect, как правило является экспертом в какой либо большой технологической либо бизнес-области, способен вести серьезные проекты и представлять компанию на уровне аккаунта;
  • SA-4, или Director of Technology, играет лидирующую роль, часто отвечает за управление технологической частью в крупных программах;
  • SA-5, или CTO, возглавляет крупные технологические направления глобально, на уровне компании или крупного аккаунта.

Если вы работаете в менее крупной компании, то позиция Solution Architect хороша тем, что сочетает в себе высокую техническую экспертизу и определенную управленческую компетенцию. С этой позиции вы можете развиваться в разных направлениях. Во-первых, вы можете расти как успешный архитектор решений и быть востребованным на рынке и в компании на ключевых позициях в самых сложных и интересных проектах, особенно на старте. При определенной доле опыта и менеджерских амбициях, вы можете замахнуться на позицию CТO компании и помогать строить правильную технологическую стратегию ее развития. Во-вторых, вы сможете развиваться как консультант или пресейл специалист, который больше работает с клиентами и часто путешествует он-сайт.

Если у вас есть вопросы о позиции Solution Architect, пишите в комментариях, постараюсь ответить.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному14
LinkedIn

Схожі статті




46 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Печально что

A-track — это разработчики, девопсы, тестировщики и другие технические специалисты

т.е если ты хочешь расти (а все хотят расти), тебе надо идти в менеджеры, архитекторы и т.д. Вполне логично, что есть люди которым нравится кодить и не очень нравится менеджить, продавать решения заказчику и в том же духе. И очень жаль, что обычно для них не создают career track.

Расти куда?

По ЗП? — так ЗП вам платит бизнес за решение задач, если бизнесу не приходят задачи сложнее чем может решить обычный Senior SE зачем ему кого-то растить?

Но к примеру у условного Google такие задачи есть и вы всегда можете пройти собеседование и устроится к ним на работу.

Второй вопрос а куда расти Senior SE? Из технических направлений «без людей» это только Software Architect ну или учёный который разрабатывает алгоритмы. Архитекторов учат большинство наших крупных аутсорсеров, а учёных у нас практически нет и учить собственно некому.

Да, в том числе и по зп, по технологиям, личностный рост и т.д. Я не соглашусь с вами, бизнесу возможно не приходят задачи сложнее чем может решить обычный senior se, но бизнесу не нужно 10 архитекторов, поэтому senior se будут уходить в другие конторы (в приведенном примере, в гугл). В принципе, так сейчас и происходит, и я думаю это устраивает аутсорсеров.

Но если у вас продуктовая контора и вы хотите, чтобы люди остались с вами надолго, то стоит подумать о треке для тех, кто не хочет «дорасти до уровня Solution Architect», а хочет развиваться в техническом плане.

Кажется, я нашел новую цель. Статья немного потушила меня, появилась мотивация двигаться дальше. Спасибо!

Ото сидить девелопер/тімлід такий на кікофф мітингу з архітектором, дивиться на діаграмки кольорові на яких все красиво розмальовано, потім приходить за свій стіл, сідає, зітхає...
І починає писати все як може/знає. А архітектура так і залишається в картинках та загальному хайлевелі «отут у нас інтеграція через кафку» а з часом стає повністю відповідною закону Конвея.

www.joelonsoftware.com/...​ure-astronauts-scare-you

Я думаю история таки не полная. Потом приходит тимлид на рабочее место, зовет джуна и говорит ему какие архитекторы таки идиоты, и как он умно и по правильному он все придумал. Джун понимает где-то 10% из того, что ему тимлид расказывает, но работой своей дорожит, поэтому бесстрашно идет в гугл и на стековерфлоу, и делает код, который ну точно работает.

На мой взгляд, во всей истории не в архитектуре дело, а в том, что люди на проекте не знают как правильно делать свою работу. Это можно и нужно исправлять.

Щось цій казочці не так.
Якщо тімлід забє на загальну архітектуру, то його проект тоді не зможе інтегруватися з іншими продуктами. Тим більше в беклозі одразу будуть заведені епіки. Якщо він забє на щось, що загальну архітектуру не афектить, то має на те право, бо всетаки архітект не є

самый квалифицированный разработчик или эксперт, который лучше всех знает технологический стек проекта

. А будь то архітект, який ще і робити щось вміє, то він сяде і за тиждень накидає костяк заклавши ту архітектуру і вкомітить то в репозиторій, скинувши кожному тімліду лінку на конкретно їх репозиторій. Далі тімлід що хоче те і робить в своєму полі діяльності. А до джуна дійдуть таски запиляти якийсь новий скрін або впихнути пару foreach. Джун то як зможе так і зробить. Також його право. На код-ревю мідли завернуть той код і заставлять переписати на for. Тобто все влаштовано так, що похибки бути не може. То або проект не потребував архітектора, або то не архітекти були ( поки я бачив за весь час одного Архітектора тільки ), або не тімліди, або не джуніки. Якосьтак.

Вот эта история мне намного больше нравиться, спасибо :)

А будь то архітект, який ще і робити щось вміє

В тому-то й прикол, що солюшон архітекти руками нічо не роблять, це просто продавці з техскіллами і їх основна IDE — це Visio навпіл з PowerPoint.

У нас это не так, большинство Solution Architects остаются hands on, делают прототипы и POC, постоянно ресерчат и пробуют новые технологии. Конечно это может быть по другому в других компаниях.

у... пєчалька у вас там... :(

Точно, архитекторы не нужны! Продавцы тоже! Ведь только код важен! И все бизнесы и компании существуют только ради того чтобы кто-то мог красиво писать в текстовые файлы и потом их запускать.

Ребят, вижу темы технолгий, архитектуры и технической карьеры многих интересуют. Напшите о чем еще было бы интересно почитать в этом разрезе. Если я что-то знаю по этому поводу, то поделюсь.

Интересная стаття, спасибо. A где в етой структуре с вашей точки зрения Enterprise Architect role? Как вы видете переход с ступени SA3 -> SA4 и с ступени SA4 -> SA5?

у нас начиная с СА3 архитекторы учавсвуют в программах Enterprise уровня и мы их обсучаем TOGAF и похожим фреймворкам. Так что можно считать, что СА3 это уже Enterprise Architect.

У нас переход на эти ступени СА4 и СА5 обычно предполагает ключевую роль и зону отвественности человека на уровне страны, большого клинета или на глобальном уровне (cross-country).

Ключевые задачи Solution Architect напоминают стэк Business Analyst + Product Owner. Я правильно понимаю, один Solution Architect может заменить Business Analyst’a и Product Owner’a?

Обычно все эти роли работают с заказчиком, чтобы определить видение конечного продукта и имеют много общего в навыках, техниках и подходах. Все же разница есть — БА\ПО отвечают за более детальную проработку продуктовой и функциональной части, архитектор отвечает за проработку технической стороны.

Могу сказать так, он не заменяет, а работает вплотную с... На примере Британских компаний могу сказать, что работа BA строят и упорядочивают все задачи и реквайрменты, ответственностью архитектора является уточнение деталей которые необходимы для построения технического решения и которые могли упустить из виду аналитики. Тут очень важно собрать все необходимые данные, чтобы понять какая нагрузка ожидает систему, количество пользователей и ожидаемый прирост, количество транзакций в день/час, количество посещений сайта.

С точки зрения Product Owner’a тоже не все так просто, у нас архитекторы не отвечают напрямую за ценовую политику, но должны давать предоставлять очень важные артефакты для уточнения, каков estimate по ресурсам / времени для выполнения конкретной задачи, плюс конечно нужно иметь представление по ценам на все те платные продукты, которые включаются в решение. Сколько стоят лицензии, фреймворки и т. д., и т. п. Целостную картину уже определяет Product Owner он же отвечает за выполнение плана.

Полностью поддреживаю, эти роли дополняют друг друга и описанная схема взаимодействия вполне рабочая.

Я бы еще добавил, что ключевая разница между дизайнером и архитектором в строительной сфере заключена в том, что архитектор знает свойства материалов и не создаст прототип, который не может существовать из-за физики. В IT создать можно все что угодно, просто неправильный выбор технологий приводит к потере времени и денег. А чтоб сделать самый правильный выбор — надо быть частью бизнеса. Потому что может оказаться, что заказчик из примера хотел подводный стадион для экзотических видов спорта. С насосами и аквалангами.

В каком то виде в IT архитектор тоже знает свойства технологий (материалов), которые он применяет в решении и в идеале имеет опыт работы с этими технологиями. Да частенько, бывает, что архитектор может не знать никаких свойств, а просто берет решение из последней статьи, которую прочитал в интернете и тогда происходит потеря времени, денег, репутации...

В IT создать можно все что угодно

 — да можно, но стоит прикидывать и реальную стоимоть, реалестичность и обоснованность такого строительства для проекта.

У меня так друг собеседовался на проект в США, спросил почему они выбрали Node.js, они сказали, что тогда это было модно.

Критерий нормальный и частенько применяется в разработчке софта :). В итоге для них это оказалось удачным решением?

Единственным и необходимым условием для регистрации в Solution Architect School in EPAM указан факт того, что соискатель является best Java Developer. С чем связана фиксация фокуса на определенном языке программирования? Если продолжить вашу аналогию со строительством, то — почему ваша компания в потенциальные архитекторы рассматривает лишь каменщиков? Причём работающих только с одним типом кирпича.

В SAS обучаются аритекторы из разных стеков, никакого фокуса в обучении на Java нет. Скорее всего речь идет о попаднии в САС при турдоустройстве и это дополнительное условие диктуется конктеным демандом.

На сайте epam.ua.tilda.ws/saslviv указано, что места для best Java Developer („Are you a Senior Java Developer? Have you already considered your next career move? ”)

А у статті написано

Часто думают, что это самый квалифицированный разработчик или эксперт, который лучше всех знает технологический стек проекта. Это не совсем так.

Походу і мідл зможе в архітектори піти))

Если он может кастомеру по очень быстренькому прототип налабать и лапши навешать, то вполне. Часто SA еще и обязанности presales выполняет

Да, СА занимается пресейлом, иногда он может полностью заниматься только этим. Но давайте будем честными про мидлов: лапшу мидл может навешать только такому же мидлу на стороне кастомера ;).

Со стороны кастомера часто бывают совершенно не технические люди

Бывают нетехнические. Если они не идиоты, то скорее всего, не верят просто наслово нашим мидлам. Вообще, если Вам кажется, что вам удалось заказчику повесить на уши лапшу, срочно проверьте свои собственные уши. Но это, конечно, субъективный опыт :)

Лапша в обобенном смысле, не обязательно неправда, которую часто впихивают настоящие сейлзы, лишь бы продать. Да и если чел пришёл с лычкой СА, кого там волнует что по чисто техническим скиллам он мидл а карьеру сделал на софт скиллах, что в реальности бывает сплошь и рядом.

Мидл не сможет, т.к. архитектор должен валидировать технические решения лидов команд или направлений базируясь на своем опыте и понимании общей архитектуры. Найдете мидла, который это может делать, дайте контакты.

Да, там речь идет о возможности для кандидатов, которые не работают в ЕПАМ. Поэтому есть конкретные входные требования. Внутри САС проходят без привязки к стеку.

А что скажете насчет «Чистой Архитектуры» Роберта Мартина и «Масштабирования приложений» Ли Атчисона? Стоит читать?

Читать стоит. В отношении подходов Роба Мартина — будте прагматичны, стоит попробовать и оставить то, что дейсвтительно приности пользу проекту.

стоит попробовать и оставить то, что дейсвтительно приности пользу проекту.

Как ввести критерии, что приносит, а что нет ? Часто у членов команды могут быть весьма различные представлении о прекрасном, а бизнесу зачастую вообще пофигу, что там за архитектура под капотом пока оно работает и проблем не доставляет.

Пользу для проекта я определяю довольно просто: если цели проекта понятны, то все что мне помогает их добиться — является полезным, а все что замедляет мой прогресс по отношению к целям — вредным или бесполезным.

Я не согласен, что бизнесу пофигу. Бизнес чувствует плохую архитектуру и плохое внутренее качетсво продукта по времени нужному на внесение простых изменений, по количеству рандомных дефектов, по ужасной производительности и неудовлетворенности конечных пользователей системы. Просто он не может вам сказать, что у вас плохая архитектура или плохой дизайн, он говорит в своих терминах — мы это не может продавать ...

Solution Architect — естественная следующая ступенька для сегодняшних senior разработчиков или тимлидов, которые хотят развиваться как инженеры.

Я думал происходит все так:
SDE => Team/Teach Lead => Application Architect => Solution Architect

Да, логика правильная, просто в нашей компании роль Application Architect может играть Team\Tech Lead, поэтому одельной ступеньки нет.

Solution Architect формирует архитектуру для всех проектов в компании, где нужна архитектура?
Или у каждого проекта свой Application Architect, который формирует и подерживает архитектуру? Тогда какая роль Solution Architect?

Конкретный подоход сильно зависит от компании. У нас проектов много и как правило они довольно большие, поэтому на проекте бывает и Solution Architect, который больше занимается общей архитектурой и несколько техлидов, работу которых супервайзит SA.

Получается что ответственность за архитектуру лежит на техлидах. SA фактически выступает в роли консультанта?
Или SA создает архитектуру(имеется в виду скелет), потом передает её тех лиду. И он уже эту архитектуру ведет и может обратится к SA за советом?
Все вопросы я задаю относительно EPAM.

Виктор, у нас огромное количество проектов, где это может быть организовано по разному. В целом может быть вариант, когда есть «пресейл архитектор», который учавствует в самых первых фазах энгейджмента и рисует архитекруту будущего решения на очень абстрактном, концептуальном уровне (тут хадуп, тут кафка, тут микросервисы). Далее такое понимание архитекртуры уходит в деливери, где есть группа архитекторов, котоыре это делатизируют и приземляют на конкретные требования и реалии проекта.

Как правило пресейл архитектор, делает транзишин того, что было продано, команде деливери и после транзишн фазы может больше в проекте не учавствовать т.к. его функция закончена. Деливери команда архитекторов может оставаться на проекте либо до конца, либо до того момента, когда девелопмент стал на рельсы и изменений в архитектуре не предвидятся.

Это один из вариантов.

Довольно интересно. Вопросов появляется все больше) Думаю эффективней будет почитать литературу. Спасибо что заинтересовали!

Спасибо за вопросы и коментарии, значит не зря статься вышла :).

Підписатись на коментарі