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

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

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

Для удовлетворения этих специфических потребностей в обеспечении архитектурного процесса появился целый класс программных продуктов. Перечислим названия некоторых компаний-разработчиков таких систем, многие из которых, за исключением последней, практически неизвестны на российском рынке: Casewise, Computas, Framework Software, Popkin Software, Proforma, Ptech, Rational Software.

Рис. 3.6. Источники информации для систем разработки Архитектуры предприятия

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

Различные планы, модели и документы, связанные с архитектурой, должны быть помещены в репозитории (специальной базе данных, созданной для хранения многих типов документов и диаграмм). Между ними должны быть установлены необходимые связи. При этом различные группы пользователей рассматривают различные категории информации и представления одной и той же архитектуры предприятия. Бизнес-менеджеров, например, больше будут интересовать диаграммы с информацией о бизнес-процессах. Менеджеров ИТ будут интересовать прикладные системы, связанные с этими бизнес-процессами, а на более глубоком уровне анализа их могут интересовать диаграммы, описывающие внутреннюю архитектуру этих систем. Если архитектура документирована с достаточной степенью детализации, появляется возможность отслеживания влияния возможных изменений. Репозиторий может содержать, например, информацию о сотрудниках и затратах. При этом появляется возможность анализировать влияние изменений в бизнес-процессах на стоимость их выполнения. Эти средства должны обеспечивать хранение артефактов в репозитории в соответствии с принятыми методиками описания архитектуры, такими, например, как модель Захмана; и чем большее количество методик выбранное средство поддерживает, тем больше возможностей выбора у пользователей.

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

Рис. 3.7. Принципы работы систем поддержки процесса разработки архитектуры

Перечислим более детально набор возможных функций систем разработки архитектуры предприятия:

· поддержание списка используемых на предприятии технологий, включая версии продуктов, категории (например, СУБД, платформы, системы хранения, средства разработки и т.д.);

· информационные модели, бизнес-процессов, данные, функции, объекты, организационные структуры (модели "как есть" и будущее их состояние);

· список прикладных систем с описанием функций, "владельцев", ответственных за эксплуатацию, поставщиков и т.д.;

· кросс-ссылки. Должны быть обозначены связи прикладных систем с поддерживаемыми ими моделями данных, моделями бизнес-процессов, обеспечивающими инфраструктурными технологиями;

· методики описания архитектуры. Мы посвятили отдельную лекцию описанию наиболее известных методик. Они популярны, поскольку обеспечивают способ организации огромного количества артефактов, составляющих основу описания архитектуры. Как правило, графически они отображаются в виде матриц со строками и столбцами, соответствующими различным представлениям (доменам) и уровням абстракции описания архитектуры. Должны быть обеспечены способы навигации между моделями, "расположенными в различных клетках";

· управление версиями и конфигурациями. Процесс разработки архитектуры является итерационным, включающим описания текущих и будущих состояний и моделей. Очень часто будут существовать многие версии этих моделей, и ими надо управлять;

· средства обеспечения полного цикла проектирования. Средства описания архитектуры предприятия должны иметь возможность обмениваться информацией с другими средствами проектирования и репозиториями.

В идеале, это должен быть двунаправленный процесс. Например, модели бизнес-процессов могут быть уже подготовлены с помощью пакета ARIS, и выбранное средство описания архитектуры предприятия должно иметь возможность обмена с этой системой;

· персонифицированный доступ. Различные пользователи имеют различные области интересов и права по работе с моделями архитектуры.

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

· географические и организационные кросс-ссылки. Разные организационные структуры могут иметь различный набор систем;

· возможность настройки. Некоторые инструменты обеспечивают возможности адаптации заложенных в них стандартных архитектурных методик и моделей.

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

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