Методика построения архитектуры предприятия при интеграции информационных систем

Ольга Рябчикова
Инженер АО ИК «АСЭ».

Данная статья включает основные понятия по теме «архитектура предприятий», а также анализ популярных методик, предназначенных для описания таких архитектур, с выявлением наиболее подходящей модели при создании такого комплексного решения, как ESB (enterprise service bus) — корпоративной интеграционной шины [1] информационных систем компаний, занимающихся проектированием и сооружением сложных инженерных объектов.

Введение

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

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

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

В результате применение фреймворков Solution Architecture (Архитектура прикладных решений) оказывается недостаточным для проектирования и успешной реализации такого сложного продукта, как ESB. Логичным становится использование Enterprise Architecture (Архитектура предприятия). Остается вопрос выбора наиболее подходящей методологии описания архитектуры при создании интеграционных решений на предприятиях по проектированию и сооружению сложных инженерных объектов.

Архитектура предприятия

Архитектура — фундаментальная организация системы, воплощенная в ее компонентах, их взаимоотношениях друг с другом и окружением, а также принципы ее разработки и эволюции [3].

Корпоративная архитектура, или архитектура предприятия, — это описание целей организации, способов достижения этих целей с помощью бизнес­процессов и методик повышения эффективности обслуживания бизнес­процессов с применением различных технологий [4].

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

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

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

• методика TOGAF;
• методика Gartner;
• методика META Group.

Методика TOGAF

Методика TOGAF является описанием архитектуры предприятия, которая предлагает способы и подходы для выстраивания, планирования, применения  IT­архитектуры предприятия и, впоследствии, управления ею. TOGAF принимает, но не строго придерживается определения ISO/IEC 42010:2007. В TOGAF термин «архитектура» имеет два значения, в зависимости от контекста:

1. Формальное описание системы или детальный план системы на уровне ее компонентов для руководства ее реализацией.
2. Структура компонентов, их взаимосвязь, а также принципы и руководящие указания по их разработке и эволюции во времени [6].

Архитектура предприятия по TOGAF представлена четырьмя направлениями:

1. Архитектура бизнеса.
2. Архитектура приложений.
3. Архитектура данных.
4. Архитектура технологии.

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

Методика TOGAF включает два направления:

1. Методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры.
2. Базовая архитектура (Foundation Architecture).

Методика ADM включает несколько фаз, которые представлены на рис. 1.

Рис. 1. Методика ADM TOGAF

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

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

• архитектуры общих систем;
• отраслевой архитектуры;
• архитектуры организации [5].

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

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

Методика Gartner

Компания Gartner трактует понятие «архитектура предприятия» как процесс перевода видения и стратегии бизнеса в эффективное изменение компании посредством создания, обсуждения и улучшений ключевых требований, принципов и моделей, которые описывают будущее состояние компании и делают возможным ее развитие [7].

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

Суть методики Gartner — создание процесса, который позволит развивать архитектуру в соответствии с высокоуровневой архитектурой бизнес­стратегии. Она образует только общее видение системы и не определяет ни формата, ни языка для описания архитектуры.

Методика META Group

Данная методика рассматривает архитектуру предприятия в интеграции с другими процессами, к примеру с процессом управления корпоративными IT­программами и проектами и процессом выработки стратегии и планирования.

Основными этапами разработки архитектуры предприятия являются:

1. Видение общих требований, где осуществляется анализ вектора развития, определение требований к информационным системам.
2. Создание концептуальной архитектуры, где определяется перечень правил, который обеспечивает общий принцип для развития информационных систем предприятия и технологической инфраструктуры.
3. Разработка плана реализации для достижения конечной архитектуры.

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

Сравнительный анализ

Какая же из методик позволит нам доступно и детализированно отобразить архитектуру ESB, которая могла бы послужить основой для последующего воплощения решения?

Можно заметить, что у всех методик есть как общие линии пересечения, так и кардинальные отличия друг от друга. Для сравнения методологий выделим несколько критериев, основываясь на экспертном мнении Роберта Сешнса [8] — известного практика компании Microsoft в области архитектуры предприятий, и с помощью таблицы соответствий определим, какая из методик более подходит для решения ранее поставленной задачи.

Из таблицы соответствия явно видно преимущество методики TOGAF. Как же выглядит применение методики на реальном проекте?

Таблица сравнения методик

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

Рис. 2. Применение Archimate при интеграции двух программных комплексов

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

Заключение

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

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

1. David Chappell. Enterprise Service Bus. Publisher: O’Reilly Media. Release Date: June 2009. Совнет. Ассоциация управления проектами.
2. Управление проектами. Свод профессиональных знаний. Национальные требования к компетентности специалистов. Версия 3.0.
3. ISO\IEC 42010:20077: Systems and Software Engineering — Recommended Practice for Architectural Description of Software­Intensive Systems, Edition 1 (technically identical to ANSI/IEEE 1471­2000).
4.  https://msdn.microsoft.com/ru­ru/library/ee895290.aspx.
5. Данилин А., Слюсаренко А. «Архитектура и стратегия. «Инь» и «янь» информационных технологий предприятия». Издательство: Интернет­Университет Информационных технологий.
6. https://www.ibm.com/developerworks/ru/library/ws­soa­term1/
7. Джеймс Г., Грета А., Роберт А. Хэндлер, Энн Лапкин и Николас Галл. «Структура архитектуры предприятия Gartner: развитие, 2005 г.». Код Gartner: G00130855.
8.  https://msdn.microsoft.com/ru­ru/library/ee914379.aspx
9. http://pubs.opengroup.org/architecture/archimate3­doc