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

Корпорация 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) - включает в себя архитектуру локальных проектов, выполняющихся в соответствии с конкретным планом развития информационных систем и бизнес-процессов. Специалисты, занимающиеся такими проектами, как правило, являются профессионалами в конкретных областях, они занимаются главным образом решением текущих задач и часто не могут оценить их влияние на предприятие в целом.