Принципы, модели и стандарты в рамках архитектуры предприятия

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

Рис. 2.Модель, используемая для описания стратегии и архитектуры информационных технологий

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

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

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

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

· Миссия и видение.

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

· Цели, задачи и стратегии.

· Архитектура информационных технологий.

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

· ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. В случае, когда речь идет о стандартах, выбираемых государством, особенно важным является подход, когда стандарты описывают только наиболее общие и важные элементы технологий в соответствии с принципами честной конкуренции.

· Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.

· Руководства или рекомендации (guidelines). Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

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

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

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

Рис. 3.Политики, стандарты и процедуры

Важным представляется следующее замечание, сформулированное в архитектурной методике META Group, которое касается роли принципов и моделей в описании архитектуры. Можно сказать, что существуют два различных подхода к процессам разработки, описания и использования архитектуры предприятия: существенная, возможно, даже большая часть специалистов и компаний считает, что основой архитектуры являются принципы, а другая часть придерживается точки зрения, что основой архитектуры является процесс создания моделей. META Group полагает, что при описании сегодняшней, существующей архитектуры (архитектуры "как есть") необходимо в большей степени руководствоваться декларациями принципов, на основе которой она построена; в то же время, будущие состояния архитектуры должны описываться с использованием соответствующих моделей, описывающих отдельные представления (домены) будущей архитектуры.

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

Основой таких рекомендаций META Group являются следующие соображения. Когда организация находится в самом начале процесса разработки своей архитектуры, то, как правило, нет полной ясности и согласия по поводу используемых моделей и даже разбиения архитектуры на представления (домены).

В этих условиях первое, что архитектура предприятия должна дать сразу и всем участникам процесса – это общие рекомендации по текущим проектам, чтобы их руководители могли понимать общее направление. Первым правилом является правило "не навреди", что и означает задание общего для всех стратегического направления. Это достигается через формулировку принципов, которые для этого являются очень мощным инструментом. Принципы – это высокоуровневые руководства к действию. Примером принципа может быть следующий: "Мы будем использовать передовые технологии, но только не самые новейшие и непроверенные". Конечно, это требует последующего уточнения понятий "передовые технологии" и "новейшие технологии". Принципы одновременно обеспечивают инструмент принятия неизбежных компромиссных решений при разработке моделей и обеспечения единства между различными доменами архитектуры.

Эволюция содержания архитектуры предприятия по мере ее разработки и развития условно показана на рис.4.

Рис. 4.Эволюция контента Архитектуры предприятия

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

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

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

Ниже приведены примеры общих принципов, связанных с архитектурой в целом:

· Все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом.

· Функциональное руководство и руководство в области ИТ должно основываться на общем видении.

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

· Функциональные (бизнес-) требования должны формировать архитектуру.

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

· Архитектура должна быть расширяемой, масштабируемой и адаптивной.

· Архитектура должна быть инструментом реализации изменений.

· Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов.

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

Примеры декларируемых принципов в области ИТ-инфраструктуры:

· Инфраструктура должна быть основана на использовании технологий, поддерживающих открытые стандарты.

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

Примеры принципов в области управления данными:

· Бизнес-структуры (отделы, департаменты, ведомства), являющиеся владельцами данных, отвечают за целостность и распространение данных.

· Данные уровня отдельных бизнес-структур (департамента, региона, города) должны быть явно описаны и доступны всем остальным бизнес-структурам (департаментам, ведомствам).

· Ведомства собирают только самый необходимый минимум данных и стремятся уменьшить нагрузку на тех, кто должен предоставлять данные.

· Данные вводятся в информационные системы один раз, и тут же выполняется проверка их корректности.

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

Примеры принципов, связанных с прикладными системами:

· Прикладные системы разрабатываются на основе стандартной, единой методологии.

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

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

· Руководство заранее планирует процесс замены устаревших прикладных систем.

Примеры принципов, связанных с управлением и контролем:

· Единая архитектура, соответствующие стандарты и руководства используются всеми структурными подразделениями (ведомствами) в процессе принятия решений о своих информационных системах.

· Стандарты пересматриваются регулярно не реже одного раза в два года с участием представителей структурных подразделений (ведомств).

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

Вот еще некоторые варианты формулировок принципов:

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

· должны существовать механизмы управляемого развития архитектуры.

· целью архитектуры должно быть уменьшение сложности интеграции систем.

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

· Информация является общекорпоративным активом.

· Прикладные системы будут строиться с использованием n-уровневой архитектуры (презентационная логика, бизнес-логика, уровень доступа к данным, уровень данных).

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

· Применение компонентной разработки информационных систем.

· Использование технологий анализа данных (Business Intelligence) для ускорения принятия решений и упрощения разработки.

· ИТ-служба будет использовать стандарты и методику управления качеством "Шесть Сигма" в процессе обеспечения качества прикладных систем и ИТ-услуг (принцип, который может быть принят в результате анализа сильных и слабых сторон ИТ-службы).

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

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

При разработке и использовании стандартов следует учитывать нижеперечисленные аспекты:

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

· Определяйте стандарты процессов. Примерами являются процессы бизнес-моделирования, методы разработки систем, тестирования, интеграции.

· Уделяйте внимание интерфейсам. Понимание интерфейсов является основой для интеграции систем.

· Теснее взаимодействуйте с бизнес-подразделениями. Например, разработка основанных на XML стандартов на электронные сообщения невозможна без участия специалистов в конкретных предметных областях.

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

· Стандарты должны включать способы проверки на соответствие.

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

Руководства (рекомендации) обеспечивают помощь в разработке и создании систем, давая примеры лучших практик и конкретные руководства по выполнению чего-либо. Сделаем наиболее важные замечания, касающиеся руководств:

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

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

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

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

Модели и моделирование

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

В общем, модели можно классифицировать по различным критериям, например:

· формальные (использующие общепринятые правила, нотации и средства) и неформальные;

· количественные – позволяющие производить численные оценки и проверки, и качественные, предназначенные для понимания поведения и структуры системы;

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

Примерами качественных и описательных моделей являются:

· текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст;

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

Примерами количественных моделей могут служить:

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

· динамические исполняемые модели, которые строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. Модели последнего типа относятся к числу наиболее сложных и часто применяются на этапе выбора архитектуры сложных систем со многими элементами и связями, особенно когда поведение элементов описывается нелинейной или случайной функцией. Хотя разработка такой модели и проведение исследований требуют определенных затрат времени и ресурсов, во многих случаях применение таких моделей оказывается экономически обоснованным (см 6.7), а в отдельных областях, связанных с военными, космическими, ядерными и другими объектами такого рода – единственно возможным.

К сожалению, возможных моделей для описания деятельности предприятия как системы существует множество, и очень часто в организации происходит достаточно разрозненный процесс моделирования. Например, для описания бизнес-архитектуры используются модели, включающие представления о бизнес-объектах и логике (например, декомпозиция процессов, сценарии использования, взаимосвязи между объектами). На уровне прикладных систем используются, например, диаграммы "сущность-отношения", карты иерархии управления, диаграммы потоков данных, на уровне инфраструктуры – топология сетей, инфраструктурные шаблоны и т.д. Консолидация таких различных представлений – то есть понимание того, как все эти многочисленные модели связаны между собой, – является весьма сложной задачей. Например, какова связь между одним артефактом на некотором высоком уровне абстракции (к примеру, модель бизнес-процесса) с другим артефактом на более детальном уровне (к примеру, стандарт на сервера приложений). Эта проблема может свести на нет пользу от моделирования. Поэтому одной из важных задач любой методики описания архитектуры становится логическая организация моделей, описывающих единую архитектуру предприятия.

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

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

Первым шагом в плане создания высокоуровневых моделей предприятия является создание моделей бизнес-процессов. Мы более подробно рассмотрим этот аспект в разделе, посвященном бизнес-архитектуре.

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

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

Эти модели описывают архитектуру предприятия на различных уровнях абстракции, которые соответствуют "взглядам" на предприятие различных категорий людей. Процесс условно отображен в виде следующей таблицы, в которой в качестве иллюстрации приведены примеры возможных моделей для каждого домена архитектуры и каждого уровня абстракции. Во-первых, заметим, что, по сути, это соответствует модели архитектуры Захмана, которая описана в 5.2. А во-вторых, с одной стороны, это список не является исчерпывающим, а с другой, на уровне описания архитектуры предприятия в целом, могут отсутствовать модели "нижних" уровней абстракции.

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

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

Таблица 1.

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

Домены	Бизнес-архитектура	Архитектура информации	Архитектура приложений	Технологическая архитектура
Перспекивы (уровни абстракции)
Контекст ("планировщик")	· Классы бизнес-процессов (группа процессов, имеющих много общих активностей) · Список бизнес-процессов	· Список бизнес-сущностей – объектов, важных для бизнеса ("клиент", счет") · Связи между сущностями (бизнес-объектами)	· Список бизнес-процессов	· Список мест расположения бизнеса
Концептуальный уровень ("владелец" предприятия)	· Сценарии использования (Use case) · Модели бизнес-процессов	· Семантические модели · Модели связей · Модели "сущность-связи"	· Разбиение процессов на сервисы	· Модели бизнес-логистики · Операционные (нефункциональные) требования · Архитектура расположения элементов центра обработки данных
Логический ("проектировщик")	· Модели процессов (потоков работ) · Модели бизнес-событий · Модель расположения процессов · Определения ролей	· Логические модели данных · Схемы данных · Спецификации документов	· Определения сервисов · Взаимосвязи между сервисами · Модели классов	· Логические типы серверов: БД, почтовые, транзакционные, … · Географическое распределение серверов · Хостируемое ПО
Физический ("разработчик")	· Спецификации процессов · Модели интеграции процессов · Описание ручных процедур · Стандарты качества	· Физические модели данных · Схемы БД · Код доступа к данным · Справочники данных	· Код программ · Описания интер-фейсов (WSDL) · Расписания процессов · Код workflow	· Физические серверы · Топология фрагментов сети · Мапирование продуктов на сервисы и приложения

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

Рассмотрим вначале концептуальный уровень абстракции. Динамическая модель для этого уровня должна отражать взаимодействия между клиентом и магазином. При этом сама проектируемая система выступает как один из акторов процесса в качестве "черного ящика". Клиент и сотрудник(и) магазина выступают как внешние по отношению к системе акторы. Весь процесс рассматривается с точки зрения клиента и сотрудника. Клиент осуществляет заказ через Интернет. Оплата выполняется с помощью кредитной карты. Заказ посылается по указанному адресу. Уведомление о выполнении заказа посылается по электронной почте. Модель на самом высоком уровне описывает бизнес-процессы продавца и содержит простой сценарий использования (use case), описывающий взаимодействия между системой и акторами. Рисунок 5 иллюстрирует такую концептуальную динамическую модель и содержит простую нотацию сценария использования для этого бизнес-взаимодействия.

Рис. 5.Динамическая концептуальная модель процесса закупки товара

Статическая модель на этом уровне абстракции отражает структуру классов и связи между объектами, необходимость в которых становится очевидной при анализе динамической модели. Другими словами, она отвечает на вопрос "Какие объекты должен понимать клиент для того, чтобы выполнить транзакцию, связанную с покупкой?" Рисунок 6 показывает диаграмму классов, которая является статической концептуальной моделью.

Рис. 6.Статическая модель процесса закупки товара в магазине

Клиент является конкретной реализацией класса Человек. Связи между клиентом и магазином обеспечены наличием Учетной записи клиента. Все Заказы ассоциированы с Учетной записью. Заказ ассоциирован со всеми приобретаемыми Элементами заказа. Каждый элемент заказа является специфическим Продуктом, где Продукт сам по себе является классом. Наконец, каждый Платеж ассоциирован с некоторым Заказом.

Вообще говоря, современное состояние индустрии информационных технологий в области моделирования можно охарактеризовать как "время больших перемен". С одной стороны, такая некоммерческая организация как Object Management Group (OMG) находится в процессе реализации ряда инициатив, которые имеют непосредственное влияние на развитие технологий моделирования предприятия и его информационных систем. Эта организация выдвинула концепцию архитектуры, основанной на моделях (MDA – Model-Driven Architecture, см. "Технологическая архитектура, стандарты и шаблоны" ), развивает язык моделирования систем Unified Modelling Language (UML). При этом основная идея состоит в автоматизированном (насколько это возможно) процессе создания кода прикладных систем на основе разработанных моделей.

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

Решая более прагматичные задачи моделирования в интересах разработчиков систем, компания Microsoft, участвуя в работе OMG, в то же время выдвинула свою инициативу, связанную с моделированием информационных систем. Она основана на использовании языков DSL (Domain Specific Languages). Идея состоит в создании некоторого числа компактных, как правило, декларативных языков, предназначенных для описания различных предметных областей. Стратегия Microsoft состоит в использовании этих языков в рамках своих средств разработки (Visual Studio).

Примерами таких языков является язык описания бизнес-сущностей Business Entity DSL (например, "клиент", "заказ"), язык описания бизнес-процессов Business Process DSL (бизнес-активности, роли, зависимости), язык описания логической архитектуры систем LogicalSystems Architecture DSL (описание конфигураций центров обработки данных), язык для описания web-сервисов Web Services DSL. При этом информация об одной модели может использоваться для создания другой модели. Примерами могут служить взаимодействие между моделями бизнес-сущностей и бизнес-процессов или между моделями web-сервисов и логическими серверами, на которых они будут размещены.

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

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

Подводя итог этому краткому обсуждению вопросов моделирования в рамках архитектуры предприятия, можно сказать следующее:

· Нет и не стоит в ближайшее время ожидать одной, универсальной технологии создания моделей.

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

Бизнес-архитектура