Архитектура цифрового мира. Андрей Николаевич ТрушкинЧитать онлайн книгу.
непосредственных задач решение реализовывало ряд шаблонов проектирования, представленных как в вышеупомянутом труде («Enterprise Integration Patterns»), так и в одной из основополагающих работ в сфере ИТ: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides «Design Patterns: Elements of Reusable Object-Oriented Software» (1994, ISBN 0-201-63361-2). К числу подобных шаблонов можно отнести каноническую модель данных, адаптер и т. д.
Как уже отмечалось выше, переход к SOA стал революционным в плане развития архитектуры и внедрения ИТ в организациях. В результате разгрузки учетных платформ от несвойственного им функционала передовые в технологическом плане финансовые организации смогли приступить к активной автоматизации своих производственных и бизнес-процессов. Практики SOA стали основными, при этом к началу 2010-х годов ведущие финансовые организации в целом завершили перевод собственной автоматизации в данном ключе. Сформированный ИТ-ландшафт был, безусловно, намного сложнее, чем представленный на Рисунке 7 пример – в крупных финансовых организациях он включал в свой состав сотни и тысячи информационных систем. Можно отметить, что к этому периоду SOA из революционной практики стала эволюционной с ярко выраженной тенденцией к застою и деградации. В чем же выражалась соответствующая тенденция?
Представим себе ситуацию, что в финансовой организации 200 информационных систем, которые выстроены и взаимодействуют между собой в соответствии с принципами SOA. При этом каждая информационная система предоставляет 10 сервисов, посредством которых ее функционал доступен контрагентам. Как результат, на интеграционной шине представлено 2000 сервисов. Каждая из систем развивается независимо в соответствии с планами владельцев систем (предположим, что владельцами систем в организации являются бизнес-подразделения). Соответственно, команда специалистов, отвечающая за развитие ESB решения, должна поддерживать актуальность всех 2000 сервисов, добавлять новые, обеспечивать корректность функционирования всего комплекса. Не будем забывать, что нередким является случай, при котором потребителями одного сервиса являются несколько информационных систем. В таком случае при развитии соответствующего сервиса необходимо также поддерживать механизмы версионности, а также обеспечивать регрессионное тестирование. Емкость любой команды не является бесконечной величиной. Кроме того, важным является тот факт, что ESB не представляет собой конечной значимой бизнес-функциональности, то есть участие членов команды развития ESB решения в создании бизнес-ценности является опосредованным, что ограничивает возможности масштабирования соответствующей команды. Результатом, как правило, являлось то, что скорость внесения изменений на уровне ESB была существенно ниже, нежели в информационных системах, автоматизирующих прикладной функционал. Особенно заметной разница в скорости внесения изменений была при сравнении ESB с системами дистанционного банковского обслуживания (ДБО), где соответствующая скорость традиционно одна из самых высоких в автоматизации финансового сектора. Автор