Наверх

Музыка ожившей архитектуры

Время чтения: 15 минут
0
Музыка ожившей архитектуры

Журналы, конференции и пресс-релизы пестрят аббревиатурой SOA. Без этого термина не обходится сегодня практически ни один специалист, когда рассуждает о доктрине развития корпоративных инфокоммуникационных ресурсов. Однако есть и скептики.

Иннокентий Бутт

Журналы, конференции и пресс-релизы пестрят аббревиатурой SOA. Без этого термина не обходится сегодня практически ни один специалист, когда рассуждает о доктрине развития корпоративных инфокоммуникационных ресурсов. Однако многие скептики упрямо твердят про то, что SOA – это еще один яркий пример маркетинговой пропаганды, пустышка, призванная завлечь клиентов и выкачать их бюджеты на очередную технологическую химеру. Они указывают на то, что главные принципы, провозглашаемые адептами SOA вовсе не оригинальны, анонсировать их как нечто новое просто несерьезно и уж если на то пошло, тезис «объединить услуги и технологии для блага пользователя, вместо того, чтобы заставлять его выживать в «зоопарке» гетерогенных продуктов» является совершенно избитым трюком рекламщиков, на все лады повторяющим его последние лет двадцать. Что ж, попробуем разобраться, чья оценка ближе к действительности.

Что такое SOA?

SOA (Service Oriented Architecture, Сервис-ориентированная архитектура, далее СОА) – термин, который многих может запутать и смутить, поскольку он часто используется для обозначения двух разных понятий. Первые два слова – сервис-ориентированная обозначают методику разработки программного обеспечения. Третье слово – архитектура – обозначает общую картину всех средств программного обеспечения в компании, подобно чертежу архитектора, который объединяет в себе все части здания. Таким образом, сервис-ориентированная архитектура – это стратегия построения всех средств ПО в компании с использованием сервис-ориентированной методики.

Что такое сервисы?

Сервисы – это компоненты ПО, построенные таким образом, чтобы они могли легко объединяться с другими компонентами. Идея сервисов очень проста: у бизнес-работников должна быть возможность работать с такими продуктами, которые им легко освоить и понять (вместо запутанных, сложных приложений вроде CRM или ERP).

Концепция сервисов заключается в том, что всю совокупность средств ПО следует объединить в некий продукт, который можно будет затем использовать в различных областях деятельности компании. Например, есть много средств ПО, обеспечивающих автоматическое выполнение разных задач, в частности в банках - отправление запроса на вебсайт кредитного агентства для получения отчета о кредитоспособности клиента. Но если программисты в банке объединят все средства ПО в один продукт под названием «определение кредитоспособности», его можно будет легко использовать в дальнейшем, например, когда банк решит выпустить новый программный продукт по кредитной информации. Работу не придется начинать с нуля – основа продукта уже заложена.

Для объединения программ разработчики создают сложный интерфейс, включающий совокупность средств ПО. Интерфейс описывает работу продукта и способ связи с ним. Эта идея далеко не нова – впервые она появилась в 1980-е, когда возникла концепция объектно-ориентированного программирования. Единственное отличие заключается в том, что современные средства ПО, разумеется, существенно сложнее и объемнее.

Есть много способов связи между сервисами, например интегрирующее ПО от поставщиков, но с 2001 года одним из самых популярных методов объединения компонентов ПО стали так называемые веб-сервисы, построенные на вездесущей Всемирной Паутине.

В чем разница между СОА и веб-сервисами?

СОА – это глобальная стратегия построения приложений ПО внутри компании, нечто вроде архитектурного проекта здания. Разница состоит в том, что в строительстве и архитектуре возможны самые разные направления и техники, а в основе СОА всегда лежит единый принцип – сервис-ориентированное программирование. Веб-сервисы же – это набор стандартных механизмов коммуникации, построенных на основе Сети. Итак, веб-сервисы – это методика связывания и коммуникации, тогда как СОА – масштабная стратегия информационных технологий.

Нужна ли лично мне СОА как стратегия?

Поскольку СОА – это архитектурная стратегия, она включает в себя намного больше, чем просто построение и введение программного обеспечения. Создание архитектуры, основанной на совокупности сервисов, предполагает целый ряд действий и решений, принятых CIO. Во-первых, CIO должен создать централизованный штат менеджеров проекта, архитекторов и разработчиков. Во-вторых, создать централизованную методологию разработки. Кроме того, необходимо, чтобы CEO и менеджеры среднего звена поддерживали инициативу IT департамента и способствовали продвижению проекта, его внедрению в бизнес процессы компании.  СОА-трансформация бизнеса невозможна без принятия всех перечисленных выше мер.

Жизненное значения для сервис ориентированной архитектуры имеют вопросы, связанные с управлением. Для того чтобы сервисы могли быть многократно использованы в разных отделах компании, необходима единая централизованная методология  разработки ПО. Тогда департаменты компании не будут разрабатывать дважды одинаковые сервисы, дублирующие друг друга. Также требуется некий единый центр хранения, база агрегации сервисов. При наличии подобной базы разработчики будут знать, куда им обращаться за сервисами, а департамент IT будет постоянно в курсе, кто эти сервисы использует. Сервисы должны быть снабжены полной документацией, так чтобы разработчики понимали, для чего нужен тот или иной сервис, как с ним следует обращаться и как объединить его с другими продуктами. Некоторые компании взимают определенную плату за пользование сервисами. Кроме того, нужно постоянно следить за тем, что сервисы эффективно работают и не перегружают корпоративную сеть.

Большинство компаний, чей опыт работы с СОА оказался удачным, создавали особую группу архитекторов. Эта группа занимается прежде всего консультированием разных отделов компании по вопросам, связанным с разработкой новых сервисов. Кроме того, она также создает подходящий для данной компании механизм управления и контроля. Все запросы по сервисам неминуемо проходят через эту группу. Таким образом, управление и взаимодействие разработки сервисов и проектов протекает заметно легче и проще.

Следует помнить о том, что внедрение СОА чаще всего оказывается наиболее успешным в тех компаниях, которые в целом эффективнее других работают с новыми технологиями. Это большие компании с большим бюджетом, выделенным на IT, чей бизнес основан на технологиях (прежде всего, это конечно, телекоммуникации). Бизнес руководители, хорошо разбирающиеся в технологиях и открытые для новых решений, - также всегда очень важный фактор для  успешного внедрения СОА. Если компания не обладает перечисленными выше свойствами, может статься, что СОА для нее окажется вовсе не такой уж панацеей.

Внедрение СОА - решение совсем не очевидное для небольших компаний, а также для компаний, в которых уже есть стратегии интеграции приложений и которые уже изрядно потратились на интегрированные пакеты приложений. CIО в таких случаях следует вводить сервис-ориентированную архитектуру очень осторожно, так как необходимо скоординировать работу сервисов и уже имеющихся стратегий и приложений. Если сервисы будут работать независимо, без взаимодействия с уже внедренными технологиями, очень маловероятно, что они смогут быть эффективно использованы в разных отделах компании, что в идеале должно быть главным преимуществом СОА. При плохой координации внутри компании проект введения СОА вообще может ожидать полный провал.

В чем преимущества СОА?

Прежде всего, следует осознать, что выгоды, которые способна принести сервис-ориентированная архитектура, необходимо рассматривать в перспективе. СОА – это меч, способный разрубить «гордиев узел» сложной, запутанной и избыточной структуры ПО в вашей компании. Но если ваша компания не испытывает подобных затруднений, если она небольшая по размеру и просто устроена, весьма маловероятно, что СОА сможет принести вам ощутимую прибыль. Сейчас за мощной рекламной кампанией стали упускать из вида тот факт, что сама по себе методика СОА не способна принести прибыль. Выгоду приносит лишь эффект интеграции внутри сложной, запутанной инфраструктуры. Известно, что на разработку хорошего сервис-ориентированного приложения приходится затрачивать времени и усилий намного больше, чем на традиционное интегрирующее ПО. Таким образом, разработка СОА требует дополнительных затрат по сравнению с другими методиками интеграции. Следовательно, очевидно, что, для того чтобы она могла приносить прибыль, она должна в дальнейшем каким-то образом эти затраты восполнять. Это происходит прежде всего за счет устранения «лишних» продуктов, т.е. тех, для которых в компании есть аналоги, тех, чьи возможности полностью не используются. Поэтому, прежде чем принимать к рассмотрению проект внедрения СОА, необходимо выяснить, есть ли в вашей компании избыточные, дублирующие друг друга продукты, средства ПО, нуждающиеся в интеграции. Если ваш ответ утвердительный – значит, сервис-ориентитрованная архитектура, в принципе, способна принести вам реальную прибыль.

Чтобы получить полное представление о преимуществах, которые вам дает сервис-ориентированная архитектура, следует рассмотреть проблему в двух аспектах: во-первых, тактические достоинства сервис-ориентированных приложений; и, во-вторых, выгоду, которую способна принести СОА в качестве глобальной стратегии.

Преимущества сервис-ориентированных приложений

                   1. Основное преимущество сервис-ориентированных приложений – это, прежде всего, многократное использование средств программного обеспечения. Если сервис был правильно разработан, им удобно пользоваться и его легко связать с другими компонентами, он может быть не один раз задействован командой разработчиков для создания новых приложений. Сервисы с самого начала разрабатываются с тем расчетом, что они будут связаны с другими компонентами, использованы в разных приложениях и для самого широкого спектра задач. Поэтому разработчикам не нужно ломать голову, пытаясь связать один продукт с другим, закрытые автономные системы с дополнительными приложениями. В случае с сервис-ориентированным программированием эта операция делается очень быстро и просто. Кроме того, особый интерфейс делает сложные по своим функциям приложения вполне доступными для понимания каждому пользователю, легкими и простыми в обращении.
Поскольку основное свойство сервис-ориентированных приложений – это возможность их многократного использования, они могут быть особенно выгодными для тех компаний, которые часто задействуют в своей работе одинаковые или похожие приложения. Например, страховая компания, включающая в себя много различных отделов, но обладающих, тем не менее, достаточно похожими с точки зрения программного обеспечения функциями.

Однако необходимо помнить, что многократное использование (и выгоды, которое оно приносит) никто не может гарантировать. В том случае, если разработчики в других отделах компании не знают об уже имеющихся сервисах или не доверяют им, сервис-ориентированные приложения никогда полностью не раскрывают своих возможностей. Как уже подчеркивалось выше, для получения максимальной прибыли от сервис-ориентированных приложений, в компании необходимы четкие механизмы управления, централизованная команда, ответственная за проект внедрения СОА, и базы хранения сервисов.

Впрочем, далеко не всегда недостаточно широкое использование сервисов связано с проблемами централизации и управления внутри компании. Нередко причиной становятся недочеты самих сервисов – например, они способны производить слишком маленькое количество операций или наоборот, пытаются справиться со слишком большим их количеством. Иногда получается так, что разработчики просто не принимают во внимание какой-либо важный аспект применения того или иного сервиса. Один из важнейших вопросов в создании сервиса – это правильное определение его размера. «Ветераны» применения сервис-ориентированной архитектуры говорят, что это почти искусство, требующее не только специальных знаний, но и интуиции. Неправильное определение размера сервиса может резко сократить возможности его использования. По оценкам аналитиков Gartner всего лишь от 10 до 40% сервисов используются многократно – несмотря на то, что это и есть основополагающий принцип их работы.

                   2. Благодаря сервис-ориентированным приложениям увеличивается эффективность работы. СОА значительно экономит время разработчиков за счет многократного использования продуктов, поэтому одна и та же команда может успевать работать над большим количеством проектов. Кроме того, интеграция программного обеспечения с помощью СОА оказывается намного дешевле (по оценкам Gartner, примерно на 30%) и быстрее, чем с помощью любых других методик.

Еще один аспект проблемы эффективности – тестирование продуктов ПО. Обычно это самый последний и мучительный этап в жизненном цикле каждого программного продукта, и зачастую ему уже не уделяется должного внимания. СОА же в основном акцентирует внимание именно на тестировании, работе приложений на практике, что также заметно повышает эффективность их работы.

                   3. Сервис-ориентированные приложения увеличивают подвижность, гибкость, мобильность структуры ПО в компании. Теоретически, даже в случае, когда компания не располагает сложной системой программных продуктов, избыточных или дублирующих друг друга, СОА может оказаться полезной. С помощью сервис-ориентированных приложений можно сложный и длительный процесс разбить на небольшие фрагменты, для каждого из которых будет разработан свой сервис, работающий автономно.

Это позволяет легко и быстро управлять процессами, менять какие-то детали, не разрушая при этом единого целого, поскольку все изменения происходят лишь внутри одного компонента.

Преимущества сервис-ориентированной архитектуры как стратегии

                   1. СОА способна обеспечить лучшее взаимодействие IT и бизнеса. Сервис-ориентированная архитектура создает полную картину всех бизнес процессов в компании, что дает возможность бизнес персоналу впервые увидеть собственными глазами, как строится бизнес с точки зрения технологий. В свою очередь, это стимулирует их поддерживать и ценить IT проекты, поскольку они начинают действительно понимать, в чем заключается польза и смысл каждого нового решения. Более того, есть предположение, что когда-нибудь, в далеком будущем, сотрудники бизнес отделов даже сами смогут заниматься изменением и соединением сервисов для новых процессов… но разумеется, пока все это в далекой перспективе.

                   2. СОА – это методика организации не только IT, но отчасти и бизнес отдела, это глобальная стратегия компании в целом. Главная особенность сервис-ориентированной архитектуры заключается в том, что она обеспечивает прибыль не только департаменту IT, но и бизнес отделу. Сервис-ориентированная архитектура создает программное обеспечение всегда с учетом бизнес потребностей компании и специфики бизнес процессов.

Единственная проблема заключается в том, что такая стратегия подходит не для всех компаний, поскольку она требует создания особого централизованного штата менеджеров, архитекторов и разработчиков. Маленькая компания просто не сможет себе этого позволить. Выделение подобной группы также может стать затруднительным для очень децентрализованных компаний.

Как обеспечить баланс между необходимостью планировать архитектуру в СОА и необходимостью быстро получать прибыли?

Планирование архитектуры в целом – сложный процесс, который всегда требует много времени. Однако сервис-ориентированные приложения наряду с использованием широко распространенных стандартов (например, таких, как SOAP) могут дать первые результаты достаточно быстро. Необходимо, чтобы эти процессы шли параллельно. Тогда вы сможете совместить как тактические, так и стратегические преимущества сервис-ориентированной архитектуры. С одной стороны, будет постоянно идти реорганизация внутри компании согласно проекту новой архитектуры, а с другой – вы всегда сможете продемонстрировать противникам непосредственные результаты нововведения (сокращение затрат, повышение производительности и т.д.). Ощутимые и быстрые положительные результаты будут, несомненно, стимулировать людей продолжать работу в том же направлении и убеждать их в правильности принятого решения. К сожалению, само по себе планирование архитектуры  реорганизация компании не дает никаких быстрых прибылей. Известно немало примеров, когда масштабные проекты изменения архитектуры компании заканчивались полным провалом, в случае, когда они не сопровождались одновременной разработкой сервисов. Не следует откладывать создание приложений на потом – иначе вы слишком рискуете дискредитировать всю идею в целом.

Как узнать, какие сервисы обеспечивают наибольшую выгоду?

Если вы сомневаетесь и не знаете, в какой области прежде всего начать разработку сервисов, отталкивайтесь от очень простой идеи - необходимо воздействовать на бизнес процессы. Начните с тех, которые затрагивают общение с клиентами, непосредственно влияют на получение прибылей. По мнению аналитиков Gartner, создание сервисов, связанных с внешними процессами (например, работа с клиентами) является наиболее эффективным. Повышение эффективности приложений в этой области на 10% будет не менее плодотворным, чем 50% (!) рост эффективности средств ПО, задействованных в других бизнес процессах.

Конечно, СОА не всегда может обеспечить больше прибыли, чем хороший программный пакет. Тем не менее, если вы уже приняли решение перейти на сервис-ориентированную архитектуру, следует придерживаться именно этой методики во всех новых проектах.

Как введение СОА отразится на отделе IT?

Если ваша компания не слишком централизованная, приготовьтесь к тому, что введение сервис-ориентированной архитектуры может оказаться настоящим испытанием. СОА всегда привносит централизующее начало. Это абсолютно неизбежно – иначе эффективность СОА стремительно приближается к нулю. Без конкретного ответственного человека и без особой команды, которая занимается только проблемами архитектуры, не стоит даже задумываться о СОА. Методология должна обязательно быть единой во всей компании, а без создания особого штата сотрудников добиться этого практически невозможно.

По мере того как количество сервисов в базе данных растет, процесс внедрения сервис-ориентированной архитектуры начинает напоминать конвейер. И, как и должно быть на процветающем заводе, скорость и объемы производства постоянно растут. Их становится все труднее контролировать. Поэтому будьте готовы к тому, что со временем потребуются дополнительные сотрудники – проект менеджеры, бизнес аналитики, архитекторы.

Сервис-ориентированная архитектура значительно сокращает время, затрачиваемое разработчиками на создание новых приложений – более чем на 50%. Нередко получается так, что с внедрением СОА два специалиста становятся способными выполнить работу, для которой раньше требовалось шестеро. Поэтому очевидно, что, для того чтобы компания «успевала» за разработчиками, ей понадобятся новые сотрудники в других областях, прежде всего проект менеджеры и архитекторы.
Кроме того, следует помнить, что зачастую внедрение сервис-ориентированной архитектуры требует затрат на обучение, так как необходимо освоение персоналом объектно-ориентированного программирования и распределенных приложений. По опросам, всего около 25% компаний располагает необходимым для СОА персоналом, 49% собирается запускать обучающие программы для своих сотрудников.

Источник: cio-world от 27 ноября 2006 года

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 0

Чтобы прокомментировать, или зарегистрируйтесь