Применение архитектурных подходов в сфере информационных технологий

О.А. Йылмаз

АРХИТЕКТУРА ПРЕДПРИЯТИЯ

Оглавление

ВВЕДЕНИЕ

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

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

При построении архитектуры предприятия, в частности, системной архитектуры, возникает немало традиционных вопросов. Все они имеют ответ, но любой ответ становится знанием предприятия только в том случае, если он задокументирован. Практически все известные методологии и стандарты (от отечественных ГОСТов и SADT до RUP) и инструменты (начиная с IDEF Designer, System Architect и BPwin/Erwin и заканчивая продуктами семейства Rational) предоставляют возможности для документирования только части из перечисленных знаний, поскольку ориентируются в значительной степени на разработку программных систем. Многие же из перечисленных выше вопросов лежат в слое бизнес-архитектуры.

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

Задачи курса «Архитектура предприятия»:

• изучить основные модели и методы управления организацией на основе архитектурных подходов;
• дать методологические основы выбора и применения методов повышения эффективности деятельности путем применения инструмента архитектуры предприятия.
• освоить основные принципы построения архитектуры предприятия и ее отдельных доменов;
• уметь пользоваться основными методическими приемами различных архитектурных подходов (модель FEAF, TOGAF, FEA, методики IBM и Microsoft и т.д.);
• получить навыки разработки архитектуры предприятия на основе построения ее «снизу-вверх» от бизнес-архитектуры до технологической архитектуры.

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

Дисциплина «Архитектура предприятия» является частью профессионального цикла дисциплин подготовки студентов по направлению подготовки 080500 «Бизнес-информатика». 

1. АРХИТЕКТУРА ПРЕДПРИЯТИЯ. АКТУАЛЬНОСТЬ ПРОБЛЕМАТИКИ И ОСНОВНЫЕ ПОНЯТИЯ.

1. Применение архитектурных подходов в сфере информационных технологий

В зарубежных странах уже давно разрабатывается целый пласт проблем связанных с архитектурным подходом к сложным организационно-техническим объектам, таким как предприятие, «электронное правительство» и информационные системы. В России, однако, очень часто архитектурный подход сводится к применению в той или иной степени «сервис-ориентированной архитектуры» (Service-oriented Architecture, SOA), которая представляет собой новый подход к разработке ИТ-решений. SOA - это архитектура для построения бизнес-приложений в виде набора слабо связанных компонентов или «сервисов», которые соединяются вместе в бизнес-процессах. Другими словами, при таком подходе традиционные бизнес-приложения и функции разбиваются на отдельные задачи, обращающиеся к сервисам. Сетевые ресурсы в среде SOA доступны как независимые сервисы, для получения доступа к которым не требуется знаний о платформенной реализации нижнего уровня. Применение данного подхода вызвано прежде всего необходимостью интеграции и взаимодействия приложений в рамках совокупности большого количества информационных систем предприятия или нескольких предприятий, объединенных в целую партнерскую цепочку.

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

Хотя концепция SOA была сформулирована специалистами в области ИТ, но в действительности это был прямой ответ на потребности сегодняшнего дня, когда становится уже не совсем понятно, где заканчиваются бизнес-функции организации и начинаются информационные технологии, их обеспечивающие, и наоборот. Ведущие поставщики информационных технологий, такие как Microsoft и IВМ, развивают эту концепцию в рекомендациях по проектированию информационных систем на своих программных платформах. А такие компании, как Gartner, считают, что сервис-ориентированная архитектура будет ведущим принципом проектирования новых критически важных прикладных систем и бизнес-процессов в ближайшем будущем.

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

Резюмируя все вышесказанное можно сказать, что под сервис-ориентированной архитектурой следует понимать подход к проектированию прикладных информационных систем, который руководствуется следующими принципами [(Introduction to Service-Oriented Architecture, 2003)]:

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

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

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

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

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

Ориентация на сервисную архитектуру позволяет построить комплексную ссылочную модель архитектуры предприятия, которая в единой манере описывает как бизнес, так и ИТ. Эта модель состоит из следующих основных компонент (рис 1.1):

• презентационный уровень описывает интерфейсные сервисы для взаимодействия пользователей с ИС, включая корпоративные и публичные порталы, доступ с мобильных устройств, а также различные преобразования информации при взаимодействии с внешними системами и устройствами;
• на уровне бизнес-сервисов формируются модели и осуществляется управление выполнением бизнес-процессов предприятия с использованием специализированных средств, а также координация автоматизированных и "ручных" операций;
• интеграционные сервисы обеспечивают взаимодействие между приложениями, которое может быть реализовано, в частности, с использованием средств обмена сообщениями или в рамках единой среды исполнения, такой как сервер приложений J2EE;
• сервисы уровня данных реализуют средства извлечения и повторного использования данных из СУБД и приложений. Явное выделение такого уровня позволяет изолировать вышестоящие компоненты архитектуры от изменений в технологиях, а также обеспечить единый унифицированный подход к выполнению операций с данными;
• уровень инфраструктуры, приложений и СУБД является основой для всей структуры, и именно здесь концентрируются основные инвестиции в ИТ.

Рис. 1.1. Сервис-ориентированная архитектура (SOA)

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

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

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

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

Таким образом, можно сделать вывод о том, что хотя эти два понятия тесно переплетаются между собой, не следует путать или сужать их. Использование сервис-ориентированной архитектуры может не сопровождаться разработкой архитектуры предприятия, более того существует лишь несколько удачных примеров одновременного их внедрения (например, компания IBM (более подробно смотри М. Ибрагим, 2008)).

Объектом изучения в рамках настоящей дисциплины является отдельная организация, и особый интерес будет представлять трактовка самого понятия «архитектуры предприятия». С одной стороны, представление о нем имеет свои корни в дисциплине, которая получила название «системное мышление». Основным объектом изучения этой дисциплины является система, когда «целое составляет нечто большее, чем механическая сумма составляющих, т.е. cucmeма обладает свойствами, которые omcymcmвyem у составляющих ее злементов» [(Rechtin, 1991)]. Эберхард Речтин (Eberhardt Rechtin), автор этого высказывания, является одним из основателей этого направления мышления.

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

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

Архитектура предприятия (Enterprise Architecture, EA) является одним из инструментов организационных изменений как для всего предприятия в целом (в том числе с использованием ИТ), и так и той части организации, которая отвечает за информационные технологии. Гуру в области бизнеса отмечают, что, к организационным изменениям можно подойти с двух сторон. Во-первых, можно произвести реорганизацию, реинжиниринг процессов, то есть , перестроить то, как организация «работает», а во-вторых, можно и нужно управлять знаниями.

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

Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В процессе проведения аудита информационных технологий, построение EA может дополнить достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL, COBIT и другие.

2. Архитектура предприятия: основные определения

Многие организации испытывают постоянные трудности и находятся в постоянном поиске синхронизации целей и задач бизнеса и процессов развития своих информационных систем. По мнению аналитической компании Butler Group, которая специализируется на исследованиях в сфере ИТ (см. www.butlergroup.com): можно даже говорить о так называемом «облаке неопределенности» между определенными организацией целями и обеспечивающей их ИТ-инфраструктурой (рис. 1.2).

Рис. 1.2. Облако неопределенности ИТ-инфраструктуры и целей организации

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

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

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

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

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

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

Широко распространенный термин, связанный с применением архитектурных методик именно в сфере информационных технологий, «ИТ-архитектура» имеет такое большое количество трактовок и может означать множество близких по смыслу, но, тем не менее, различающихся понятий. Для различных людей смысл этого термина может быть разным. С одной стороны, можно достаточно быстро сформулировать интуитивное определение, которое после анализа окажется вполне применимым. С другой стороны, при формальном подходе известных определений архитектуры существует несколько сотен. Для этого достаточно зайти на сайт Института Проектирования Программного Обеспечения Карнеги-Меллона (SEI - Carnegie Mellon Software Епgineering Institute) http://www.sei.cmu.edu/architecture/ и просмотреть представленные там трактовки. Из самых простых (словарь Уэбстера) заключается в том, что ИТ-архитектура - это «способ, который используется для организации и uнmeгpaцuu компонент компьютерной системы».

Более полное и объемное определение [(Monin)] заключается в том, что «Архитектура системы состоит из нескольких компонент, внешних свойств и интерфейсов, связей и накладываемых ограничений, а также архитектуры этих внутренних компонент». Такая широкая трактовка удобна тем, что является достаточно общей, применимой практически к любой системе, а не обязательно только к системе, использующей информационные технологии, и при этом позволяет ограничить степень детализации на нужном уровне. Упоминание внутренних компонент специально перенесено в конец определения - для отражения того факта, что «хорошая», четко построенная архитектура позволяет обеспечить повторное использование или модернизацию/замену таких внутренних компонент без изменения внешней охватывающей системы. Итеративное, иерархическое построение архитектуры позволяет решить и еще одну важную задачу - облегчить ее восприятие человеком.

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

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

Прежде чем привести полное определение Архитектуры ИТ, обратим внимание на еще одну немаловажную деталь. В соответствии с тезисом, сформулированным Giga Group [(The Pillars of Enterprise Architecture Terminology, 2002)] «в индустрии ИТ нет одного, единственно правильного стандарта на определение Архитектуры ИТ, поэтому общие соглашения внутри организации важнее теоретической точности». Итак, важна не столько академическая точность определения того, что такое Архитектура ИТ, сколько то, насколько на практике в реальности будут воплощены архитектурные принципы. Организация может и сама сформулировать и принять для себя определение данного понятия, лишь бы оно было полным, целостным и понятным всем участникам проекта по разработке архитектуры.

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

В самом общем виде, в соответствии с определениями Gartner [(Defining Architecture for IT: А Framework of Frameworks, 2002)], архитектура это общий план или концепция, используемая для создания системы, такой как здание или информационная система, или «абстрактное описание cucmeмы, ее структуры, компонентов и их взаимосвязей»; «семейство руководящих принципов, концепций, правил, шаблонов, интерфейсов и стандартов, используемых при построении совокупности информационных технологий предприятия».

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

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

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

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

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

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

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