 | Уровень сложности: сложный Жан-Луи Марешо (Jean-Louis Maréchaux), специалист по программному обеспечению, IBM
31.07.2009 Чтобы оставаться конкурентоспособной, организация должна модернизировать свои ИТ-системы. Модернизированные ИТ-решения призваны создавать новое качество на основе имеющихся систем и обеспечивать гибкость и беспроблемную интероперабельность в отношении широкого круга технологий. В случае унаследованных систем с этим часто возникают трудности. Сервис-ориентированная архитектура (SOA), в последние годы принятая на вооружение многими организациями, дает путь практического решения задачи развития и повторного использования имеющихся ресурсов. Эта статья знакомит читателя с типовым подходом к модернизации унаследованных систем, включающим в себя определение ИТ-элементов, которые необходимо снабдить дополнительными качествами, выяснение того, насколько успешно удалось осуществить такое дополнение, представление каждой функциональной возможности в виде современного интерфейса и использование новых сервисов для автоматизации будущих бизнес-процессов.
Введение
Модернизация ИТ-системы — сложный и долговременный процесс. Отправной его точкой чаще всего является решение не переписывать имеющиеся системы заново, а трансформировать их. Такое решение обычно принимается из-за того, что в организации скапливается огромное количество прежних наработок, многие из которых написаны на устаревших языках и с трудом допускают дальнейшее развитие и поддержку.
Трансформация имеющихся ИТ-систем еще более усложняется, если организация утрачивает глубокое функциональное знание своих унаследованных систем. Возможна ситуация, когда бизнес-процессы организации были внедрены достаточно давно и не сопровождаются эффективной документацией или компьютерными системами, которые бы позволяли контролировать их во всех деталях. Такой недостаток документальной поддержки усугубляется оборотом ресурсов организации: вполне может оказаться, что те люди, которые некогда наполнили содержанием имеющиеся бизнес-системы и глубоко понимали реализуемые бизнес-процессы и системы автоматизации, уже не работают.
Таким образом, модернизационные мероприятия должны затронуть два аспекта:
- Прежде всего необходимо понять сущность бизнес-процессов, которые автоматизируют унаследованные системы, и сопоставить их с имеющимися потребностями (анализ расхождений, gap analysis). Идентифицировав существующие текущие бизнес-процессы, можно будет приступить к усовершенствованию устаревших частей для создания нового качества на основе существующих ресурсов.
- Следующий шаг носит более технический характер. Унаследованные системы могут быть построены на основе устаревших технологических платформ, сложных в обслуживании и не поддерживаемых производителем. В то же время целевая архитектура должна основываться на самых передовых технологиях, обеспечивающих максимальное повторное использование имеющихся ресурсов.
Бизнес-компонентизация
Первая задача в процессе модернизации унаследованной системы заключается в том, чтобы как следует уяснить суть текущих бизнес-процессов. Существует много путей ее решения; в частности, можно прибегнуть к методическому изучению всего бизнеса с помощью методики компонентного бизнес-моделирования (КБМ). КБМ — это аналитический базис, позволяющий определить и усовершенствовать наиболее важные аспекты деятельности организации. В КБМ-модели различные виды бизнес-деятельности подразделяются на автономные управляемые компоненты. Такой метод дает возможность осмыслить и описать каждую из составляющих вашей организации. Это первый этап модернизационных мероприятий: выделение бизнес-компонентов организации. На этом этапе строится КБМ-схема, включающая в себя всю совокупность бизнес-компонентов и осуществляемых ими сервисов. Такие стратегические "кирпичики" — отправная точка той технической модернизации, к которой вы стремитесь.
Рисунок 1. КБМ-схема, показывающая основные "кирпичики" бизнеса
После того, как КБМ-карта построена, можно приступить к анализу устранения расхождений (fit/gap analysis) между текущими возможностями вашей системы и стоящими перед вами бизнес-целями. Иными словами, вам необходимо определить те из "кирпичиков", на которые будут направлены ваши модернизационные мероприятия.
Внедрение бизнес-сервисов при помощи технических компонентов
Для осуществления запланированной бизнес-трансформации одной лишь бизнес-компонентизации недостаточно: она представляет собой только лишь описание компонентов, которые должна включать в себя ИТ-система. Следующим необходимым этапом является проектирование тех или иных бизнес-функций в виде четко определенных сервисов.
Организации, проводящие у себя модернизационные мероприятия, обычно преследуют следующие ключевые технические цели:
-
Гибкость: Модернизированная система должна улучшить способность бизнеса к реагированию на изменения при минимальном участии ИТ и минимальных затратах.
-
Многократное использование: Модернизированная система должна основываться на четко определенных элементах, допускающих многократное использование. Она должна извлекать пользу из имеющихся унаследованных приложений, создавая на их основе новое качество.
-
Интероперабельность: Модернизированная система должна быть способна к диалогу с другими системами, применяемыми организацией и ее деловыми партнерами.
Для достижения этих целей в рамках модернизационного проекта можно прибегнуть к SOA-подходу. Консорциум OASIS определяет SOA как "парадигму для организации и использования распределенных возможностей, которые могут находиться под управлением доменов, принадлежащих различным владельцам. Эта парадигма предоставляет универсальные средства по предложению, выявлению, взаимодействию и использованию возможностей для достижения желаемых эффектов, согласующихся с измеримыми начальными условиями и ожиданиями". (Более подробную информацию см. в разделе "Ресурсы".)
Архитектурный стиль SOA предоставляет следующие возможности:
- Разработку сервисов, отражающих реальные разновидности деятельности, которые входят в осуществляемые предприятием бизнес-процессы. SOA позволяет согласовать применяемые информационные технологии со стратегическими целями бизнеса.
- Удобство совершенствования первоначальной архитектуры системы с внедрением новых бизнес-функций и технологий будущего. SOA повышает техническую гибкость и, соответственно, способность бизнеса к реагированию на изменения.
- После того как существующие приложения представлены в виде сервисов, их можно согласовать с другими сервисами для организации полноценных бизнес-процессов. SOA поощряет повторное использование имеющихся ресурсов.
- Упрощается взаимодействие несовместимых систем, построенных на базе различных технологий. SOA способствует интероперабельности приложений.
SOA — это естественный подход к внедрению бизнес-компонентов, которые были определены на этапе КБМ. Во-первых, она позволяет представить унаследованное приложение в виде совокупности сервисов, после чего создать новые бизнес-процессы, произведя сборку и согласование этих сервисов. Во-вторых, поскольку SOA основана на открытых, повсеместно принятых стандартах, она эффективно способствует интероперабельности между деловыми партнерами.
Поскольку SOA не зависит от технологии, она вписывается в контекст любых модернизационных мероприятий — написаны ли унаследованные системы на КОБОЛе, RPG, C/C++ или с помощью какой-либо другой технологии.
Методология разработки в SOA
Выбрав архитектурный подход, необходимо согласовать его техническую реализацию с первоначальными бизнес-целями. SOA-компоненты должны обеспечить работоспособность и поддержку бизнес-процессов. Однако прежде всего они должны быть определены, спроектированы, разработаны, протестированы и введены в эксплуатацию таким образом, чтобы иметь возможность контролировать риски и чтобы организация приобретала новое качество. Эффективный менеджмент такого процесса разработки может быть обеспечен благодаря использованию проверенных подходов к разработке специализированного программного обеспечения (в данном случае SOA).
Несмотря на сравнительную новизну SOA-подхода, IBM® предлагает проверенную методику разработки программного обеспечения, включающую в себя наиболее новаторские приемы идентификации, спецификации и реализации сервисов. Эта методика объединяет наиболее прогрессивный и универсальный процесс разработки программного обеспечения IBM Rational® Unified Process® (см. раздел "Ресурсы") с самыми эффективными приемами SOA-дизайна. Эти наиболее эффективные приемы, в свое время отобранные консультационной службой IBM Global Business Systems среди более чем 3 500 случаев применения SOA, носят название сервис-ориентированного моделирования и архитектуры (SOMA). Сочетание первого и второго, представляющее собой продукт, доступный на коммерческой основе, носит название RUP® для SOMA (см. раздел
"Ресурсы").
SOMA включает процесс, позволяющий повысить степень соответствия ИТ-систем требованиям бизнеса. Предписываемые им действия направлены на:
- определение ИТ-сервисов, необходимых для удовлетворения потребностей бизнеса;
- спецификацию этих сервисов;
- реализацию сервисов путем разработки компонентов, соответствующих спецификациям сервисов, и принятия решений относительно места этих компонентов в общей ИТ-архитектуре организации.
Возможно, здесь вы спросите: ну и что? Вопрос совершенно закономерный: в самом деле, какое все это имеет отношение к модернизации унаследованных систем?
Во-первых, RUP содержит набор рекомендаций по развитию старых систем. В частности, в нем перечисляются разновидности такого развития (расширение, косметическое переоформление, миграция, разработка заново), а также приводятся указания по ключевым этапам процесса и характеристики конечных продуктов, обеспечивающих необходимую эволюцию унаследованных систем.
Во-вторых, составив список бизнес-компонентов для КБМ, а затем проведя мероприятия RUP для SOMA, вы сможете специфицировать необходимые технические сервисы и определить, какие из них лучше реализуемы на основе существующих и модифицированных унаследованных приложений.
Практический пример:
архитектура модернизированной системы
Пару лет назад я принимал участие в модернизационном проекте для клиента из фармацевтической промышленности. Изучив потребности заказчика, мы определили, что SOA-методика прекрасно подходит для того, чтобы согласовать имеющуюся ИТ-систему с текущими задачами его бизнеса.
Приложение, которое нам требовалось модернизировать, представляло собой унаследованную систему, написанную на RPG за 15 лет до того. Выяснив с помощью метода SOMA, какие сервисы необходимо реализовать, мы проанализировали существующее приложение и его структуру. Поскольку один из ключевых принципов SOA заключается в том, чтобы создавать новое бизнес-качество на основе имеющихся ресурсов, мы стремились повторно использовать как можно больше RPG-кода и создать новую бизнес-функциональность при помощи инновационного подхода.
Мы пришли к выводу, что модернизация должна затронуть прежде всего три области: базу данных, RPG-код и технологическую платформу.
Модернизация базы данных
Многие унаследованные системы отличаются весьма примитивной структурой данных. Мы нисколько не удивились, обнаружив, что эта проблема характерна и для системы нашего заказчика. Многократное дублирование информации за годы использования системы привело к тому, что одни и те же сведения содержались в нескольких таблицах. Ссылочная целостность данных отсутствовала, концепция первичных и внешних ключей не выдерживалась последовательно в рамках всей базы данных.
Соответственно нашей первой целью было модернизировать базу данных так, чтобы создать прозрачную и простую в использовании информационную систему. Мы построили реляционную базу данных, применив нормализационные принципы (см. дополнительную информацию в разделе "Ресурсы"). Для облегчения использования данных в рамках организации мы разбили базу данных на две различные схемы:
- Одна из схем была предназначена для корпоративных данных, допускающих повторное использование во многих различных приложениях.
- Другая схема содержала данные, касающиеся исключительно унаследованного приложения, которое нам предстояло модернизировать.
После этого мы заполнили вновь созданную базу данных материалом унаследованной базы данных, используя стратегию ETL (Extract Load and Transform — "Извлечение — преобразование- загрузка"). Таким образом была построена информационная система, с одной стороны, способная поставлять данные в систему клиента, а с другой — имеющая более типовой уровень, относящийся к корпоративным данным.
Обновление унаследованных программ
Бизнес-логика унаследованной системы была реализована в целом ряде RPG-программ. Как и исходная база данных, эти программы не следовали структурированной архитектуре. Они разрабатывались, чтобы быстро удовлетворить потребности бизнеса, после чего активно модифицировались для устранения технических и функциональных проблем. Одна и та же бизнес-логика дублировалась в огромном множестве программ, так что поддержание работоспособности системы превратилось в сложную и чрезвычайно дорогостоящую задачу.
Чтобы извлечь пользу из этого монолитного кода, мы прибегли к стратегии четкой модуляризации. Наш подход был прост: нужно было создать простые RPG-модули для бизнес-компонентов, допускающих повторное использование. У каждого из таких модулей были четко определенные задачи, а элементы бизнес-логики, дублирующиеся в различных программах, были локализованы в конкретных уникальных компонентах системы. Мы выбрали этот подход потому, что он облегчает обслуживание системы в будущем. Благодаря ему нам также оказалось проще определить сервисы на основе слабо связанных компонентов. Такая RPG-компонентизация была частью глобального сервис-ориентированного подхода.
Реализация технологической платформы
Организации обычно возлагают на внедрение SOA большие надежды. Часто они требуют, чтобы SOA сумела превратить имеющиеся ресурсы в индивидуальные бизнес-функции и процессы, а также обеспечила эффективное реагирование на постоянно меняющиеся условия рынка. Из-за таких требований возможности повторного использования и гибкости большое значение приобретает техническая платформа SOA-решения. Она должна поддерживать работу общепринятых технологий и соответствовать стандартам отрасли, чтобы облегчить интеграцию с бизнес-партнерами. Кроме того, SOA-решение должно соответствовать всем нефункциональным требованиям по обеспечению бизнесом качества обслуживания (Quality of Service, QoS). Обычно сюда входят требования, связанные с безопасностью, доступностью, производительностью, переносимостью с платформы на платформу и т. д.
Определение архитектуры будущего модернизированного приложения — не простая задача. По сравнению с проектом, выполняющимся "с чистого листа", здесь приходится принимать во внимание гораздо большее количество ограничений. Прежде всего нужно иметь в виду, что модернизация — это не переписывание заново. В нашем проекте мы практически в самом начале решили строить конечное решение на платформе Java™ 2 Platform, Enterprise Edition (J2EE). Заказчик хотел использовать современную мощную технологию, а Java к тому времени уже применялась в некоторых его частных проектах.
В целом мы следовали архитектурным подходам J2EE (см. раздел "Ресурсы"), стремясь согласовывать то, что мы делаем, с проверенными методиками и решениями. По существу это была реализация шаблона Model-View-Controller (MVC), но обогащенного рядом SOA-концепций. Давайте рассмотрим соответствующие уровни более подробно.
-
Уровень 1: самый нижний уровень, ответственный за поставку всех данных остальной системе. К нему относится база данных и некоторые из унаследованных программ в их первоначальном варианте. (Часть не особо ответственных программ не были модернизированы, т. к. их преобразование не порождало нового бизнес-качества.)
-
Уровень 2: компонент уровня предприятия, ответственный за реализацию функциональности декларированных сервисов. Он включает в себя RPG-модули, определенные в ходе процедуры компонентизации, и Java-компоненты, реализующие новые функции модернизированной системы.
-
Уровень 3: сервисный уровень, согласующий между собой обращения к компонентам предприятия и формирующий тем самым целостные бизнес-процессы. Он включает в себя крупномодульные Java-компоненты.
-
Уровень 4: верхний уровень, представляет собой точку входа в модернизированное приложение. Он включает в себя компоненты пользовательского интерфейса, а также процессы, обращенные к внешним потребителям услуг организации.
Кроме того, мы определили два дополнительных уровня, ответственных за ключевые нефункциональные требования:
-
Уровень 5: это интегрирующий уровень, обеспечивающий интероперабельность между различными платформами. Он был реализован с помощью корпоративной сервисной шины (Enterprise Service Bus, ESB). ESB играет роль промежуточного уровня, обеспечивающего возможность коммуникации между различными процессами приложения. Объединяя событийно-управляемый и сервис-ориентированный подходы, этот уровень упрощает интеграцию бизнес-подразделений, служит связующим звеном между разнородными платформами и средами.
-
Уровень 6: этот уровень предоставляет средства для удовлетворения требований QoS на уровне предприятия. В частности, модернизированное приложение должно быть снабжено первоклассными механизмами обеспечения безопасности, целостности и доступности.
Наш подход состоял в том, чтобы принять в качестве ПО промежуточного уровня (middleware) ведущий сервер приложений J2EE. Тем самым обеспечивалась устойчивая модель безопасности и надежное управление транзакциями. Требования QoS при этом реализовались самим сервером приложений. Различные уровни архитектуры нашего решения показаны на рисунке 2.
Рисунок 2. Пример SOA-структуры для модернизации унаследованной системы
Заключение
SOA обеспечивает гибкость системы и поддерживает ее способность к реагированию. Благодаря ей становится возможным повторное использование имеющихся ресурсов, лучшее согласование ИТ-систем с потребностями бизнеса. В этом смысле SOA является хорошим средством модернизации унаследованных систем.
Модернизация ИТ-системы начинается с осмысления бизнес-содержания системы. На основе этого знания становится возможным осуществить анализ расхождений между имеющейся системой и бизнес-целями организации. По его итогам определяется необходимая бизнес-архитектура модернизированной системы.
С помощью мероприятий RUP для SOMA техническая архитектура может быть согласована с потребностями бизнеса. RUP для SOMA служит источником плана действий по преобразованию монолитной устаревшей унаследованной системы в гибкую систему, основанную на модульности, многократном использовании, свободной связи и интероперабельности. После этого модернизированная унаследованная система может быть установлена на современной платформе, такой как Java Platform, Enterprise Edition (Java EE). Существующий код может быть использован повторно и представлен в виде сервисов, а система может теперь с большей легкостью взаимодействовать с бизнес-партнерами. Сказанное наглядно представлено на рисунке 3.
Рисунок 3. "Устои" и "фундамент" SOA-модернизации унаследованных систем
Благодарности
Я хотел бы выразить свою признательность Тодду Даннаванту, исполнительному консультанту и общемировому лидеру сообщества Architecture Management Community of Practice при IBM Rational. Тодд любезно согласился поделиться со мной опытом и произвести техническое рецензирование этой статьи. Будучи хорошим специалистом по архитектуре ПО, он в конце концов решил переработать кое-что в ее содержании. Особенно полезным участие Тодда оказалось в том отношении, что он "разложил по полочкам" те мысли, которые я хотел здесь высказать.
Ресурсы Научиться
- Оригинал статьи "Modernize legacy systems using an SOA approach" (EN).
- Узнайте больше о компонентном подходе и о модели
Component
Business Model (EN).
- Прочтите статью
"Влияние сервис-ориентированности на бизнес-уровне" (EN) — прекрасный обзор, посвященный сервис-ориентированной архитектуре и области ее применения.
- Загрузите
Reference
Model for Service Oriented Architecture 1.0
[PDF] с сайта OASIS — консорциума по открытым стандартам.
- Узнайте больше об
IBM Rational Unified
Process.
- Ознакомьтесь с коллекцией руководств по наиболее эффективным приемам разработки на сайте
Rational Process Library
- Прочтите статью Али Арсанджани
"Сервис-ориентированное моделирование и архитектура"
(developerWorks, ноябрь 2004 г.) — вы узнаете, как определить, конкретизировать и реализовать сервисы в вашей SOA.
- Прочтите руководство
"Практическое проектирование базы данных, Часть 2"
(EN) (developerWorks, июнь 2003 г.), чтобы узнать больше о проектировании баз данных и нормальных формах.
- Посетите Web-сайт
Core J2EE Patterns.
- В разделе
SOA и Web-сервисов на
сайте IBM developerWorks вы найдете сотни полезных статей, а также руководств по разработке приложений Web-сервисов — начального, среднего и профессионального уровня.
- Играйте в
SOA-песочнице IBM!
Повышайте свою квалификацию, получая непосредственный практический опыт в точках входа IBM SOA (EN).
- На
сайте IBM SOA вы найдете обзор SOA и узнаете, как IBM может помочь вам освоиться в этой области.
- Следите за
Семинары и мероприятия на developerWorks.
- Ищите книги по этой и другим темам в
книжном магазине Safari.
- Ознакомьтесь с краткой
демонстрацией на тему Web-сервисов (EN).
Получить продукты и технологии
Обсудить
Об авторе | 
| | Жан-Луи Марешо (Jean-Louis Maréchaux) работает ИТ-архитектором в группе IBM Business Consulting Services в Канаде. Его интересы и область специализации включают в себя J2EE-архитектуру, технологии Web-сервисов, SOA и процесс разработки программных систем (IBM Rational® Unified Process). |
Выскажите мнение об этой странице
| |
