За последний год в обсуждении тематики сервисно-ориентированной архитектуры (SOA) произошли разительные перемены. До лета 2007 г. ведущая роль явно принадлежала международным вендорам, которые на своих конференциях рассказывали о теоретических основах этой концепции и убеждали клиентов в ее пользе, в том числе ссылаясь на исследования западных аналитиков. Сами заказчики на мероприятиях преимущественно молча слушали (до вопросов и дискуссий дело часто просто не доходило), но в блогах довольно активно обсуждали услышанное между собой, делая при этом много критических замечаний. Любопытно, что системные интеграторы тогда вообще предпочитали не высказываться по теме ни публично, ни в приватных беседах.
Однако с осени того же года ситуация поменялась: поставщики ПО фактически прекратили свое пропагандистское давление на рынок в этом направлении, но при этом аббревиатура SOА фактически превратилась в общеупотребимый термин. Стало создаваться впечатление, что мы уже оказались в SOA-мире. Правда, одновременно начали расти законные опасения, что на самом деле модная “наклейка” применяется без разбора ко всему, что делается в ИТ-отрасли. Именно на этом фоне сформировалась новая волна интереса к теме, чтобы все же разобраться в ней детальнее.
В целом можно уверенно констатировать, что российский ИТ-рынок к нынешнему моменту уже перестал воспринимать SOA как нечто загадочное и не очень понятное. Его участники хорошо разобрались в теоретических, архитектурных и методических аспектах данной концепции. Но в то же время остается еще немало принципиальных вопросов, в первую очередь со стороны клиентов. Например: насколько реалистичны все эти идеи в их практическом воплощении? в каких случаях стоит брать на вооружение SOA? какие конкретные преимущества от SOA получит не только само предприятие в целом, но и его ИТ-служба? какие препятствия нужно будет преодолеть по дороге к получению эффекта от SOA и как долог будет этот путь?
Чтобы разобраться в этих вопросам, мы провели опрос экспертов, представляющих три основные категории участников рынка: вендоров, интеграторов и заказчиков. В настоящей публикации представлены мнения первых двух категорий, объединенных в группу “поставщики”.
Общая характеристика текущего момента
В целом, по оценкам наших экспертов, как раз сейчас рынок корпоративных систем достиг той критической точки, когда приходит ясное понимание принципов SOA. Время детства уже прошло, но взрослая жизнь еще не началась. В любом случае у всех участников рынка появилось четкое понимание, что SOA — это не какой-то продукт и даже не методология реализации проектов, а целая философия построения современных ИТ-систем.
По мнению Леонида Алтухова, интерес заказчиков к SOA определяется их потребностями в комплексных, законченных решениях, отражающих специфику их бизнеса и быстро приносящих конкурентные преимущества. Это зачастую вызывает необходимость использования продуктов от нескольких вендоров, а также затрагивает уже существующую ИТ-инфраструктуру. Для движения вперед по дороге SOA необходимы усилия всех сторон: вендоров, партнеров и заказчиков. В частности, от заказчиков требуется полное понимание своего бизнеса и желание работать на перспективу, не ожидая сиюминутной отдачи, а от вендоров и интеграторов — высокая квалификация на всех уровнях, понимание задач клиентов и согласование зон ответственности.
В то же время Александр Павлов считает, что в России использование SOA пока очень ограниченно. Это. в частности, объясняется высокой начальной стоимостью таких проектов, отсутствием практики объективной оценки качества и стоимости услуг. Технической проблемой является недостаточный уровень автоматизации и интеграции систем реального времени для предоставления услуг, включая средства управления такими комплексами. По данным г-на Павлова, в последнее время началось выполнение нескольких проектов с использованием SOA, сегодня они находятся на стадии технологического описания и внедрения основных сервисов. Но нужно иметь в виду, что главные трудности возникнут при переходе от проектов к продуктивной эксплуатации, поскольку SOA предполагает непрерывную оптимизацию сервисов на основе анализа результатов их использования.
Но нужно понимать и то, что SOA — это не панацея от всех бед и не цель, а средство ее достижения и получения практических результатов. В то же время сегодня мы можем наблюдать, что без опоры на анализ конкретных примеров использования SOA мощный маркетинговый натиск вендоров не только не срабатывает, но порой дает обратный эффект. На это самокритично делает акцент Дмитрий Мартынов, правда, вместе с тем подчеркивая, что Microsoft до недавних пор вообще не термин SOA, проповедуя сугубо прагматичный подход пошаговой эволюции ИТ-стратегии заказчиков в соответствии с их собственным пониманием развития своего бизнеса и роли ИТ в этом процессе.
Интерес к использованию SOA на развитых ИТ-рынках во многом определяется наличием в компаниях мощной системы средств автоматизации, оперативную модернизацию которой проводить становится все сложнее и сложнее. В этой связи Глеб Ладыженский отмечает, что российские предприятия еще не испытывают подобных проблем в полной мере, поскольку они пока не отягощены большим количеством унаследованных приложений, их информационные системы слабы и разрозненны, а потому ландшафт для выполнения новых проектов в нашей стране вполне благоприятный. Второй момент, не способствующий широкому продвижению SOA в России, — отсутствие долгосрочного планирования развития бизнеса: “Вся страна живет короткими деньгами, короткими проектами и думает короткими мыслями”. А ведь для получения максимальной отдачи от инвестиций в SOA рекомендуется, как утверждают эксперты Gartner, “рассматривать SOA как долгосрочную программную архитектуру и инженерную практику (требующую соответствующих квалифицированных кадров), а не как способ решения текущих проблем ИТ-департаментов”.
Представитель Oracle оценил краткосрочные перспективы SOA в России не очень оптимистично: “В России не происходит и в ближайшем будущем не произойдет ничего такого, что могло бы кардинально повлиять на развитие технологий в принципе. Пока мы находимся на глубокой периферии мирового процесса развития ИТ. Реально значимыми являются лишь те действия, которые крупнейшие российские корпорации осуществляют в части формирования современной компьютерной, телекоммуникационной и программной инфраструктур, опираясь на свои неизмеримо возросшие финансовые возможности. Часть этого процесса — модернизация программных инфраструктур ИС. Там производится масса нерациональных действий, но все-таки малая толика средств расходуется и на достойные цели. Будем рады и этому: если мы хотя бы научимся правильно использовать программные продукты, в которых нашли свое воплощение созданные не нами технологии, — для нашей страны уже это будет большим шагом вперед”.
А вот Aндрей Подвезько считает, что SOA набирает обороты в России, свидетельство чему -- постоянно возрастающий интерес к Web-сервисам. Он также сослался на данные аналитических компаний, но его сведения относятся исключительно к зарубежной практике. В пользу тенденции к использованию SOA в нашей стране говорит растущее число интеграционных проектов, что является первым этапом построения архитектуры на основе сервисов.
Представители компаний-интеграторов говорят, что SOA в корпоративных ИТ-проектах в России начинает применяться, но процесс этот идет не быстро. Высказываются сетования на то, что отечественные заказчики не готовы быть “пионерами инноваций”, поэтому ждут, когда появятся реальные отзывы о выполненных проектах. Но в целом знания в области методологии и технологий и у заказчиков, и у интеграторов значительно углубились, все ведущие вендоры серьезно повысили SOA-готовность своих продуктов, появились вспомогательные решения, упрощающие разработку, развертывание и настройку SOA-архитектур.
Дмитрий Грязнов говорит, что хотя заказчики уже не воспринимают SOA как очередную “маркетинговую затею”, но все же на данный момент уровень понимания SOA как методики и архитектуры с их стороны явно недостаточен. Впрочем, нельзя сказать и того, что интеграторы уже готовы на 100% к работе в этом направлении; эксперт из “Ай-Теко” считает, что они только сейчас поняли, что SOA — это прежде всего интеграция ИТ в бизнес, и перестали ассоциировать архитектуру исключительно со стандартами, технологиями, продуктами и т. д.
В свою очередь, Александр Дубина подчеркивает, что SOA — дело очень дорогостоящее (если хочется истинной SOA, то только за основное ПО нужно выложить 500 тыс. долл.) и очень ресурсоемкое, на десятки человеко-лет. Он считает, что SOA бывает востребована тогда, когда нужна интеграция нескольких крупных систем, имеющих взаимодополняющий функционал и обслуживающих десятки тысяч транзакций в день (банковский сектор, аэропорты и др.).
Павел Болотин высказал мнение, что готовность к SOA со стороны заказчиков во многом определяется уровнем их платежеспособности, который достаточно высок в кредитно-финансовой сфере и телекоме, где уже есть примеры реализации SOA-проектов. В большинстве случаев идет внедрение корпоративных сервисных шин с подключением к ним унаследованных систем. Эти внедрения создают базис для дальнейшего развития SOA на предприятии, поскольку, имея шину, люди начинают задумываться об управлении бизнес-процессами и их оптимизации. В целом SOA сейчас наиболее востребована в тех организациях, где гибкость и скорость реакции на изменения являются ключевыми, а это в основном компании, работающие с конечными потребителями.
Есть ли альтернатива SOA?
Общее мнение экспертов примерно таково: SOA — это один из подходов к созданию корпоративных ИТ-систем. Его актуальность на современном этапе развития бизнеса и ИТ возрастает, но это не значит, что SOA подходит всем заказчикам и что стремиться к ее использованию нужно любой ценой. При этом следует понимать, что SOA появилась не на пустом месте, -- по сути речь идет о реализации на новом качественном уровне давно известных идей модульной архитектуры. Но тут важно подчеркнуть, что если раньше такие понятия, как “модуль”, “компонент ИТ-системы”, были чисто технологическими, то теперь они перешли в категории, находящиеся на стыке ИТ и бизнеса. Новизна ИТ-сервиса как элемента системы заключается не в том, что доступ к нему выполняется по стандартным технологиям, а в том, что он выполняет ту или иную, но законченную бизнес-операцию.
В этом плане Леонид Алтухов напоминает: сервисом может быть как отдельный программный модуль системы, так и огромная система управления предприятием; выявление и формализация таких сервисов – задача очень важная. Но собирая в ходе создания ИТ-систем сервисы в увязывающие их бизнес-процессы, нельзя забывать о поддержке непрерывной работоспособности всей ИТ-экосистемы предприятия.
Правда, обращая внимание на технологический аспект вопроса, Aндрей Подвезько подчеркивает, что раньше создание композитных систем с использованием таких средств, как COM или CORBA, базировалось на тесно связанных моделях взаимодействия компонентов, а применение Web Services реализует принцип слабых связей, что позволяет повысить гибкость и надежность создаваемых систем.
Но говоря о технологиях, нужно все же понимать, что истоки SOA лежат в постоянных усилиях ИТ-сообщества увязать возможности информационных технологий и потребности бизнеса. Причины появления SOA заключаются в высокой динамике современного бизнеса и повышенных требованиях к изменчивости (адаптивности) информационных систем по отношению к этой динамике. Сейчас уже недостаточно, чтобы информационная система обеспечивала простую автоматизацию информационных и расчетных задач бизнеса компании. Необходимо добиться того, чтобы быстро меняющиеся требования бизнеса (которые сами по себе суть следствия обострения конкуренции) находили адекватное отражение в информационной системе. Говоря проще, информационная система должна меняться столь же быстро, сколь быстро меняются требования бизнеса и бизнес-процессы компании.
Глеб Ладыженский отмечает, что информационные системы старой доброй традиционной архитектуры, построенные из набора разнородных программных компонентов и объединяющие унаследованные монолитные приложения с нестандартизированными интерфейсами, консервативны по своей внутренней конструкции, они не могут меняться быстро. SOA — это вариант решения данной проблемы. Но нужно иметь в виду, что как и у всякой парадигмы информационных технологий, у SOA есть множество аспектов, и исчерпывающее определение ее предложить довольно сложно.
По мнению Дмитрия Мартынова, если говорить о новых подходах к созданию корпоративных ИТ-систем, то SOA нужно рассматривать как компонент более общей сервисной идеологии, которая включает возможность использования онлайновых сервисов, Web 2.0, гибридных схем применения ПО, хостинга и аутсорсинга.
Павел Болотин отмечает, что речь идет о новом этапе развития корпоративных ИТ-систем. Раньше основной упор делался на функциональные возможности систем, и здесь лучшим способом было применение монолитных бизнес-систем. Сейчас на первый план выходит возможность повышения гибкости решений. Но вряд ли стоит говорить о том, что SOA полностью заменит монолитные системы. В этом плане он обращает внимание на два момента. Во-первых, слишком много функционала уже наработано в рамках автономных систем, разработка аналогичного по возможностям рынка “сервисов” займет продолжительное время. Во-вторых, есть еще внутренняя (in-house) разработка бизнес-систем, которая позволяет компании до некоторой степени оставаться гибкой, не прибегая к SOA.
Александр Дубина также считает, что традиционные подходы развития ИТ-систем будут и дальше использоваться при внедрении новых автономных прикладных решений. Что же касается интеграционных задач, то во многих случаях вполне достаточно файлового обмена, взаимодействия СУБД и т. д.
Василий Анфиногентов подчеркивает, что если в компании существуют уже давно устоявшиеся бизнес-процессы, которые мало подвержены изменениям, и используются достаточно закрытые для внешнего мира workflow- или ERP-системы, то в данном случае можно ничего и не менять. В основе такой архитектуры будет лежать функциональность, а не процессы, и интеграция скорее всего будет обеспечиваться через общую базу данных. Но если организациям нужно постоянно корректировать свой бизнес, то им следует опираться на динамичную интеграционную среду, и в данном случае лучший вариант — это SOA.
По мнению Дмитрия Грязнова, SOA — это общий путь развития корпоративных ИТ-систем, но при этом он оговорился, что речь идет о компаниях, которые переходят к процессной модели управления бизнесом.
А вот Александр Павлов вспомнил, что одной из миссий SOA является снижение эксплуатационных затрат. В этой связи он высказал мнение, что эффективной альтернативой SOA могут являться консолидированные центры обработки данных с высокой степенью виртуализации и автоматизации управления. В таких центрах качество услуг обеспечивается строгим контролем и избыточностью ИТ-ресурсов; при этом оптимальное управление осуществляется по отлаженным алгоритмам.
Чем отличается SOA-проект от не-SOA?
Этот вопрос возник в связи с тем, что сейчас все чаще приходится слышать о реализции SOA-проектов, но при их ближайшем рассмотрении бывает довольно трудно понять, чем же они отличаются от того, что имело место пять и даже десять лет назад. В целом мнения наших экспертов по этому вопросу совпали далеко не во всем.
Александр Павлов считает, что основным отличием SOA является реализация бизнес-процессов на основе слабо связанных сервисов, которые развиваются независимо друг от друга. При этом должен соблюдаться ряд международных рекомендаций, позволяющих взаимодействовать этим сервисам на разных платформах и соответствовать требованиям потребителей сервисов, их разработчиков и провайдеров, а также аудиторов и регулирующих организаций.
С ним в целом солидарен Aндрей Подвезько: SOA-проект отличается от не-SOA использованием независимых слабо связанных сервисов с четко определенными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу. Сервисы в SOA-проекте представляют собой модули бизнес-логики достаточно высокого уровня.
Дмитрий Грязнов выделил три основных признака SOA-проекта: использование соглашения об уровне сервиса (SLA), метрического инструментария и композитных приложений. Если же проект подразумевает к тому же тарификацию или биллинг сервисов, то это, безусловно, говорит об использовании в проекте SOA.
Александр Дубина сделал акцент на сугубо технологическом моменте: используются ли Web-сервисы на самом деле, или они являются просто дорогостоящей накруткой над стандартными процедурами файлового обмена либо, например, над процедурами ODBC-взаимодействия? Впрочем, он еще раз подчеркнул, что SOA — не самоцель. Для решения многих интеграционных задач нет нужды в технологиях Web Services и вполне можно обойтись гораздо более дешевыми проверенными простыми механизмами.
По мнению Павла Болотина, поскольку сейчас идет первичная стадия внедрения SOA (подгонка под требования SOA унаследованных систем), то в данный момент любое внедрение, включающее в себя использование средств программной инфраструктуры SOA (сервисная шина, портал, BPM), можно считать SOA-проектом. В более жестком определении к SOA нужно относить проекты, где бизнес-логика нескольких систем и сервисов вынесена в отдельное приложение — оркестратор бизнес-процессов.
Василий Анфиногентов считает, что ключевым моментом в оценке типа проекта является понимание того, по какому принципу строится информационная система компании в целом. Если автоматизация идет от одной функциональности к другой в зависимости от типа решаемых задач (как это делается при внедрении различных модулей ERP-систем), то такой проект нельзя назвать сервисно-ориентированным. Настоящий SOA-проект обязательно включает реализацию единых бизнес-процессов, оркестровку сервисов, предполагая как минимум третий уровень зрелости ИТ-архитектуры предприятия. Создание соответствующих Web-сервисов является делом вторичным по отношению к самой концепции SOA.
С точки зрения Леонида Алтухова, однозначные критерии определения SOA-проекта сформулировать сложно, если возможно вообще. Важны не формальные признаки, а восприятие SOA как философии, определенный стиль ведения и разработки проекта. Слепое формальное использование подходов SOA не даст нужного результата и лишь принесет вред организации. Одна из задач SOA —использовать комплексный подход к внедрению, исключающий так называемую “лоскутную автоматизацию”. Раньше для этого предлагалось применять единое комплексное решение от одного вендора, которое покрывало бы все потребности заказчика. SOA подразумевает работу с большим числом приложений от разных поставщиков. Но чтобы избежать “лоскутности”, каждое прикладное решение должно рассматриваться как компонент интегрированной ИТ-системы предприятия.
Дмитрий Мартынов сделал акцент на том, что в первую очередь нужно говорить не о SOA-проектах, а о SOA-стратегии заказчика. Многие клиенты часто делают фатальную ошибку, переводя вопрос реализации SOA в разряд пусть и высокоприоритетного, но проекта, со своим бюджетом, спонсорами и сроками. А начинать надо с создания SOA-стратегии, горизонтально пронизывающей иерархию организации, имеющей поддержку со стороны менеджмента и реализуемой в виде постепенного ввода бизнес-сервисов и их интеграции с унаследованными приложениями.
В то же время есть довольно четкий набор технологических атрибутов, традиционно связываемых с SOA: наличие автономных сервисов, обладающих четкими границами и точками входа; обмен данными на основе передачи сообщений; сами сообщения описываются контрактами. С точки зрения бизнеса SOA-проект должен ассоциироваться с повышением стратегической ценности ИТ для бизнеса, с возможностью быстро вводить в действие новые приложения за счет повторного использования сервисов и с наличием SLA.
Важнейшим аспектом реализации SOA-проекта, по мнению Глеба Ладыженского, является то, что он связан в той или иной мере с модернизацией всей информационной системы компании (а не только отдельных ее элементов наподобие кадровой или финансовой систем). И в этом качестве он требует от руководства железной политической воли, последовательности и систематичности всех действий. Говорить о внедрении SOA в организации в принципе неверно (это ведь совсем не то же самое, что внедрять ERP-системы). Речь идет о долгосрочной модернизации информационной системы компании осмысленными и четко просчитанными порциями, где SOA — это своего рода компас, позволяющий правильно задавать направление модернизации.
Тут эксперт из Oracle опять высказал довольно скептичную оценку ситуации. По его прогнозу, в ближайшее время в России общее количество проектов, претендующих на статус “реализованных в рамках SOA”, будет невелико. Причины — общая неподготовленность большинства ИТ-коллективов к реализации такого рода проектов, отсутствие систематичности и последовательности в работе (так называемые “метания”), слабая проектная культура, недостаток знаний и навыков исполнительского состава и его малочисленность. И в этом плане очень важно, чтобы неквалифицированный подход к реализации SOA не скомпрометировал саму парадигму этой концепции.
Что же касается вопроса о том, как отличить реальный SOA-проект от квази-SOA, то можно сформулировать три критерия истинности SOA-проектов. Первый состоит в том, что реальный проект категории SOA инициируется руководителями бизнеса, видящими в его реализации свой интерес. То есть SOA — это не способ решения насущных задач ИТ-департаментов, а долгосрочная стратегическая инициатива управляющих бизнесом. Второй критерий — горизонт планирования модернизации ИС организации, который должен быть не менее пяти лет. Третий критерий — глубина охвата ИС модернизацией; “переделка” отдельных бизнес-приложений в формате SOA не есть реальный SOA-проект. Проект SOA может считаться реальным только в том случае, если он затрагивает всю информационную систему организации.
Достоинства и недостатки SOA
О преимуществах SOA говорится много. В технологическом плане — это гибкость, многодоменная подчиненность элементов систем, возможность разбивать внедрение систем на конечные реализуемые блоки, повторное использование компонентов. С точки зрения бизнеса — быстрая реакция ИТ на его потребности.
Но тут нужно вспомнить известную истину: новые технологии сами по себе не решают бизнес-проблемы компаний. Чтобы получить реальный эффект от SOA, заказчик должен хорошо понимать суть этой архитектуры, четко представлять себе размер затрат, связанных с ее применением, а также знать свои реальные деловые задачи и возможности. Только после этого, по выражению Леонида Алтухова, можно приниматься за тяжелый труд по выявлению будущих кубиков автоматизации.
Для внедрения SOA надо много работать, анализировать потребности предприятия, определять существующие бизнес-процессы, формализовать новые, выявлять еще не автоматизированные и быть готовым к возможным изменениям в процессах и организационной структуре. Заложив фундамент сервисов и очертив потенциальные зоны для автоматизации, можно двигаться дальше и выбирать участки, на которых будут проведены опытные работы по внедрению SOA. Реальный эффект будет виден по завершении трансформации ИТ-инфраструктуры, когда все ИТ-ресурсы будут определены и упорядочены и из этих “кубиков” будет создана стройная и гибкая ИТ-система, отражающая бизнес предприятия и при необходимости позволяющая безболезненно вынимать один кубик и вставлять другой, уже новый.
Александр Павлов, со своей стороны, отмечает, что при использовании SOA остаются все инфраструктурные проблемы ИТ — ограниченность бюджета развития и технологий, а также и других ресурсов. Например, часто очень важны затраты времени на устранение последствий сбоев, что непосредственно влияет как на качество сервисов, так и на результаты бизнеса. В условиях меняющихся распределенных архитектур задачи обеспечения их надежности и производительности могут стать решающими для успешной реализации SOA-проекта. Не менее актуальная задача -- обеспечение тестирования столь сложного комплекса как на этапе его создания, так и при дальнейших изменениях в процессе эксплуатации.
Дмитрий Мартынов считает, что основная сложность в реализации SOA-проектов лежит не в технологической, а в организационной плоскости. При этом ключевым фактором успеха является постепенность реализации сервисов в четком соответствии с потребностями бизнеса.
Практика использования SOA в ИТ-проектах
Непосредственно перед подготовкой данного обзора, в начале мая мы провели опрос читателей PC Week/RE. Ниже представлены его результаты, но в целом нужно сказать, что наши респонденты продемонстрировали не только понимание проблематики, но и высокий уровень практического опыта в этой сфере. Хотя, конечно, нужно сделать поправку на то, что понятия “SOA” и “SOA-проект” не имеют четкого определения, а потому причисление своего опыта к данной сфере является весьма условным.
Но в любом случае стоит отметить, что большинство (две трети) наших респондентов считают, что SOA — это не просто игра слов, а заслуживающий внимания подход к разработке ИТ-систем.
Глеб Ладыженский также отмечает, что первый фактор, способствующий успеху проектов в категории SOA, — это общая готовность организации к испытаниям, связанным с реализацией данного подхода к архитектуре ИС. Общая честная оценка состояния организации и ее ИТ-ландшафта в преддверии осуществления проекта категории SOA — вот достойная задача для реально практикующих консалтинговых компаний. Второй фактор заключается в очевидном и заинтересованном влиянии руководителей бизнеса на старт и сам процесс реализации проектов в категории SOA.
Заказчику нужно также четко понимать, что SOA должна применяться ко всей информационной системе, а не только к отдельным ее компонентам. В любой организации идея обобществления неизбежно наталкивается на скрытый саботаж руководителей подразделений, не желающих “делиться” информацией, услугами, кадрами и т. д. И в этом смысле проект SOA требует от руководства политической воли и изощренности мышления, последовательности и систематичности всех действий. Еще один объективный момент, негативно влияющий на применимость SOA, — это серьезный кризис кадрового обеспечения инфраструктурных проектов (к которым относятся и проекты категории SOA). По своей сути и специфике задействованного ПО такие проекты требуют определенного числа специалистов очень высокой квалификации, обладающих отработанными методологиями ведения проектов и высокой проектной культурой. По мнению г-на Ладыженского, таких коллективов не много и портфель их заказов полон, а новых квалифицированных специалистов брать неоткуда.
Aндрей Подвезько считает, что одна из главных проблем SOA-проектов — непоследовательное и неполное применение принципов SOA на практике. Предпосылками успешной реализации внедрения SOA являются: качественный анализ бизнес-процессов, продуманная проектная организация и планирование, внедрение концепции бизнес-сервисов, осмысленный выбор интегратора, поддержка высшего руководства, наличие бюджета. Грамотное применение SOA обеспечивает большую гибкость, быстрое внедрение и невысокую стоимость развития и интеграции бизнес-приложений. Но по сравнению с традиционной “монолитной” или клиент-серверной архитектурой SOA требует более внимательного проектирования, часто с применением дополнительного, так называемого “промежуточного” слоя. Тестирование, отладка, поддержка и обеспечение надежности и безопасности SOA-систем — все это сложные и довольно затратные процессы. Однако все вышеперечисленные задачи являются первостепенными для успешного внедрения SOA.
Дмитрий Грязнов еще раз подчеркнул, что основное преимущество SOA-проектов -- использование инновационной архитектуры, способствующей повышению эффективности и конкурентоспособности бизнеса заказчиков. Проблемы же заключаются в создании и поддержании соответствующего уровня экспертизы.
Павел Болотин, говоря о трудностях продвижения SOA, обратил внимание на высокую стоимость технологий, небольшой опыт внедрения на рынке и острый дефицит грамотных специалистов. Заказчику нужно понимать, что в SOA-проектах у него не получится “отсидеться” в стороне, ожидая, пока консультанты сделают свое дело. Дело не сдвинется с места, если со стороны клиента не будут выделены адекватные специалисты, бюджет на обучение и не будет поддержки на всех уровнях управления. Необходимое условие успешной реализации SOA-проектов – наличие координационного центра и архитектурного комитета, осуществляющих организационный и технический контроль за ходом реализации группы проектов.
Василий Анфиногентов отметил, что SOA в ее технологическом аспекте требует определенной переработки существующих приложений (создания адаптеров) и следования вполне определенным, порой жестким, требованиям при проектировании новых приложений. Если этим требованиям следуют, то решение вопросов интеграции, оркестровки становится легче во много раз по сравнению со стандартными подходами. При этом влияние технологической составляющей уменьшается по мере движения от отдельных функций к реализации бизнес-процессов. Организационная модель компании в этом случае следует за иерархией бизнес-процессов и их оркестровкой.
Соображения напоследок
В заключение стоит привести некоторые мнения наших экспертов, подводящие черту под данным обсуждением.
Дмитрий Грязнов: “SOA — это не решение, а методика трансформации ресурсной модели функционирования ИТ-подразделения в сервисную модель”.
Василий Анфиногентов: “SOA в принципе наиболее удобна там, где используется процессный подход к управлению. Но и организациям с чисто функциональным построением SOA может принести существенную пользу при создании информационных систем, хотя для таких предприятий наиболее оптимальным будет подход “от сервисов — снизу вверх”, а для проектно-ориентированных, напротив, “от процессов — сверху вниз”. В любом случая для эффективного использования SOA и бизнес-процессы, и ИТ-инфраструктура должны быть зрелыми. Желательно, чтобы 90% операций в какой-то степени были автоматизированы. Должна быть возможность четкого отслеживания протекания процессов, чтобы управлять ими оперативно и так же быстро реализовывать их в информационных системах. Для большинства российских предприятий это, к сожалению, пока невозможно — не хватает уровня зрелости управления организацией”.
Глеб Ладыженский: “Говоря о взаимосвязи SOA с ранее известными интеграционными подходами (например, с Enterprise Application Integration, EAI), нужно отметить, что здесь есть преемственность в смысле программной инфраструктуры, но нет преемственности в плане методологии. При этом SOA не отменяет востребованность той же EAI со стороны клиентов, а лишь предоставляет им новый путь решения их проблем. Но не нужно думать, что если люди выбрали вариант традиционной интеграции, то они потом смогут легко переключиться на SOA. В смысле утилизации унаследованной программной инфраструктуры — да, смогут, но при этом потребуется существенная модернизация программной инфраструктуры и полный цикл работы с бизнес-процессами. Не лучше ли сразу начать с SOA/BPM?”
Нетрудно заметить, что все эти высказывания адресованы заказчикам. Любопытно узнать, что те сами думают по поводу SOA.
Результаты исследования AMR Researсh
В конце 2007 г. компания AMR Research опубликовала результаты исследования под названием “SOA: состояние рынка”. Этот отчет начинается с констатации того факта, что сегодня не существует общепризнанного определения SOA, поэтому оценка состояния рынка и прогноз его развития носят довольно условный характер. По мнению экспертов AMR, SOA не является какой-то отдельной продуктовой или сервисной категорией, а представляет собой подход к выполнению ИТ-проектов с использованием ранее существовавших и вновь созданных технологий и услуг. Фактически сегодня SOA в технологическом плане больше ассоциируется с интеграционными платформами различных вендоров, а также с такими технологиями, как Web 2.0, управление бизнес-процессами (Business Process Management, BPM) и интеграция корпоративных приложений (Enterprise Application Integration, EAI). Именно в таком контексте имеет смысл говорить о каких-то долях рынка.
Осенью 2007-го AMR провела в США опрос корпоративных заказчиков относительно использования ими интеграционных платформ различных поставщиков (см. рисунок). Но тут нужно подчеркнуть, что если SOA — это почти всегда интеграция, то интеграция — далеко не всегда (а может быть, сейчас — в основном не всегда) SOA. Не говоря уже о том, что такие средства, как Microsoft .NET и IBM WebSphere, используются не только для интеграции, но чаще всего в качестве платформы приложения. В этом плане полученные результаты скорее отражают не столько текущую расстановку сил на рынке SOA, сколько потенциальные возможности.
Так или иначе, но данные AMR однозначно говорят о том, что ключевая роль в SOA-технологиях принадлежит группе ведущих мегавендоров (Microsoft, IBM, SAP и Oracle), которая не только предлагает широкий набор технологий и продуктов, но активно продвигает на рынок идеи SOA, используя свое влияние на ИТ-сообщество. Такие известные поставщики интеграционных средств, как BEA, Progress Software, Software AG и TIBCO, также имеют представительные наборы решений, но все же уступают по уровню присутствия на рынке “большой четверке”. Есть также группа нишевых игроков, таких как Cape Clear и Amberpoint, изначально нацеленных на концепцию SOA и предлагающих специализированные продукты, которые отсутствуют в пакетах глобальных поставщиков.
По мнению AMR, 2008 г. станет переломным для продвижения идей SOA в том плане, что эти подходы к реализации ИТ-проектов начнут широко применяться в конкретных проектах заказчиков. Существенно усилятся позиции на этом рынке SAP и Oracle, которые уже сформировали хорошие наборы продуктов связующего слоя.
