Следите за нашими новостями на Facebook! Всегда что-нибудь интересное ;)
Будьте в курсе!
Подпишитесь на нашу рассылку, и мы будем присылать вам интересные статьи, анонсы и новости.

Алексей Лосев

Директор по разработке

  • Кандидат физико-математических наук.
  • Microsoft MVP (Most Valuable Professional), Visual Studio and Development Technologies.
  • 18+ лет личного стажа разработчика ПО на платформе .NET.
  • 10+ лет управления командами разработки различного масштаба.
  • 8+ лет преподавания разработки ПО в МГТУ им. Баумана.
  • Выстраивание процессов разработки ПО по Agile (Scrum) и внедрение управления проектами по PMBOK.
  • Управление разработкой банковского ПО в части ITSM информационной безопасности, внутренней автоматизации.Лучшие практики ITSM (ITIL).

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

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

© Роберт Мартин
For what?
Software Architector
Togaf
Чем занимаются архитекторы, мы с вами в прошлый раз поговорили, но вот какая от этой деятельности польза? Давайте взглянем на взаимосвязь архитектурных артефактов, предлагаемую Togaf (можно и в модель Захмана посмотреть, и в следующий раз даже посмотрим, но для текущей темы картинка из Togaf нагляднее):
Взаимосвязь архитектурных артефактов по модели Togaf
(Рис. 1) Модель архитектуры программного обеспечения по Togaf
Широта охвата нас пока не интересует, а вот основные домены и уровень погружения в компанию очень даже.

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

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

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

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

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

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