Кому и зачем нужны продукты класса Enterprise Architect

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

Типовые задачи в зоне ответственности руководства приведены в левой колонке (см ниже). Очевидно, что задачи руководства лежат в области обоснования принимаемых решений и повышения управляемости компании. Для пользователей СиММА (аналитиков и архитекторов) задачи носят скорее инструментальный характер (см. правую колонку): делать свою работу быстрее, удобнее, с меньшим числом ошибок. 

Задачи руководителей или менеджмента.		Задачи аналитиков и архитекторов.
Качество/точность решений, принимаемых на основе моделей. Экономия: хорошая модель защищает от некачественных решений или позволяет отказаться от провальной инициативы. Возможность проиграть больше вариантов. Обоснованность/убедительность решений, подкрепленных моделью.   Следование стандартам отрасли или регулятора.   Единый язык изменений / инжиниринга - общее понимание инициатив в компании со стороны всех участников бизнеса: сотрудников, менеджмента, акционеров. Единый взгляд участников бизнеса на реальность. Прозрачность решений и изменений.   Скоррелированность / увязка / синхронизация инициатив.   Поиск возможностей.   Управляемость изменений и внедрение изменений на основе моделей (MDD - model driven design). Возможность отслеживания изменений. Возможность измерения / фиксации изменений.		создать модель текущего состояния компании, создать модель компании. Зачем? - потому что невозможно изучать / анализировать организацию путем личного осмотра всех ее участков и особенностей функционирования. Модель помогает выполнить различные виды анализа, например: структурный, функциональный, процессный, архитектурный. определить модель будущего состояния компании. Что есть будущее состояние? - из каких компонентов будет состоять компания: организационных, процессных, программных, интеграционных. Какие результаты должна порождать компания на каждой стадии выполнения ее процессов. спроектировать переход из текущего состояния в будущее. Такой переход есть набор (каталог!) разрывов между двумя моделями (AsIs и ToBe или между транзитными архитектурами). Если более строго, переход из одной модели в другую - это тоже модель, модель (или проект) перехода. выполнить расчёты на базе созданных моделей. инвентаризация реальности или учет объектов реальности (в том числе объектов ментального характера типа цели, требования, ограничения, интересы, идеи). Мы вкладываем в слово "инвентаризация" максимально точное отражение реальности в СиММА без каких-либо модельных упрощений. прогнозирование развития ситуации - вид расчетов, который выводит нас на свойства или иные возможности компании в будущем. упростить, облегчить рутинную работу по созданию и систематизации различных проектных артефактов. обеспечить коллективную работу над сложными моделями. создать консистеный репозиторий данных о компании.  упростить свою работу, делать её быстрее и удобнее. обеспечить возможность коллаборации нескольких аналитиков или архитекторов над одной или группой совместных задач.

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

Первая причина такого отношения к архитекторам и обеспечению их инструментами кроется в том, что архитектора по ИТ (в отличие от обычного строительства зданий) нанимают не перед созданием системы, а в ходе её неудачного спонтанного создания или даже после него. То есть стадия проектирования (между прочим, не дешёвая) полностью упущена. Таким образом архитектор трактуется не как проектировщик [с нужными ему стандартами, методиками, инструментами проектирования, сроками], а как антикризисный менеджер, который должен потушить пожар неудачной разработки. В этой ситуации архитектору действительно не до моделей, здесь главным инструментом выступает Power Point и Draw.io для создания убедительных слайдов и нескольких несложных диаграмм, помещающихся на слайд. 

Вторая причина, по которой моделям и проектированию не уделяется должного внимания [даже если архитектор проекта нанят своевременно] кроется в самой природе организационного дизайна или там разработки программного обеспечения: в этих сферах проектирование-конструирование-реализация могут происходить одновременно, спонтанно, носить временный или экспериментально-поисковый характер. В такой ситуации архитектору не всегда находится место, так как он со своими проектно-инженерными практиками может стать лишь тормозом или узким местом команды энтузиастов, заряженной на быстрый успех что-то попробовать, освоить, сваять. Не зря на эту тему ломаются копья в вопросе какой объем "up front desing" необходим. Тем не менее во всех случаях длительной agile-разработки моделям и архитектурному репозиторию всё-таки отводится важная и заслуженная роль - роль инвентаризации (описания) спонтанно складывающейся реальности. Это крайне полезно: если мы не знаем, куда и зачем мы идём, то мы хотя бы будем знать, что мы уже имеем и где мы находимся. Собственно практики типа architecture as code, пытающиеся встроиться в процесс разработки, тому подверждение. Можно также сказать иначе: если у команды нет изначальной архитектуры и замысла, то их надо нащупать, зафиксировать и контролировать (то, что называется Continuous Architecture) по мере развития проекта: нельзя бесконечно наращивать мышечную массу, не имея представления о скелете и его возможностях.

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

---

СиММА - инструмент анализа и проектирования. Обеспечьте профессионалов инструментом!
Сферы применения СиММА смотрим по ссылке >>>

---

 
Каким образом СиММА поддерживает решение или исполнение перечисленных выше задач? Будучи системой моделирования, СиММА позволяет построить неограниченное число моделей, отражающих различные точки зрения заинтересованных лиц. В основе моделирования СиММА используется архитектурный подход, направленный на расслоение предприятия в виде набора взаимосвязанных каталогов: систем, функций, процессов, данных, интеграций, API, требований, подразделений, НПА, ограничений, драйверов и т.д.  Следующие функции поддерживаются репозиторием СиММА:

1. Ведение неограниченного числа каталогов (цели, задачи, направления, мотивы, принципы, проекты, решения, процессы, системы, функции, ограничения, сервисы, данные, API, интеграции и т.д.).
2. По каждому элементу каталога поддерживается карточка с уникальным набором атрибутов.
3. Связывание элементов друг с другом, включая возможность трассировки связанных элементов.
4. Атрибутирование связей.
5. Коллективная работа с данными в каталогах. 
6. Ведение истории изменения элементов в каталогах (или версионирование).
7. Возможность вести каталог ADR, связанных со всеми элементами архитектуры во всех слоях.
8. Сортировка и фильтрация элементов по их связям и атрибутам.
9. Диаграммирование - построение на базе каталогов неограниченного количества схем в различных нотациях.
10. Контроль использования нотаций моделирования.
11. Коллективная работа с данными на диаграммах.
12. Маркировка элементов признаком AsIs/ToBe.
13. Загрузка данных в каталоги СиММА из Excel или через API.
14. Возможность создания отчетов с помощью API.

Это инструментальные возможности. Но что в результате получает руководство компании?

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

Об архитектуре и архитектурных моделях на базе репозиториев класса Enterprise Architect вы можете ознакомиться в нашей статье на тему подготовки предприятия к цифровой трансформации.