Назначение СиММА для аналитиков, архитекторов и менеджмента компании

Кому и зачем нужны продукты класса 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 вы можете ознакомиться в нашей статье на тему подготовки предприятия к цифровой трансформации.

Остались вопросы?
Оставьте свои данные и мы свяжемся с Вами в ближайшее время

Контакты

Адрес офиса:
105082, г. Москва, Спартаковский пер., 2, стр. 1, БЦ "Платформа"
Эл. почта:
Заказать звонок