Управление портфелем приложений

Предположительно, одним из первых упоминаний понятия «портфель приложений» стала статья Сайруса Гибсона и Ричарда Нолана «Управление четырьмя стадиями роста ЭВМ» (англ. Managing the Four Stages of EDP Growth) в журнале Harvard Business Review в 1974 году^[2].

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

Компания Nolan, Norton & Co. одной из первых применила эти концепции на практике, проводя исследования в DuPont, Deere, Union Carbide, IBM, Merrill Lynch и других компаниях. В рамках так называемых «этапных оценок» измерялась степень поддержки каждым приложением бизнес-функций и процессов, оценивались затраты на приложение, его функциональные и технические характеристики. Эти измерения обеспечили комплексный взгляд на применение ИТ в бизнесе, позволили выявить сильные и слабые стороны, а также наметить пути совершенствования.

Широкое внедрение APM началось в конце 1980-х и продолжалось в 1990-х годах, когда организации приступили к оценке риска отказа приложений в связи с наступлением 2000 года (проблема «Year 2000» или Y2K)^[3]. В этот период десятки тысяч ИТ-организаций по всему миру сформировали подробные списки своих приложений, включая сведения о каждом из них.

Во многих компаниях использование таких списков вызывало вопросы со стороны бизнеса из-за высоких затрат на устранение Y2K-рискa. Иногда само понятие управления портфелем преподносилось как дополнительная выгода для бюджетов ИТ-подразделений наряду со снижением риска отказа приложений.

Выделяют две основные категории решений по управлению портфелем приложений: «сверху вниз» и «снизу вверх»^[4]. Первая задача — выяснить, какие приложения существуют в организации и каковы их основные характеристики (гибкость, поддерживаемость, владелец и др.), что обычно называют «инвентаризацией». Альтернативный подход — подробный анализ посредством разбора исходного кода приложения и связанных с ним компонентов с размещением сведений в базе (т. н. «снизу вверх»); этому способствуют инструменты для майнинга приложений и современные APM-системы.

Сотни инструментов поддерживают подход «сверху вниз», так как основная задача — сбор корректной информации; хранение и поддержка сведений относительно просты. Многие организации из-за этого используют для хранения данных инвентаризации Microsoft Excel. Однако по мере усложнения портфеля Excel становится труднее поддерживать, а автоматическое обновление данных ограничено. К тому же инвентаризация не заменяет глубокого понимания, которое даёт анализ «снизу вверх».

По данным компании Forrester Research, на текущие расходы по эксплуатации и сопровождению ИТ-решений предприятия тратят две трети и более своих операционных бюджетов^[5].

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

Поскольку большая часть затрат уходит на существующие приложения, прозрачность текущего портфеля и потребления ресурсов становится первой целью управления портфелем приложений^[6].^[7] Это позволяет: 1) выявлять и устранять частично или полностью дублирующиеся приложения, 2) количественно оценивать состояние приложений (стабильность, качество, поддерживаемость), 3) оценивать бизнес-ценность и важность каждого приложения, 4) распределять ресурсы в соответствии с состоянием и значимостью приложений в рамках приоритетов бизнеса.

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

Используя принципы управления инвестиционным портфелем, специалисты по управлению портфелем приложений собирают информацию о каждом используемом приложении: расходы на разработку и сопровождение, создаваемая бизнес-ценность, качество, ожидаемый срок службы^[1]. Такой подход позволяет формировать аналитические отчёты по работе ИТ-инфраструктуры в соотношении затрат на владение и предоставляемой бизнес-ценности.

В управлении портфелем приложений определение понятия «приложение» является ключевым моментом. Многие поставщики услуг помогают компаниям формировать собственное определение, поскольку обсуждения по этому вопросу часто приводят к разногласиям^[8].

• Прикладное программное обеспечение — исполняемый программный компонент или тесно связанный набор исполняемых компонентов (один или несколько), внедрённых совместно, который выполняет часть или все действия, необходимые для создания, изменения, управления, вычисления или отображения информации для определённой деловой задачи. Каждый компонент не должен входить в состав другого приложения.
• Программный компонент — исполняемый набор инструкций, размещённый в одном контейнере развертывания, который нельзя далее раздробить. Примеры: динамические библиотеки (DLL), веб-страницы ASP, консольные приложения EXE. ZIP-файл может содержать несколько компонентов, потому что их легко выделить, распаковав архив.

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

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

Определение приложения для целей управления портфелем должно соответствовать ряду критериев:

• Быть простым для объяснения, понимания и применения сотрудниками бизнеса.
• Соответствовать логике для девелоперов, специалистов по эксплуатации и менеджеров проектов в ИТ-подразделениях.
• Пригодиться в качестве входных данных для расчёта совокупной стоимости портфеля — поскольку численность приложений влечёт затраты.
• Быть полезным для архитекторов предприятия при оценке проектов на соответствие целям оптимизации и упрощения портфеля.
• Однозначно определять границы приложения — чтобы нельзя было, изменив определение, искусственно объединить несколько решений в одно.

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

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

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