Содержание курса

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

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

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

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

Модели представления, которые определяют, какие представления (views) архитектуры используются (логическое, физическое, развертывания, компонентное, процессное).

Нотации и языки моделирования. Средства для формального и визуального описания архитектуры: (UML, SysML, ArchiMate, BPMN, собственные DSL).

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

Правила и стандарты качества. Критерии, которым должно соответствовать описание (ISO/IEC/IEEE 42010, ГОСТ-34, TOGAF, DoDAF / MODAF / NAF, RUP).

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

Архитектурный метод описания (Architectural viewpoint) — это набор принципов, процедур и нотаций, которые используются для систематического создания описания архитектуры системы. Шаблон или образец по которому определяют, как собирать, структурировать и представлять информацию об архитектуре. 

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

Модель (фреймворк) Закхмана — это одна из самых ранних и известных моделей для описания архитектуры предприятия. Модель основана на дисциплине классической архитектуры и призвана обеспечить общее толков��ние архитектурных аспектов и предоставить набор перспектив, или структур (framework), для описания сложных корпоративных систем. Выглядит она так:

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

Разберем подробно правила использования матрицы сначала в разрезе строк.

Первая строка соответствует уровню интересов высшего руководства (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес, например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.

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

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

На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды. Уровень ИТ-проектировщиков и разработчиков

Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.

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

Теперь давайте разберем правила заполнения непосредственно ячеек матрицы в разрезе колонок.

Первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе данные.

На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе.

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

На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи.

Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов).

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

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

Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций.

На первом уровне определяется каталог бизнес-процессов (Продажи, производство, закупки, логистика ...).

Второй уровень будет содержать модель бизнес-процессов из каталога. При этом определяются потоки работ, роли, бизнес правила.

Впоследствии модель детализируется в операции над данными и в архитектуру приложений (уровень 3). Определяются системные процедуры и формируются функциональные требования (Алгоритм расчёта стоимости, логика маршрутизации заявки ...).

Четвертый уровень детализирует процессы до модулей, компонент. Формируются спецификации требований.

Пятый уровень содержит программный код или конфигурации.

Наконец, рассматривается фактическая работа функций в реальной эксплуатации.

При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.

Колонка таблицы, отвечающая на вопрос «ГДЕ?", определяет пространственное распределение компонент системы и сетевую организацию.

На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов.

На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой (будь то обмен информацией или поставки товаров).

На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети.

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

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

Последний уровень описывает функционирование реализованной сети.

Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. 

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

На концептуальном уровне определяются бизнес-роли и организационная структура (Менеджер по продажам, складской работник, IT-администратор, отдел продаж, склад ...).

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

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

Уровень детального представления описывает конкретные конфигурации и настройки пользователя (Таблицы пользователей, конфигурация прав доступа, логи активности сотрудников ...).

Последний уровень описывает обученных пользователей системы.

Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики бизнес-процессов и работы системы.

Детализация осуществляется по вре��енным ориентирам предприятия сверху вниз, начиная от календарного плана, годовых циклов бизнеса, отчетных периодов и прочее.

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

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

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

Пятый уровень определяет физическую реализацию обработки таких событий (Файлы конфигураций, таблицы событий в БД…).

Наконец, на 6-м уровне – фактическая история функционирования системы (Наблюдаемые циклы и интервалы, журнал запуска процессов …).

Колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем.

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

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

Третий уровень включает логические правила и ограничения для реализации бизнес-процессов, которые лягут в основу цифровизации.

На физическом уровне определяется реализация правил в ИТ-системах. Как бизнес-правила превращаются в технические механизмы.

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

На 6 уровне фиксируют, как правила реально работают в жизни (собирается обратная связь).

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

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

Погрузившись во все эту ”карусель” сложностей и разнообразия возникает немаловажный вопрос: «Всегда ли необходимо выполнять такой сложный и ресурсоемкий процесс описания архитектуры?»

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

Принято выделять:

1. Стандартный подход. Заключается в разработке или выборе на начальном этапе общей схемы и правил для описания архитектуры.

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

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

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

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

P.S. Занимаясь организацией процесса принятия и внедрения новой архитектуры важно отдавать себе отчет, что он затрагивает мнение большого количества влиятельных людей, работу функционирующих бизнес-процессов, выстроенных взаимоотношений и коммуникаций. Большинство участников будущих изменений архитектуры не представляют себе не только всю новую целевую архитектуру, но и текущую ( функционирующую), они стараются избегать нововведений. А посему процедура построения Архитектуры во много является политическим процессом.