Многие считают, что задача архитекторов – создавать схемы и диаграммы, а в широких массах эта деятельность вообще носит неофициальное название «рисовать квадратики». В какой-то степени это правда, и часть времени архитектор тратит именно на это. Ведь основным результатом работы архитектора является документ, а не часть кода или готовый программный модуль, как у разработчика, или настроенное оборудование, как у инженера. В ряде случаев отношение к этому «рисованию квадратиков» снисходительное, но ведь на практике очень часто то, что нарисовано в них, потом будет реализовано в жизни.
Поэтому, несмотря на эту снисходительность, относиться к созданным диаграммам приходится со всей ответственностью. В связи с этим логично задуматься, а как правильно создавать архитектурные артефакты: документы с описанием, диаграммы, модели? Как сделать так, чтобы архитектурные документы были максимально полезны и использовались другими техническими специалистами в проекте? Как не допустить ошибок? Есть ли уже описанные процессы, специальные инструменты, да и просто рекомендации? Если проект сложный и в нем участвуют несколько архитекторов в разных ролях (к примеру, от инфраструктуры, от прикладных модулей и корпоративный), то как правильно распределить обязанности, кто что делает и в каком формате?
Даем определение и делаем аналогии
Здесь на авансцену и выходят архитектурные методы. Что это такое? Метод — это руководство, как создавать и внедрять архитектуру и ИТ-решения проверенным и последовательным образом. По факту, это руководство является сбором знаний и опыта ведущих специалистов организации. Методы закрывают полный жизненный цикл создания архитектуры и продуктов и включают в себя материалы для проектирования, планирования и внедрения ИТ-решений. Метод можно сравнить с методичкой для студента, которая описывает, что, кому и когда нужно делать и что в итоге получится. Или упрощенно метод можно представить как руководство пользователя (user manual) по использованию любой техники – в целом, можно обойтись и разобраться самому, но зачем, если уже все написано.
Фреймворк vs метод – в чем разница?
Здесь стоит сделать небольшое отступление и вспомнить о существовании архитектурных фреймворков. Какая разница, это одно и то же – скажете вы. Не совсем: архитектурный фреймворк действительно описывает все необходимые вещи, а именно список ролей, артефактов, их шаблонов, описание процессов и практик по созданию архитектуры, но архитектурный метод связывает все эти вещи воедино. То есть фреймворк можно представить как нечто статичное, а метод — как динамичное. Один фреймворк может быть легко связан с несколькими методами, а наоборот связь (один метод – несколько фреймворков) не совсем эффективна.
Логично ведь иметь одну единую классификацию ролей, единый список архитектурных артефактов или практик, а не пять разных. Куда разумнее иметь пять разных способов их использования или, по-другому, методов. Безусловно, метод может использовать не все роли и не все артефакты из фреймворка. В IBM, к примеру, существует единый фреймворк с созвучным названием Unified Method Framework, где приведен исчерпывающий список практик, артефактов, ролей, и с которым связаны практически все использующиеся методы. Среди открытых стандартов можно привести пример The Open Group Architecture Framework (TOGAF) и Architecture Development Method (ADM) в области управления и создания корпоративной архитектуры.
Составляющие метода
Подробнее разберем, что же включает в себя описание метода, из каких частей он состоит? Во-первых, каждый метод должен быть однозначно идентифицирован по названию (например, Architecture Quickstart, Agile with Discipline). Казалось бы, это весьма очевидная мысль, но на практике она нередко выручала, когда международная команда архитекторов (еще и из разных стран) обсуждает основные шаги предстоящего проекта. Достаточно сказать пару слов из названия метода, и все понимают, про что идет речь, так как методы едины для всей компании. В целом, важность названия не стоит недооценивать.
Идем дальше: метод должен включать описание процесса создания архитектуры решений и ключевых действий. Можно сказать, что метод дает последовательную инструкцию: сделай раз, сделай два, сделай три. Все шаги процесса связаны с ролями, описанными в фреймворке. Ролью может быть архитектор приложений, проектный менеджер, Agile коуч, DevOps инженер.
Метод также дает связь между шагами процесса и созданием необходимых рабочих продуктов (work products). Эти самые рабочие продукты можно разбить на 2 категории: артефакты и deliverables (результирующие продукты). Отличие очень простое – артефакты могут быть промежуточными результатами и не использоваться как результат на ключевых вехах проекта. Примером артефакта можно назвать результат интервью при сборе требований, gap-анализ сравнения с референсной архитектурой, один или несколько сценариев использования (use cases). К слову, упражнение по сравнению текущей архитектуры с референсной делается практически в каждом проекте и наиболее частыми областями в последнее время являются cloud-native и концепция data reservoir.
В случае deliverables это уже готовый прототип, описание проекта либо целевая архитектура. Как правило, для получения deliverable необходимо сделать несколько артефактов. В большинстве проектов для создания целевой архитектуры мы используем набор из примерно 10 ключевых артефактов, куда входят документы с описанием бизнес-задач, текущих ограничений ИТ систем, принятых в ходе проекта архитектурных решений, матрицы нефункциональных требований, а также набор моделей и диаграмм: например, компонентная, операционная и развертывания.
Метод также связывает рабочие продукты, сам процесс, роли участников с практиками. В качестве примера практики из разработки можно привести парное программирование или test-driven разработку, из архитектуры – практику эволюции архитектуры. То есть метод дает описание, какие практики лучше всего использовать при создании артефактов.
Большим блоком в описании каждого метода является часть, связанная с управленческими процессами. Сюда входят такие вещи, как дорожные карты (по сути, рекомендации по использованию практик), шаблоны артефактов (матрицы требований, чеклисты внедрения, диаграмма потоков данных), а также списки и описания ключевых концептов. Концепт — это диаграмма классов, функциональная декомпозиция, архитектурные решения – те базовые понятие и вещи, которые должен знать каждый архитектор для успешной работы.
База знаний методов
Видно, что метод – это описание, как правильно создавать архитектуру, основанное на практическом опыте более опытных людей. Логично, что такие описания должны храниться в компании централизованно и быть доступны всем желающим. В IBM, к примеру, это реализуется на базе портала IBM MethodWeb, где находится список архитектурных методов и их описание. Для повышения эффективности использования методов они могут быть встроены в специальные инструменты, которые используют архитекторы при проектировании решений (это было давно реализовано в Rational System/Software Architect и может быть сделано в других программных продуктах. Описание метода может быть выгружено, к примеру, в xml формат и импортировано в инструментарий.
Методы – не только для архитекторов
В примерах выше встречались практики или артефакты, которые относятся не только к задачам архитекторов, но и деятельности разработчиков. Это сделано не случайно – методы могут использоваться не только в архитектуре, но и в разработке (IBM Garage Method – метод по созданию cloud-native приложений) или даже в понимании бизнес-проблем (Enterprise Design Thinking). Структура у этих методов может немного отличаться друг от друга, но задача по систематизации подхода остается прежней.
Типы методов
Важно отметить, что вряд ли нужно стремиться к наличию единого метода по разработке архитектуры. В IBM, к примеру, больше сотни архитектурных методов и все они решают разные задачи. Посмотрим, какие типы методов существуют: сразу можно разделить на те, которые используются при проектировании (на стадии pre-sale), и те, которые используются при внедрении решений (на стадии delivery). Есть методы специально для прикладной архитектуры, инфраструктуры, данных или корпоративного уровня (enterprise architecture). Существуют методы, специализирующиеся на Agile разработке, другие – на waterfall. Не так давно появились методы, заточенные на создание продуктов на базе cloud-native стека технологий. Также существуют методы, которые сфокусированы на конкретном семействе продуктов, например SAP или Oracle, где есть свои отличительные черты.
Жизненный цикл метода
Стоит немного затронуть тему жизненного цикла методов. Всем известно, что технологии сейчас быстро меняются и, соответственно, нужно постоянно подстраиваться под этот ритм. Казалось, совсем недавно только начинали использовать виртуализацию или сервисную шину, а сейчас все активно обсуждают service mesh и контейнеры. Это означает, что в компании должен быть формализован процесс по обновлению и созданию методов.
В IBM у каждого метода есть свой владелец, который и отвечает за поддержание его актуальности для какого-либо направления деятельности компании (модернизация приложений, построение когнитивных сервисов и др.) В целом, любой архитектор может предложить как изменить текущий метод, так и создать свой собственный. Для этого необходимо сделать его описание по предложенной структуре, включив все необходимые элементы как роли, практики, артефакты и пр., а также обосновать уникальность. Обязательным правилом добавления метода в общий реестр является его соответствие реальным практическим задачам, то есть метод должен быть использован в одном или нескольких проектах.
Что же получается в итоге?
Метод – это интеллектуальный капитал компании, где отражаются опыт и знания ее сотрудников по результатам выполненных проектов. Благодаря этому не нужно каждый раз изобретать колесо в начале проекта и думать, с чего начать. Методы повышают повторное использование материалов из проекта в проект, позволяя в то же время грамотно распределять задачи между участниками. Многие компании в области консалтинга используют различные методы при выполнении проектов для клиентов. В IBM часть методов является закрытой (Architecture Quickstart), часть возможна к лицензированию и использованию (Team Solution Design), а часть – открыта (IBM Garage Method).
С другой стороны, нельзя не отметить, что архитектурный метод – это не серебряная пуля, которая сразу решит все проблемы в ИТ, например, связанные с бесперебойностью работы продуктивных систем. Также нелогично всецело и полностью следовать методу, когда стоит небольшая задача, которую надо реализовать в короткие сроки, чтобы проверить какую-либо гипотезу. Все же в проекте конечной целью является не использование метода, а достижение результата, как пример – созданный продукт. На практике методы редко используются на 100%, а опытные архитекторы комбинируют части из разных методов, адаптируя их под задачи проекта, образовывая тем самым свои собственные. Но все же методы позволяют снизить число ошибок, которые специалисты могут допустить при проектировании решений либо из-за неопытности, либо из-за различного понимания одних и тех же терминов и концептов, либо из-за нехватки времени. Для большой компании создание ряда архитектурных методов является важной задачей, позволяющей накапливать, систематизировать и повторно использовать практические знания, превращая их в интеллектуальный капитал.