О внедрении SOA в «Национальной логистической компании» (НЛК) мы уже писали в IE, № 3/2008. На этот раз Максим Штенцов, заместитель директора ИТ-отдела по развитию, согласился рассказать нам о том, как в НЛК решаются проблемы и преодолеваются заблуждения, обычно возникающие на пути внедрения SOA.
Intelligent Enterprise: Считается, что SOA требует больших инвестиций при том, что результат явно не виден и растягивается на годы. Поэтому у бизнеса, особенно сейчас, могут возникнуть серьезные сомнения в целесообразности использования такой архитектуры. Каков был опыт в вашем случае и какие рекомендации по взаимодействию с бизнесом вы могли бы дать ИТ-директору, считающему, что SOA использовать необходимо?
Максим Штенцов: Я считаю, что отдельного согласования применения SOA с бизнесом не требуется. Это идеология и принципы, которые входят в сферу ответственности ИТ‑департамента.
Рекомендую поступательное движение в этом вопросе: на начальном этапе можно собственными силами проанализировать небольшой автоматизированный бизнес-процесс, нарезать его на модули, посмотреть, какими сервисами его целесообразно представить. Это не займет много времени, но позволит погрузиться в тематику SOA.
Поскольку SOA — это прежде всего принципы, то для следования им не требуется начинать с огромных бюджетов. Если вы собрались похудеть, вовсе не обязательно покупать карту в самый дорогой фитнес-клуб — можно просто меньше есть и больше двигаться.
На текущий момент в большинство сред разработки и языков программирования уже входят компоненты для создания и вызова Web‑сервисов. Вам не надо покупать что‑то дополнительное к используемому у вас инструментарию разработки — скажем, Delphi или Visual Studio. Например, весьма популярные в России продукты «1С» в последних версиях позволяют вызывать внутренние функции посредством Web‑сервиса. Конечно, кроме всего этого вам потребуется связующее звено, а именно — программный продукт класса ESB. Нет проблем и с этим, на рынке представлены решения среди ПО с открытым кодом, например Mule (http://mule.mulesource.org/). Если постараться, можно найти уже имеющийся в компании сервер, который справится с функционированием этого лёгкого ESB-решения, а в качестве ОС использовать Linux.
Такой «нулевой» по затратам вариант, разумеется, не подойдёт крупным корпорациям, которым необходимо интегрировать сотни приложений, выдерживать жёсткие временные рамки выполнения проектов и которые предъявляют повышенные требования к отказоустойчивости и масштабируемости решений. Но по крайней мере ИТ-руководители малого и среднего бизнеса должны понимать, что стоимость входного билета в мир SOA начинается по сути с нуля. Главное — желание двигаться в данном направлении.
Даже если вы хотите использовать платные продукты, можно начать с минимальными затратами. Так, например, если рассчитать цены на сайте одного из поставщиков решений, то по минимальным объёмам лицензирования за сервер приложений и BPEL‑сервер вам придется отдать примерно двадцать тысяч долларов. Не думаю, что это неподъемная сумма для ИТ-бюджета.
В дальнейшем при решении новых задач потребуются небольшие денежные и временные ресурсы, чтобы разработчики двигались в этом направлении, применяли принципы SOA. И в итоге если вы следовали принципам SOA, эффективность решения проявится сама по себе. Вот тогда с этим наглядным результатом стоит идти к руководству компании и просить инвестиции на обучение и более масштабное внедрение SOA. Если же вы не увидели результата, то, наверное, SOA вам действительно не нужна — не прошла проверки жизнью.
Расскажите, насколько вам удалось продвинуться на пути создания SOA. Каков сейчас масштаб решения?
В сторону SOA мы стали двигаться более года назад. Всё началось с того, что пришли к необходимости заменить интеграционное решение «точка — точка» на более эффективное промышленное. А поскольку для интеграции приложений принципы SOA подходят как нельзя лучше, на них мы и решили опираться. На текущий момент через решение проходит порядка пятисот транзакций в день, проектом охвачено пять бизнес-приложений и семь клиентских систем. Реализовано пятьдесят технологических сервисов и шесть адаптеров.
С нашей стороны в проекте задействовано около десяти сотрудников — как программистов, так и аналитиков. Кроме того, для его реализации привлечено несколько внешних подрядчиков — системных интеграторов.
Хотя термину SOA уже много лет, споры о том, что это такое и как правильно применять эти принципы, до сих пор не прекращаются…
Да, на практике такая неопределенность мешает: в команде нет единого понимания, к чему мы движемся, что строим. Поэтому понимание принципов SOA в проекте или в компании нужно как‑то зафиксировать — создать что‑то вроде глоссария терминов. Это позволит при привлечении новых участников, как внутренних, так и внешних, быстрее находить общий язык. А поскольку SOA — это идея, ее внедрение невозможно без идеолога, лидера, который продвигает данные принципы в компании, и неважно, сотрудник это ИТ‑департамента или нет. Основная проблема — согласованность форматов и моделей данных. Если говорить про технологическую оснастку, то в настоящий момент существуют общепризнанные стандарты XML, SOAP и многие другие, и здесь, наверное, проблем уже нет. Что же касается моделей данных в самих бизнес-приложениях, тут, конечно, пока еще «вакуум». И несмотря на заявления поставщиков ПО о SOA‑совместимости и о том, что осталось только из кирпичиков собрать нужное здание, по факту оказывается, что готовых сервисов в бизнес-приложениях еще крайне мало.
Хотел бы добавить, что при выборе нового ПО сейчас уже, пожалуй, стоит обращать внимание на его совместимость с принципами SOA. Безусловно, стоимость и функциональность при выборе остаются на первом месте. Но я верю, что SOA в долгосрочной перспективе позволит снизить издержки и даст возможность гибко восполнять недостающую функциональность текущих решений.
В нашем случае удалось найти устоявшиеся модели данных, используемые в мировой практике компаниями для обмена сообщениями в части логистики. Таким образом, используя канонический формат данных, мы немного сэкономили время, взяв уже готовую модель, достаточно на наш взгляд удачную. Я бы советовал не усложнять модель при проектировании. Безусловно, желание привнести всю различную специфику в некую единую модель данных существует, но надо держать себя в руках, потому что лаконичность данных, используемых при вызове веб‑сервисов, в дальнейшем снимет некоторые проблемы развития и производительности, а также поможет избежать некоторых других проблем.
Помимо этого мне кажется важным при реализации SOA прибегать к возможностям приложений: если там уже лежит какая‑то логика исполнения, то лучше ее использовать. Попытки вынести на уровень интеграционной платформы логику исполнения, дублирующую то, что уже есть в приложениях, по‑моему, неэффективны.
Часто приходится слышать о том, что для построения SOA не хватает квалифицированных кадров. Где их взять?
Отсутствие квалифицированных кадров для SOA-проектов не уникально, это вообще проблема ИТ-индустрии. Акцент хотелось бы сделать на том, что внутри компании надо обязательно иметь архитектора SOA. Причём эту компетенцию нужно сохранять длительное время — ведь проект не закончится через год, будет новый проект, интеграция с новым приложением, будут меняться бизнес-процессы. Так что желательно иметь человека, который мог бы закрепить в компании единый стиль построения SOA. Разработчиков и аналитиков найти проще, хотя бы внешних. Мы работаем с несколькими подрядчиками, и принципы модульности и слабосвязанности позволяют делать это и снять остроту отсутствия квалифицированных разработчиков. Если говорить о внутренних кадрах, то я на собственном опыте убедился, что программисты не имеют ничего против SOA. Принципы модульности, гибкости, повторного использования давно применяются разработчиками, поэтому на нашей практике специалисту достаточно двух недель, чтобы влиться в проект. И с этой точки зрения лучше останавливать выбор на достаточно распространенной платформе, для которой уже есть наработки, примеры использования.
В комплексной системе, когда возникает много объектов, теряется контроль над их появлением, использованием, актуальностью. Как упорядочить сервисы?
Со временем становится необходимо вести реестр сервисов. Он не обязательно должен быть автоматизирован согласно UDDI, потому что на текущий момент такая автоматизация, на мой взгляд, громоздка и не дает реальной отдачи. Вполне достаточно вести его в Excel, лишь бы он был актуален и обновлялся. Актуальность можно обеспечить регулярным аудитом, кроме идентификации сервисов. Заодно стоит выяснять — а нужны ли они?
Потому что по мере продвижения проекта SOA возникает понимание, чтó было сделано не так, что хотелось бы улучшить, а чтó оказалось лишним. Еще такой совет: не нужно создавать слишком много сервисов, потому что стремление всё перевести на веб‑сервисы может привести к печальным результатам. Когда любая, даже единичная операция у вас представлена веб‑сервисом — такое большое их количество будет тяжело контролировать, их надо укрупнять.
Надо следить и за версионностью отдельных сервисов, потому что хоть вендоры и заявляют о возможности замены приложений без изменения интерфейса, на моей практике это не так: если меняется приложение — зачастую меняется и сервис, отображающий доступ к нему.
Еще одно распространенное возражение против использования SOA — потеря производительности. Насколько XML и веб-технологии в реальной жизни справляются с объемами данных?
Во-первых, технологии нужно использовать по назначению. Если издержки XML-обработки или веб‑сервисов неприемлемы, то можно взять любой другой инструментарий — это не нарушает принципов SOA, тут всего лишь нужны другие технологии. Наше решение не потребовало больших вычислительных ресурсов и базируется на серверах начального уровня. Соответственно совсем недорого создать двукратный запас мощности по памяти, по процессорам, чтобы выйти из зоны риска. Во многие платформы заложены механизмы управления и разнесения нагрузки. Настроить это не так просто, но по мере приближения к порогу производительности этим можно воспользоваться.
И безусловно не стоит забывать оптимизировать логику — как в выделении сервисов, так и в исполнении конкретных бизнес-процессов. Это дает самый большой эффект при решении задач производительности.
А что можно сказать о надежности SOA-решений?
Конечно, принцип модульности увеличивает количество взаимосвязей в системе. Более того, какой‑то сервис может быть вам неподконтролен, находиться во внешней среде. Поэтому точек отказа много. Мне кажется, единственное правильное решение — усилить тестирование, запланировать тестовую среду, учитывая, что одновременно будет идти разработка разных компонентов и потребуется поддерживать несколько тестовых сред. В тестовой среде должна находиться не только сама платформа, но и все связанные бизнес-приложения, чтобы можно было убедиться, что всё будет работать правильно. Для снижения издержек на оборудование мы используем технологию виртуализации.
На текущем этапе мы уже поняли, что дальше не можем обходиться без автоматизированного тестирования. Ручное тестирование уже сейчас может занимать больше времени, чем требуется на разработку. Поэтому по возможности стоит сразу планировать переход к автоматизированному тестированию.
Разумеется, нужно определить процедуру внесения изменений. Особенно если вы используете несколько внешних подрядчиков: она должна согласовывать возникающие между ними вопросы, отражать версионный контроль. Я бы вообще сказал, что при построении SOA возникают повышенные требования к ИТ-разработке, потому что надо более качественно документировать, тестировать и управлять изменениями.
Сейчас платформы изжили детские болезни, но без квалифицированной поддержки можно в одночасье потерять все результаты. Мы первое время опирались на службу поддержки нашего подрядчика, создание собственной компетенции заняло несколько месяцев.
И еще один совет: выделите модуль обработки ошибок для перевода их на понятный людям язык и уведомления ответственных лиц. По нашему опыту количество логических ошибок типа «документ в неверном статусе» на порядок превышает технические сбои платформы, и такой сервис уведомления бизнес-пользователей позволит решать проблемы без участия ИТ‑специалистов.
Альтернативный вариант интеграционного проекта
Александр Хлуденев
Руководитель направления системных решений компании КРОКСегодня в условиях сокращения ИТ-бюджетов к каждому проекту по развитию и модернизации ИТ-инфраструктуры стоит подходить максимально взвешенно и выбирать решения, позволяющие получить максимальный эффект при минимальных затратах. И интеграционные проекты здесь не исключение. Часто выбор соответствующего решения делается в пользу объединения приложений на уровне разработки интеграционной логики. Такой подход позволяет избежать расходов на лицензирование интеграционной платформы и дополнительных временных и финансовых затрат на создание интеграционной инфраструктуры. Но надо учитывать, что поддержка и развитие соответствующих продуктов требует больших вложений по сравнению с применением интеграционной платформы, поскольку возникает необходимость низкоуровневого кодирования интеграционной логики, создания средств диагностики и мониторинга работы решения, управления распределенными транзакциями. То есть реализации всех тех функций, которыми обладает зрелое интеграционное решение.
Альтернативным и более надежным вариантом интеграционного проекта является использование свободно распространяемого ПО. Оно имеет те же функциональные возможности, что и продукты основных производителей интеграционных решений, и может служить в качестве инфраструктуры для их построения. Последующее развитие интеграционных решений можно осуществлять путём их перевода на промышленное ПО для обеспечения требуемых показателей производительности, масштабируемости и надежности.
