Системная архитектура

I. Вступление

Архитектура распределяет массы и объемы.
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы «собственного исполнения». Такая работа, естественно, требовала привлечения специалиста высокой квалификации. А как это сделать дешево и сердито, чтобы призванный варяг был «и чтец и жнец и на дуде игрец»? Решили без всяких излишеств разработчика ПО, поименовать архитектором, и заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их на свое усмотрение, принимать самостоятельные решения и т.п…
Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют достаточно низкоуровневое проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути — является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове.
И документации вроде бы много, но она разрознена по репозиториям проектов, Вики системам и т.п. Найти логически целостное описание решения и рекомендации по его использованию крайне сложно, а уж проследить ответвляющиеся частные технические решения по цепочке: от потребностей пользователя, до конечной поставки заказчику, вообще не реально, И это несмотря на то, что для заказчика обычно готовится некая версия на базе типового продукта, доработанного в соответствии с его специфическими потребностями. А ведь иногда бывает так необходимо отследить, например, с кем связан компонент, который предполагается использовать при проектировании нового модуля. С кем он, так сказать, разделен шестью рукопожатиями, и какое пагубное влияние могут оказать все эти неучтенные связи на стабильность его поведения.
Подобная ситуация царит во многих крупных ИТ компаниях. Вроде есть архитекторы и архитектурные советы и прочие атрибуты «высокой» архитектуры, а порядка в этом царстве не наблюдается. По вышеперечисленным симптомам, выходит, что на предприятии свирепствует – «острая архитектурная недостаточность».
Мне стало интересно разобраться со всеми аспектами архитектуры, собрав в данной статье структурированно и последовательно информацию о том, что же такое ИТ архитектура, кто такие ИТ архитекторы, и «с чем их едят».

II. Определение понятия «архитектура»

А что можно думать об архитектуре?

Она, как солнце: большая, блестящая и она рядом.
Роджер Желязны. (Мастер сновидений)Давайте для начала пройдемся по определениям.
Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию. Очень скупая формулировка и развернуть ее, проиллюстрировав в полной мере смысл, сложно. Поэтому постараемся сузить проблематику и оттолкнемся от чего-то меньшего, например, составной части этой системы:
Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:

  • выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
  • соединение выбранных элементов структуры и поведения, во всё более крупные системы;
  • архитектурный стиль, который направляет всю организацию — все элементы, их интерфейсы, их сотрудничество и их соединение (1)

Довольно лаконичное определение, дополнив которое можно приблизится к пониманию, что же принято ассоциировать с явлением — ИТ Архитектура.
Во-первых, это специально подобранный, набор структурных элементов, организованных определенными способами для взаимодействия друг с другом, складывающихся в единый программно-аппаратный комплекс. Я бы еще добавил: выстроенный в угоду достижения определенных бизнес целей.
Во-вторых, место «совокупности этих элементов», как части, в более крупных системах, включая поведение, точки взаимодействия и т.п. То есть возможность абстрагирования рассматриваемой архитектуры на более высокий уровень, и соответственно детализация архитектуры в наборы составных архитектур нижнего уровня.
В-третьих, использование всеми участниками — единого подхода для организации решений в процессе производства информационных систем.
Раз уж речь зашла о едином подходе, давайте внесем ясность и в этот вопрос:
Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц (2). Ведь в ходе проектирования, разработки, развития и модернизации программной системы, «совокупность решений о ее организации» (Архитектура), требует постоянного обсуждения со всеми заинтересованными лицами проекта, включая бизнес. Опять же принципиально, чтобы все при этом выстраивали перед собой одну и туже картинку, в том числе учитывающую текущее актуальное состояние архитектуры.

Итак, размявшись на общих положениях и задав направление для исследования понятия Архитектура, продолжим углубляться в суть этого явления.

Разделы ИТ Архитекторы

Поскольку понятие ИТ архитектуры охватывает целый букет аспектов производства программных продуктов, начиная еще от определения целей автоматизации и заканчивая аж утилизацией устаревшего в какой-то момент ПО, принято делить его на несколько частей:
1) Информационная архитектура (Enterprise Information Architecture, сокр. EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:

  • базы данных и хранилища данных;
  • информационные потоки (как внутри организации, так и связи с внешним миром).

2) Архитектура прикладных решений (Enterprise Solution Architecture сокр. ESA) – представляет архитектуру приложений, включающую в себя совокупность программных продуктов и интерфейсов между ними. Делится на два направления:

  • область разработки прикладных систем;
  • портфель прикладных систем.

3) Техническая архитектура (Enterprise Technical Architecture сокр. ETA) — совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Описывает полное представление инфраструктуры предприятия, включая:

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

Плюс к этому добавляется и архитектура самого предмета автоматизации:
4) Бизнес-архитектура предприятия (Enterprise Business Architecture, ЕВА) — целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнес-архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.
Соответственно для работы с каждым из вышеперечисленных разделов, требуется своя группа заинтересованных лиц, имеющих различную квалификацию и предпочтения, а возможно и цели. Поэтому многочисленные этапы ведения проекта порождают артефакты, описывающие аспекты архитектуры в разных стилях и жанрах. В добавок, они создаются чаще всего разнородными инструментами, используя разнообразные нотации, приемы, представления и т.п.
Стало быть, каждому разделу архитектуры соответствует как минимум одна группа стейкхолдеров, имеющая свои взгляды на представления и методы описания архитектуры. Подыщем определение для этой реалии.
Архитектурная группа описаний (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания (2).Разобравшись вкратце с концепцией, направлениями и разделами архитектуры, а также выявив несовпадения в представлениях архитектуры разными группами заинтересованных лиц, перейдем к разбору непосредственно самих этих представлений (артефактов), отражающих архитектуру.

Представления ИТ Архитекторы

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

По всей вероятности нужна была какая-то подводка. А очень может быть, сначала надо было открыть людям целый новый мир, и только потом, в его свете, доносить эту свою идею. Это сродни тому, как иностранцу, не владеющему твоим родным языком, объяснять на нем теорию относительности Эйнштейна. Особенно если ты ее сам как-то не очень…
Очевидно, что и для эффективного представления архитектурных решений всем заинтересованным лицам, требуется некий способ, позволяющий доступно, но достаточно развернуто донести их суть до максимально широкого круга лиц. Таким способом может служить принятый в организации стандарт — Архитектурное описание и соответствующие методы их поддержания. Для более точного осмысления этого явления, пустим в ход и их определение:
Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры (2). Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам (2).Тем самым, выделенные архитектурные группы, используя единые архитектурные методы описания, значительно повышают эффективность своей работы, достигая максимально согласованного и целостного восприятия обсуждаемых проблем.
Но можно ли загнать специалистов разных направлений, имеющих разную квалификацию, а возможно и образ мышления, в единые рамки, и действительно ли это так необходимо?
Например, диаграмма, описывающая формирование целей и показателей на основании выявления стекхолдеров, вызовов и их проблематики см. рис.1, по своей природе очень сильно отличается от диаграмм со схемой прокладки сети, а также диаграмм в нотации UML и прочих.

Рисунок 1. Модель выработки целей и показателей
На практике использование разнородных артефактов является большой проблемой, поскольку теряется возможность сквозной трассировки архитектурных решений от целей и стратегий к потребностям, далее к описанию бизнес-процессов и функций системы, от них к структуре данных и поведенческим моделям, от моделей к макетам экранов и т.д. по цепочке. Ведь создают все эти артефакты специалисты разных архитектурных групп, которые формировались сами по себе, подбирая годами под себя оптимальные инструменты и методики.
Фиксируя все эти разнообразные описания и представления, возникает резонный вопрос: Как же их объединить в некий всеобъемлющий контекст?
Например, для разработки больших информационных систем еще в конце прошлого века использовали модель Закмана (3), в качестве схемы организации архитектурных артефактов.
Модель Закмана основана на дисциплине классической архитектуры и призвана обеспечить общее толкование архитектурных аспектов и предоставить набор перспектив, или структур (framework), для описания сложных корпоративных систем.
Сама модель представляется в виде матрицы — таблицы, имеющей пять строк и шесть столбцов, см. рис. 2. Каждая ячейка таблицы – презентует набор артефактов, раскрывающих один из насущных аспектов архитектуры.

Рисунок 2. Представление модели Закмана
Примечательно, что основная идея матрицы помимо того, чтобы вынудить заполнить все ячейки, не пропустив важные характеристики системы, состоит и в определении последовательности заполнения. Ведь только заполнив одни ячейки, открывается возможность на основании их заполнить следующие, пока пазлы не сложатся в цельную картинку. Таким образом, различные по своему представлению архитектурные описания ложатся в разные ячейки матрицы и ею же увязываются в единое архитектурное полотно.
Стоит отметить, что на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Модель Закмана со временем дорабатывалась и послужила прародителем для многих архитектурных каркасов и спецификаций.
Одной из таких актуальных спецификаций является например, графический язык ArchiMate, содержащий набор понятий для описания архитектуры предприятия и фреймворк, представляющий логическую структуру для классификации этой информации Последняя версия стандарта 3.0 вышла в июне 2016 года.
В ArchiMate, при создании моделей, используются базовые понятия «элемент» и «отношение» см. рис.3. На основе элементов и отношений строятся модели предприятия или его отдельных частей.

Рисунок 3. Основные понятия ArchiMate 3.0
Вся прелесть подхода состоит в том, что элементами могут быть проекции самых разнообразных реальных сущностей и явлений, встречающихся в жизни. Например, мотивационные элементы (стейкхолдеры, драйвер мотивации, цель, результат, ценность и т.д.), элементы организации и поведения (исполнители, роли, процессы, функции, события, взаимодействие и т.д.), бизнес элементы (информационный актив, соглашение, продукт/услуга, компонент приложения, интерфейс приложения, автоматизируемая функция и т.д.), технологические элементы (узел/ресурс, устройство, коммуникационная сеть, технологический процесс и т.д.). Каждый вид элемента представлен на диаграммах своим уникальным обозначением. Таким образом в одном информационном пространстве могут сочетаться столь разные отражения сущностей, явлений, событий, действий и т.д., образующих архитектуру предприятия.
Сами модели располагают в одной из ячеек каркаса на пересечении Слоя (уровень представления) и Аспекта. Схематично структура фреймворка представлена на рис. 4.

Рисунок 4. Слои фреймворка ArchiMate 3.0
В качестве Слоев рассматриваются конструктивные субсистемы предприятия, образующие некое самодостаточное представление (срез) организации. А Аспекты в свою очередь относят элементы, к одному из трех основных типов:
1) Активный структурный элемент (active structure element) позиционирует его, как некую сущность, которая способна выполнять определенные действия
2) Пассивный структурный элемент (passive structure element) позиционирует его, как некоторый объект, над котором выполняются действия.
3) Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.
Более подробно ознакомится со спецификацией можно в обзоре ArchiMate (4).
Такого рода инструменты позволяют объединить в единое информационное пространство разнородные аспекты архитектуры, используя унифицированное архитектурное описание и методы, обеспечивая трассировку между диаграммами и элементами.
Погрузившись во все эту «карусель» сложностей и разнообразия возникает один немаловажный вопрос: А всегда ли необходимо выполнять такой сложный и ресурсоемкий процесс описания архитектуры? На самом деле существует несколько подходов к ее построению, например:
1) Стандартный подход, заключается в разработке или выборе на начальном этапе общей схемы и правил для описания архитектуры. На основании выработанных стандартов, описывается базовая (текущая) архитектура, и отталкиваясь от нее, проектируется целевая (новая). Определив разницу, формируют мероприятия по переходу от базовой архитектуры к целевой. Только после этого начинается конструирование, приобретение и разработка компонентов системы. В качестве недостатков, можно выделить: существенные начальные инвестиций, как финансовые, так и временные. Также этот подход может привести к тому, что называется «паралич из-за анализа».
2) Подход «статус-кво». Разработка рассматривается как реакция на те или иные возникающие затруднения или воздействия.
3) Сегментный подход, опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы. Он сосредотачивается на главных областях бизнеса. Позволяет сократить возможные риски, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта. Могут возникнуть проблемы на этапе интеграции сегментов.

Резюме раздела

Итак сделаем краткую выжимку из рассмотренного нами материала:

  1. Архитектура предприятия связывает бизнес-потребности предприятия, информационные технологии, процессы стратегического бизнес-планирования, прикладные информационные системы и процессы их сопровождения.
  2. В процессе разработки и поддержания архитектуры предприятия участвуют разные группы заинтересованных лиц, имеющие различные требования к ее представлениям (архитектурный подход);
  3. Для удобства, архитектуру принято делить на разделы, соответствующие разным архитектурным зонам и подходам;
  4. Для разных архитектурных групп и подходов существуют различные группы описания (визуализации) архитектуры.
  5. Для удобства организации работы с разнородными артефактами используют архитектурные методы описания, представляющие собой специальные фреймворки и спецификации, и позволяющие работать со всеми артефактами в едином визуальном пространстве. Использование подобных конструкций помогает с одной стороны, логически разбить все представления архитектуры на отдельные разделы для упрощения их формирования и восприятия, а с другой – обеспечить возможность рассмотрения целостной архитектуры с изолированных точек зрения или соответствующих уровней абстракции.
  6. В зависимости от потребностей и возможностей предприятия, можно выбрать один из нескольких архитектурных подходов, различающихся по объему и составу выполняемых работ, что в свою очередь определяет уровень затрат и качество проектирования.

Со следующей частью статьи можно ознакомиться, перейдя по
Более подробно ознакомиться с материалом можно на: Youtub канале
Об авторских тренингах на тему: «Архитектура ИТ решений» подробнее можно узнать на сайте компании ООО ИЦ Таврида
Список литературы 1. Википедия. Архитектура программного обеспечения. — Режим доступа: ru.wikipedia.org/wiki/Архитектура_программного_обеспечения, свободный. — Загл. с экрана.
2. Свободная энциклопедия Википедия. Архитектура системы. Режим доступа: ru.wikipedia.org/wiki/Архитектура_системы, свободный. — Загл. с экрана.
3. Ю.М, Мадорская. Схема Захмана при разработке требований к ИС. б.м.: Практика проектирования систем.-2015. . Режим доступа: reqcenter.pro/zachman-framework, свободный. — Загл. с экрана.
4. Рубенчик, Андрей. Моделирование архитектуры предприятия. Обзор языка ArchiMate. Корпоративный менеджмент. . Режим доступа: www.cfin.ru/itm/standards/ArchiMate.shtml, свободный. — Загл. с экрана…
5. БудуГуру, Сайт. ИТ-архитектор. Режим доступа buduguru.org/profession/2, свободный. — Загл. с экрана.

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

В самом общем виде под архитектурой предприятия (ЕА — Enterprise Architecture) понимается всестороннее и исчерпывающее описание (модель) всех его ключевых элементов и межэлементных отношений. Согласно ISO 15704 («Industrial Automa-tion Systems — Requirements for Enterprise-Reference Architectures and Methodologies. 1999») архитектура предприятия должна включать роль людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия. Архитектура (в соответствии с документом «Federal Enterprise Architecture Framework. Dev. by: The Chief Information Officers Council (USA)») является стратегической информационной основой, определяющей:
структуру бизнеса;
информацию, необходимую для ведения бизнеса;
технологии, применяемые для поддержания бизнес-операций;
процессы преобразования, развития и перехода, необходимые для реализации новых технологий в ответ на изменение/появление новых бизнес-потребностей.

Состав, структура и процесс выстраивания архитектуры

Архитектура предприятия традиционно представляется в виде следующих слоев: корпоративные миссия и стратегия, цели и задачи; бизнес-архитектура; системная архитектура (ИТ — архитектура).

Корпоративные миссия и стратегия определяют основные направления развития предприятия и ставят долгосрочные цели и задачи.

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

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

Исследования выполнены автором в рамках работ Фонда ФОСТАС в 2003 г. Публикация осуществляется на основе разрешения, полученного Фондом от МЭРТ.

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

Архитектура данных включает: БД и хранилища данных; системы управления БД или хранилищами данных; правила и средства санкционирования доступа к данным. Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ. Сетевая архитектура включает:
локальные и территориальные вычислительные сети;
используемые в сетях коммуникационные протоколы, сервисы и системы адресации;
аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает:
аппаратные средства вычислительной техники — серверы, рабочие станции, накопители и другое компьютерное оборудование;
операционные и управляющие системы, утилиты и офисные программные системы;
аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом — серверов) и БД в условиях чрезвычайных обстоятельств.

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

Моделирование архитектуры

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

Среда моделирования архитектуры предприятия должна включать четыре компонента.
1) Блок элементарных объектов предприятия:
описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого на предприятии в настоящее время);
средства, используемые для порождения таких представлений (т.е. данных по объектам) со-гласно определенным правилам (например, ERP, SCM, CRM, СУБД).
2) Блок моделей архитектуры предприятия:
собственно модели различных видов (процессно-функциональные, информационные, ресурсные, организационные и др.), состоящие из элементов, абстрактно отображающих элементарные объекты;
средства моделирования, обеспечивающие анализ, проектирование и использование моделей.
3) Блок языков и методологий моделирования, включая:
общемодельные конструкции;
процессы моделирования архитектуры предприятия;
средства, поддерживающие процесс определения и модификации методологий и языков.
4) Блок языков мета-моделирования и мета-методологий для описания концепции, синтаксиса и семантики языков моделирования и методологий их применения, а также для описания процессов построения этих языков и методологий.

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

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

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

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

    Конкурирующая среда GERAM (Generalised Enterprise Reference Architecture and Methodology) определяет комплекс концепций, методов и моделей, необходимых для проектирования и сопровождения современного предприятия (любого типа) в течение всего времени его существования. GERAM обеспечивает поддержку всех вышепредставленных элементов среды моделирования архитектуры, базируясь при этом на:

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

    Следует отметить, что в настоящее время прослеживается тенденция к обогащению подходов в части покрытия среды моделирования, например, одна из последних разработок университета г. Бордо GRAI Integrated Methodology (GRAI-GIM) обеспечивает референсную модель с концепцией, языком, графическим формализмом и инженерным методом реали-зации методологии.

    К наиболее распространённым в настоящее время языкам моделирования предприятий относятся, прежде всего, IDEF, ARIS и BPML.

    Идея создания семейства стандартов IDEF (Integrated Computer Automated Manufacturing Definition) родилась в середине 70-х годов в ВВС США как решение проблемы повышения производительности и эффективности информационных технологий, возникшей при реализации программы ICAM (Integrated Computer Aided Manufacturing). Часть этого семейства из 14 стандартов, относящихся к методам и технологиям создания моделей сложных систем и проектирования компьютерных систем, имеет непосредственное отношение к моделированию бизнес-процессов, а именно: IDEF0 (модель функций), IDEF1 и его расширение IDEF1X (информационная модель и модель данных соответственно), IDEF2 (динамическая модель), IDEF3 (модель процессов) и IDEF4 (объектно-ориентированные методы проектирования). Часть стандартов семейства фактически осталась на бумаге (стандарт IDEF2), другая часть (IDEF0 и IDEF1X) превратилась в стандарт правительства США, известный как FIPS. Основными недостатками IDEF являются:

    ARIS в целом преодолевает перечисленные недостатки IDEF, однако его методология по сути является методологией-оболочкой: нет четко описанных регламентов действий, не предлагается уникального подхода к проблеме моделирования архитектуры предприятия. Сам язык включает более 100 типов моделей, 90% из которых практически никогда не ис-пользуются, инструментальная поддержка осуществляется продуктом той же компании — разработчика методологии. Этот продукт имеет цену, на порядок превышающую стоимость инструментов аналогичного класса для аналогичных платформ, и огромные трудозатраты на его разработку, что вряд ли позволит создать когда-либо конкурирующий инструментарий, поддерживающий данный язык.

    Одной из последних разработок в данной области является создание специального языка, ориентированного на моделирование бизнес-процессов BPML (Business Process Modeling Language). Этот язык обеспечивает построение абстрактной исполняемой модели взаимодействующих процессов на основе концепции конечного автомата (машины конечных состояний). BPML представляет бизнес-процессы посредством объединения описания взаимодействий управляющих потоков, потоков данных и событий с дополнительными ортогональными средствами моделирования бизнес-правил, ролей, контекста взаимодействия. Он поддерживает синхронные и асинхронные распределенные транзакции, поэтому может быть использован как исполняемая модель для встраивания существующих приложений в качестве процессных компонент внутри е-бизнес-процессов.

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

    Решением данной проблемы занимается рабочая группа, созданная компаниями-производителями языков моделирования, целью деятельности которой является создание унифицированного языка моделирования UEML (Unified Enterprise Modeling Language) с четко определенными синтаксисом, семантикой и правилами взаимоотношений (отображе-ний) между различными языками моделирования архитектуры предприятий. Проект UEML включает разработку:

    Заключение

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

    В среднем, каждый из вендоров осуществляет продажи ПО на сумму 7… 15 млн. долл. США в год (исключение составляет компания IDS Scheer: объявленный ею доход за 2002 г. составил 211 млн. долл. США, но он включает не только продажи ПО, но и консалтинг, обучение, выполнение проектов и т.п.).

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

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

    Список литературы

    1. Галактионов В.И. Системная архитектура и ее место в архитектуре предприятия//Директор информационной службы. 2002. № 5.
    2. Разработка типовых требований к процессам информатизации органов государственной власти, включая разработку единой методологии построения «электронного прави-тельства»//Отчет о НИОКР. Фонд ФОСТАС, № госрегистрации 1027739757561, инв. № 2811/01. Москва. 2003.
    3. Электронное правительство: рекомендации по внедрению в РФ /Под ред. В.И. Дрожжинова и Е.З. Зиндера, ЭКО-ТРЕНДЗ. Москва. 2004.
    4. Harmon P. Developing an Enterprise Architecture // Business Process Trends, January, 2003.
    5. Report on the State of the Art in Enterprise Modeling, University of Namur, 2002.

    • моделирование бизнеса с позиции менеджера, включающее построение концепций с использованием графических образов (пиктограмм) для представления бизнес-объектов и событий;
    • моделирование бизнес-процессов, бизнес-функций, ресурсов;
    • моделирование оргструктуры, включая ее нисходящую логическую схему, а также логические схемы принятия решений;
    • преобразование бизнес-моделей в модели приложений и технологической архитектуры.
    • универсальные интегрирующие среды (например, Zachman Framework, GERAM);
    • языки моделирования предприятий (например, IDEF, ARIS, BPML);
    • программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS);
    • мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML).
    • концепциях, ориентированных на человека (описание ролей, поддержка осуществляемых ролями процессов);
    • процессно-ориентированных концепциях для описания бизнес-процессов;
    • концепциях, ориентированных на технологии, для описания технологической поддержки процессов (моделирования и использования моделей).
    • наличие всего трех типов моделей — функциональной, информационной и процессной, остальные аспекты архитектуры если и могут быть отображены, то на примитивном, недостаточном для серьезного анализа уровне;
    • отсутствие интеграции даже для перечисленных трех типов моделей (при этом отсутствует как концепция интеграции, так и какая-либо реализация на уровне инструментов одного и того же производителя).
    • общего, визуального, базированного на шаблонах языка для коммерческих инструментальных средств моделирования предприятий и программных систем класса workflow;
    • стандартизованных, независимых от инструментов механизмов передачи знаний (моделей) между проектами;
    • репозитория моделей предприятий.
    • оказание помощи менеджерам при анализе потенциальных изменений и их реализации;
    • предоставление основы для совместной работы бизнес-менеджеров и ИТ-менеджеров над целями, бизнес-процессами и выстраиванием предприятия в целом;
    • предоставление единого хранилища всей информации о предприятии;
    • обеспечение менеджерам поддержки в принятии решений: они могут обозревать отношения, задавать вопросы, идентифицировать проблемы, выполнять моделирование и т.д.

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

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

    Общая характеристика системной архитектуры проектируемого программного средства (архитектуры верхнего уровня) – это описание объектов технических и программных средств и ручных операций.

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

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

    Системная архитектура и требования к объектам архитектуры должны быть оценены с учетом следующих критериев (при этом результаты оценок должны быть документально оформлены):

    a) учет требований к системе;

    b) соответствие требованиям к системе;

    c) соответствие используемых стандартов и методов проектирования;

    d) возможность программных объектов архитектуры выполнять установленные для них требования;

    e) возможности эксплуатации и сопровождения.

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

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

    Разработчик должен установить и документально оформить следующие требования к программным средствам, включая технические требования к характеристикам качества (рекомендации по определению характеристик качества приведены в ГОСТ Р ИСО/МЭК 9126):

    a) функциональные и технические требования, включая производительность, физические характеристики и окружающие условия, под которые должен быть создан программный объект архитектуры (далее — программный объект);

    b) требования к внешним интерфейсам программного объекта архитектуры;

    c) квалификационные требования;

    d) требования безопасности, включая требования, относящиеся к методам эксплуатации и сопровождения, воздействию окружающей среды и травмобезопасности персонала;

    e) требования защиты, включая требования, относящиеся к допустимой точности информации;

    f) эргономические требования, включая требования, относящиеся к ручным операциям, взаимодействию «человек-машина», персоналу и областям, требующим концентрации внимания человека, связанным с чувствительностью объекта к ошибкам человека и обученности персонала;

    g) требования к определению данных и базе данных;

    h) требования по вводу в действие и приемке поставляемого программного продукта на объекте(ах) эксплуатации и сопровождения;

    i) требования к документации пользователя;

    j) требования к эксплуатации объекта пользователем;

    k) требования к обслуживанию пользователя.

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

    a) учет требований к системе и проекту системы;

    b) внешняя согласованность с требованиями к системе;

    c) внутренняя согласованность требований к объектам между собой;

    d) тестируемость требований;

    е) выполнимость программного проекта;

    f) возможность эксплуатации и сопровождения.