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

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

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

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

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

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

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

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

---

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

---

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

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

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

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