Секреты СОА: как получить реальную отдачу
В последнее время многие компании всерьез увлеклись идеей сервис-ориентированной архитектуры (СОА) и вложили в ее осуществление немало средств и усилий. СОА становится все более популярным подходом для построения новых корпоративных систем. К этой концепции более или менее привыкли, она теперь понятна широкому кругу руководителей, и ее разработка не представляет особой сложности для программистов, но, тем не менее, не все так просто. Вопрос о правильном использовании СОА остается открытым, а тема целесообразности и своевременности ее применения - актуальной.
Если точно так же в рамках большой корпорации СОА начнет развиваться в нескольких независимых подразделениях, интеграция частей должна пройти сравнительно безболезненно. Это не означает, конечно, что при создании ИС на базе СОА не страшны любые архитектурные ошибки. Просто цена этих в чем-то неизбежных ошибок не может быть непомерной. СОА не должна требовать сначала спроектировать всю систему "от и до" и только потом переходить к ее реализации, она должна поддерживать принцип "последовательного приближения" к результату. На границе двух систем нестыкующиеся сервисы необходимо отбросить и заменить "конформными". Именно для этого сервисы должны быть достаточно "легковесными".
Следствием этого должна стать инвариантность структуры СОА к очередности ее реализации. И это своеобразный плюс. Ведь бизнес очень плохо относится к просьбам о многомиллионных бюджетах, результатом освоения которых будет просто "новая технология, которая потом решит все проблемы". И наоборот, если практический результат будет заметен достаточно быстро, то сама по себе технология для бизнеса не так уж и важна.
Все рецепты и подходы к построению СОА требуют практической апробации
Принцип "последовательного приближения" означает, что для СОА подходит и, более того, необходима итерационная модель разработки. При этом должна быть предоставлена возможность достаточно быстро получить работающий прототип сервиса, апробировать его, сделать необходимые уточнения и повторить цикл разработки несколько раз. Принцип RAD (Rapid Applications Development) должен сработать на двух уровнях. Сначала быстрое итерационное прототипирование сервиса, затем также итерационное встраивание сервиса в существующую архитектуру сервисов и, главное, в существующие бизнес-процессы с непременным участием пользователей.
И, наверное, снова стоит воспользоваться определением от противного. Итерационная модель разработки – наиболее эффективная в настоящее время модель – должна срабатывать для СОА, иначе СОА будет не в состоянии продемонстрировать декларируемую здесь эффективность.
Организация разработки
Вернемся к вопросу о том, как организовать разработку, а точнее сказать, жизненный цикл ИС на принципах СОА. Понятно, что вопрос выбора разработчика сервиса должен перестать быть настолько принципиальным, как сейчас. Необходимо иметь возможность разрабатывать сервисы самостоятельно, заказывать на стороне или покупать готовые. Вместо переделки сервиса, если это по какой-то причине затруднено, должна производиться его замена.
Более важен вопрос, кто будет производить оркестровку сервисов. Эта задача должна быть по плечу самому предприятию – именно предприятие является единственным владельцем своих неповторимых бизнес-процессов. Но можно и ее передать подрядчику, главное – не тому же самому, кто производит сервисы.
Интересы разработчика сервисов и интегратора системы могут противоречить друг другу. При этом надо понимать, что от такого интегратора будет кардинально зависеть бизнес и придется выстраивать с ним политику долговременного сотрудничества.
Полностью же избавиться от заботы о своих информационных ресурсах предприятию не удастся, даже если будет реализована модель СОА и вся поддержка ИС будет отдана на аутсорсинг. Бизнес-процессы – это все-таки неотъемлемая часть самого бизнеса.
Пора ли заниматься СОА?
Когда заказчик ИС хочет принять для себя решение, стоит и пора ли ему заниматься СОА, он видит вокруг себя довольно противоречивую картину. Ключевые поставщики заявляют, что необходимые инструментарий и инфраструктура уже есть, можно брать и пользоваться. В условиях жесткой конкуренции все крупные игроки готовы продемонстрировать "джентльменский набор" для СОА. Кто-то говорит, что СОА уже "внутри его продуктов". Проверить это тяжело, однако странно было бы ожидать от поставщиков иной позиции.
Если заглянуть в копилку открытого ПО, то понятно, что многие стандарты находятся в развитии, а релизы кода идут один за другим. При этом зачастую с серьезной ревизией ранее принятых решений. Здесь проблемы не замалчиваются, и становится понятно, что объективные трудности еще существуют.
Есть крупные компании, заявляющие, что они уже давно используют ту или иную технологию и в полной мере смогли реализовать ее преимущества. Но учитывая, что подобные заявления призваны увеличивать капитализацию этих компаний, сказать, что на самом деле творится за высокими корпоративными заборами, затруднительно.
Есть опросы ИТ-специалистов, которые в большинстве своем свидетельствуют о том, что в более или менее отдаленной перспективе они все-таки собираются использовать СОА и не поставили на ней крест. Но также понятно и то, что эпоха массового применения СОА еще не наступила. Есть большой хор скептиков, саркастически объявляющих СОА очередной модой, которая вот-вот пройдет и будет заменена чем-то другим.
Все это так, но хочется заметить скептикам, что СОА не связана мертво с какой-то технологией, чтобы умереть вместе с ней. СОА определяется скорее результатом, который должен быть получен, а не набором методик его достижения. Это набор принципов, которые выглядят достаточно логично и последовательно, но реализация которых на практике – весьма нетривиальная задача.
Рецепты и подходы к построению СОА, декларируемые в том числе и в этом материале, - вещь не бесспорная. Они требуют практической апробации. Единственный способ проверить их правильность – заняться разработкой ИС на принципах СОА с теми инструментами, которые существуют сегодня, и, может быть, понять их ограниченность. Те, кто хочет получить новое качество ИС, не смогут оказаться в стороне от этого процесса. Времени с момента появления термина СОА прошло достаточно много и альтернативы в лице другой столь же фундаментальной парадигмы развития информационных систем пока просто не появилось.
Короткая ссылка на материал: //cnews.ru/link/a2552
