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

Для пользователей СиММА (аналитиков и архитекторов) задачи носят инструментальный характер:

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

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

Было бы странно, если бы директор завода нанял архитектора, не обеспечив его циркулем и кульманом. Но в ИТ-сфере и в Enterprise Architecture это норма. 

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

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

В чём же на самом деле нуждается менеджмент, если слова "проектироваение" и "модель" ему не чужды?  Вот типовые задачи в зоне ответственности руководства, которые требуют инженерного и, считай, научного подхода (да-да, к сожалению, инженерия для человека с гуманитарным образованием - это наука):

Если менеждмент не ставит перед собой таких задач или не ожидает от аналитиков и архитекторов помощи в их решении, то вряд ли удастся обосновать закупку нужного инструмента и внедрение практики моделирования или там архитектурирования.  Зачастую, менеджмент, в неявном виде, имеет следующие задачи-антиподы:

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

Казалось бы есть совершенно не опасная потребность в едином взгляде всех заинтересантов бизнеса (сотрудников, менеджеров, акционеров) на реальность. Но и здесь есть возражения:

• средний стаж работы менеджера и сотрудника - 2-3 года. Зачем ему понимание общей картины и сближение взглядов с временными коллегами?
• если стаж работы сотрудника в компании более 3 лет, то ему уже и так ясно, как удержаться и продержаться - и это точно не про архитектуру.
• компании частно склеены не из бизнес-смыслов, а из связей, знакомств, выгод - в этом нет оснований для прозрачности и общих взглядов, здесь каждый сам за себя.
• ряд компаний, особенно больших, "эффективных", странового масштаба, держатся на плаву отнюдь не потому, что ведут бизнес рационально. Есть много других оснований для непотопляемости.