Моя история не для всех.
В том смысле, что тема не хайповая.
Но тем, кто в теме, надеюсь, будет интересно.
Она (рассказ) основана на реальном опыте последних лет. Я расскажу об одном из вариантов – с моей точки зрения, эффективных – управления сложным архитектурным ландшафтом.
Что я подразумеваю под «сложными»: это несколько сотен бизнес-приложений с достаточно внушительным разбросом атрибутов — технология, неоднородность функционала, связность с другими приложениями, критичность, возраст, размер и так далее.
Добавьте к этому динамику, поскольку несколько десятков внутренних и внешних команд постоянно меняют ландшафт. Иными словами, самое отпетое, или, выражаясь устойчивым жаргоном, «кровавое» предприятие.
Очевидно, что в этом кипящем котле каждая новая инициатива изменений начиналась с поиска: где и что нужно сделать, как определить достаточность и необходимость изменений.
То есть анализ был проведен.
А поскольку котел большой и степень изменения высока, анализ, и он должен быть качественный, длился месяцами.
Но тщательность не гарантировала 100% качества, поскольку на той же поляне, что и ваша инициатива, могли толкаться другие, внося изменения, которых вы не ожидали.
Кто-то скажет, что это обычная картина для «кровавого» предприятия.
Или это случай Agile-команды с одним владельцем продукта? Все учтено и команда все знает. Я не буду спорить.
Во многом это правда.
Но независимые команды не могут быть построены на разорванном лоскутном ландшафте.
Но действительно большие проблемы не могут быть решены одной командой.
И в любой методологии должен быть разумный уровень порядка.
Единый архитектурный репозиторий
Именно с наведения порядка мы и начали.В результате был создан единый архитектурный репозиторий.
Начнем с его метамодели.
На мой взгляд, такие изменения всегда должны начинаться с разработки метамодели.
Это лучший способ объяснить заинтересованным сторонам и, самое главное, самим себе, что может предоставить новый репозиторий.
Метамодель покажет, насколько ваши цели вписываются в возможности систем, где будет реализован репозиторий.
При его разработке проще всего просмотреть документы, которые уже есть у вашей компании.
Изучите существующий опыт. Посмотрите ванильные модели от разных производителей.
Если уж серьезно, то почитайте ГОСТы, например ГОСТ 57100 (ISO 42010).
Для начала включайте в метамодель только самое необходимое, поскольку начинать лучше с простого.
Потом, если окажется, что такой модели недостаточно, то разработать ее не составит труда.
Причем развитие будет осознанным.
То есть самый правильный подход здесь — итеративный.
Начните с небольшого архитектурного объекта.
Посмотрите, как ваша модель с этим справится.
Достаточно ли у него элементов, связей и атрибутов для поставленных целей, и тогда принимается решение о его развитии.
Мы подошли к метамодели чисто утилитарно.
В качестве перспективных были определены три цели:
- Опишите современный архитектурный ландшафт.
- На основе текущей ситуации уметь создавать архитектуру решения для изменений.
- Поддерживайте репозиторий в актуальном состоянии.
Он имеет несколько слоев и представляет собой две части репозитория: Current и Solution. «Текущее» сегодня в упрощенном виде представлено на рисунке.
Решение по сути повторяет структуру «Текущего», но имеет некоторые особенности.
Хотя модель и сейчас остается довольно простой, первый вариант был намного проще.
Это был просто прикладной уровень.
Затем репозиторий пополнился компонентами, затем бизнес-объектами и бизнес-слоем.
Время от времени мы ощущаем последствия краткости модели, но для нас гораздо важнее не ее сложность, а область архитектуры, охватываемая репозиторием, и актуальность информации в хранилище.
Итак, похоже, мы нашли ту золотую середину, когда достаточно усилий для поддержания актуальной информации в репозитории и в то же время уровень детализации полезен и достаточен для анализа архитектуры и создания решений для инициатив.
.
Наш репозиторий основан на Sparx Enterprise Architect: были использованы практически все возможности, предоставляемые этой системой для настройки решения — он использует собственную метамодель (технологию MDG), поддерживаемую тысячами строк кода на Java и Javascript. Конечно, кастомизация приводит к необходимости самостоятельной разработки и поддержки, но мы были к этому готовы.
Текущая архитектура
Теперь немного подробнее о том, каково текущее состояние репозитория.
На уровне бизнес-уровня основными элементами являются бизнес-услуги и варианты использования: 
Услуги: 
И сценарии использования: 
В нашем случае варианты использования детализируют бизнес-услугу в конкретных условиях ее использования.
Но все же скрипт — это довольно грубое представление бизнес-функциональности.
Сценарии использования автоматизируются приложениями — это уже уровень Архитектуры приложений, где приложения связаны между собой информационными потоками: 
Потоки содержат бизнес-объекты уровня архитектуры данных: 
Основой архитектуры приложений является компонентная архитектура, где каждое приложение имеет представление своей структуры в виде компонентов, а потоки детализируются в виде взаимодействия компонентов через интерфейсы: 
Теперь еще раз посмотрим на упомянутые элементы и их взаимоотношения.
Все очень просто, но позволяет на достаточном уровне описать архитектуру крупного банка.
За несколько лет работы в хранилище накопилось почти десять тысяч архитектурных элементов, между которыми образовалось несколько десятков тысяч связей.
И это только современная архитектура.
Архитектура решения
Перейдем ко второму пункту целей, изложенных выше.От нас требуется создавать архитектуру решений для инициатив разного масштаба, реализуемых с использованием различных методологий, в том числе Agile. Решение описано для каждого уровня архитектуры.
Метамодель Solution части репозитория в основном повторяет структуру Current, но имеет отличия.
Например, набор атрибутов перекрывается лишь частично.
Плюс элементы и связи из части Solution имеют набор атрибутов, необходимых для описания решения.
Давайте пройдемся по всем четырем слоям решения.
Бизнес-архитектура содержит два типа элементов.
Это крупные Use Cases, реализуемые в проекте, и более детальные Требования для «водопадных» проектов или User Stories в случае Agile-инициатив.
Более того, Use Cases обязательно имеют свое зеркало в Текущей части.
При этом Требования и Пользовательские истории являются элементами исключительно части Решения и не имеют представления в Текущей части.
Еще одна важная деталь: репозиторий Sparx для них не является мастер-системой.
Они экспортируются из других систем.
Требования и пользовательские истории сопоставляются с ответственными за них приложениями.
Остальные уровни архитектуры решения имеют диаграммы, аналогичные текущей архитектуре: 
Цветовая гамма элементов и соединений Архитектуры решения передает внешний вид архитектурных изменений.
Описания изменений могут вноситься как в соответствующие атрибуты элементов и связей, так и в примечания, прилагаемые к элементам.
На основе этих данных формируются соответствующие части архитектурного документа.
Хотя, как показывает практика, наибольшей популярностью пользуются диаграммы.
Они используются во время обсуждений с архитекторами предприятия, командами разработчиков, поставщиками и архитектурным комитетом.
Что самое примечательное, так это то, что благодаря «уникальность» репозитория все элементы и связи, используемые в диаграммах, документированы и единообразно понятны всем участникам обсуждений.
Поэтому изначально все участники находятся на одной волне.
 |
 |
|---|---|
| При анализе крупных инициатив Архитектор решений не тратит время на поиск информации.
|
Изучая архитектуру решения, архитектор программного обеспечения видит хорошо известные ему элементы.
Он понимает, о чем эта архитектура |
Таким образом, при выпуске решения в производство архитектурные изменения передаются из части Solution в текущую часть с помощью скриптов.
Репозиторий, благодаря этой взаимосвязи, остается актуальным, несмотря на продолжающиеся инициативы по изменению ландшафта.
Поддержка репозитория
Репозиторий со столь значительным количеством элементов и связей, в котором работают десятки пользователей, необходимо поддерживать в адекватном состоянии.Например, необходимо заполнить все обязательные атрибуты; связи между элементами должны быть определенного типа.
При этом состояние архитектур Приложения и Компонента должно соответствовать друг другу, поскольку они представляют собой одни и те же приложения, но с разным уровнем детализации.
Конечно, обучение пользователей играет важную роль.
Но это крайне мало.
Люди склонны совершать ошибки.
Мы решили эту проблему, используя код Java и JavaScript. Каждую ночь по расписанию запускаются скрипты, которые значительно облегчают нашу жизнь:
- Проверьте содержимое репозитория на соответствие метамодели.
Скрипт либо сам исправляет ошибки, либо указывает на необходимость вмешательства человека.
- Создайте контент текущей архитектуры приложения на основе текущей архитектуры компонентов.
- Создайте несколько типов диаграмм для визуализации содержимого репозитория.
- Создавайте документы по архитектуре решений для подготовленных инициатив.
- Загрузите содержимое репозитория для общего банковского доступа на HTML-портал.
- Еще одно преимущество простой метамодели: благодаря ее простоте сценарии автоматизации также становятся проще.
выводы
Сравнивая два государства – сегодняшнее и тот «доисторический» период – мы отчетливо можем отметить, что требования к архитекторам возросли.Также увеличился порог входа для любого человека, которому по тем или иным причинам необходим анализ архитектуры.
Чрезвычайно важно, чтобы люди, отвечающие за поддержание репозитория, тратили на это много времени и в нашем случае должны были уметь разрабатывать код. Возвращаясь к метамодели репозитория, хочу отметить, что в рамках простой модели очень сложно собрать воедино мнения многих заинтересованных сторон, а еще сложнее оставаться при ней длительное время.
И любые изменения в метамодели должны в той или иной форме отражаться в скриптах автоматизации.
С другой стороны, анализ архитектуры и проектирование решений стали проще и короче.
Качество архитектуры решения выросло на порядок.
Решение стало гораздо более подробным и всегда остается последовательным.
В работе архитектора теперь сведены к минимуму рутинные операции, связанные с подготовкой документации и необходимостью поддержания ее в актуальном состоянии.
Архитектор по-настоящему творческий человек.
И в заключение несколько слов об инструменте, который мы использовали для реализации репозитория, Sparx Enterprise Architect. На мой взгляд, у него отличное соотношение цена/качество.
Конечно, в первую очередь это связано с его невысокой ценой, но практически весь необходимый нам функционал присутствует. Чего нам не хватает, так это разнообразия интерактивных представлений данных в архитектурном репозитории.
Ведь качественный анализ без них крайне затруднителен.
Мы начали с простых SQL-запросов непосредственно к базе данных Sparx. Но потом решили эту проблему самостоятельной разработкой.
Помимо самого Sparx, мы просматриваем репозиторий через кастомное веб-приложение, где самые популярные представления представлены в табличном виде с возможностью фильтрации, сортировки и трассировки между ними по выбранным значениям: 
Теги: #Анализ и проектирование систем #архитектура решений #sparx ea #архитектура, основанная на дизайне
-
Обзоры Веб-Хостинга И Купоны
19 Oct, 24 -
Любопытный Случай С Root-Доступом К Mysql
19 Oct, 24 -
Биотетрис: Успокойся И Побей Рекорды
19 Oct, 24
