Бизнес-Моделирование
Разработка ПО для моделирования систем, процессов, данных, интеграций
Назначение СиММА для аналитиков, архитекторов и менеджмента компании
Кому и зачем нужны продукты класса Enterprise Architect
Очень часто неофиты программных продуктов класса Enterprise Architect не в состоянии аргументированно объяснить руководству зачем им нужны инструменты моделирования. По этой причине мы решили опубликовать типовые задачи, которые возлагаются на модели и моделирование независимо от того, кем и в каком инструменте они будут выполнены.
Типовые задачи в зоне ответственности руководства приведены в левой колонке (см ниже). Очевидно, что задачи руководства лежат в области обоснования принимаемых решений и повышения управляемости компании. Для пользователей СиММА (аналитиков и архитекторов) задачи носят скорее инструментальный характер (см. правую колонку): делать свою работу быстрее, удобнее, с меньшим числом ошибок.
Задачи руководителей или менеджмента. | Задачи аналитиков и архитекторов. | |
|
|
|
Менеджмент компании к инструментальным задачам архитекторов и аналитиков, как правило, не проявляет интереса. Не до конца понимая суть и преимущества проектирования, менеджмент компании считает, что для управления компанией и ее развитием достаточно изощренной системы контроля поручений и изнуряющего темпа бесконечных совещаний. Обеспечив проектировщиков экселем и power point, закрывая глаза на использование бесплатных продуктов (к сожалению весьма ограниченных и чаще всего импортных) менеджмент, тем не менее, требует от аналитиков (и уж тем более высокооплачиваемых архитекторов) взвешенных и консистентных решений.
Первая причина такого отношения к архитекторам и обеспечению их инструментами кроется в том, что архитектора по ИТ (в отличие от обычного строительства зданий) нанимают не перед созданием системы, а в ходе её неудачного спонтанного создания или даже после него. То есть стадия проектирования (между прочим, не дешёвая) полностью упущена. Таким образом архитектор трактуется не как проектировщик [с нужными ему стандартами, методиками, инструментами проектирования, сроками], а как антикризисный менеджер, который должен потушить пожар неудачной разработки. В этой ситуации архитектору действительно не до моделей, здесь главным инструментом выступает Power Point и Draw.io для создания убедительных слайдов и нескольких несложных диаграмм, помещающихся на слайд.
Вторая причина, по которой моделям и проектированию не уделяется должного внимания [даже если архитектор проекта нанят своевременно] кроется в самой природе организационного дизайна или там разработки программного обеспечения: в этих сферах проектирование-конструирование-реализация могут происходить одновременно, спонтанно, носить временный или экспериментально-поисковый характер. В такой ситуации архитектору не всегда находится место, так как он со своими проектно-инженерными практиками может стать лишь тормозом или узким местом команды энтузиастов, заряженной на быстрый успех что-то попробовать, освоить, сваять. Не зря на эту тему ломаются копья в вопросе какой объем "up front desing" необходим. Тем не менее во всех случаях длительной agile-разработки моделям и архитектурному репозиторию всё-таки отводится важная и заслуженная роль - роль инвентаризации (описания) спонтанно складывающейся реальности. Это крайне полезно: если мы не знаем, куда и зачем мы идём, то мы хотя бы будем знать, что мы уже имеем и где мы находимся. Собственно практики типа architecture as code, пытающиеся встроиться в процесс разработки, тому подверждение. Можно также сказать иначе: если у команды нет изначальной архитектуры и замысла, то их надо нащупать, зафиксировать и контролировать (то, что называется Continuous Architecture) по мере развития проекта: нельзя бесконечно наращивать мышечную массу, не имея представления о скелете и его возможностях.
В конце концов, если вы читаете эту статью, то можете быть уверены, что всё большее число команд архитекторов и аналитиков находят с менеджментом общий язык и приходят к необходимости архитектурной практики. Как минимум для того, чтобы описать ландшафт изменений в компании (процессы, системы, функции, сервисы, данные) и вовремя принять сложные комплексные решения. Но практика или любая профессиональная деятельность требуют своих специфических инструментов, особенно если у вас идут десятки параллельных проектов, в которых заняты сотни разработчиков, аналитков, тестировщиков и инженеров.
СиММА - инструмент анализа и проектирования. Обеспечьте профессионалов инструментом!
Сферы применения СиММА смотрим по ссылке >>>
Каким образом СиММА поддерживает решение или исполнение перечисленных выше задач? Будучи системой моделирования, СиММА позволяет построить неограниченное число моделей, отражающих различные точки зрения заинтересованных лиц. В основе моделирования СиММА используется архитектурный подход, направленный на расслоение предприятия в виде набора взаимосвязанных каталогов: систем, функций, процессов, данных, интеграций, API, требований, подразделений, НПА, ограничений, драйверов и т.д. Следующие функции поддерживаются репозиторием СиММА:
- Ведение неограниченного числа каталогов (цели, задачи, направления, мотивы, принципы, проекты, решения, процессы, системы, функции, ограничения, сервисы, данные, API, интеграции и т.д.).
- По каждому элементу каталога поддерживается карточка с уникальным набором атрибутов.
- Связывание элементов друг с другом, включая возможность трассировки связанных элементов.
- Атрибутирование связей.
- Коллективная работа с данными в каталогах.
- Ведение истории изменения элементов в каталогах (или версионирование).
- Возможность вести каталог ADR, связанных со всеми элементами архитектуры во всех слоях.
- Сортировка и фильтрация элементов по их связям и атрибутам.
- Диаграммирование - построение на базе каталогов неограниченного количества схем в различных нотациях.
- Контроль использования нотаций моделирования.
- Коллективная работа с данными на диаграммах.
- Маркировка элементов признаком AsIs/ToBe.
- Загрузка данных в каталоги СиММА из Excel или через API.
- Возможность создания отчетов с помощью API.
Это инструментальные возможности. Но что в результате получает руководство компании?
- единый репозиторий данных о компании.
- единый язык, на котором общаются руководители, аналитики, архитекторы.
- консистентные модели, так как они построены на базе одних и тех же каталогизированных (читай - выверенных) данных.
- отслеживаемость изменений, происходящих в компании.
- четкое понимание взаимосвязи и взаимовлияния инициатив.
- прозрачность работы аналитиков и архитекторов.
- возможность кооперации менеджмента с аналитиками и архитекторами, ведь зачастую именно руководители являются первоклассными экспертами на своем предприятии.
Об архитектуре и архитектурных моделях на базе репозиториев класса Enterprise Architect вы можете ознакомиться в нашей статье на тему подготовки предприятия к цифровой трансформации.