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

Мы уже отмечали, что архитектура предприятия является важным, но не единственным критическим элементом в производственной цепочке, связанной с управлением информационными технологиями предприятия, которая объединяет процессы стратегического бизнес-планирования, прикладные информационные системы и процессы их сопровождения, обеспечивающие реализацию потребностей бизнеса [3.21].

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

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

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

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

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

· стратегия и планирование на уровне предприятия.

· архитектура предприятия.

· управление ИТ-программами и проектами.

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

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

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

Рис. 4.6. Интеграция ключевых процессов управления информационными технологиями предприятия

В связи с этим соотношение между сегодняшним состоянием архитектуры предприятия (архитектура "как есть"), будущим желаемым состоянием архитектуры (архитектура "как должно быть"), портфелем ИТ-активов и портфелем ИТ-проектов можно также условно отобразить в виде следующей схемы[3.22]:

Рис. 4.7. Архитектура, ИТ-активы и ИТ-проекты

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

Общие элементы определений "Архитектуры предприятия" и основные заблуждения

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

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

На одну и ту же архитектуру существуют различные взгляды (или представления).

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

Итак, перечислим общие элементы определений, связанных с архитектурой:

· архитектура определяет основные компоненты (бизнес-архитектура, архитектура приложений и т.д.);

· архитектура определяет взаимосвязи между компонентами и взаимодействия между ними;

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

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

· каждая система имеет архитектуру – даже система, которая состоит из одной компоненты;

· архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;

· определения архитектуры не содержат описания самих компонент.

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

· архитектура и проектировочные решения (дизайн систем) – это одно и то же;

· архитектура и инфраструктура – это одно и то же;

· архитектура – это только структура;

· архитектура – это "плоское" понятие, и одного представления схемы описания архитектуры будет достаточно;

· архитектуру нельзя оценить;

· архитектура – это искусство или наука.

Обсудим эти заблуждения чуть более подробно, следуя идеям Буча (Grady Booch), одного из создателей языка UML.

Архитектура включает анализ рисков и обоснования, объяснения причин. Сами архитектурные, проектировочные решения являются одним из проявлений архитектуры.

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-04-25