Тема 5 Архитектура и управление IT-портфелем

 

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

 

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

 

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

 

 

IT-программы и проекты

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

 

Процессы выработки стратегии и планирование обеспечивают основу для отбора, управления и оценки ИТ-ресурсов и проектов.

 

Соотношение между АП <<как есть>> и <<как должно быть>>

 

 

 

Особенности АП

 

 

Контекст разработки АП

 

Определение разработки АП

 

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

Методики разработки АП

 

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

 

 

Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF (Department of Defence Architecture Framework).

Описание IT-архитектуры

 

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

 

 

Пример модели архитектуры предприятия

 

Содержание (предмет) Архитектуры предприятия Определения архитектуры
Описания систем Руководства, Правила и Стандарты
Как есть Как должно быть
Бизнес-архитектура Связи между бизнес-процессами     Принципы (система ценностей и постулатов) Новые требования
Бизнес-функции    
Подфункции    
Новые функции    
Архитектура информации Информация     Шаблоны, Правила (политики), Сервисы Модели технологической архитектуры (список стандартных технологий и продуктов)
Архитектура приложений Приложения    
Точки доступа    
Интеграция    
Технологическая архитектура Инфраструктура    
Платформы    
Системы хранения    
Сети    
Безопасность    
Системное управление    
Описание текущей среды ИТ Область управления и контроля архитектуры
Движущие силы с точки зрения бизнеса и стратегии

 

Модель Захмана

 

 

 

 

Правила заполнения таблицы Захмана

 

 

Основные характеристики модели Захмана

 

· простота для понимания как техническими, так и нетехническими специалистами;

· целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом;

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

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

· Применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого;

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

 

Модель описания IT-архитектуры Gartner

 

Модель Gartner 2002 года сформирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:

· Среда бизнес-взаимодействия (Business Relationship Grid);

 

· Бизнес-процессы и стили бизнес-процессов;

· Шаблоны;

· Технологические строительные блоки (кирпичики – bricks).

 

 

 

Описание уровней модели Gartner (1)

 

В этой схеме верхние два уровня ориентированы на совместное обсуждение с бизнес-руководителями и IT-специалистами и в какой-то степени соответствует тому, что мы называли бизнес-архитектурой, а ниже два уровня входят во внутреннюю компетенцию ИТ-службы:

· Верхний уровень Среды бизнес-взаимодействия описывает, новую модель «виртуального» бизнеса, а также все что связано с кооперацией предприятий и бизнесом В2В. Этот уровень соответствует понятию «отраслевой нервной системы» взаимодействующих предприятий. Он получил развитие в связи с распространением Интернет как среды взаимодействия, и связан с понятием доступа, межорганизационного взаимодействия.

Описание уровней модели Gartner (2)

 

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

· Следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных задач на предприятии. Отметим, что шаблоны охватывают не только область программного обеспечения, но и соответствующие сетевые и вычислительные ресурсы, как мы рассматривали ранее в разделе 4.7. примерами шаблонов является трехуровневая архитектура прикладных систем (интерфейс – логика – данные), использование «толстого» клиента в архитектуре клиент/сервер, хранилища данных. Что касается приложений, то упор сделан на использовании шаблонов сервис-ориентированной архитектуры, т.е. реализации приложений в виде модульного набора различных типов сервисов. Это, в том числе, позволяет в перспективе интегрировать приложения как web-сервисы.

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

 

IT-архитектура в модели Gartner

 

 

Методика META Group

 

Исторически архитектурная методика META Group оперировала таким понятием, так Технологическая архитектура масштаба предприятия (EWTA –Enterprise Wide Technical Architecture). Однако по мере того, как в индустрии происходило понимание более тесной связи между бизнесом и информационными технологиями, в представления (домены или предметные области) Архитектуры предприятия META Group были добавлены такие домены, как Бизнес-архитектура (EBA - Enterprise Business Architecture), Архитектура информации (EAI – Enterprise Information Architecture) и портфель прикладных систем предприятия (EAP – Enterprise Application Portfolio). Это соответствует эволюции понятия «Архитектура предприятия», которая происходила на рынке в целом (см. раздел 3.2.1), и принятой сегодня практике выделения доменов архитектуры.

Кроме того, расширяя многие другие представления, архитектурная методика META Group рассматривает Архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами.

Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture).

 

Аналитическая работа и компоненты АП

 

 

Этапы разработки АП по методике META Group

На этапе 1разрабатывается Видение общих требований. Разработка видения общих требований включает в себя:

 

· Анализ тенденций развития внешней для предприятия среды, включая технологические тенденции;

· Бизнес-стратегии и основные движущие силы с точки зрения бизнеса;

· Требования к информационным системам со стороны бизнеса;

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

 

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

 

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

 

 

Структура описания элементов (доменов) АП

Домен технологической архитектуры
Принципы построения
Технологии
Стандарты
Продукты
Конфигурации
Концептуальная архитектура
 
 

 


Состав описания домена (элемента) АП (1)

 

· Формулировка миссии домена: стратегические цели домена.

· Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий.

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

 

Состав описания домена (элемента) АП (2)

 

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

· Лучшие практики.

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

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

Методика TOGAF

 

Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий, а такжекомпаний из спискаFortune 1000. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития.

 

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

 

В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятием TOGAF и моделью
Захмана.

 

Структура TOGAF

Разработка архитектуры
Методика разработки архитектур ADM
Техническая эталонная модель TRM   Таксономия сервисов
База стандартов
База элементарных блоков
База ресурсов, в т.ч. язык ADML, принципы, представления, примеры реализации  

 


Фазы разработки архитектуры

 

В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:

· Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.

· Фаза А: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.

· Фаза B: разработка бизнес-архитектуры предприятия.

· Фаза С: разработка архитектуры данных и архитектуры приложений.

· Фаза D: разработка технологической архитектуры.

· Фаза Е: поверка возможности реализации предложенных решений.

· Фаза F: планирование перехода к новой системе.

· Фаза G: формирование системы управления преобразованиями.

· Фаза H: управление изменением архитектуры.

 

Каждая фаза. В свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные процессы:

 

· Описание существующей технологической архитектуры.

 

§ Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации.

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

§ Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.

§ Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.

§ Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.

 

· Формирование целевой технологической архитектуры.

 

§ Описание существующей системы в терминах TOGAF.

§ Определение перспектив (представлений) архитектуры.

§ Формирование модели целевой архитектуры.

§ Определение ИТ-служб (сервисов).

§ Подтверждение учета бизнеса-требований.

§ Определение архитектуры и используемых блоков (шаблонов).

§ Проведение анализа расхождений (gap analysis).

 

NASCIO Architecture Toolkit