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

Цифровая трансформация прочно укрепилась в качестве направления развития нашей страны. 5 июля 2017 г. министр связи и массовых коммуникаций Российской Федерации Николай Никифоров в рамках заседания Совета при Президенте по стратегическому развитию и приоритетным проектам представил Владимиру Путину разработанную министерством программу «Цифровая экономика». Главная идея программы, по словам министра, состоит в том, чтобы создать в России определённый набор условий для запуска и ускорения цифровизации привычного жизненного и экономического уклада. 

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

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

Начать эту главу мы хотим с краткого экскурса в возникновение и развитие понятия «архитектура предприятия». 

Как область знаний, архитектура предприятия родилась в 80-х годах прошлого века в ответ на вопросы, которые волновали как отдельные предприятия, так и целые государства: почему такой полезный инструмент, как ИТ, несмотря на значительные усилия заинтересованных сторон и существенные инвестиции, не приносит ожидаемых выгод? Одна из причин неэффективности — оторванность автоматизации от бизнес-процессов предприятия и несогласованность усилий по автоматизации в отдельных подразделениях. Сейчас, с появлением облачных технологий, эта угроза вышла на новый уровень: возникают так называемые теневые облака, когда отдельные функциональные подразделения, привлечённые видимой простотой внедрения и относительной дешевизной облаков (ежемесячный платёж за аренду ПО может быть «невидим» в бюджете подразделения), внедряют их вне архитектуры предприятия, без согласования с подразделениями ИТ, которые об этих проектах зачастую даже не подозревают.

В начале 80-х годов компания IBM начала разрабатывать метод Business System Planning (BSP), предназначенный для анализа и описания архитектуры программных систем. BSP определяет 13 этапов внедрения информационных систем и основан на построении и постепенном уточнении ряда матриц, в частности, матрицы «руководители — процесс», определяющей вовлеченность руководителей в основные бизнес-процессы, матрицы «информационные системы — руководители», отражающей потребность руководителей в программных системах, матрицы «информационные системы — процессы», матрицы «информационные системы – файлы данных». 

Джон Захман окончил Химический факультет Университета Northwestern, затем несколько лет прослужил офицером в Армии США. В 1964 пришёл в IBM, где занимал ряд маркетинговых позиций в Чикаго, Нью-Йорке и Лос-Анжелесе. В 1970 г. стал заниматься методологией BSP. На основании анализа BSP Джон Захман создал свою модель, ставшую стандартом де-факто моделирования архитектуры предприятия. Он описал эту модель в ряде статей, первая из которых появилась в 1987 году В ней он одним из первых употребил термин «архитектура предприятия» (Enterprise Architecture). 

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

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

Джон Захман, «A Framework for Information» System Architecture.IBM System Journal, vol. 26, no. 3, 1987

Роль CIO — архитектор предприятия

Для моделирования архитектуры предприятия появилась новая роль (должность) — архитектор предприятия. Он отвечает за создание, развитие, актуализацию корпоративных архитектурных моделей. Он также следит за тем, чтобы архитектура внедряемых программных систем, с одной стороны соответствовала архитектуре предприятия, а с другой — способствовала её развитию. На больших предприятиях (в связи со сложностью архитектурных моделей) существуют отдельные подразделения, объединяющие таких архитекторов. Архитектор предприятия должен обладать системным подходом, аналитическим мышлением, широкой эрудицией в области ИТ, корпоративного управления, бизнес-процессов, владеть средствами моделирования архитектуры. Архитектор предприятия должен уметь понимать проблемы и предметную область бизнеса и объяснять их техническим специалистам, а также владеть принципами современных технологий и объяснять их возможности представителям бизнеса. Области компетенции архитектора предприятия показаны на Рис. 1.

Рис. 1. Роль CIO – архитектор предприятия.

Архитектурный процесс на предприятии должен осуществляться под руководством CIO. В акте Клингера-Коэна, который регулирует политику в области ИТ для государственных организаций США, к инвестициям в ИТ предъявляются следующие требования:

• инвестиции в ИТ должны поддерживать стратегию развития ИТ, согласованную со стратегией развитии организации, и основываться на архитектуре предприятия;
• в каждой государственной организации должен быть руководитель — CIO, показатели деятельности которого должны быть чётко определены;
• одна из основных функций CIO — развитие архитектуры предприятия.

Таким образом, акт Клингера-Коэна провозгласил, что моделирование архитектуры предприятия является основой процесса планирования затрат и управления инвестициями правительства США в области ИТ, и это область ответственности CIO. Хотя в России нет пока аналога акта Клингера-Коэна, нельзя забывать, что одно из самых зрелых с точки зрения ИТ государств считает этот процесс основной обязанностью CIO.

Акт Клингера-Коэна (Clinger-Coen Act — CCA) — это федеральный закон США 1996 г., который предписывает государственным предприятиям соблюдать принципы управления ИТ, основанные на измерении производительности и архитектуре предприятия. CCA требует, чтобы каждое государственное агентство США разрабатывало модель архитектуры предприятия. CCA послужил источником значительных изменений в ролях и ответственности различных федеральных агентств в области управления развитием и приобретением ИТ. В частности, с ним связано появление позиции CIO во всех государственных предприятиях. Появление закона инициировало внедрение концепции архитектуры предприятия не только в государственных агентствах, но и во всех организациях США. 

Для улучшения использования информационных ресурсов и выполнения акта Клингера-Коэна было образовано межагентское объединение американского правительства CIO Council. В 1998 г. CIO Council начал развивать Federal Enterprise Architecture Framework (Структура Федеральной Архитектуры Госпредприятий) – один из Фреймвоков архитектуры предприятия.

Общие понятия и определения

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

Архитектура предприятия (Enterprise Architecture) — это область знаний об организации, её компонентах, их взаимодействии, с учётом развития. Термин «архитектура предприятия» является сужением термина «архитектура системы», который в соответствии с IEEE определяется следующим образом:Архитектура — это базовая организация системы, воплощённая в её компонентах, их отношениях между собой и с окружением, а также принципы, определяющие её проектирование и развитие. (ANSI/IEEE Std 1471-2000)Предприятие является, несомненно, одной из самых сложных систем окружающего нас мира и для него полностью правомерно использование понятия «архитектура». И чем больше и сложнее предприятие, тем важнее для него архитектурный подход.

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

Определение из акта Клингера-Коэна чётко перечисляет, какие области охватывает архитектура предприятия:

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

Архитектурные модели и фреймвоки

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

Выбор модели определяется целью применения архитектурного подхода. Ниже мы подробно расскажем о нескольких самых распространённых моделях и фреймвоках архитектуры предприятия — модели Захмана, Стивена Спивака и TOGAF, а также стандарте на описание архитектуры предприятия Archimate. Кроме них существуют и другие важные архитектурные модели: FEA (Federal Enterprise Architecture, наиболее интересная её часть — справочная модель производительности (Performance Reference Model, PRM), DoDAF (Departent of Defence Architecture Framework), GERAM (Generalised Enterprise Reference Architecture and Methodology) и MOF (Microsoft Operations Framework).

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

В области архитектуры предприятия наиболее известны следующие фреймвоки:

FEAF — Federal Enterprise Architecture FrameworkDo

DAF — Departent of Defence Architecture Framework

TOGAF — The Open Group Architecture Framework

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

Большинство моделей описания архитектуры предприятия в той или иной степени используют «перспективы», уровни взгляда на предприятие или слои. Как правило, в качестве основных уровней (слоёв) архитектуры предприятия рассматриваются четыре архитектуры:

• Архитектура бизнеса (бизнес-архитектура).
• Архитектура данных.
• Архитектура приложений.
• Технологическая архитектура (инфраструктура).

Именно такие уровни (слои) описания архитектуры использованы в моделях TOGAF, FEA, Стивена Спивака, MOF и других. Опишем подробнее, какие элементы включаются в описание каждой из архитектур.

1. Архитектура бизнеса описывает, как работает бизнес. Существует множество подходов к описанию того, как работает бизнес, и нет единого устоявшегося мнения о том, какие элементы следует включить в описание архитектуры бизнеса. Однако, принято считать, что наиболее значимыми элементами в этой области являются «процессы и информация», «организация» и «производительность». Элемент «процессы и информация» наиболее важен, так как описывает и классифицирует бизнес-структуры, бизнес-процессы и потоки деятельности, которые составляют бизнес- модель организации. Элемент «организация» описывает организационную структуру и методы работы, продукты и услуги, которые производит бизнес, бизнес-единицы их размещение и т. д. Элемент «производительность» описывает показатели, которые измеряют эффективность работы предприятия (производительность, бизнес-риски и др.). Один из возможных вариантов отображения бизнес-архитектуры приведён на Рис. 2.

Рис. 2. Вариант отображения бизнес-архитектуры.

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

• Структура данных.
• Требования к переносу данных.
• Требования по управлению данными.

2.1. Структура данных, в свою очередь, состоит из классификаторов и характеристик данных. Выделяются четыре типа данных: мастер-данные, метаданные, транзакционные и исторические данные (Рис. 3).

Рис. 3. Типы данных в описании архитектуры данных. 

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

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

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

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

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

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

• структура — организационная структура и органы стандартизации управления преобразованием данных;
• люди — навыки и роли, которые нужны для преобразования данных;
• системы управления данными на протяжении их жизненных циклов. 

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

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

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

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

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

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

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

Архитектурный подход при внедрении бизнес-приложений — модель Захмана

Самой популярной архитектурной моделью, которая активно используется при описании не только архитектуры предприятия, но и архитектуры других систем, является модель Захмана. Первый вариант своей модели Джон Захман создал в 1987 г. для использования, прежде всего, при внедрении крупных бизнес-приложений.

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

В модели Захмана выделяются следующие перспективы:

1. Хозяин или планировщик (Planner) — тот, кто устанавливает направление развития организации: прогнозирует изменения внешней среды, область функционирования организации, цели её деятельности. Это могут быть инвесторы или собрание акционеров компании.

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

3. Проектировщик (Designer) — конструктор или системный архитектор, который является промежуточным звеном между желаемым состоянием организации (с точки зрения «владельца») и технически/физически возможным. Сюда относятся аналитики и проектировщики. Применительно к ИТ, это постановщики задач и бизнес-аналитики.

4. Подрядчик (Builder) — генеральный подрядчик, который обеспечивает производство конечного продукта или услуги. В рамках проекта — это руководитель проекта или системный аналитик. 

5. Субподрядчик (Subconstructor) — тот, кто отвечает за построение и компоновку части конечного продукта или услуги, проектировщик и разработчик части конечного продукта или услуги. Например, это внешние компании, которые поставляют оборудование или программное обеспечение, или разрабатывают подсистему.

6. Пользователь — тот, кто использует продукты или услуги работающего предприятия. Применительно к ИТ — это рядовые сотрудники компании.

Столбцы же матрицы отражают различные стороны (или аспекты) деятельности системы, или в конкретном случае, предприятия, которые сгруппированы по ответам на вопросы: Кто, Что, Где, Когда, Как, и Почему. 

Запоминаем столбцы матрицы Захмана через детский стишок

Есть у меня шестёрка слуг,

Проворных, удалых,

И все, что вижу я вокруг,

Все знаю я от них.

Они по знаку моему являются в нужде.

Зовут их: Как и Почему, Кто, Что, Когда и Где.

Редьярд Киплинг (перевод С.Я. Маршака)

Для пояснения приведём примеры того, что относится к разным столбцам модели Захмана для предприятия.

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

Что — это объекты предприятия, включая используемые данные (оборудование, материалы, элементы и базы данных).

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

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

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

Почему (или Зачем) — это мотивация и порядок трансляции миссии и стратегии на нижние уровни (стратегии, желаемые результаты и параметры достижений).

Архитектура, что бы это ни было, это именно то, что наводит мосты между стратегией и её реализацией.

Джон Захман

Пример матрицы Захмана показан в Рис. 4.

Рис. 4. Модель Захмана.

Захман писал: «Вопросы что, как, где, кто, когда и зачем существуют тысячи лет. И они будут существовать ещё тысячи лет. Требования к системам, процесс проектирования, производства или концептуальный, логический и физический уровень описания также существуют в течение тысяч лет и будут существовать ещё тысячи лет. Логическая структура классификации и схема — неизменны».

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

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

Архитектура как процесс

У термина «архитектура» существуют две стороны, которые дополняют друг друга. Одна — архитектура как описание, статический слепок некоторой сложной системы. И вторая — архитектура как процесс, набор руководств и правил, которые определяют построение новых подсистем сложной системы, а, следовательно, её развитие. Здесь уместно вспомнить определение Gartner Group: «Архитектура — это глагол, а не существительное». Архитектура как процесс — это один из важнейших процессов предприятия. Архитектура предприятия находится в постоянном развитии от текущей архитектуры предприятия к целевой. Разовое создание набора архитектурных моделей с неясным сценарием не принесёт компании выгоды. Именно поэтому появляется всё больше архитекторов и целых подразделений, которые на постоянной основе занимаются моделированием и развитием архитектуры предприятия.

Развитие архитектуры предприятия осуществляется в выбранном стратегическом направлении и на основании видения и принципов развития организации. Институт разработки архитектуры предприятий (Institute for Enterprise Architecture Development, IFEAD) обобщает основные руководящие принципы архитектуры предприятия следующим образом: «нет стратегических прогнозов — нет архитектуры предприятия». То есть архитектура предприятия — это целостный взгляд, который объединяет элементы бизнеса и технологии, исходя из общего стратегического прогноза развития предприятия.

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

Спивак, как и Захман, работал в IBM, был озабочен теми же проблемами и обратился к архитектурным подходам лишь на год позже Захмана. Он соединил модель Захмана с методикой планирования и формирования целевой архитектуры. В основе метода Спивака лежит процесс планирования архитектуры предприятия (Enterprise Architecture Planning, EAP), направленный на разработку архитектуры, оптимально использующей информацию для поддержки бизнеса. Процесс EAP направлен на определение того, какие данные, приложения и технологии наиболее полно отвечают потребностям конкретного предприятия. Основные этапы EAP модели Спивака приведены на Рис. 5. Однако в полной мере процесс планирования и изменения архитектуры предприятия нашёл отражение в методологии TOGAF.

Рис. 5. Семь шагов архитектурного процесса Спивака.

Практические шаги по моделированию архитектуры предприятия

На практике процесс работы с архитектурой предприятия состоит из пяти шагов:

• Определение общих контуров (видения) архитектуры — какой должна быть архитектура предприятия и зачем мы её описываем, а также рамки разработки архитектуры, заинтересованные лица и план работ.
• Построение модели архитектуры «как есть».
• Построение модели архитектуры «как должно быть».
• Определение шагов, которые позволят перейти от «как есть» к «как должно быть». План изменений архитектуры чаще всего содержит более одного предлагаемого решения, в результате чего может возникнуть несколько вариантов изменения архитектуры.
• Формирование путей дальнейшего развития архитектурной модели, т.е. определение правил дальнейшей детализации и актуализации модели, дополнения её конкретными архитектурными шаблонами, описаниями типовых элементов (схем процессов, схем баз данных, программ), каталогами и базами реализаций типовых элементов, примерами применения типовых элементов.

Кроме того, необходимо сделать архитектурную модель общим инструментом бизнеса и ИТ, используя её для подготовки как стратегических, так и оперативных решений. Это предполагает:

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

Модель TOGAF

Один из наиболее популярных и развитых фреймвоков описания архитектуры принадлежит международному консорциуму The Open Group и так и называется: The Open Group Architecture Framework (TOGAF), то есть «Архитектурный фреймвок, созданный The Open Group». TOGAF является промышленным стандартом описания архитектуры предприятия, который может бесплатно использоваться любой организацией, разрабатывающей собственную архитектуру. TOGAF постоянно развивается с середины 90-х годов, в настоящее время актуальна его 9-я версия (9.2. с апреля 2018 года).

The Open Group — некоммерческий консорциум, сформированный при объединении X/Open с Open Software Foundation в 1996 году, для разработки и продвижения вендоро-независимых открытых технологических стандартов в области ИТ. Сейчас в него входит более 500 крупных организаций из разных стран, как покупателей, так и производителей информационных технологий, а также правительственные агентства, в частности, Capgemini, Fujitsu, Sun Microsystems, Hitachi, Hewlett-Packard, IBM, NEC, US Department of Defense, NASA и другие. 

The Open Group наиболее известен как сертифицирующий орган для торговой марки UNIX. Он является автором Single UNIX Specification, расширяющей стандарты POSIX и являющейся официальным определением UNIX. The Open Group считает своей задачей обеспечить достижение целей бизнеса с помощью ИТ-стандартов. Девиз этого консорциума— «Безграничный поток информации».

Примечательно определение архитектуры предприятия, данное Open Group «Архитектура предприятия — это способ понимания различных элементов, которые в совокупности составляют предприятие, и то, как эти элементы взаимосвязаны». Фреймвок TOGAF в качестве основных компонентов архитектуры предприятия рассматривает уже знакомые нам четыре типа архитектуры: архитектуру бизнеса, архитектуру данных, архитектуру приложений и технологическую архитектуру. Архитектура данных и архитектура приложений объединены в архитектуру ИС. И этап разработки модели ИС состоит из 2-х частей: разработки модели архитектуры данных и модели архитектуры приложения.

Основное отличие TOGAF от других архитектурных фреймвоков заключается в том, что он фокусируется на процессе разработки архитектуры, и кроме информационной базы стандартных архитектурных моделей, его основу составляет подробно описанный пошаговый итеративный метод разработки архитектуры, который называется Architecture Development Method (ADM). Основные его компоненты и этапы приведены на Рис. 6.

Рис. 6. Фазы ADM TOGAF.

ADM — циклический, итеративный процесс, состоящий из 9 фаз. На каждой итерации должны быть выбраны следующие решения:

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

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

ADM показателен своей цикличностью, повторяемостью шагов, характеризующих постоянное совершенствование архитектуры предприятия, связью между компонентами и центральным местом, которое отводится требованиям бизнеса. Как видно из Рис. 6, центральное место в процессе TOGAF занимают требования. Управление требованиями ADM работает с любыми видами требований, в частности, с требованиями новых функциональных возможностей и изменений бизнеса. И поскольку требования постоянно изменяются, управление требованиями ведётся на протяжении всего жизненного цикла архитектуры предприятия, который совпадает с жизненным циклом самого предприятия.

В соответствии с последней версией TOGAF процесс разработки архитектуры (ADM) состоит из девяти фаз:

• Подготовительная фаза: подготовительная деятельность, направленная на выявление бизнес-требований для целевой архитектуры предприятия («как должно быть»), включая основные принципы, адаптацию методики под особенности предприятия и выбор средств описания архитектуры.
• Фаза A: Архитектурное видение — начальная фаза цикла разработки архитектуры. Здесь описываются рамки процесса разработки архитектуры, определяются заинтересованные лица, формируется видение того, какой должна быть архитектура предприятия, утверждаются архитектурные принципы, видение и план работ.
• Фаза B: Архитектура бизнеса — разработка бизнес-архитектуры предприятия, основанная на согласованных на предыдущем шаге, принципах и видении архитектуры. Описание существующей бизнес-архитектуры и формирование целевой.
• Фаза C: Архитектура информационных систем — разработка архитектуры данных и архитектуры приложений. Описание существующих архитектур данных и приложений и формирование целевых.
• Фаза D: Технологическая архитектура — описание существующей технологической архитектуры и формирование целевой.
• Фаза E: Проверка возможностей реализации решений, предложенных для построения целевой архитектуры предприятия. Это база для начального планирования реализации и выявления двигателей (стимулов) процесса построения целевой архитектуры, определённой на предыдущих фазах, выраженная в возможностях её реализации и решении основных вопросов.
• Фаза F: Планирование перехода к целевой архитектуре — формирование последовательности подробных переходных архитектур и разработка плана миграции.
• Фаза G: Управление построением целевой архитектуры и её контроль — формирование системы руководства преобразованием архитектуры предприятия (Implementation governance), которая предполагает создание «Совета по архитектуре» и стратегии соответствия архитектуре, которая, в свою очередь, определяет правила оценки проектов в части соответствия целевой архитектуре.
• Фаза H: Управление изменениями — процедуры для управления изменениями новой архитектуры.

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

Кроме процесса разработки архитектуры, модель TOGAF включает коллекцию компоновочных блоков (шаблонов), названную «континуум предприятия» (Enterprise Continuum). TOGAF подразумевает, что эта коллекция предоставляет коллективам, занимающимся архитектурой предприятия, соответствующие шаблоны архитектур, модели и процессы, из которых можно собирать готовые решения, как в LEGO. Кроме этого, модель TOGAF содержит описание типичных выходов архитектурного процесса, средств для оценки этих выходов и самого архитектурного процесса, и требования к персоналу, участвующему в моделировании и построении архитектуры.

В целом модель TOGAF является цельным и подробным методом формирования и развития архитектурного процесса на предприятиях и используется во многих организациях в разных странах мира.

Стандарты архитектуры предприятия

Стандарты архитектуры предприятия определяют понятия, концепции, основные подходы, требования, применяемые для анализа и развития предприятия, как сложной системы, включающей социальные, экономические и технологические элементы, которые объединены общим предназначением.Важнейшими стандартами, относящимися к архитектуре предприятия, являются стандарты ISO 14258:1998 (с изменениями от 2000 г.) и ISO 15704:2000.

Стандарт ISO 14258 — «Промышленные автоматизированные системы. Концепции и правила для моделей предприятия» (Industrial automation systems— Concepts and rules for enterprise models) появился в 1999 г., а в 2008 г. его перевод был принят как ГОСТ Р. В стандарте содержатся концепции и правила для моделирования производственных предприятий с целью обеспечения более эффективной интеграции элементов предприятия, в частности, производственных процессов. Стандарт отмечает необходимость системного подхода к предприятию, определяя его как «социально разнородную систему, определяемую свойствами и характеристиками людей и машин». В соответствии со стандартом ISO 14258 архитектура и методики уровня предприятия должны включать в своё содержание роли людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия.

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

• Ответить на вопрос, что надо сделать — W (What).
• Ответить на вопрос, как надо сделать — H (How).
• После этого сделать то, что надо — D (Do).

В Табл. 2 отображена связь между фазами жизненного цикла системы (продукта, проекта, программной системы, предприятия и т. д.) и этими действиями. В каждой клеточке указана информация, которая должна поддерживать каждую фазу/действие.Кроме того, стандарт ISO 14258 также выделяет статические и динамические модели. Например, такие модели, как TOGAF, несомненно относятся к динамическим, а модель Захмана — к статическим. Стандарт выдвигает требования к моделям, к их информационному обеспечению и взаимодействию.

Табл. 2. Связь между стадиями жизненного цикла системы и видами деятельности.

Стандарт ISO 15704 «Промышленные системы. Требования к стандартным архитектурам и методологиям предприятия» (Industrial automation systems. Requirements for enterprise-reference architectures and methodologies). Стандарт ISO 15704 появился в 2000 году и закрепил основные положения современного подхода к архитектуре предприятия. В 2008 г. перевод этого стандарта был принят как ГОСТ Р. С учётом его положений в 2006 году был выпущен стандарт ISO 19439 «Enterprise integration — Framework for enterprise modelling» (Интеграция предприятия — Рамочная структура для моделирования предприятия). В 2005 году в стандарт ISO 15704 включены «Дополнительные представления с точки зрения пользователя».

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

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

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

В стандарте определены два класса функций предприятия:

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

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

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

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

В приложении к стандарту приведена модель GERAM (Generalised Enterprise Reference Architecture and Methodology) — обобщённая стандартная архитектура предприятия и методологии, разработанная целевой группой IFIP/IFAC по архитектурам интеграции предприятия. Основным компонентом GERAM является GERA (Generic Enterprise Reference Architecture) — общая стандартная архитектура предприятия. 

На Рис. 7 приведены этапы жизненного цикла любого предприятия в соответствии с GERA.Кроме того, в другом приложении к стандарту описано Экономическое представление в архитектуре системы CIM (Computer-Integrated Manufacturing) – модель архитектуры информационных систем, основанная на системах математического проектирования и производства.

Рис. 7. Этапы жизненного цикла GERA для любого предприятия или производственного объекта.

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

Рис. 8. Основа экономического изображения.

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

Рис. 9. Иерархия перспективных инвестиций.

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

Стандарты эталонных архитектурных моделей для новых технологий

Отдельно стоит обратить внимание на стандартизацию таких относительно новых, но стремительно развивающихся областей, как облачные технологии и Интернет вещей. Примечательно, что для первой ещё в 2014 году появились стандарты ISO/IEC: 17788 «Информационные технологии — Облачные вычисления — Общие положения и словарь», ISO/IEC 17789 «Информационные технологии — Облачные вычисления — Эталонная архитектура», определяющие основные роли и подроли облачных вычислений, связи между ними, а также сквозные аспекты облачных вычислений, которые должны обеспечиваться всеми участниками.

Аналогичная работа по созданию модели эталонной архитектуры идёт сейчас в области Интернета вещей. В ближайшее время должны появиться стандарты ISO/IEC 30141. Information technology — Internet of Things Reference Architecture (IoT RA) и ISO/IEC 20924, Information technology — Internet of Things — Definition and Vocabulary. Таким образом, в области новых технологий основополагающие стандарты связаны с эталонной архитектурной моделью. 

Общие принципы построения архитектурной модели

Построение архитектурной модели — архитектурный процесс — подчиняется определённым принципам. Важнейшие из них:

• Принцип постепенной детализации. Следует начинать с взгляда на предприятие с большой высоты (перспектива «хозяин» в модели Захмана или архитектура бизнеса в модели TOGAF и др.), а не с подробного описания одной или нескольких нижележащих элементов. Это связано с тем, что, описывая какой-либо из нижележащих элементов общей модели предприятия, мы не получим единого системного взгляда на предприятие, которое призвана дать его архитектурная модель. По мере необходимости детализацию можно углублять, но это должно определяться тем, как будет использоваться архитектурная модель.
• Принцип согласованности слоёв. В случае, если за основу взято наиболее популярное представление архитектуры предприятия как «слоёного пирога» (четыре уровня в модели TOGAF или «перспективы» в модели Захмана), необходимо добиваться согласованности слоёв. Ведь цель построения архитектурной модели — получить единую и взаимосвязанную картину предприятия. Поэтому не стоит описывать слои по отдельности, поручая эту работу различным подразделениям. Лучше выделить процесс, или, на первых порах — проект  — по описанию архитектуры предприятия, и создать единую команду.
• Принцип независимости слоёв. Вместе с тем, слои (уровни, «перспективы») должны быть независимы. Возможно выделение любых необходимых слоёв или уровней (например, архитектура интеграции, определяющая принципы взаимодействия и интеграции приложений, данных и бизнес-процессов в распределённой среде компании в модели Frameworx (бывший NGOSS), или архитектура безопасности). Поэтому при их выделении применяют следующие условия:
  • в случае если нижний слой вышел из строя, верхний работать не может;
  • неработоспособность верхнего слоя не влияет на работоспособность нижнего;
  • работоспособность элементов внутри одного слоя может влиять на работоспособность других элементов этого же слоя, а может и не влиять.
• Принцип полноты. Модель архитектуры предприятия должна описывать предприятие с требуемой полнотой. В то же время, не следует увлекаться большим количеством архитектур и уровней, так как это усложняет модель. Количество архитектур и уровней должно определяться конкретными задачами, для решения которых строится архитектурная модель.
• Принцип непротиворечивости. Элементы архитектурной модели не должны противоречить друг другу.
• Принцип отсутствия дублирования. Элементы архитектурной модели не должны дублировать друг друга.
• Принцип постоянной трансформации текущей архитектуры предприятия. Не следует забывать, что любое предприятие находится в постоянном развитии. А значит, его архитектурная модель полезна только тогда, когда она актуальна и постоянно приводится в соответствие с реальным состоянием предприятия.

С чего начать?

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

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

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

Рис. 10. Пример архитектурной модели Холдинга (источник: ОАО «СИБУР – Русские шины», 9/4/2017). 

Такая простейшая модель уже позволяет обсуждать с руководством компании стратегию развития ИТ и наметить, чего хочется достичь за период планирования. Прежде всего, расставить приоритеты заполнения «белых пятен» неавтоматизированных бизнес-процессов. Или, например, добиться того, чтобы одна ERP-система покрывала большую часть потребностей в автоматизации. Или чтобы все компании использовали для бухгалтерского учёта одну и ту же систему, причём одной и той же версии.

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

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

Ответы на эти вопросы существенно повлияют на выбор целевой архитектурной модели.

Инструменты построения архитектурной модели

Традиционно для моделирования архитектуры предприятия использовали методы описания бизнес-процессов. Например, семейство языков моделирования IDEF (Integrated Computer Automated Manufacturing Definition), которое возникло в середине 70-х годов в ВВС США, как решение проблемы повышения производительности и эффективности информационных технологий. Часть стандартов этого семейства может быть использована при построении моделей архитектуры бизнеса, архитектуры данных и прикладной архитектуры.

Язык, использованный в инструментах линейки ARIS (Architecture of Integrated Information Systems) также позволяет описывать бизнес-процессы. Кроме того, в эту линейку входит отдельное решение, которое называется Enterprise Architecture Management (Управление архитектурой предприятия) и предназначено для создания архитектурных моделей предприятия и поддержки их в актуальном состоянии.

BPML (Business Process Modeling Language) — язык моделирования бизнес-процессов был разработан для описания архитектуры Бизнеса. BPML представляет бизнес-процессы как комплекс взаимодействий управляющих потоков, потоков данных и потоков событий и средств моделирования бизнес-правил, ролей их взаимодействий. Существует много программных систем, которые предоставляют возможность описания архитектуры бизнеса на этом языке, в частности, Popkin System Architect.

Язык UML подходит для описания всех слоёв архитектуры предприятия. Эту нотацию поддерживают многие инструментальные средства от ARIS до Microsoft Visio и Rational Rose. 

В 2008 г. консорциум Open Group приобрёл права на развитие языка описания архитектуры предприятия Archimate, который разрабатывался в Нидерландах по заказу голландского правительства, ряда государственных и крупных частных компаний, а также образовательных организаций. Первая версия международного стандарта появилась в 2009 г., стандарт постоянно развивается, с июня 2016 г. актуальна его третья версия. Archimate полностью совместим с TOGAF. Так же, как и в TOGAF, в нем выделяются 4 уровня описания архитектуры предприятия: архитектура бизнеса, архитектура данных, архитектура программных приложения и технологическая архитектура. Archimate представляет собой зрелый стандарт моделирования архитектуры предприятия, поскольку основан на большой аналитической и научной работе представительной группы экспертов и учёных и опирается на вышеописанные средства моделирования, существовавшие до его появления. Archimate прост для понимания и освоения. Множество программных продуктов позволяют моделировать архитектуру предприятия на этом языке, включая бесплатно-распространяемое ПО. Мало того, даже те инструменты моделирования, которые появились до Archimate, дают возможность импортировать и экспортировать модели в этот стандарт.

Основу Archimate составляют три типа элементов:

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

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

Варианты архитектур по определённым признакам группируются в стили, так же, как в архитектуре зданий. Остановимся на двух современных архитектурных стилях: сервисная архитектура и архитектура, управляемая моделями. Заметим, что к прикладным архитектурным стилям также часто также относят два противоположных подхода: все на базе «единой системы» или набор «лучших в своём классе» приложений.

Сервисно-ориентированная архитектура (Service Oriented Architecture, SOA)

SOA — это стандарт архитектуры предприятия, прежде всего, архитектуры приложений. Он направлен на решение проблем интеграции разнообразных программных систем в единую программную среду предприятия. Стандарт основан на понятии сервиса, т.е. удовлетворения потребностей одного объекта другим. Согласно Gartner Group, под сервисно-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами:

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

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

Рис. 11. SOA. 

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

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

SOA подробно описан в TOGAF и является одной из рекомендованных стандартных архитектурных моделей этого фреймвока.

Один из вариантов SOA — стандарт web-сервисов, предложенный в 2004 г. компаниями Microsoft и IBM. Web-сервисы опираются на три стандарта:

• SOAP — Simple Object Access Protocol, простой протокол доступа к объектам; протокол обмена сообщениями, основанный на XML, используемый для взаимодействия между участниками предоставления / получения сервиса.
• WSDL — Web Services Description Language, язык описания веб-сервиса и доступа к ним, также основанный на XML.
• UDDI — Universal Discovery, Description and Integration, универсальный интерфейс распознавания, описания и интеграции; каталог веб-сервисов и сведений о компонентах, предоставляющих веб-сервисы, описанные на WSDL.

Рис. 12 поясняет роль этих понятий в архитектуре web-сервисов.

Рис. 12. Архитектура Web-сервисов.

SOA лежит также в основе эталонной архитектурной модели облачных вычислений.

Архитектура, управляемая моделями (Model Driven Architecture, MDA)

Архитектура, управляемая моделями, так же, как и сервисно-ориентированная архитектура, является стандартом архитектуры приложений. Она не противоречит SOA, эти архитектуры могут использоваться одновременно на одном предприятии для построения его единой информационной среды. Архитектуру, управляемую моделями с 2001 г., развивает международный консорциум OMG (Object Management Group). Прежде всего, архитектура MDA предназначена для проектирования программных систем и состоит из спецификаций, написанных в основном на UML, и руководств по их использованию.

Идея MDA состоит в том, что система может строиться как последовательность взаимосвязанных моделей, которые должны последовательно детализировать систему, начиная с независимой от технологий модели CIM, через платформенно-независимую модель PIM, затем – платформенно-зависимую модель PSM и к конкретной программной реализацией. Структура MDA показана на Рис. 13.

Рис. 13. Model Driven Architecture.

Каждый тип моделей соответствует определённому уровню развития программной системы:

• исходной является так называемая «независимая модель вычислений» (Computational Independent Model, CIM), где аналитиком описывается бизнес-логика системы;
• далее она трансформируется в платформенно-независимую модель (Platform- Independent Model, PIM), в которой систему описывают уже ИТ-архитекторы;
• далее она трансформируется в платформенно-специфичную модель (Platform — Specific Model, PSM), создаваемую разработчиком системы и уже использующей преимущества выбранной платформы и обходящей её недостатки к программному коду;
• платформенно-специфичная модель автоматически или с минимальным участием программиста приводится к исполняемому коду и соответствующим структурам данных.

Таким образом, мы получаем три подуровня прикладной архитектуры. Уровень CIM лежит ближе к архитектуре бизнеса, код — к инфраструктуре. Стандарт MDA содержит правила перехода от уровня CIM к PIM и от уровня PIM к PSM для некоторых платформ, в число которых входят CORBA, J2EE, .NET.

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

В 2016 г. была создана Национальная Ассоциация Архитекторов Предприятий, которая в настоящее время занимается вопросами сертификации отечественных архитекторов. Хотим также отметить, что в 2014 г. был утверждён приказом Минтруда профессиональный стандарт «Архитектор программного обеспечения,» который охватывает один из архитектурных слоёв (или одну из перспектив), описанных выше.

Авторы: Марина Аншина, Константин Зимин, Владимир Ананьин, Сергей Кирюшин

Источник: Учебник 4CIO. Настольная книга ИТ-директора

© Клуб Топ-менеджеров России 4CIO