Предприятия отчаянно нуждаются в архитектурном подходе, позволяющем выжать больше пользы из разрозненных унаследованных ресурсов
Мода в ИТ приходит и уходит, так называемые изменения парадигмы происходят с раздражающей регулярностью, но унаследованные системы, похоже, будут всегда. В какой крупной компании нет унаследованного приложения, выполняемого на устаревшем оборудовании, которое прячется в темном углу ВЦ?
Тем временем бизнес продолжает требовать постоянного повышения гибкости ИТ-инфраструктуры. Конкурентное давление, требования законодательства и непрерывный поиск путей повышения эффективности бизнеса — все это заставляет ИТ приспосабливаться к изменяющейся бизнес-среде. Но с каждым новым технологическим прорывом кажется, что потребности бизнеса все больше ускользают от возможностей технологий. С этим нужно что-то делать! Подход «выбросить и заменить» не срабатывает — слишком дорого и опасно. Нагромождение программных средств промежуточного слоя уж точно не поможет — кому нужно склеивать склейки? А простое добавление приложений или того или иного оборудования для решения какой-либо отдельно взятой проблемы вообще ничего не решает — в конце концов, меньше всего нам нужен рост количества унаследованных систем. Сегодня предприятия отчаянно нуждаются в новом архитектурном подходе, позволяющем выжать больше пользы из разрозненных унаследованных ресурсов, достаточно гибком, чтобы вписаться в динамичную бизнес-среду.
Унаследованные системы в рамках SOA
Сервисно-ориентированная архитектура (Service-Oriented Architecture, SOA) привлекает не только своей рекламой. Назойливая реклама, утверждающая, что SOA в состоянии решить все проблемы, неизбежно порождает антирекламу. Как только вы закатаете рукава и займетесь переделкой унаследованных приложений в сервисы, вы обнаружите, что обещанные преимущества гибкости, повторного использования и эффективности находятся полностью вне досягаемости, поскольку сервисы — это просто интерфейсы к существующему функционалу. Правда, не будучи столь сенсационной, очевидно, лежит между этими двумя крайностями.
Фактически, есть три основных подхода к включению унаследованных приложений в реализацию SOA: прямое обращение к данным, заключенным в унаследованных системах, обращение к бизнес-логике через интерфейсы прикладного программирования (API) или через другие программные средства и эмуляция взаимодействия с пользователем посредством эмуляции терминала.
Выбор подхода зависит от специфики требований и технических ограничений. Программный подход кажется наилучшим, поскольку позволяет получить непосредственный доступ к данным и функциональным возможностям, однако во многих случаях API недоступны или не годятся для прямого доступа. Поэтому многим предприятиям приходится довольствоваться методом преобразования экрана.
Восходящий и нисходящий подходы к построению SOA
Сегодня эти подходы знакомы большинству специалистов по интеграции данных. Новый поворот истории заключается в том, что мы можем использовать их преимущества при переходе к SOA. Первый шаг к принятию наследства в рамках SOA — прикрыть унаследованные системы сервисными интерфейсами. Однако простая публикация унаследованных ресурсов и сервисов, которую можно назвать восходящим подходом, сама по себе не обеспечивает SOA. В сущности мы просто превратили коробку случайных игрушек в блоки Lego, и теперь они прекрасно сочетаются друг с другом. Но дайте эти блоки малышам, и неизвестно, что они соберут. Чтобы построить из блоков Lego красивый замок, вам нужны план и дисциплина. Если унаследованные ресурсы, оформленные в виде сервисов, — это блоки Lego, то план и дисциплина — это архитектура SOA.
Фактически, вам нужен план, направляющий развитие инициативы SOA в целом, чтобы развивать свою технологию в направлении текущих потребностей бизнеса. Лучший способ построения SOA состоит в объединении нисходящего подхода с восходящим. Нисходящий подход начинается с архитекторов, создающих долгосрочный проект. В этом проекте важно выбрать правильный уровень детализации, поскольку перегруженность деталями может замедлить работу, а недостаточная детализация обедняет архитектуру. Однако при построении SOA не следует сбрасывать со счетов и восходящий подход. Если вы ограничитесь лишь нисходящими методами, вам, вероятно, предложат сервисы, технически слишком громоздкие или сложные в реализации. С другой стороны, замыкание в рамках исключительно восходящего подхода может привести к ненужным сервисам.
SOA — не волшебная панацея, но при должном балансе восходящего и нисходящего подходов к разработке новой архитектуры можно достичь радикального повышения качественных показателей ведения бизнеса. Фактически, на горизонте нет никаких жизнеспособных альтернатив для SOA. Вопрос не в том «SOA или что-то другое?», вопрос формулируется следующим образом: «SOA: когда и как?». Поэтому SOA — это вовсе не пустой ИТ-прожект. Что и говорить, SOA требует напряжения сил, но бесспорно, останется с нами навсегда.