Архитектор, а зачем ты нужен?

Статья подготовлена для корпоративного портала.

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

                -- Роберт Мартин

Чем занимаются архитекторы, мы с вами в прошлый раз поговорили, но вот какая от этой деятельности польза? Давайте взглянем на взаимосвязь архитектурных артефактов, предлагаемую Togaf (можно и в модель Захмана посмотреть, и в следующий раз даже посмотрим, но для текущей темы картинка из Togaf нагляднее):

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

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

Когда за работу берутся IT специалисты, - не важно: разработчики, описывающие архитектуру приложений, или системные администраторы, описывающие технологический слой, - то эффекта на первых порах как такового нет. Ну появились какие-то документы, так чем читать описания и разбираться в диаграммах, проще подойти к знающему человеку и спросить у него: т.е. абстрактный архитектор тратит время на фиксацию архитектурных артефактов и, как и раньше, на ответы. Пользы от диаграмм нет. Чтобы польза появилась, команда должна стать достаточно большой или должно пройти значительное время. При большой команде времени архитектора на всех не хватает, и люди вынуждены обращаться к другим источникам знаний. А время расставляет все по местам, помним про отпуска? Что делать, когда знающего человека нет на месте? Правильно: искать документы. А после того, как первый раз получил ответ в документации, второй… Да еще не надо ждать, пока занятый другими коллегами архитектор ответит… Люди начинают этим пользоваться. Бизнес, как правило, эффект не очень видит, но, с точки зрения IT специалистов, наблюдается снижение сложности новых доработок.

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

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

Архитекторы, как и менеджеры, любят матрицы 2 на 2. Не откажу себе в удовольствии и основное содержимое статьи отображу именно в виде такой матрицы:

Главное, не забывайте, что перейти из «Отсутствия архитектуры» в «Корпоративную архитектуру» за один прием не получится. Это долгий процесс, который, возможно, какое-то время будет идти двумя отдельными ветками бизнес- и IT-архитектур с последующим их объединением, а, может быть, и подтягивание недостающей IT-архитектуры к тому, что уже есть в бизнес-архитектуре. У каждой компании в этом процессе может быть свой путь.

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