Сервис-ориентированную архитектуру продают как лекарство от всех болезней корпоративной ИТ. Вендоры обещают гибкость, переиспользование и мгновенную реакцию на запросы бизнеса. На практике половина проектов SOA не возвращает вложенных денег: компания покупает дорогую шину, оборачивает сервисами пару старых систем и останавливается. Разберём трезво, когда SOA действительно окупается, а когда остаётся строчкой расходов в бюджете.

Где SOA приносит деньги

SOA окупается там, где у вас много систем и много связей между ними. Если ERP, биллинг, CRM и складская система обмениваются данными через десяток точечных интеграций «каждый с каждым», то любое изменение в одной системе ломает три других. Это классическая «интеграция-паутина»: стоимость поддержки растёт квадратично с числом систем.

Сервисный слой разрывает эту зависимость. Каждая система публикует контракт, остальные обращаются к нему, а не лезут напрямую в чужую базу. Заменить биллинг становится задачей на месяцы, а не на годы. Именно здесь возникает реальная экономия – на сопровождении и на скорости изменений, а не на «инновационности» как таковой.

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

Когда SOA не нужна

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

Опасна и обратная крайность – обернуть всё подряд веб-сервисами «на всякий случай». Сервис, у которого один потребитель и нет планов на второго, не даёт переиспользования. Вы платите за сериализацию, сетевые вызовы и версионирование контракта, не получая взамен гибкости. SOA – это инвестиция в развязку зависимостей, а зависимостей, которые стоит развязывать, у вас должно быть достаточно много.

Что определяет окупаемость

Технология вторична. Решают три вещи: зрелость процессов, дисциплина контрактов и управление версиями.

Зрелость процессов – у вас должны быть описанные бизнес-процессы, которые сервисы автоматизируют. Нельзя «осервисить» хаос: вы получите хаос, разложенный по веб-сервисам. Дисциплина контрактов – интерфейс сервиса фиксируется и меняется по правилам, иначе развязка зависимостей превращается в новую паутину, только поверх XML. Управление версиями – потребители не должны ломаться, когда поставщик меняет сервис; без продуманного версионирования вы получите остановки эксплуатации на каждом релизе.

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

Вывод

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