Уважаемые читатели, эта статья будет для вас полезна, если:

• Вы являетесь действующим архитектором ИТ и вам необходима дискуссия с коллегами о роли архитектора;

• Вы хотите стать архитектором, но еще не осознали, кто это;

• С вами рядом работает архитектор, и вы не понимаете, чем он занимается;

• Вы не владеете английским, но давно хотели прочитать книгу западного автора по архитектуре;

• И в целом если вы интересующийся современными веяниями ИТ, а именно архитектура является популярным запросом от работодателей в виду растущих масштабов автоматизации.

Про автора книги

В начале статьи хочу представить автора книги, которая стала основой рецензии/размышлений в данной статье.

Gregor Hohpe – корпоративный стратег, как указано на сайте AWS, который помогает ИТ-лидерам и Бизнес-лидерам переосмыслить текущую ИТ-стратегию и получить больший результат от их Cloud-путешествия.

Помимо «Software architect elevator» Грегор также является автором книг «Cloud strategy» и «Enterprise integration patterns».

Введение статьи

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

Мы пока начнем с элеватора.

Хочу отметить, что Gregor Hohpe является популяризатором архитектуры как специализации, и в этом его большая заслуга.

В данном случае хочу рассказать о книге Грегора "Architect elevator", которая охватывает так называемую менеджерскую и социальную составляющие части архитектурной работы.

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

Также почему я снова достал книгу из стола - мне случайно попалась статья, в которой Gregor Hohpe коротко рассматривает один из вопросов, затронутых в книге (или может просто рекламирует книгу): https://architectelevator.com/transformation/debugging-architect/

DEBUGGING ARCHITECTS - ещё одна статья автора по теме книги

Вопрос, которым Gregor Hohpe задается в статье: «Должен ли архитектор программировать?».

Этот вопрос упомянут в его статье (ссылка выше), и даны размышления на эту тему. Но ответ на самом деле-то очевиден, и, пожалуй, дискуссии на эту тему пора заканчивать – архитектор должен программировать, если он работает с конкретной технологией. Т.е. он является архитектором конкретной технологии или архитектором АС, но имеет в своей зоне ответственности отдельную выделенную для него подсистему.

Например, он является архитектором Hadoop, и в зоне его ответственности только Hadoop, и его (его в смысле Hadoop, а не в смысле архитектора) настолько много, что такому архитектору не нужно других технологий, потому что в его рабочем дне только 8 часов, в которые укладывается только Hadoop.

Другой пример, когда архитектор отвечает за взаимодействия систем через API, при этом одна система, к которой он, архитектор, прикреплен, написана на Java. Другая система, выставляющая API, написана на NodeJS. И еще 100 смежных систем на своем языке. На каком языке должен программировать архитектор?

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

Третий пример: выдающегося архитектора приглашают на проект (он, кстати, оптимально писал на Python, участвуя в предыдущем проекте). Он знает свое архитектурное дело, рисует идеально квадратики и стрелочки идеально проектирует системы и готовит диаграммы, знает и практикует паттерны проектирования, плотно работает с протоколами взаимодействия. И когда его приглашали, знали, что на новом проекте уже определен язык Java как основа, и что выдающийся архитектор не писал ранее на Java и не собирается. Должен ли он программировать на новом проекте? Или зачем его приглашали? Наверно, от него ждали чего-то другого чем писать или проверять код? Наверно, его обязанности более верхнеуровневые?

Поэтому итоговый ответ на тему программирования архитектором следующий: архитектор должен или не должен программировать в зависимости от зоны его ответственности.

О самой книге

Так вот, возвращаясь к книге.

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

Сказать по правде, после первых двух глав начало складываться впечатление, что книга – очередная пафосная с громкими заявлениями. Предлагаю вместе посмотреть, что Gregor Hohpe предлагает. Хотя, конспектируя основные термины, начал считать книгу вполне полезной.

Определение элеватора выглядит следующим образом:

архитекторы управляют лифтом вверх и вниз и перемещаются между комнатой корпоративного правления крупного предприятия – так называемый Пентхаус – и машинным отделением, где строится продукт.

Машинное отделение - т.е. где работают программисты. В очередной раз в книге дано определение, чем занимаются архитекторы (кроме того, что водят лифт), и звучит оно так: ИТ-архитекторы имеют много специализаций – это могут быть:

• сетевые архитекторы (ключевое слово «network»),

• архитекторы безопасности (ключевое слово «security»),

• архитекторы программного обеспечения («software»),

• архитекторы решений («solutions»),

• корпоративные архитекторы («enterprise»),

• и конечно же многие другие.

В общем случае предполагается, что разработчики работают с функциональными требованиями, в то время как архитекторы работают с нефункциональными требованиями, часто определяемыми как «ilities». ¨Это:

• масштабируемость,

• надежность в эксплуатации,

• доступность,

• совместимость,

• и мой любимый термин в таких случаях – и многое другое.

Ну а далее в лучших традициях жанра:

• Архитекторы соединяют различные точки в работе – смотрят между строк, чтобы убедиться, что не нарушены зависимости,

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

• Архитекторы смотрят выше названия продукта и списка характеристик, чтобы выбрать решение, даже с учетом копромиссов,

• Архитекторы устанавливают связь между потребностями Бизнеса и транслируют эти потребности в технические термины,

• ИТ – это очень сложно. Архитекторы поддерживают гармонию для уменьшения сложности.

И еще немного социального:

• Сегодня успешные архитекторы не только ИТ-специалисты, они также основные агенты изменений,

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

Многие разработчики или технические архитекторы (наверно это team leads) рассматривают некоторых «корпоративных» архитекторов наименее полезными, потому что они не пишут код. Это про тех, которые только общаются с руководством, и все меньше спускаются к инженерным коллегам. Такие карьеристы наслаждаются хорошим видом с верхнего этажа с большим удовольствием, а разработчики чувствуют, что эти архитекторы не работают так усердно, как требуется, и пренебрегают посещать разработчиков.

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

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

Дальше автор приводит в пример фильм Метрополис. Фильм 1927 года. Скажу честно, описание фильма довольно интересное, но спецэффекты вряд ли впечатлят. Интересно, смотрел ли его автор реально, или просто узнал, что есть такой фильм. Было бы конечно интересно прочитать подобный роман, т.к. романы не устаревают, но не нашел такого, поэтому буду смотреть, только если замучает ностальгия.

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

Его сын - Фредер догадывается о несправедливости, царящей в метрополисе. Спустившись в машинную зону, Фредер приходит в ужас: он видит страшного Молоха, пожирающего людей. Не в силах смириться с увиденным, он начинает борьбу со злом.»

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

Далее еще один пример расхождения между архитекторами и разработчиками - длительные циклы реализации проектов не обещают ничего хорошего, и могут привести к так называемому сценарию «Мечта архитектора – кошмар программиста», в котором архитекторы достигают своих абстрактных идеалов, но в действительности предложенная реализация не целесообразна. Но это уже другая тема между водопадом и Agile.

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

Классификация архитекторов по версии автора книги

Какие же бывают архитекторы с предложенной автором классификацией:

Матрица. Главный планировщик

Архитектор Матрицы – «холодный, лишенный чувства юмора седовласый мужчина в светло-сером костюме» - он разработал «Матрицу» и знает все и контролирует все.

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

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

Эдвард «Руки-ножницы». Садовник

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

Сложная ИТ-структура предприятия действительно кажется органичной, а хорошая архитектура обладает чувством равновесия, аналогично тому, что мы можем найти в прекрасном саду.

Точка исчезновения. Путеводитель

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

Волшебник страны Оз

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

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

Супергерой, Суперклей!

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

Также в книге высказывается мнение, что вместо супергероев компаниям нужны архитекторы—“суперклеи” - ребята, которые объединяют архитектуру, технические детали, потребности бизнеса и людей в рамках большой организации или сложных проектов.

Быть клеем (или катализатором) означает хорошо разбираться в том, что вы склеиваете.

Резюме статьи

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

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