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

Модели и инструменты управления портфелем приложений

Существуют различные способы оценки портфеля и различные классификации прикладных систем предприятия. Одной из возможных моделей оценки портфеля прикладных систем является оценка их по двум критериям – ценность с точки зрения бизнеса и техническое состояние, что проиллюстрировано на рис. 6.3 [4.19].

Рис. 6.3. Оценка портфеля прикладных систем по критериям "бизнес-ценность" и "техническое состояние"

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

В результате такой оценки прикладные системы относятся к одной из четырех возможных категорий:

• системам грозит вывод из эксплуатации (замена) или консолидация;
• системы, требующие переоценки или перепозиционирования;
• системы, требующие обновления;
• системы, требующие сопровождения и развития.

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

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

Ниже даны краткие характеристики каждой категории систем в соответствии с этой классификацией:

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

Этот же способ оценки назван Матрицей оценки состояния прикладных информационных систем (Health Grid) [4.14]. Графическое расположение систем на матрице, кроме двух параметров – ценность с точки зрения бизнеса и техническое состояние, – может нести в себе еще и дополнительную информацию. Во-первых, каждой прикладной системе соответствует круг, диаметр которого пропорционален общей стоимости информационной системы, с учетом стоимости приобретения, эксплуатации и сопровождения (стоимости обновлений). Во-вторых, круги окрашиваются в один из пяти цветов, характеризующих реальную важность системы, а не просто потенциальную ценность для бизнеса (например, система в данный момент может считаться малоценной для бизнеса, но достаточно важной, поскольку ценность ее может быть повышена в будущем за счет обновления и обеспечения доступа к накопленным данным через Интернет).

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

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

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

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

• Название системы.
• Описание системы.
• Список технологических компонентов. Это важно, поскольку они могут использоваться независимо для построения других решений. При этом основные компоненты должны быть отдельно описаны, включая их функции и техническое состояние.
• Область применения с точки зрения бизнеса, т.е. функциональные возможности (например, CRM, финансы, управление кадрами, каналы продаж через Интернет и пр.).
• "Владелец" системы со стороны бизнеса.
• Оценка пользы прикладной системы для бизнеса.
• Ответственный со стороны ИТ-подразделения.
• Оценка технического состояния.
• Оценка возможностей по обеспечению новых потребностей бизнеса.
• Дата обновления этой информации.

Для оценки портфеля прикладных систем может быть также использована модель, предложенная Gartner [4.20].

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

Интересно то, что совершенно разные авторитетные источники – Gartner, META Group, а также Уэйл и Броадбент в своей книге "Использование возможностей инфраструктуры. Как лидеры рынка получают преимущества от информационных технологий" [4.20], [4.19], [4.14] – дружно выделяют три категории прикладных систем, правда, используя для обозначения этих категорий несколько разные определения. Однако критерии отнесения прикладных систем к той или иной категории при этом полностью совпадают.