IT для неайтишников: Какими бывают IT-шники? Часть 7

Периодически мне задают вопрос: "Кто есть кто в мире ИТ?". Вопрос этот интересный и объёмный. Чтобы не рассказывать всё по много раз, я напишу несколько статей и буду на них ссылаться. Седьмая часть будет посвящена архитекторам. Их тоже далеко не одна разновидность. Есть архитекторы решений, системные архитекторы, технические архитекторы, функциональные архитекторы и другие архитекторы тоже есть. Понятие архитектуры многогранно, попробуем в нем разобраться.

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

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

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

Что такое архитектура? Прежде всего это искусство строить, затем это наука о том, как строить. То есть перед нами одновременное сочетание науки и искусства, которое требует одновременно знать, как и что можно сделать, так и чувствовать, где и как поступить. Нельзя забывать, что архитектура всегда создаётся для живых и развивающихся систем. Даже если эти системы информационные.

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

Как и в зодчестве, в IT-архитектуре действует Триада Витрувия: Прочность, Польза, Красота (лат. Firmitas, Utilitas, Venustas). Вещь должна быть прочной, полезной и красивой. Информационная система должна быть устойчивой (лёгкой в сопровождении), легко масштабируемой под растущие нагрузки, позволять легко наращивать функционал, нести бизнес-пользу, с ней должно быть приятно и удобно работать.

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

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

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

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

Но на самом деле всё немного сложнее. Прежде всего мы должны ответить на вопрос: «Зачем мы это делаем?». То есть должны обратиться к бизнес-архитектуре. Бизнес работает с процессами, бизнес-процессы - это тоже система. В современном мире бизнес-процессы выполняют либо люди, либо автоматизированные системы. То есть выполнение бизнес-процессов разделяют между собой социальная, она же HR-архитектура, и IT-архитектура.

Причём следует понимать, что HR-архитектура прежде всего сосредоточена на социальных системах, а потом уже на информационных системах, а IT-архитектура сосредоточена прежде всего на информационных системах, а потом уже на социальных системах. Это даже не связанные, а глубоко взаимопроникающие области.

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

Статья об IT, поэтому сосредоточимся на IT-архитектуре, зная, что над ней есть бизнес-архитектура и рядом с ней HR-архитектура. Собственно, IT-архитектура тоже неоднородна и состоит из множества областей. Рассмотрим лишь основные из них.

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

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

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

Собственно в рамках функциональной архитектуры мы создаём дорожную сеть и прокладываем по ней маршруты бизнес-процессов, которые должны удовлетворить системной архитектуре и бизнес-архитектуре.

Для понимания. Если вам нужна дорога, но её строительству мешает частный дом, то это небольшая проблема. Если это многоэтажный жилой дом, то его тоже можно расселить и снести. А если это памятник архитектуры, который вы обязаны сохранить? Нет, и его можно подвигать, кроме шуток. Ладно, но если это ТЭЦ, к которой сходятся электросети, тепловые сети и логистические сети для подвоза топлива и сотрудников? Уже будет очень сложно всё перестроить.

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

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

Ну и для понимания. Допустим, нам нужны виртуальные сервера, которые создаются на базе реальных серверов, которые размещены в ЦОД (центр обработки данных). Вот в этом ЦОД основную стоимость может составлять не совокупная стоимость серверов, а система кондиционирования и электроснабжения. Сервера греются, когда работают, их нужно охлаждать, энергии они тоже потребляют немеряно.

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

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

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

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

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

Однако, сейчас у бизнеса появились возможности собирать и обрабатывать большие объёмы данных. Отсюда и появились понятия Big Data (Большие данные) и Data mining (глубинный анализ данных). Стали широко использоваться такие вещи, как ML (машинное обучение) и регрессионный анализ данных.

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

За счёт роста объёма данных, архитектура данных стала смежным вопросом с архитектурой инфраструктуры и системной архитектурой.

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

Свёртывание объёмов данных в какие-то «агрегаты», выбор момента и места, где это свёртывание произойдёт, это тоже вопросы архитектуры данных.

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

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

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

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

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

Ну а теперь немного об архитекторах, как и обещалось.

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

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

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

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

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

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

Если это не какая-то коробочная система с типовым функционалом, который нужно дорабатывать стандартным образом (справится и методолог), а мы оказались в рамках крупной компании, то придётся иметь дело с целой иерархией бизнес-процессов, которые связаны между собой нетривиальным образом. Как результат, будет образованна сложная система со своими потоками данных, у этой системы должна быть своя архитектура. Не техническая, а функциональная. Если в «технического» архитектора могут развиться разработчик и системный аналитик, то в функционального архитектора может развиться бизнес-аналитик.

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

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

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

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

Системные архитекторы мыслят категориями: вот тут у меня кусочек SAP, здесь OLAP-кубик, вот тут конгломерат сервисов подписания документов с помощью электронных цифровых подписей и визуализации документов, плюс ещё россыпь из десятков крупных систем. Какие-то из них находятся во внутренних контурах компании, в разных сегментах с разной степенью защищенности на случай успешной атаки злых хакеров, какие-то лежат в DMZ (Demilitarized Zone), какие-то высунуты наружу. Между ними проходят какие-то глобальные потоки данных и есть какие-то внутренние границы. Чтобы когда рухнул один сегмент сети, другие могли работать. И эти границы очень строго защищаются.

Ещё системные архитекторы занимаются борьбой с «зоопарком», это состояние, когда в рамках одной системы представлены различные технологии-аналоги. Например, одновременно используется SAP ERP и 1C ERP. То есть системы выполняют сходные функции, но требуют для обслуживания и развития разные команды технических специалистов с разной специализацией. Это неудобно и требует лишних финансовых вложений.

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

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

Польза для среднего бизнеса понятна. С одной стороны держать у себя в штате сильных архитекторов дорого и не нужно, тем более на простых задачах им может быть скучно. То есть они нужны в рамках выполнения крупных проектов, преобразований и консультаций. А мелкий бизнес тут при чём?

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

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

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме:

• IT для неайтишников: Зачем оно нужно?
• IT для неайтишников: Какими бывают IT-шники? Часть 1
• IT для неайтишников: Какими бывают IT-шники? Часть 2
• IT для неайтишников: Какими бывают IT-шники? Часть 3
• IT для неайтишников: Какими бывают IT-шники? Часть 4
• IT для неайтишников: Какими бывают IT-шники? Часть 5
• IT для неайтишников: Какими бывают IT-шники? Часть 6
• IT для неайтишников: Какими бывают IT-шники? Часть 7
• IT для неайтишников: Какими бывают IT-шники? Часть 8
• IT для неайтишников: Куда исчезают программисты после 40 лет?
• IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
• IT для неайтишников: Технический долг или почему теперь всё так долго?
• IT для неайтишников: Осторожно - JSDD (Бизнес в заложниках у IT)
• IT для неайтишников: Инженеры в заложниках у бизнеса
• IT для неайтишников: Потеряли ключи от IT, что делать?
• Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
• Процессы в ИТ: Долго, дорого и не то
• Саморегуляция в ИТ: минимально допустимая эффективность работы
• Telegram-канал Записки ITBP (короткие сообщения)
• Канал на Дзен Записки ITBP (статьи среднего размера)