Слон покинул здание

Длительному царству громоздких монолитных корпоративных приложений приходит конец. Стоит ли ждать от них "нового царства" гибкости, в которой так нуждаются компании? Сейчас настает время гибких и легко подключаемых сервисов. Осторожное планирование и внимание к техническим и культурным деталям позволит компаниям взнуздать новую мощь ИТ-индустрии.

Полнофункциональные корпоративные приложения безраздельно властвовали на рынке более десяти лет. Начавшаяся в начале 1990-х гонка за реинжинирингом бизнеса, помноженная на паранойю 2000 года, заставила многие крупные организации внедрить ERP-системы и другие комплексные приложения, принеся в жертву новой моде унаследованные системы и "домашние" разработки. Но смогут ли ERP-системы удержаться у власти в условиях становления и созревания Web-сервисов?

Разочарованные высокой стоимостью и сложностью интеграции "комплексных" решений, компании обратились к консолидации. Место царствующего дома в сфере корпоративных приложений заняли SAP и Oracle (вместе с PeopleSoft). Череда поглощений и активная разработка позволили им собрать всеобъемлющее портфолио продуктов, которое охватывает производство, управление цепочками поставок и людскими ресурсами, финансы и управление отношениями с клиентами. Microsoft стремится к такой же гегемонии, но среди мелких и средних компаний.

Однако освобождение от интеграции гетерогенной прикладной инфраструктуры не прошло безболезненно - жесткая ориентация на одного поставщика, непомерные расходы на оплату лицензий и услуги консультантов, практически полное отсутствие гибкости. Иногда казалось, что будущее беспросветно. Но на горизонте забрезжил свет: ориентированная на Web-сервисы архитектура (Service-Oriented Architecture, SOA) и разработка составных приложений начинают вытеснять неуклюжие гигантские решения. Борьба "в верхах" обостряется, и настал час истины - Oracle, SAP и более мелкие поставщики корпоративного ПО должны перевернуть мир или исчезнуть с рынка.

Независимо от того, планирует ваша компания приобретать или разрабатывать ПО, появление SOA обязательно окажет огромное влияние на выбор корпоративных приложений. В этой статье мы сначала остановимся на некоторых сложностях монолитного корпоративного ПО и объясним, почему требуется новый подход. Затем сосредоточимся на способах решения ключевых архитектурных вопросов при создании приложений предприятия - ведь именно это отличает "старый режим" от революционных составных приложений.

Тяготы консолидации

Молва об ужасах интеграции вызвала к жизни тенденцию к консолидации. В 1997 году компания Hershey Food попыталась интегрировать приложения Manugistics, SAP и Siebel, чтобы усовершенствовать обработку заказов. Потратив 2,5 года и 112 млн долларов, Hershey была вынуждена признать неудачу. Из-за неработающих процессов исполнения заказов приходилось постоянно звонить своим клиентам и выяснять, сколько кондитерских изделий те получили в последней поставке. Тогда в Hershey решили объединить обработку более чем 95% бизнес-процессов в рамках SAP R/3. С тех пор компании удалось снизить затраты и повысить качество и эффективность своей интегрированной платформы для поддержки принятия решений.

Компания SAP говорит об опыте Hershey как об успехе консолидации, утверждая, что эта история поучительна и наглядно демонстрирует, с чем сталкивается большинство компаний при попытке интеграции своих приложений - консолидированных и не очень. Однако, решая некоторые из проблем, консолидация приложений создает новые трудности.

Во-первых, обновление и модификация массивных систем обычно требуют многолетнего планирования и миллионных денежных затрат. Опытные интеграторы SAP подтвердят, что в Hershey сильно недооценили объем работ по установке и настройке шести модулей SAP (финансов, снабжения, управления поставкой материалов, складского учета, обработки заказов и выставления счетов) и их интеграции с двумя модулями Manugistics (планирования и графиков) и одним модулем Siebel (продвижения товаров на основании ценовой информации).

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

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

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

Oracle, SAP и другие поставщики комплексного ПО - далеко не дураки и много работают над обновлением своих платформ, обеспечением поддержки SOA и интеграции, основанной на отраслевых стандартах. Однако, разработчики инфраструктурного ПО, в числе которых BEA и IBM, видят в новой ситуации возможность извлечь пользу из набирающей обороты тенденции, когда слоноподобные решения выпроваживаются за дверь. На смену идеологии гигантомании приходит новое видение ПО. Оно обещает снижение затрат за счет использования отраслевых стандартов, возможности повторного использования и постепенного наращивания функциональности.

Составное ПО

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

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

SOA также будет интересен компаниям, инвестировавшим значительные средства в ИТ. Вполне возможно, что основанный на сервисах подход позволит легче интегрировать унаследованные системы и одновременно обеспечит компании больше гибкости в будущем. Банку Merrill Lynch требовалось создать новый набор финансовых Web-приложений для поддержки сильно возросшего штата финансовых аналитиков. SOA и разработанное составное ПО позволили компании развернуть Web-приложения, которые обеспечили доступ к информации, которая хранится в 40 тыс. прикладных систем.

В конечном счете составной подход способствует координации ИТ в соответствии с бизнес-целями компании. На исключительно подвижном рынке мобильной телефонии операторы конкурируют, предлагая новые, захватывающие услуги и контент, которые, в свою очередь, предоставляются сторонними поставщиками. Компании Vodafone и T-Mobile используют SOA, чтобы контролировать использование клиентами услуг и контента сторонних поставщиков, развернутое в их мобильных сетях. Таким образом, ИТ сообразуется с бизнес-целями, так как именно этот отдел отвечает за реализацию и поддержку сервисов, обращенных лицом к клиенту и партнерам.

Больше чем ПО промежуточного уровня

Большинство SOA-решений фокусируется вокруг инфраструктуры Web Services Framework (WSF). Это инициатива W3C цель которой - поддержка автоматизированного определения, развертывания и управления децентрализованными сервисами. Практически все прикладные платформы, инфраструктурные сервисы и приобретенные системы поддерживают WSF. Подобная база для SOA критически важна, однако WSF - всего лишь необходимое, но не достаточное условие успеха SOA и составных приложений.

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

Таким образом, SOA должна определить функциональность приложения как набор совместно и повторно используемых сервисов. При необходимости в качестве технологии среднего уровня SOA можно использовать общую шину корпоративных сервисов (Enterprise Service Bus, ESB). Программное обеспечение ESB взяло на себя роль, которую ранее выполнял ориентированный на сообщения средний уровень и расширило ее в области Web-сервисов и XML.

У каждого сервиса должна быть четко определенная бизнес-задача. Любое приложение, которое будет выполнить эту же задачу, должно задействовать для этих целей совместно используемый сервис. Основная идея в том, что при изменении связанных с задачей бизнес-правил разработчикам будет достаточно изменить только один сервис, выполняющий конкретную задачу. Все приложения, использующие сервис, автоматически примут новые бизнес-правила. Разработчики смогут реагировать на появление новых бизнес-процессов, собирая сервисы в новое составное приложение.

Повторное использование всегда оставалось "священной коровой" разработки ПО и приоритетом при объектноориентированной разработке. Объектноориентированные приложения обычно совместно используют код, но при этом ожидается, что каждое приложение выполняет собственный экземпляр кода. С другой стороны, в SOA системы совместно используют единственный экземпляр кода, то есть сервис во время исполнения.

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

Проектирование: революция в мозгах

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

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

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

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

Сервис должен находиться на более высоком уровне абстракции, четко отделенном от деталей реализации. Это жизненно важно не только для обеспечения гибкости составной системы, но и чтобы освободить ИТ-персонал от выполнения только задач поддержки. Таким образом, разработчики смогут изменять приложение, не оказывая влияния на потребителей сервиса.

"Поднимая" уровень абстракции сервиса выше особенностей реализации, архитекторы и разработчики корпоративных систем должны следовать трем правилам.

1. Мыслить в терминах сервисов, а не компонентов или приложений. Каждый сервис должен предоставлять относительно автономную, крупномодульную функциональность, предпочтительно такую, что хорошо согласуется с бизнес-задачей. Архитекторы не должны разрабатывать сервисы как мелкомодульные компоненты или объекты, зависящие от других компонентов. Например, сервис не должен предоставлять объекты, такие как тележка с покупками. Он должен предоставлять задачи, например "обработка заказа" или "проверка наличия товара на складе". Ясно, что разработчики вправе использовать мелкомодульные компоненты и сильные связи внутри сервиса, но чтобы такая реализация оставалась скрытой от потребителей сервиса.

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

2. Работать с документами, не с классами. Сервис должен обмениваться четко структурированными сообщениями, а не объектами или классами. Сервисы не должны предоставлять через интерфейс множества и типы данных, характерные для того или иного языка. В основу схемы определения данных сообщений следует положить XML.

3. Использовать лаконичные интерфейсы, а не полнофункциональные объекты. Задача состоит в том, чтобы сократить до минимума число сетевых взаимодействий при выполнении задачи. В многофункциональном приложении используется схема с удаленным объектом, в которой пользователь вызывает операции на объекте, размещенном на сервисе. При этом каждый этап работы пользователя требует отдельного взаимодействия с сервисом. В "лаконичном" подходе используется ориентированная на сервисы схема; пользователь создает заказ локально, и для отправки заказа требуется только одно взаимодействие с сервисом. Лаконичная схема интерфейсов снижает вероятность того, что внешние программные интерфейсы изменятся вместе с переменами во внутренней реализации сервиса.

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

В составных приложениях бизнес-логика определяется отдельно от инфраструктуры отдельных приложений. Например, вместо жесткой фиксации семантики в коде используйте внешнюю инфраструктуру безопасности общего назначения. Это станет шаблоном, позволяющим реализовать аутентификацию и авторизацию, основанные на политиках, которые определяют требуемую семантику безопасности сервиса в рамках контекста определенного приложения.

SOA нуждается в руководстве

Разумное руководство жизненно важно для архитекторов и разработчиков составных решений - только в такой ситуации они смогут чувствовать уверенность, реализуя новую SOA-архитектуру. Необходимое условие успеха - обучение и постоянное внимание со стороны ИТ-отдела к руководству разработкой и развертыванию сервиса.

Руководство необходимо процессам, которые компания реализует для обеспечения "правильности" работы, то есть соответствия с принятой практикой, архитектурными принципами, юридическими и отраслевыми стандартами и другими требованиями. Руководство обеспечивает бизнес-контекст и направляет в нужное русло фундаментальные перемены в архитектуре, разработке и управлении проектами, вызываемые к жизни реализацией SOA и составных приложений. Люди обычно сопротивляются переменам - вот почему необходима руководящая инфраструктура, задающая новые правила и цели игры.

ИТ-директор и менеджеры разработки приложений также должны учитывать систему стимулирования. Возможно, существующие программы стимулирования в действительности препятствуют разработке повторно используемых сервисов? Большинство программ ориентированы на сокращение вывода продукта на рынок и сокращение затрат. Проектирование с расчетом на повторное использование требует больше времени и ресурсов. Команда разработчиков повторно используемых сервисов часто не в состоянии четко сформулировать, какую выгоду в конечном итоге предоставит создаваемый сервис. Почему же именно разработчик, даже не руководитель подразделения, у которого есть бюджет на разработку, должен соглашаться увеличить бремя разработки повторно используемого сервиса только для того, чтобы кто-то еще мог получить от него пользу?

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

Однако, правильное руководство поможет изменить культуру. Разработчикам нужны стимулы для создания сервисов, которые могут повторно использоваться другими разработчиками.

***

Растут ожидания, растет оценка возможностей SOA и составных приложений в плане снижения затрат и обеспечения более высокого качества бизнес-процессов. А значит, компании все больше будут задумываться над нецелесообразностью монолитных комплексных решений. Век громоздких, массивных, неуклюжих приложений уходит в прошлое. Настает время гибких, легко подключаемых сервисов.

Безумие в ипотечном кредитовании «Безумие» — только так можно охарактеризовать нынешнее состояние рынка ипотечного кредитования. «В конце 30-х заемщики обычно полностью выплачивали закладную, и все были счастливы, — говорит Келли Вильямс, ИТ-директор First Franklin, подразделения банка National City Bank of Indiana, специализирующегося на «нетрадиционных» ссудах на покупку жилья (то есть для новых и имеющих трудности с кредитом заемщиков) и кредитных линий, предоставляемых заемщикам под обеспечение недвижимостью. — Сегодня люди постоянно меняют закладные и оперируют инвестицией в собственный дом как финансовым инструментом. Это «держит в тонусе» ипотечные компании, которым приходится быть изобретательными и быстро выводить на рынок новые продукты. В этой отрасли выигрывает первый, кто представил новый продукт на рынке». Крупный технологический прорыв, который обеспечил First Franklin успех, — автоматизированная система выдачи ссуд, созданная на базе BEA WebLogic Server и WebLogic Integration. ИТ-команда компании разработала систему, для управления информацией о подающих заявление на ссуду и усовершенствования поддержки принятия решений о выдаче ссуд. По мнению Келли Вильямс и главного технологического архитектора и старшего вице-президента по разработке приложений Фрэнсиса, эта система создала условия для более крупного проекта: создания ориентированной на сервисы архитектуре и, в перспективе, определяемых бизнес-процессами составных прикладных систем. В First Franklin задействовали технологию BEA для создания SOA-архитектуры, используемой для поддержки системы выдачи ссуды и других прикладных сервисов для отслеживания и управления ссудой. SOA также позволила First Franklin обеспечить поддержку отраслевых стандартов и XML-документов, что очень важно для ипотечной отрасли. Web-сервис для отчетности — всего лишь первая ласточка, за которой последует реализация больших планов по внедрению BI-решений и аналитики, доступ к которым будет предоставляться в рамках SOA. «Мы уже видим положительные результаты от SOA, — говорит Бретт Фрэнсис. — У нас есть один сервис, который выполняет обновление ценовой информации во всех наших приложениях. Теперь не нужно выполнять эту операцию отдельно в каждом из них. Мы в состоянии быстрее реализовывать изменения, потому что все у нас теперь «крутится» вокруг бизнеса. Например, в одном из отделов захотели выполнить анализ, поэтому сформулировали запрос так: не «предоставьте информацию о ценах», а «предоставьте информацию о всех ссудах и ценах». И нам потребовалось всего две недели, чтобы разработать отдельное Web-приложение, которое выполняло анализ в автоматическом режиме». Отсутствующая часть, над которой, кстати, сейчас работают в First Franklin, — шина корпоративных сервисов (ESB). «Получив ESB, вы можете избавиться от тесных связей между приложениями и действительно собирать из сервисов решения, обслуживающие нужды бизнес-процессов, — замечает Бретт Фрэнсис. — Независимо от модели, если сервисы или приложения «разговаривают» только друг с другом, вы неизбежно получите неструктурированную монолитную программу. ESB нам нужна, чтобы отделить сервисы от прикладных программ, которые их используют. Это позволит нам построить на базе SOA по-настоящему составные приложения». Самая большая проблема, стоявшая перед First Franklin, заключалась в определении бизнес-процессов. «Создание прототипов очень удобно, потому что это действительно единственный способ выяснить, что бизнес-процесс делает в тот или иной момент времени. Другой (неудачный) вариант — попытка задокументировать все процессы и постоянно поддерживать документацию в актуальном состоянии, — говорит Бретт Фрэнсис. — Слишком много помех, так как процессы в ипотечной отрасли слишком быстро меняются».