Концепция

Введение

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

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

Важный момент: архитектура это все таки не код, а данные.

Архитектура как данные имеют сложную, порой слабо формализованную структуру.

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

Управление архитектурой и управление данными об архитектуре - разные, но взаимосвязанные процессы. Управление архитектурой как таковой - это управление собственно бизнесом (или информационной системой), в зависимости от того, архитектурой чего мы управляем. Соответственно, управление архитектурой состоит из "управления архитектурной документацией" и процесса "внедрения архитектурных изменений", а так же "сбора объективной информации, требований и возможностей" и процесса "принятия решений по изменениям".

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

Вариант реализации хранения и управления данными об архитектуре

Единицей хранение является документ (документ об архитектуре или архитектурный документ).

Документ фиксирует некое состояние архитектуры на определенный момент времени. (Состояние "как есть" или "как должно быть" или "вариант" и прочее.)

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

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

Документ отражает состояние, зафиксированное и хранящееся в базе. То есть на определенный момент времени документ статичен. Но документ может изменятся во времени, формируя статические "версии".

Важный момент. Документ может меняться в 2х "направлениях" одновременно:

- изменение в связи с уточнением понимания отображаемых аспектов (устранение ошибок, например),

- Изменение в связи с изменением аспектов в отображаемой системе.

Помимо статических документов, есть еще отображения (или "отчеты") - это по сути такие же документы, но они не хранятся в базе, а динамически собираются по данным из базы или из других источников в момент их использования.

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

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

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

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

Диаграмма или текст (а так же структурированные формы и т.п.) могут быть не только "выводом" документа, но и способом его внесения в систему и редактирования (внесения корректировок).

Управление изменениями (данных)

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

Если наполнить систему данными - архитектурными документами в некоем "согласованном" состоянии, и учесть связи взаимного влияния документов как аспектов системы друг на друга, то можно реализовать контроль развития (и управление изменениями) системы следующим образом:

• Появление новых требований или обнаружение несоответствий формирует новый документ (или версию старого) (условно подсветим "красным")

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

• Правка "розовых"" документов делает ранее "красный"" документ "зеленым", то есть согласованным с ними, а эти документы - "красными". И формирует "розовыми" следующие связанные. И т.п.

• Часть документов отражает фактическое состояние системы (например по данным автоматических средств измерения) - процесс (очередной виток) изменений закончится тогда, когда все документы в цепочки станут опять взаимосогласованными.

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

Важный момент: У документа нужно контролировать еще третье измерение "версии" - "согласованность". (или видел/не видел).

Суть в следующем: например утвердили некую версию документа. По ней разработчик начал работу (согласовал свою систему управления работой). Допустим, изменились обстоятельства, и в исходный документ внесли изменения. Разработчик должен увидеть, что нынешний утвержденный вариант исходного документа изменился, и ему нужно согласовать свою систему с новым вариантом. Ну или - продолжить работу по старому, до определенной точки, и возможно - в результате вынудить внести в исходный документ очередные изменения, которые будут более легко согласуемы со сделанной работой.
Таким образом у каждого звена, связанного цепочкой управления возникает гибкость. Что позволит справится с управлением очень сложными системами.

Выводы

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

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