Последние двадцать лет привели к серьезной трансформации технологического ландшафта и работы архитекторов, которые за ним должны следить. Архитекторы работают с технологиями и людьми. Компьютерные технологии за последние десятилетия значительно изменились и продолжают это делать. Люди меняются не так быстро. Однако, для работы с людьми выделяются новые роли: продакт-менеджеры, прожект-менеджеры, тимлиды. Роль и влияние архитекторов не так велико, как раньше, они становятся прерогативой больших компаний.

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

История пойдёт от первого лица. От лица Игоря Симдянова, разработчика с 20-летним стажем, автора двух десятков книг по веб-разработке и базам данных, архитектором решений в «Нетологии».

Почему архитекторов не много?

Сейчас мы переживаем эпоху максимальной IT трансформации, это большой компьютерный «взрыв» обусловленный законом Мура.

Закон Мура это не совсем закон, скорее эмпирическое наблюдение одного из основателей компании Intel Гордона Мура. Заключается оно о том, что количество транзисторов на кристалле микросхемы удваивается каждые 18 месяцев. Если нарисовать график, где по оси Y будет количество транзисторов, а по оси X — время, получится экспоненциальная кривая. Закон Мура сформулированный в 1970 году оказался на редкость живучим и работает уже десятилетиями. Человеческое сознание не может развиваться так быстро, поэтому программные технологии развиваются скачками.

Всё это приводит к тому, что развитие технологий идет через «вехи». Ниже приводится примерный перечень, не претендующий на полноту:

1960 — появление операционных систем

1968 — разделение аппаратной и программной частей компьютера

1975 — первый микрокомпьютер

1980 — первая реляционная база данных

1990 — появление сети Интернет

1995 — появление поисковых систем 

2000 — гибкие методологии

2001 — первый многоядерный процессор

2002 — первое публичное облако (Amazon Web Service)

2006 — AMD-V виртуализация, открывается эра микросервисов

2010 — появление NoSQL

2013 — появление технологии Docker

2014 — появление Kubernetes

…

На графике ниже вначале представлен закон Мура. Где-то начиная с 2005 года по настоящий момент, рост замедлился. Об этом говорят эксперты отрасли.

Например, на днях глава Intel Пэт Гелсингер сообщил, что закон Мура замедлился и теперь составляет 3 года вместо 1,8. Это означает, что мы начинаем выходить на S-образную кривую, которая представлена на рисунке выше. Такова судьба любого взрывообразного процесса: рано или поздно «топливо» заканчивается, процесс замедляется и выходит на «плато». Переход от сборки электрических схем, к обрабатывающей технологии изготовления, послужило в свое время триггером для взрывообразного прогресса в микроэлектронике, а вслед за этим и в информационных технологиях. Теперь идет обратный процесс: трудности уменьшения типоразмера электрических схем, приводит к замедлению прогресса в микроэлектронике, что следом приведет к замедлению прогресса в информационных технологиях. Это не значит, что они остановятся, просто скорость замедлится до скорости развития других инженерных технологий.

Несмотря на замедление, информационные технологии сейчас находятся в зоне максимальной скорости. В IT вкладывают огромное количество денег и они приносят максимальный доход. В отрасль стекаются лучшие кадры и таланты. Фактически IT стал таким же драйвером инженерного развития, как космос в 1970-80 годах. К сожалению, это не навсегда.

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

Подробнее о последствиях остановки закона Мура можно прочесть в моей статье на Хабре.

Как возникли и архитекторы?

Понятие «Архитектор» возникло в 1970 году. Первым в обиход его ввёл Фредерик Брукс в работе «Мифический человеко-месяц». В книге он описал период своей работы, которая пришлась на эпоху отделения аппаратной части компьютера от программной. Аппаратной частью занимались конструкторы. Кто-то должен был взять на себя координирование разработки программной части, т.е. операционных систем. Для такой роли из строительной области заимствовали понятие «Архитектор».

Долгое время архитектор отвечал за всю программную часть компьютерной системы. Однако со временем стали появляться разные типы архитекторов. Как правило, появление нового типа архитектора было вызвано фундаментальным сдвигом в компьютерных технологиях — наступлением одной из «вех».

Для первых компьютеров практически всё программное обеспечение было заказным. Со временем готового ПО, коробочных решений, становилось всё больше. Это программное обеспечение должно было предсказуемо вести себя на разных компьютерах, быть совместимым друг с другом и с другим представленным на рынке ПО. Фактически появился новый тип компаний, зарабатывающих созданием программного обеспечения. Именно в этот момент возникает роль «архитектор предприятия» (enterprise-архитектор). Он обеспечивает технологическую целостность всего жизненного цикла создания программного продукта. Фактически, это предтеча современных бизнес-архитекторов, но с большим технологическим погружением.

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

На сегодняшний день типов архитекторов достаточно много:

• Системный архитектор (1970 год)

• Архитектор приложений (1980 год)

• Архитектор предприятия (1990 год)

• Сетевой архитектор (2000 год)

• Архитектор решений (2010 год)

• Data-архитектор (2015 год)

• ML-архитектор (2020 год)

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

Чем занимаются архитекторы?

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

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

Однако модель — всегда упрощение реальности. Если взять уравнение Ньютона и попробовать рассчитать расстояние, которая преодолеет летящая вверх пуля, получим ответ 25 км. В реальности она пролетит только 2 км. Это расплата за упрощение, пренебрежение сопротивлением воздуха.

В человеческом теле математики ровно столько, сколько нужно для его функционирования. Через зону Брока мы вытаскиваем эту математику в наш язык и сознание. Однако вселенная много больше человеческого тела и математики в ней тоже много больше. Поэтому идея Гильберта вывести математику из математики потерпела крах.  Гедель, Тьюринг, Черч 100 лет назад показали, что наша математика ограничена. То есть не только наши компьютеры не смогут изобрести недоступную нам математику, но и человек, и все созданные им вычислительные системы в этом ограничены.

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

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

Одной из первых моделей в IT-отрасли можно считать вклад Клода Шеннона. Только работал он не с компьютерами, а с электрическими схемами.

Заслуга Шеннона в том, что он впервые применил алгебру Буля к электрическим схемам. Это позволило перевести запутанную схему в уравнения и провести их упрощение (рефакторинг). Построив схему обратно, можно получить упрощённый вариант, который работает точно так же, как запутанный клубок в начале.

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

Так рождается архитектурно-экономический цикл когда модель проходит несколько итераций:

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

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

Гибкие методологии

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

Этому способствовало большой объем накопленных архитектурных знаний. С момента создания первых компьютеров было обнаружено множество удачных решений и подходов. Часть из них оформлялась в паттерны.

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

Выстроив архитектурные решения по временной шкале, мы получим значительный объем накопленных знаний. Однако, он регулярно требует пересмотра, особенно когда возникает одна из «вех». Массовое распространение интернета приводит к изменению способов доставки программного обеспечения. Появление docker требует переосмысления архитектуры распределённых приложений. Когда целые страны проваливаются в Интернет, появляются большие данные.

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

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

Командам, которым для разработки программы достаточно фреймворка можно отказаться от архитектора. Особенно если компьютерные «вехи» будут возникать реже, например, вследствие замедления закона Мура. Под архитектурную работу можно не выделять отдельную роль. Ведь готового архитектурного знания много, в том числе на вооружении обычных разработчиков. Роль архитектора может быть такой же ненужной в команде, как роль «создатель языка программирования». При необходимости язык программирования может построить любой разработчик, более того, он скорее предпочтет объектно-ориентированный подход или разработку DSL-языка. То же самое может произойти с ролью архитектора, если развитие компьютерных технологий будет происходить более плавно.

Впрочем, следует сразу оговориться, что в некоторых случаях без архитектора и его «вертолетного взгляда» на систему, не обойтись:

• Создание девайсов

• Операционные системы и другое большое коробочное программное обеспечение

• Большие структуры со множеством подразделений

• Небывальщина

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

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

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

В случае возникновения новой «вехи», лучше, если будет хоть какая-то архитектура. Разрабатывать программу для квантового компьютера через A/B-тесты не получится: не от чего отталкиваться, архитектуру придется спроектировать, даже если с первого раза она получится не совсем удачной.

Устройство современной команды

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

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

Когда менеджеры бегают между совещаниями, реагируют на внешние угрозы, ругаются с контрагентами, психика — ускоряется.

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

То же самое происходит со стороны бизнеса. Призывы успокоиться и выйти из состояния «нужно же что-то делать», означает не просто переключение нейромедиатора, а кражу «кайфа» от работы.

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

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

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

Обратный случай, когда человек наоборот склонен к разгону психики и не способен ее тормозить. Это путь к маниакально-депрессивному психозу. Причем вы можете спокойно работать с этими людьми годами, не испытывая серьёзных проблем. Ну такой человек может совершенно не помнить своих собственных вчерашних инициатив, но зато будет пробивным и активным! Всех заражает работоспособностью, убеждая в какой-то идее буквально гипнотизирует коллектив.

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

В левом верхнем кружочке на изображении выше — изолированные разработчики в состоянии потока. От всех невзгод их как щит закрывает прожект-менеджер — он фильтрует данные и взаимодействует с продактом. Задача продакта — смотреть на продукт глазами клиента так, чтобы команда не разработала быстрый, безопасный и бесполезный «Hello, World».

Внизу картинки — архитектор, он должен выдвигать нефункциональные требования. Этот человек следит за правильностью происходящего — чтобы не плодились «велосипеды» и использовались технологии, на которые закуплены лицензии. Однако часто этой роли нет, особенно в маленьких компаниях. Тогда её заменяет системный аналитик. Например, в «Нетологии» большой запрос на курс архитектуры для middle и senior системных аналитиков, потому что на работе им это нужно.

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

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

Как найти общий язык с бизнесом

С момента возникновения программирования мы пытаемся найти общий язык для бизнеса и разработки. Разработчики с одной стороны горы роют тоннель объектно-ориентированного программирования и пытаются говорить о бизнесе его словами. В то же время бизнес с другой стороны придумывает гибкие технологии, фреймворки типа Cobit, чтобы разговаривать с разработчиком на одном языке.

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

Самое плохое, когда разработчики и бизнес не понимают с чем столкнулись. Все мы наблюдали ситуацию, когда бизнес перебрасывает проблемы через гору и просит разработчиков всё автоматизировать, а те перекидывают их обратно и требуют техническое задание. Разработчики в сердцах могут восклицать, что бизнес сам не знает какое программное обеспечение он заказывает. И они совершенно правы. Ошибка лишь в том, что эта ситуация — нормально. Просто нужно всем вместе навалиться на сложность и пытаться построить сквозь неё туннель, а не ждать, что кто-то другой разберётся за вас. 

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

Domain Driven Design

Естественным развитием гибких методик разработки стал архитектурный подход Domain Driven Design (DDD), введенный Эриком Эвансом. В нём он адаптировал архитектурные подходы для современных команд и ввёл понятие "Единого языка" к которому должны стремиться бизнес и разработка. А ещё оттуда пошли понятия доменов и контекстов.

Самое главное, что DDD предлагает перестать делать вид, что мы можем заранее в деталях продумать архитектуру. Сложность никуда не девается, а задача бизнеса и разработки совместно и последовательно этот тоннель пробить, разрабатывая несколько версий. Если модели нет, то строить её — итерационно или при помощи А/В-тестирования — как угодно.

Многие могли наблюдать ситуацию, когда продакт-менеджеры с помощью А/В-тестов помогают двигаться вперёд. Они делят поток посетителей надвое и каждого направляют на одну из двух страниц. Затем смотрят результаты — где лучше продажи, усвояемость материала, больше регистраций.

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

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

Выводы

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

В гибких Agile-командах многие готовы подхватить роль архитектора, например, тимлиды и техлиды. Архитектор там не нужен. Всё будет работать хорошо, пока не потребуется небывальщина  — то, для чего готовых типовых решений нет. 

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