Принципы управления архитектурой предприятия

Управление децентрализованной архитектурой

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

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

Управление “архитектурой как код”, позволяет применить опыт Open Source сообществ. В этом случае существует центральный репозиторий с концептуальной архитектурой (как будет). Все имеют доступ к нему, получая необходимые сведения о планах развития. Изменения в репозиторий попадают через Pull requests. Ревьюверами являются техлидеры команд.

Таким образом достигается информирование об архитектурных решениях. Возникает консенсус. Происходит обмен опытом.

Описание архитектуры “как есть” остается в командах. Т.е., несмотря на то, что имеется централизованный репозиторий «как будет», у команд остается право на автономное принятие быстрых решений. Этот подход реализует Agile манифест. Если необходимо срочно внести обоснованные изменения в продукт, должна быть возможность это сделать. Такая ситуация считается инцидентом.

Противоречие с центральным репозиторием устраняется путем сверки “как есть” с “как будет”. Отклонения обосновываются и, с отставанием, вносятся. Таким образом, инцидентные решения остаются в поле управления.

От бизнес- архитектуре к архитектуре ИТ

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

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

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

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

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

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

Управление версиями архитектуры

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

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

Аналогичные проблемы свойственны кодовой базе систем. В процессе параллельной разработки фич, разработчики сталкиваются с задачей объединения результата в релизы. Решается она через инкрементальное развитие кода. Популярным инструментом является git.

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

DocHub предлагает отказаться от использования визуальных редакторов в пользу описания архитектуры кодом. Использовать принципы управления архитектурой аналогично принципам управления кодовой базой. Для этого предоставляются четыре языка описания архитектуры:

PlantUML — позволяет создавать диаграммы из обычного текстового языка;
Markdown — язык разметки, созданный с целью обозначения форматирования в тексте;
Swagger — язык описания интерфейсов для описания RESTful API;
Манифесты — структурированные файлы в формате YAML/JSON для описания архитектурных объектов.

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

Унифицировать процессы развития архитектуры и разработки;
Архитектурные артефакты могут быть размещены непосредственно в репозитории кодовой базы и развиваться одновременно с кодовой базой системы;
Возникает возможность управления архитектурными идеями через Pull request;
Создается база для взаимного проникновения экспертиз разработки и проектирования.

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

Посмотреть, потрогать

В отличии от первой версии DocHub, эта версия публикуется в альфе. Это обусловлено тем, что мы хотим получить как внутренние, так и внешние мнения об инструменте. Учесть их.

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

Живое демо можно посмотреть тут https://dochub.info/. Это развернутый DocHub, описывающий архитектуру самого себя.

Вы можете развернуть DocHub у себя. Но учтите, что он интенсивно допиливается. Ветка концепта — https://github.com/RabotaRu/DocHub/tree/archops-conception-v2 (readme устарело и будет обновлено. Честно-честно). Развертывание такое:

DocHub будет доступен по адресу: http://localhost:8080/

Управление архитектурой холдинга (экосистем)

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

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

Компании холдинга имеют разную степень автономности. Часто находятся на различных этапах развития. Это выражается в неоднородности процессов управления.

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

Центр в этом случае выступает майнтейнером (Maintainer) архитектурного кода. Он является владельцем центрального репозитория архитектуры. Устанавливает стандарты работы с ним.

Компании выступают в роли контрибьюторов (Contributors). У них есть собственный форк или ветка в центральном репозитории. Развитие архитектуры экосистемы ведется через Pull requests.

DocHub используется как универсальное средство представления артефактов экосистемы.

Архитектурные фасады

Под архитектурным фасадом понимается публичная часть архитектуры. Распространенным примером являются API-контракты сервиса.

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

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

II. Определение понятия «архитектура»

А что можно думать об архитектуре?
Она, как солнце: большая, блестящая и она рядом.
Роджер Желязны. (Мастер сновидений)
Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.
Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:

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

Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц (2).

1. Разделы ИТ Архитекторы

базы данных и хранилища данных;
информационные потоки (как внутри организации, так и связи с внешним миром).

область разработки прикладных систем;
портфель прикладных систем.

информацию об инфраструктуре предприятия;
системное программное обеспечение (СУБД, системы интеграции);
стандарты на программно-аппаратные средства;
средства обеспечения безопасности (программно-аппаратные);
системы управления инфраструктурой.

Архитектурная группа описаний (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания (2).

2. Представления ИТ Архитекторы

Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры (2).
Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам (2).
Рисунок 1. Модель выработки целей и показателей Рисунок 2. Представление модели ЗакманаРисунок 3. Основные понятия ArchiMate 3.0Рисунок 4. Слои фреймворка ArchiMate 3.0

3. Резюме раздела

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

Список литературы

Предпосылки

Ограничения бывают разные. Например, компания со своими процессами. Вы генерируете идею, и она тонет в бюрократии. Идея рассматривается долгими днями, неделями, месяцами…

К счастью, это ограничение можно снять:

Можно сменить среду. Уйти туда, где вы можете реализоваться;
Затеять свой интересный проект и пилить его запоями по ночам.

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

Но есть и более глобальные ограничения. Можно сказать — фундаментальные. К таким ограничениям я отношу память, опыт, знания и время. Рамки некоторых ограничений можно раздвигать. Обучаясь, тренируясь, накапливая опыт. Но они будут оставаться с тобой всегда. А вот время…

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

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

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

Больше архитекторов? Решение интересное, но бесперспективное. Дело в том, что нарушается Agile Manifesto. Команда теряет автономность. Возникают ограничения ее эффективности.

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

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

И мы задумались… а можно ли как-то использовать интеллектуальный потенциал команд консолидированно? Создать не просто успешные команды, а развить положительную синергию их деятельности. Первым шагом для нас стала версия DocHub, пропагандирующая принцип contract-first.

Настроив процессы развития контрактов через GitFlow, мы заметно расширили свои возможности. Теперь, каждая команда, не ожидая архитектора, может развивать контракты. При этом управляемость не ухудшилась, а улучшилась. Я стал выполнять роль ревьювера контрактов. Архитектора стало “больше”.

Вдохновленные этой историей, мы пошли дальше. DocHub позволил решить ряд проблем. Но далеко не все. Осталась главная проблема — целевое развитие архитектуры. Т.е. достижение командами состояния, отраженного в архитектуре — как будет.

Была проделана работа по анализу существующих инструментов, которые могли бы подойти нам. Ключевой идеей сразу стало развитии архитектуры через код. На горизонте забрезжил PlantUML.

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

Как известно, проблемы не приходят поодиночке. Допустим, мы заставим разработчиков выучить PlantUML. И даже заставим их вносить изменения в файлы, описывающие архитектуру. Но как это все собирать в кучу со всех команд? Как рендерить? В конфлюенсе?

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

Думаю, интригу я нагнал достаточно. Пора познакомить вас с новым DocHub. Теперь это инструмент управления архитектурой через код. Он должен значительно снизить наши ограничения. Позволить командам видеть весь актуальный ландшафт. А это, в свою очередь, приведет к той заветной положительной синергии.