Архитектура корпоративного приложения

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

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

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

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

Архитектура уровня проекта

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

Архитектура приложения

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

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

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

Рис. 1. Связь бизнеса и систем

<!--[if !vml]--><!--[endif]-->

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

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

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

Integrated Architecture Framework от Cap Gemini Ernst & Young

За последние 10 лет в Cap Gemini Ernst & Young был разработан подход к анализу и разработке архитектур предприятия и уровня проекта, известный как Integrated Architecture Framework (IAF). Этот подход (сейчас используется его третья редакция) был разработан на глобальном уровне на основе опыта Cap Gemini Ernst & Young, накопленного в реальных проектах, и прошел официальное рецензирование, в том числе в академических учреждениях. IAF успешно применялся при выполнении сотен аудиторских заданий по всему миру.

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

Рис.2 Integrated Architecture Framework

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

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

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

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

• В каких областях бизнеса требуется ИТ-поддержка?
• Какой должна быть общая бизнес-архитектура (например, модель front-office, mid-office или back-office)?
• Как системы отражают архитектуру организации/бизнеса, какова степень консолидации систем в отделах в набор базовых приложений, допустима ли определенная их гибкость и нужна ли служба централизованной интеграции?
  

На логическом уровне решение описывается как сервисы или компоненты, независимые от конкретной продукции (или товаров), с четким определением контрактов их интеграции или совместной работы. Будучи независимым от продукции, данный уровень архитектуры относительно стабилен. Он может измениться в силу изменений на верхнем уровне, в том числе из-за внедрения новой фундаментальной бизнес-модели (например, перехода на модель, ориентированную на потребителя), а также изменений на более низком уровне, включая переход на новую технологию (скажем, CRM), или фундаментальных перемен в технологической парадигме (например, Services Architecture или Grid). Таким образом, можно точно и последовательно оценить влияние изменений на бизнес-уровне или уровне технологий.

К основным решениям, принимаемым на этом уровне относятся следующие.

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

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

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

Именно на этом уровне можно использовать инфраструктуры и архитектуры решений типа Microsoft Systems Architecture (MSA) для ускорения разработки физической архитектуры, повышения качества архитектуры в целом (за счет проверенных решений) и уменьшения рисков, связанных с проектом.

На этом уровне принимаются следующие основные решения.

• Какие физические компоненты станут частью пакета решения (например, физические компоненты из ERP-решения)?
• Какие дополнительные компоненты понадобятся помимо этого пакета и каковы стандарты и руководства для их разработки (язык, инструменты и т. д.)?
• Каковы стандарты и детальные критерии выбора для развертываемых инфраструктурных продуктов? Ответ на этот вопрос позволит создать список кандидатов.
  

Связь и управление архитектурой

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

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

Связь архитектуры и проекта

По мере того как термин «архитектура» все чаще применяется в бизнесе и ИТ, возникает путаница. Например, во многих организациях считают, что архитектура и проект — это одно и то же. С точки зрения Cap Gemini Ernst & Young, это не так, поскольку проект и архитектура предлагают разные, взаимодополняющие подходы к решению, — фактически в проектах Cap Gemini Ernst & Young используется IAF и Rational Unified Process (RUP), что обеспечивает полноценный цикл разработки от архитектуры до кода. В табл. 1 дано сравнение архитектуры (IAF) и дизайна (RUP, в том числе архитектуры приложения).

Табл. 1. Сравнение архитектуры и проекта

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

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

Рис. 3. IAF и RUP

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

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

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

Резюме

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

Основная цель работы над архитектурой предприятия — понять:

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

А это приводит к решению, которое:

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

А также обосновывает:

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

Дополнительные материалы

Cap Gemini Ernst & Young Technology Services: http://www.cgey.com/technology
Services Architecture: http://www.cgey.com/ technology/sa/index.shtml
Adaptive IT: http://www.cgey.com/adaptive/ solutions/adaptive-it-overview.shtml