Модели архитектуры предприятия, разработанные в корпоративной среде

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

Взгляды компании Microsoft на архитектуру информационных систем до-статочно подробно изложены в [(Platt)]. Эти подходы в большей степени сфокуси-рованы на процессах разработки конкретных программных прикладных систем и создании технологической инфраструктуры, включая центры обработки дан-ных различного масштаба и уровня надежности. Как практически и во всех дру-гих методиках, здесь выделяются четыре представления (домена) в архитекту-ре: бизнес-архитектура, архитектура информации, прикладные системы и техно-логическая архитектура. Эти представления рассматриваются на различных уровнях абстракции: концептуальном, логическом и физическом. Помимо этого, явно выделяются процессы разработки прикладных систем, организация про-цессов эксплуатации технологической инфраструктуры и создание соответст-вующих шаблонов, которые могут использоваться как при разработке архитекту-ры систем, так и при ее создании.

При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы раз-работки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (МSM), которые будут рас-смотрены ниже.

Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов:

· MSF - «Как правильно создавать ИТ-системы?»

· MSA - «Как правильно создавать технологическую инфраструктуру?»

· MOF - «Как правильно эксплуатировать технологическую инфраструктуру?»

· MSM - «Как правильно строить процессы управления технологической ин-фраструктурой?»

Методики Microsoft сосредоточены, в основном, на системном уровне - уровне архитектуры прикладных систем и обеспечивающей инфраст-руктуры (это не методики описания архитектуры предприятия как таковые). Поэтому в этой более «узкой» области полезными являются приведенные соотношения между различными перспективами описания системы и моделями, используемыми для описания на соответствующем уровне абстракции так, как показано на рис. 2.11 [(А. Данилин, 2005)].

Рис. 2.11. Соотношение между уровня абстракции и различными моделями

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

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

· общее понимание и язык описания архитектуры;

· общие руководства, рекомендации по использованию специфических кон-цепций;

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

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

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

· на уровне концептуальной архитектуры в форме концепций построения бизнес-моделей и соответствующих шаблонов;

· на уровне логической архитектуры в форме концепций построения моде-лей приложений и соответствующих шаблонов;

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

·

Рисунок 2.12 показывает взаимосвязи между различными перспективами в описании архитектуры, используемыми шаблонами проектирования, а также примерно отображает соответствие между методиками Microsoft и соответству-ющими элементами архитектуры.

Рис. 2.12. Архитектурные шаблоны и методики компании Microsoft

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

Поэтому помимо самих методик MSF, MOF, MSA и MSM компанией опубликованы по-дробные руководства по разработке архитектуры систем [(Microsoft Application Architecture Guide, 2nd Edition, 2009)], а также шаблоны, которые могут применяться при проектировании корпоративных информационных систем [(Enterprise Solution Patterns Using Microsoft .NET, 2003)].

Корпорация Microsoft при построении любых информационных систем (не только с использованием архитектур, платформ и продуктов Microsoft) реко-мендует применять методику разработки приложений, получившую название Microsoft Solutions Fromework (MSF). Одно из важных достоинств методологии MSF , которая во многом опирается на представления о современной программной архитектуре , состоит в том, что в результате следования дисциплине, принципам и методам, заложенным в ее основу, решения получаются комплексными, интеграционными, работоспособными, с ясно определенными приоритетами.

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

Компоненты, составляющие основу методики MSF , могут применяться по отдельности или в совокупности для увеличения вероятности успеха в следующих областях:

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

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

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

Компонентами MSF являются:

• Базовые принципы. Они служат основой MSF и выражают основные ценности и стандарты, применимые ко всем элементам методики.
• Модели MSF . Это в какой-то степени карты организации проектных групп и процессов работы. Две модели являются основными в методике MSF : Модель команд и Модель процессов.
• Дисциплины MSF . Это предметные области, которые используют специфический набор методов, терминов и подходов. В настоящий момент MSF включает в себя три дисциплины: управление рисками (risk management), управление подготовкой (readiness management) и управление проектами (project management).
• Проверенные практические методики (практики) MSF . Они являются плодотворными не только в сфере информационных технологий, но также и в широком спектре других отраслей. Зачастую эти методики применимы к использованию и сопровождению ИТ-систем и иных бизнес-процессов в той же степени, что и к разработке ИТ-проектов. Примерами таких практик являются анализ результатов после контрольной точки, определение и контроль факторов риска и т.д.
• Рекомендации MSF . Это не обязательные, но рекомендуемые практики и руководства, связанные с применением моделей и дисциплин MSF .

Разработка информационных систем с помощью MSF ведется в соответствии с концепцией «приоритета архитектуры», впервые предложенной в книге Уолкера Ройса "Управление программными проектами: унифицированный метод" ("Software Project Management: A Unified Framework" // Addison-Wesley, 1998). Она означает, что все три составляющие ИТ-проектов – планирование, создание и сопровождение системы – базируются на четко определенной высокоуровневой архитектуре , что эта архитектура сформирована до того, как начата разработка, и, наконец, что именно эта архитектура и определяет направление работы. Прежде чем применять подобный подход к конкретным приложениям, необходимо полностью определить архитектуру на уровне предприятия.

Методика Microsoft Systems Architecture (MSA) относится к той части архитектуры предприятия, которая называется Технологической архитектурой. Задачей методики является стандартизация подходов к строительству центров обработки данных (Data Centers), которые лежат в основе любой корпоративной информационной системы. Методика MSA призвана помочь ИТ-подразделениям предприятий создать такие решения, которые отвечали бы шести основным требованиям: безопасности, надежности, доступности, быстродействию, управляемости и простоте технической поддержки. Залогом эффективности применения MSA на практике служит то, что все входящие в состав этого решения рекомендации появились на свет в результате тщательного тестирования описываемых конфигураций программного и аппаратного обеспечения в лабораторных условиях, моделировавших самые непростые ситуации из числа возможных в повседневной практике эксплуатации информационных систем.

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

MSA описывает следующие конфигурации инфраструктуры:

• Вычислительный центр уровня подразделения (DDC – Departmental Data Center).
• Вычислительный центр уровня предприятия (EDC – Enterprise Data Center).
• Вычислительный центр Интернет-систем (IDC – Internet Data Center).
• Вычислительный центр для высокомасштабируемых сервисов (HSSDS – Highly Scalable Services Data Center).

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

MSA предоставляет следующие документы для специалистов, решивших воспользоваться этой методикой:

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

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

В процессе исследования и накопления практического опыта специалисты компании IBM сделали немало интересных открытий (см. подробно (М. Ибрагим, 2008)). Прежде всего в исследовании Технологической академии IBM архитектура EA определяется следующим образом:

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

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

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

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

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

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

Рис. 2.13. Инфраструктура EA, разработанная компанией IBM

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

Рис. 2.14. Структура понятия архитектура предприятия (модель IBM)

Представленная на рисунке 2.14 концепция может помочь предприятиям в разработке самой EA, отвечая на вопросы, приведенные на нем разрабатываются блоки архитектуры предприятия (или предметные области):

• бизнес-архитектура;
• архитектура приложений;
• архитектура информации;
• архитектура технологии.

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

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

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

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

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

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

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

Архитектура предприятия, согласно представлению Gartner, связана со стратегией, а не с технической реализацией. Она направлена на достижение цели. Два самых важных вопроса, которыми задается компания Gartner, - это куда организация стремится и как она туда попадет. Любое действие, не связанное напрямую с этими вопросами, считается неуместным. Аналитики Gartner любят употреблять следующую фразу: «Ровно столько архитектуры, сколько необходимо, и точно в срок».

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

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

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

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

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

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

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