Многие компании уже осознали необходимость планирования развития не только бизнеса, но и ресурсов, необходимых для его поддержки. Налаживание оптимальной взаимосвязи бизнеса и ИТ невозможно без планирования ИТ-стратегии, согласованной с задачами и целями организации. Один из инструментов обеспечения подобной согласованности – сервисная архитектура, применяемая при проектировании и реализации приложений. Однако успех вопрлощения этого подхода в корпоративных информационных системах зависит от планирования и проектирования архитектуры приложений или, если подняться на одну ступень выше, от планирования и проектирования архитектуры предприятия в целом.
Архитектура предприятия
Архитектура предприятия (Enterprise Architecture, EA) – это концепция, описывающая текущее и целевое состояние архитектуры приложений, бизнес-процессов, ИТ-инфраструктуры, согласованных с бизнес-стратегией компании. Она также описывает механизмы организации, управления и ведения архитектуры, планы по переходу к целевому состоянию. Архитектура предприятия является попыткой построить систему управления предприятием «сверху вниз». Есть множество различных моделей, позволяющих выбрать наиболее оптимальный вариант осуществления подобной трансформации, часть из них предлагает разнообразные версии структуры архитектуры предприятия (метамодели), раскрытые в моделях Захмана (Zachman Framework) или в модели US Federal EA, другие описывают подход к построению архитектуры предприятия (TOGAF). Компания SAP разработала методологию ведения архитектуры предприятия SAP EAF на базе TOGAF, которая ориентирована на интерпретацию и поддержку реализации целей компании посредством планирования и ведения специализированных описаний и представлений в следующих областях: бизнес-архитектура (в том числе бизнес-процессы, организационная структура); архитектура приложений; архитектура данных; техническая архитектура. Основное назначение SAP EAF – ускорение разработки архитектуры предприятия и снижение ее трудоемкости.
В рамках методологии создается ряд взаимосвязанных диаграмм, описывающих текущее и целевое состояние компании, а также план проведения изменений. SAP EAF предполагает также постановку процесса по непрерывному управлению архитектурой предприятия и полную реализацию цикла управления архитектурой предприятия.
Можно выделить три уровня архитектуры: архитектура предприятия, архитектура корпоративных (сквозных) приложений и архитектура приложений (рис. 1).
Архитектура предприятия рассматривает ландшафт предприятия в целом, определяет структуру, контекст и стандарты организации, поддерживает корпоративную стратегию, планирует развитие бизнес-процессов и ИТ-систем. Горизонт планирования архитектуры предприятия составляет обычно три–пять лет. В рамках архитектуры предприятия разрабатывается видение и определяются возможности и «разрывы» в ландшафте, а также разрабатывается план перехода и план миграции, включающий новые решения и проекты.
Архитектура корпоративных приложений ориентирована на поддержку решения одной из стратегических задач в перспективе до двух лет, включает в себя соответствующие проекты по реализации ИТ-систем. Один из подходов, который можно использовать для поддержки стратегических преобразований, базируется на идеях сервисной архитектуры (Service-Oriented Architecture, SOA), его успех во многом зависит от того, насколько точно архитектор понимает связь ИТ-ландшафта с бизнес-процессами и целями внедрения отдельных компонентов ландшафта. Иначе возникает риск создания и внедрения эффективного механизма интеграции приложений на базе сервисов без получения каких-либо бизнес-выгод.
Планирование архитектуры приложения ориентировано на перспективу до года и поддерживает тактические проекты. Архитектура приложения описывает решение и реализацию конкретной ИТ-системы, отражает выполнение соответствующего шага плана трансформации и реализацию одного из проектов.
Подход по планированию и проектированию архитектуры на базе методологии SAP EAF поддерживает разработку архитектуры на каждом из перечисленных уровней.
SOA
Если переходить к архитектуре конкретных приложений, то можно увидеть разнообразие различных типов архитектур, используемых при построении информационных систем. Среди них все большую популярность приобретает сервисная архитектура приложений. Концепция сервисной архитектуры существует уже давно, но далеко не всегда ее применение ведет к успеху – многое зависит от выбранного подхода к ведению и управлению архитектурой предприятия в целом.
Прикладная логика реализуется в SOA-приложениях так же, как и в обычных, а для доступа к функциям приложений используется специальная «обертка» в виде Web-сервиса, позволяющая вызывать данную функциональность из других приложений и подсистем. При этом SOA рассматривается не только как архитектура для развертывания и выполнения распределенных прикладных решений, но и как модель программирования, в которой архитектура приложения строится на основе сервисов, предоставляемых другим приложениям в сетевой среде с помощью описания и публикации соответствующих интерфейсов. Однако концепция SOA не дает точного описания, как именно должны взаимодействовать сервисы, как добиться того, чтобы они понимали друг друга и могли быть интегрированы.
Сервисы в SOA могут представлять собой простые или сложные объекты, процессы взаимодействия некоторого множества объектов, процессы, состоящие в свою очередь из нескольких процессов, или даже некий комплекс приложений, которые в совокупности приводят к получению единого результата. Важно, что с точки зрения архитектуры сервис (независимо от внутренней структуры и языка реализации) выглядит как единое целое.
К сервисам можно отнести элементы, которые: являются востребованной функцией приложения либо системы; являются выполняемой функцией; удовлетворяют политике и требованиям к качеству сервиса – обеспечивают масштабируемость, надежность, соблюдение соглашения об уровне обслуживании.
Для того чтобы начать переход к сервисной архитектуре, необходимо определить процессы и приложения, которые больше всего подходят для использования данной концепции. Для этого в SAP рекомендуют анализировать архитектуру предприятия в целом, причем от уровня детализации описания бизнес-процессов, ИТ-систем и данных, выполняемых в рамках проводимого анализа, зависит проработка потенциальных сервисов, описание их операций и политик. Это позволит корректно отразить и реализовать целевые бизнес-процессы и потребности пользователей в ИТ-системах.
При идентификации сервисов необходимо обращать внимание на следующие черты бизнес-процесса, которые помогут отличить сервисы от обычных операций процесса и определить потенциальных кандидатов на роль сервисов:
- возможность повторного использования функциональности;
- степень стандартизации прикладной функциональности;
- степень автоматизации операций сервиса, в котором не должно быть задач, выполняемых вручную;
- приемлемая стоимость реализации;
- возможность синхронного взаимодействия приложений; для реализации асинхронного взаимодействия, как правило, используется корпоративная сервисная шина (Enterprise Service Bus, ESB).
В рамках архитектуры предприятия выделяют два подхода: бизнес-представление SOA и ее техническое представление. Техническое представление – это SOA в классическом понимании, а бизнес-представление введено в рамках концепций SAP EAF и TOGAF, и направлено оно на то, чтобы выявить новые возможности бизнеса, применяя концепцию SOA, и использовать их для успешного развития предприятия, а также при реализации новых продуктов и услуг. Бизнес-сервис – это компонент, который:
- выполняется вручную или является автоматизированным;
- выполняется в рамках предприятия или передан на аутсорсинг;
- доступен для сотрудников предприятия, партнеров, клиентов и поставщиков;
- выполняется в рамках соответствующей организационной единицы или на уровне корпоративного центра компетенций;
- имеет соглашение об уровне обслуживания (Service Level Agreement, SLA).
Примерами бизнес-сервисов могут служить электронная почта, call-центр, ИТ-поддержка в режиме онлайн, энергоснабжение, централизованные закупки и др. Выделение бизнес-сервисов позволяет определить бизнес-модель предприятия, которая накладывает ограничения на сервисные операции, интерфейсы и определяет соглашение об уровне обслуживания. Кроме того, такая формализация бизнес-процессов существенно облегчает работу разработчика SOA-решений.
ИТ-стратегия, архитектура предприятия и SOA
Зрелые компании достаточно четко описывают текущее состояние архитектуры предприятия (т.е. в классическом варианте состояние бизнес-архитектуры, архитектуры приложений, архитектуры данных, технической архитектуры) и необходимые организационные процедуры и процессы управления. Однако концепция архитектуры предприятия охватывает лишь часть ИТ-стратегии (рис. 2), а SOA является одной из концепций уровня архитектуры корпоративных приложений и помогает создавать корпоративные приложения на основе принципов, заложенных в архитектуру предприятия.
Архитектура предприятия покрывает часть важных для ИТ-стратегии компонентов, оставляя за рамками элементы стандартных для ИТ-департамента процедур планирования, принципов и методов управления, организации деятельности и поддержки. С другой стороны, в современных организациях, где нет четко выделенного процесса ведения архитектуры предприятия, отсутствуют архитекторы (бизнес, технические и корпоративные), – в лучшем случае функции технических архитекторов распределены между несколькими специалистами.
Характерной иллюстрацией различия проектов по построению ИТ-стратегии и архитектуры предприятия является то, насколько большое внимание уделяется проработке принципов управления ИТ-ресурсами при формировании ИТ-стратегии, в то время как при проектировании архитектуры предприятия ведется разработка соответствующих документов только для группы архитекторов. Таким образом, концепция архитектуры предприятия ориентирована на поддержку организации в части эффективного планирования и управления ИТ-процессами. Эта концепция должна помочь в построении эффективной системы управления предприятием и упростить задачу ИТ-директора по управлению и развитию информационных технологий в рамках компании.
ИТ-стратегия является важным компонентом управления, планирования и развития информационных технологий в рамках предприятия. Для того чтобы помочь организациям в ведении и управлении ИТ, появилась концепция архитектуры предприятия, которая включает в себя компоненты управления ИТ-ландшафтом, ИТ-инфраструктурой, процедуры ведения и изменения архитектуры предприятия, планирование навыков ИТ-персонала, мониторинг эффективности.
Все перечисленные компоненты расшифровывают и расширяют понятие ИТ-стратегии и помогают ИТ-директору правильно построить план развития и перехода к целевому ландшафту в зависимости от поставленных бизнесом целей. При этом хорошо структурированные и детальные описания всех доменов архитектуры предприятия позволяют построить и реализовать приложения, в наибольшей степени отражающие требования бизнеса, а также выбрать соответствующую архитектуру корпоративных приложений или принять решение о переходе на сервисную архитектуру. В этом случае результаты проектирования архитектуры предприятия используются как входящая информация и ограничения для описания и выделения сервисов приложений. Причем важно понимать, что SOA используется для разработки архитектуры корпоративных приложений и зависит от стратегического видения архитектурных принципов и ИТ-целей, принятых в рамках архитектуры предприятия.
***
Понятия SOA и архитектура предприятия относятся к разным уровням архитектуры: архитектура предприятия определяет целевую ИТ-архитектуру в рамках компании, основные направления развития и план трансформации, в то время как SOA используется при разработке и проектировании корпоративных приложений. Успешность реализации и результат разработки сервис-ориентированных приложений зависят от того, насколько полно
и детально ведется архитектура предприятия, понимается ли она бизнес-пользователями и отражает ли актуальные бизнес-цели и потребности. n
Ирина Пырлина (irina.pyrlina@sap.com) – старший консультант департамента управления корпоративной архитектурой и основными данными компании «САП СНГ», Сергей Пузыня (sergej.pusynja@sap.com) – руководитель департамента управления корпоративной архитектурой и основными данными «САП СНГ».
Рис. 1. Уровни архитектуры
Рис. 2. ИТ-стратегия, архитектура предприятия и SOA
SOA: подходы к реализации. Управление ИТ
Появление концепции SOA стало закономерным шагом на пути поиска решения одной из самых насущных и сложных проблем ИТ-индустрии – проблемы интеграции приложений.
http://www.osp.ru/os/2004/06/184450
Методология SAP EAF
Методология состоит из SAP EAF Architecture Process, SAP EAF MetaModel, руководства, ресурсной базы и инструментов.
SAP EAF Architecture Process – модель, описывающая процесс разработки архитектуры и предлагающая разбить его на фазы (см. рисунок): видение архитектуры (А) – определение границ проекта, разработка общего представления архитектуры, согласование плана работ и подхода; бизнес-архитектура (B) – множество бизнес- и технических требований, целей и стратегических направлений развития, данные gap-анализа, описание текущих и целевых бизнес-процессов, функций, сервисов, план перехода на новую бизнес-архитектуру; архитектура информационной системы (С) – формализованное описание существующей архитектуры приложений и данных на основе разработанной бизнес-архитектуры и проведенного gap-анализа, документация по целевой архитектуре и составные элементы архитектуры приложений и архитектуры данных. Далее в SAP EAF Architecture Process входит описание текущей и целевой технической архитектуры (D): системное программное обеспечение, серверы, базы данных, аппаратное обеспечение, сеть, а также высокоуровневый план перехода к целевой архитектуре (Е).
Планирование миграции (F) предполагает разработку детального плана перехода к целевой архитектуре, включающего все необходимые для этого изменения (организационные, бизнес-процессы, ИТ-ландшафт). Основная цель управления реализацией (G) состоит в мониторинге процессов проектирования, реализации корпоративных информационных систем и своевременном внесении изменений во все домены архитектуры предприятия. Управление изменениями архитектуры (H) включает в себя весь комплекс мероприятий по управлению изменениями (разработка новой функциональности, изменения в бизнес-процессах, изменения принципов управления). Управление требованиями является ядром процесса создания архитектуры предприятия на базе SAP EAF и предусматривает постоянный мониторинг, сбор и формализация потребностей бизнеса.
SAP EAF MetaModel – модель, определяющая соглашения о проектировании архитектуры предприятия. На базе отдельных каталогов в модели описываются компоненты архитектуры, взаимоотношения между компонентами отображаются с помощью специальных матриц. В финальном графическом представлении описываются все домены текущей и целевой архитектур.
Руководства по построению архитектуры предприятия, шаблоны и примеры. Ресурсная база – база архитектурных стандартов, используемых при проектировании архитектуры предприятия. Инструменты, поддерживающие разработку и моделирование архитектуры предприятия. Модель архитектуры предприятия на базе SAP EAF может быть описана с помощью целого ряда инструментов, существующих сегодня на рынке моделирования бизнес-процессов (например, ARIS).
Таким образом, методология SAP EAF определяет последовательность действий (SAP EAF Architecture Process) и набор результирующих документов (матрицы, представления – SAP EAF Metamodel), разрабатываемых на каждом шаге при проектировании архитектуры предприятия.
