Содержание курса
Архитектура прикладных решений. Область разработки прикладных систем
Архитектура прикладных решений. Портфель прикладных систем
Графический язык моделирования ArchiMate
Портфель прикладных систем (Application Portfolio) - это ключевое понятие в управлении ИТ-архитектурой, описывает потребности бизнес-процессов предприятия в информационных технологиях, которые способны обеспечить автоматизированное ведение деятельности. Включает в себя набор интегрированных информационных систем, как существующих, так и вакантных на данный момент, то есть тех, которые потребуются в будущем для обеспечения новых потребностей бизнеса и деятельности организации.
Таким образом он позволяет определить актуальный уровень покрытия необходимой функциональности бизнес-архитектуры, цифровыми решениями. А также устанавливает ответственность и приоритетность каждого приложения и варианты достижения результата, посредством либо разработки системы, либо приобретения готовых приложений, учитывая интеграцию и использование возможностей уже имеющихся ИС.
Рассмотрим эффект применения этого инструмента с разных ракурсов.
С точки зрения установления актуального состояния архитектуры, портфель описывает текущее положение компенсированности бизнес процессов предприятия - цифровыми решениями.
С точки зрения стратегии развития архитектуры, портфель презентует набор целевых прикладных систем, которые должны в перспективе удовлетворять потребности бизнес-процессов предприятия.
С точки же зрения процесса реализации планов развития, под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов предприятия (финансы, люди, оборудование, материалы, энергия и прочее), направленных на трансформацию бизнес-процессов организации путем внедрения их цифровых двойников.
Опираясь на вышесказанное, можно подытожить: портфель прикладных систем – это интегрированный набор информационных систем предприятия, который обеспечивает потребности бизнеса и включает в себя следующие разделы:
- Во-первых, имеющийся набор прикладных систем. Текущий профиль информационных систем (existing portfolio) описывает существующие приложения, компоненты, интерфейсы, связанные с ними бизнес-процессы, и является текущей архитектурой приложений.
Это каталог имеющихся приложений и компонент, который отражает их связи с поддерживаемыми ими бизнес-процессами, интерфейсы с другими системами, используемую и требуемую информацию, применяемые инфраструктурные шаблоны.
Портфель может стать полезным инструментом, если он помогает многократно переиспользовать ранее проработанные элементы в рамках данного предприятия, и стимулировать такое повторное использование.
- Во-вторых, Планируемый портфель информационных систем (planned portfolio) – описывает желаемую, необходимую в будущем для бизнеса функциональность, и является целевой архитектурой приложений.
По сути, это картинка того, какими системы должны стать в будущем, когда всё задуманное по архитектуре и развитию будет реализовано.
При формировании планируемого портфеля необходимо учитывать следующие ключевые принципы:
Выравнивание с бизнес-стратегией — поддержка стратегических направлений компании.
Архитектурная согласованность — совместимость, стандартизация, единая интеграционная платформа.
Оптимизация затрат — снижение TCO за счёт консолидации и облачных решений.
Управляемость и гибкость — упрощение поддержки, ускорение изменений.
Повышение качества данных — унификация источников, мастер-данные, аналитическая зрелость.
Эта модель будущего дает основание для перехода к следующей составляющей.
- И в-третьих, План миграции (migration planning) - это документ, описывающий набор изменений, необходимых для перехода из текущего состояния в планируемое (целевое). На основании плана миграции активируются проекты внедрения новых информационных систем или внесения изменений в существующие системы. Об этом подробно речь пойдет дальше.
Сами Проекты также могут объединяться в портфели проектов.
Первым шагом к совершенству в вопросах управления приложениями является Инвентаризация прикладных решений.
4.2.1. Инвентаризация портфеля прикладных решений
Инвентаризация портфеля прикладных решений — это базовый шаг в управлении приложениями (Application Portfolio Management, APM). Она создаёт “единый список всех приложений компании” и даёт прозрачное понимание, какие системы реально используются, кто за них отвечает, какие процессы они поддерживают и в каком они состоянии.
Теперь о важных аспектах:
Аспекты портфеля прикладных решений — это различные взгляды (перспективы), через которые оцениваются, описываются и управляются приложения в организации.
Каждый аспект отражает определённый слой характеристик — от бизнес-ценности до технического состояния и ресурсного использования.
Аспект окружения портфеля приложений это архитектурный взгляд, который показывает в каком контексте функционируют приложения, отражает взаимосвязи между функциональными и технологическими (операционными) компонентами ИТ-инфраструктуры. То есть объясняет, почему именно те или иные технологии были заложены в инфраструктуру для поддержки приложений, включенных в портфель прикладных систем предприятия. Фиксация составляющих элементов аспекта окружения формирует карту “среды существования приложений” — технологической, организационной и бизнес-среды, в которой они работают.
Пример таблицы “Аспект окружения портфеля приложений”.
Приложение | Внешние системы / окружение | Тип взаимодействия | Среда развертывания | Пользователи / роли | Внешние ограничения | Влияние изменений | Ответственный |
1. CRM (Customer Management) | ERP (SAP), MDM, Почтовый шлюз | REST API, MQ | Облако (Azure), Kubernetes | Отдел продаж, маркетинг | GDPR, 152-ФЗ | Высокое — влияет на продажи и клиентский сервис | Руководитель отдела продаж |
2. ERP (SAP S/4HANA) | CRM, WMS, HRM, BI-система | SOAP, OData, файлы | Локальный ЦОД | Финансы, логистика | Внутренние регламенты, ISO 9001 | Очень высокое — ядро бизнес-процессов | CIO / Финансовый директор |
3. BI (Power BI) | ERP, CRM, DWH | SQL, API, ETL | Облако (Microsoft Power BI Service) | Руководители, аналитики | Корп. политика безопасности | Среднее — изменения влияют на отчётность | Архитектор данных |
4. Портал клиентов | CRM, Платёжный шлюз, Сервис уведомлений | REST, HTTPS | Облако (AWS), CDN | Клиенты, поддержка | 152-ФЗ, PCI DSS | Высокое — влияет на клиентский опыт | Менеджер по цифровым продуктам |
5. HRM (1С: Зарплата и кадры) | ERP, MDM, Сервис аутентификации | SOAP, LDAP | Локальный сервер | HR, бухгалтерия | Трудовой кодекс РФ | Низкое — влияние локальное | Руководитель HR |
Использование такой таблицы позволяет:
формировать единое представление контекста работы приложений;
содействовать при оценке архитектурных изменений — какие системы нужно адаптировать;
выступать основой для построения диаграмм контекста и ландшафта приложений;
упрощать управление интеграциями и рисками.
Ресурсный аспект, портфеля прикладных систем обнаруживается во взгляде на приложения с точки зрения ресурсов, необходимых для их создания, эксплуатации и развития. Эта характеристика отражает объем и структуру, во что портфель обойдется с точки зрения финансовых, людских, технологических затрат и как долго организация будет мигрировать в целевое состояние с помощью данных прикладных систем.
Пример таблицы “Ресурсный аспект окружения портф��ля приложений”.
Приложение | Категория | Стоимость владения (TCO), ₽/год | Команда поддержки | Лицензии / Подписки | Инфраструктура | Нагрузка на ИТ-ресурсы | Эффектив. (ROI) | Решение / стратегия |
1. ERP (SAP S/4HANA) | Core | 25 000 000 | 8 | SAP Enterprise | Локальный ЦОД | Высокая | 120% | Сохранить, оптимизировать лицензии |
2.CRM (Bitrix24) | Customer-facing | 7 500 000 | 3 | SaaS | Облако (Bitrix Cloud) | Средняя | 150% | Сохранить, интегрировать с BI |
3.BI (Power BI) | Analytical | 3 200 000 | 2 | Microsoft 365 E5 | Облако (Azure) | Средняя | 200% | Развивать аналитику |
4.HRM (1С: Зарплата) | Supporting | 2 800 000 | 2 | 1С лицензия | Локальный сервер | Низкая | 80% | Постепенная миграция |
5.MDM (Master Data Hub) | Shared Service | 5 500 000 | 4 | Enterprise License | Облако (AWS) | Средняя | 100% | Развивать, повысить автоматизацию |
6.Портал клиентов | Customer-facing | 4 000 000 | 3 | Custom Dev | Облако (AWS) | Высокая | 180% | Приоритетное развитие |
Систематизация ресурсного аспекта позволяет:
обеспечить прозрачность затрат. Понять, сколько стоит каждое приложение, и его доля в общем решении;
планировать бюджет. Определить приоритеты инвестиций;
оптимизировать ИТ-ландшафт. Найти дублирующие или неэффективные системы;
управлять загрузкой. Балансировать ресурсы команд и подрядчиков;
поддерживать решения по развитию. Решить — развивать, заменить или вывести приложение;
Часто рассматривают и другие аспекты (эволюционный, интеграционный, безопасности и прочие), поддерживающие многомерное описание приложений. Их анализ обеспечивает комплексное понимание состояния ИТ-ландшафта и помогает управлять им стратегически.
Из вышесказанного очевидно, что Портфель содержит достаточно большое количество взаимосвязей и цепочек, беря начало от бизнес-процессов, функционирование которых обеспечивается работой прикладных систем. В свою очередь этим прикладным системам для работы необходимы данные, которые они преобразуют в информацию, обретающую принципиально новое качество. Для выполнения всех этих активностей, прикладные системы и данные требуют соответствующей инфраструктуры, построенной на основании принятой в организации технологической архитектуры, о которой мы подробно поговорим в следующей части.
Вторым шагом в формировании портфеля прикладных систем выполняется оценка текущего его состояния и того, насколько он реально соответствует потребностям организации на текущей стадии зрелости, а также масштаб перспектив с точки зрения развития бизнеса и стратегий использования технологий на предприятии.
Степень комплементарности прикладных систем - бизнес-стратегиям оценивается на основе вклада цифровых решений в достижение бизнес-результатов, установленных запросами бизнес-архитектуры предприятия.
4.2.2. Оценка и оптимизация текущего портфеля прикладных систем
Оценка состояния (Application portfolio assessment) – это ключевой этап управления ИТ-архитектурой, позволяющий понять, насколько текущий набор приложений соответствует бизнес-целям, техническим требованиям и экономической эффективности.
Оценка портфеля позволяет идентифицировать проблемные области и определить возможности для лучшего удовлетворения потребностей бизнеса. На основании этого анализа открывается возможность выработать взвешенные решения об инвестициях в новые системы или обновление существующих. Определить, какие приложения следует сохранять, развивать, модернизировать или выводить из эксплуатации, чтобы портфель был эффективным, устойчивым и согласованным с бизнес-стратегией.
Категории оценивания могут быть следующими:
С точки зрения Бизнес-ценности прикладная система оценивается по способности обеспечивать выполнение основных функций предприятия, подразделения или процесса.
С точки зрения Бизнес-стратегий оценивается вклад прикладных систем в достижение бизнес-целей, и регламентируется бизнес-архитектурой предприятия.
С точки зрения Технического состояния оцениваются такие характеристики как: точность и корректность данных, структура программного кода, быстрота отклика, уровень технического сопровождения, возможность получения отчетов и прочие нефункциональные требования.
С точки зрения Технологического соответствия, на основе анализа оценивается то, насколько прикладные системы соответствуют принципам и технологическим стандартам, принятым в технологической архитектуре предприятия. Учитывается ее влияние на, сложность сопровождения, длительность времени вынужденных простоев, проблемы лицензионного использования и прочее.
С точки зрения Экономической эффективности насколько оправданы затраты.
С точки зрения Пользовательской оценки насколько активно используется система.
Собранные оценки позволяют понять текущее состояние приложений, их ценность для бизнеса, техническое здоровье, а также определить необходимые действия:
Если ценность приложения для обеспечения функционирования бизнеса не высока, техническое состояние плохое, а технологическая инфраструктура устарела и давно не эффективна, то системе грозит вывод из эксплуатации.
Если ценность приложения для функционала высокая, но технологическое соответствие современным трендам оставляет желать лучшего, то система нуждается в обновлении инфраструктуры, обеспечивающей ее поддержку и обслуживание.
Если приложение по каким-то причинам потеряло свою первоначальную ценность для организации, но его состояние остается хорошим, то надо попытаться найти ему новое применение (перепозиционировать приложение).
Если же ценность приложения высокая и при этом технологическое состояние хорошее, то никаких изменений не надо, а достаточно просто надлежащим образом сопровождать систему и обеспечить ее адаптацию к меняющимся условиям.
В результате такой оценки прикладные системы относятся к одной из четырех возможных категорий:
1) системе грозит вывод из эксплуатации (замена) или консолидация;
Эти прикладные системы являются кандидатами на вывод из эксплуатации или замену. Но необходимо понимать, что стоимость замены некоторых унаследованных систем может оказаться неоправданно высокой и будет иметь весьма ограниченную ценность с точки зрения бизнеса.
2) система, требует переоценки или перепозиционирования;
Как правило, это прикладные системы, которые были недавно запущены в эксплуатацию в соответствии с рекомендациями, принятыми в рамках архитектуры предприятия. Однако объем и характер решаемых ими задач таковы, что их вклад в достижение ключевых бизнес-результатов незначителен.
В этой ситуации рекомендуется переформатировать принципы использования этих приложений или их компонент в рамках более рентабельных бизнес-процессов и организационных структур предприятия.
3) система, требует обновления;
Эти прикладные системы исправно обслуживают ключевые бизнес-функции, но создают существенные проблемы, в процессе их эксплуатации и сопровождении. Например, при интеграции этих систем с другими прикладными системами предприятия.
Рецептом здесь является постепенный переход на использование более адаптивной архитектуры приложения (компонентный подход, n-уровневая архитектура, микропроцессный подход или прочие архитектурные стили, рассмотренные в предыдущей части).
4) система, требует сопровождения и развития.
системы критически важны с точки зрения бизнеса и спроектированы в соответствии с современными представлениями об архитектуре прикладных систем.
Существуют и другие сегментации, влияющие на оценку. Например, классификация приложений по фокусу вклада в эффективность функционирования предприятия.
Классификация приложений по фокусу вклада обычно делит каталог так:
Во-первых, Базовые транзакционные (или вспомогательные и обслуживающие) приложения. Они играют важную роль с точки зрения поддержки операционной деятельности организации, но не обеспечивают явные преимущества перед другими организациями конкурентами.
Например, приложение для расчета заработной платы или система управления персоналом. Таких приложений в портфеле информационных систем предприятия обычно большинство.
Второй класс приложений – Информационные (дающие преимущества). Эти приложения, обеспечивают информацию для учета, управления, контроля, анализа и совместной работы. Они улучшают качество функционирования организации. Такие системы позволяют обеспечить следующие преимущества:
ускорение процесса принятия решения;
более быстрый вывод на рынок новых продуктов и услуг;
уменьшение производственного цикла;
более широкий набор продуктов и услуг;
меньшая стоимость выполнения операций.
И наконец, третий класс приложения, несет Инновационный характер и позволяет радикально влиять, на эффективность функционирования организаций. К примеру, кардинально изменяя саму основу конкуренции и за счет этого получать преимущества на рынке. Это так называемые инновационные (стратегические или "пограничные") приложения. Именно они способны обеспечить конкурентные преимущества в разных сегментах.
Например, на определенном этапе это было - внедрение электронной торговли через интернет или подключение к сайту продаж - системы оплаты посредством банковских карт, позже - применение технологий искусственного интеллекта. В начале внедрения таких инновационных решений всегда есть множество рисков и неопределенностей, но постепенно они адаптируются и начинают широко применяться. Их эксклюзивность перерастает в массовость, определяющими факторами снова становятся стоимость и надежность. В результате они переходят в разряд приложений второго типа - базовые транзакционные.
Собранная таким образом информация о системе фиксируется в ее паспорте, включая помимо описания, компонентного состава и характеристик, еще и: перечень заинтересованных лиц, владельцев, области применения и прочее. Паспорта систем собираются и классифицируются в каталог прикладных систем портфеля.
Когда определен текущий портфель и есть понимание, о том каким должен быть целевой портфель, можно переходить к формированию плана миграции.
4.2.3. План миграции
План миграции портфеля прикладных решений — это структурированный план действий по модернизации, замене, интеграции или выводу приложений из эксплуатации для достижения целевой архитектуры предприятия.
Для обеспечения плавной миграции портфеля прилож��ний из текущего состояния в целевое, кроме определения принадлежности приложений портфеля к определенной ценностно-эксплуатационной группе, необходимо выполнить следующие дополнительные манипуляции:
оценить потребности предприятия, которые никак не обслуживаются существующим портфелем прикладных систем;
сопоставить технологические и операционные требования (надежность, масштабность, переносимость и т.п.) портфеля прикладных систем с действующей технологической инфраструктурой и идентифицировать в ней отсутствие тех возможностей, которые могут потребоваться в перспективе;
согласовать между собой (синхронизировать) проекты внедрения прикладных систем и развития инфраструктуры с учетом результатов предыдущих двух позиций и на этой основе расставить приоритеты и по ценности для дела, и по улучшению технологического состояния.
Пример упрощенной таблицы Плана миграции:
Приложение | Текущее состояние | Целевое состояние | Действие | Срок | Приоритет | Ответственный | Примечание |
1. ERP (SAP ECC) | Локальный ЦОД, устаревшая версия | SAP S/4HANA Cloud | Миграция | 2025 Q2–Q4 | 1 | CIO | Основная система учёта |
2. CRM (Bitrix24 On-premise) | Самостоятельный сервер | SaaS Bitrix Cloud | Перенос / интеграция | 2025 Q1 | 2 | ИТ-директор | Уменьшение TCO |
3. HRM (1С) | Локально | HRM в облаке | Замена | 2026 Q1 | 3 | HR-директор | Совмещение с ERP |
4. BI (QlikView) | Старая платформа | Power BI Cloud | Замена | 2025 Q3 | 2 | Архитектор данных | Интеграция с Azure DWH |
5. Legacy Portal | Устаревший код | Новый фронт (React, API Gateway) | Разработка с нуля | 2026 Q2 | 4 | Dev Lead | Улучшение UX/UI |
Структура документа плана миграции, как пошаговая дорожная карта, может иметь следующую структуру:
Введение. Цель и обоснование миграции, связь со стратегией;
Исходное состояние (AS-IS). Текущие приложения, их роли, проблемы;
Целевое состояние (TO-BE). Желаемая структура портфеля и архитектурные принципы;
Разрыв (Gap Analysis). Сравнение AS-IS и TO-BE: что нужно изменить;
Мероприятия по миграции. Конкретные шаги, проекты, инициативы;
Приоритеты и фазы реализации. Очередность и сроки перехода;
Риски и зависимости. Технические и организационные риски, меры снижения;
Ресурсы и ответственность. Команды, бюджеты, ответственные лица;
Показатели успеха (KPI). Как измеряется успешность перехода.
Поэтому, на самом деле, в совокупности с обозначенными выше типами прикладных систем, необходимо рассматривать инфраструктуру или технологическую архитектуру, которой будет посвящена следующая часть.
4.2.4. Управление портфелем прикладных систем
Управление портфелем прикладных систем (Application Portfolio Management — APM) – это системный процесс учёта, анализа, оценки, оптимизации и развития всех приложений предприятия с целью повышения их бизнес-ценности, снижения затрат и обеспечения архитектурной согласованности.
Основные цели этого процесса:
Оптимизация портфеля. Удаление дублирующих и неэффективных систем и прочее.
Управление затратами. Снижение совокупной стоимости владения (TCO Total Cost of Ownership — полная стоимость владения ИС).
Поддержка бизнес-стратегии. Приложения должны поддерживать ключевые процессы.
Повышение архитектурной зрелости. Соответствие корпоративным стандартам и целевой архитектуре.
Управление жизненным циклом приложений. Планирование модернизации, замены и вывода из эксплуатации.
Повышение прозрачности ИТ-ландшафта. Понимание, какие системы есть, зачем они нужны и как связаны
Инструмент Портфель прикладных систем позволяет организовать и поддерживать конструктивный диалог функциональных руководителей бизнеса с ИТ-специалистами и обеспечивает его результативность, помогая находить компромиссы.
Например, при решении задачи инвестирования в развитие информационных технологий, портфель прикладных решений выступает ключевым инструментом. По существу, он позволяет совместно топ-менеджменту предприятия и руководству ИТ-службы выработать решение относительно того, в какой из функционально-технологических активов организационной системы направить инвестиционные ресурсы. Это обеспечивает:
Согласование приоритетов: Бизнес хочет ценность и поддержку процессов, ИТ — устойчивость, безопасность и оптимизацию. Портфель помогает найти баланс: что развивать, что модернизировать, что выводить.
Прозрачность ресурсов и затрат: Руководители понимают, сколько стоит каждое приложение, какие ресурсы нужны, и какие бизнес-процессы оно поддерживает.
Управление рисками и зависимостями: Совместный анализ позволяет выявить критические системы, узкие места и интеграционные риски.
Планирование развития портфеля: Диалог помогает формировать дорожные карты миграции, модернизации и внедрения новых решений, учитывая потребности бизнеса и возможности ИТ.
Обеспечение согласованности с архитектурной стратегией: ИТ-специалисты показывают, как приложения вписываются в архитектурные.
Таким образом обоим сторонам приходится нести солидарную ответственность за разработку, внедрение и обеспечение функционирования прикладных систем.
В следующей части, как анонсировалось выше, мы рассмотрим технологическую архитектуру.
