Даг Хеншен

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

Складываем вместе: две древних унаследованных системы, необходимость ежедневно обрабатывать сотни тысяч операций и настоятельное требование "сверху" сделать работу государственных органов оперативнее. У нас получится сложнейшая, практически неподъемная задача. Именно так обстояли дела в департаменте транспортных средств, который занимается регистрацией самого большого в США парка транспортных средств штата Калифорния -- легковых автомобилей, грузовиков, мотоциклов и водных судов.
Первая из двух унаследованных систем отдела обеспечивает регистрацию при личной явке граждан в 167 рядовых офисах и работает на компьютерах RS 6000, которые есть в каждом офисе. Вторая система обеспечивает начисление платежей при пролонгации регистрации и рассылку соответствующих документов по почте. Она развернута на мэйнфреймах в центре обработки данных.
Ясно, что при наличии двух разных систем для обслуживания практически одного и того же процесса информация дублировалась, и повышалась вероятность рассогласования данных. При каждом изменении тарифов или правил начисления платежей приходилось организовывать две команды разработчиков и задействовать две группы аналитиков. И без того безрадостную картину усложняло то, что некоторые компьютерные программы использовались уже более трех десятилетий, и их код оброс тысячами модификаций и "поправок", поэтому даже внесение даже небольших изменений требовало обширного анализа и тщательного тестирования.
К 2000 году в отделе признали, что пора переходить к современной архитектуре, которая позволит реализовать государственную программу eGovernment и предоставить гражданам доступ через Интернет.

Централизованная обработка правил

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

К концу 2000 года проект получил одобрение, и менеджеры департамента в качестве системы, основанной на правилах, выбрали Blaze Advisor. Начатая в 2001 году первая стадия проекта охватила только регистрацию водных судов, на которую приходилось всего 2 тыс. транзакций в день. В процессе проектирования было определено 150 бизнес-правил. Это лишь небольшая часть всех транспортных средств. Правило, например, диктовало, что временные жители штата должны платить за регистрацию 37, а постоянные -- 9 долларов.

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

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

Сервисная архитектура

Дополнительные задержки в работе команды возникли в конце 2001 года, когда группа технических стандартов департамента потребовала реализовать централизованную, ориентированную на сервисы архитектуру -- то есть правила должны были выполняться на сервере приложений, а не на RS 6000. По словам Алана Деммина, решение было правильным, но новая постановка задачи потребовала разработки нового подхода и технико-экономического обоснования, что вылилось в пятимесячную задержку.
В качестве сервера приложений выбрали IBM WebSphere. С обновленным планом проект продолжался весь 2002 год. Основной объем работы был связан с определением новых правил для автомобилей и других типов транспортных средств. "Качественное проектирование бизнес-правил требует от разработчика максимального углубления в предметную область, -- говорит Алан Деммин. -- По мере накопления опыта мы научились избавляться от промежуточных правил и переходить сразу к ключевым, которые намного проще будет поддерживать в будущем". Департаменту хватило 2100 правил, хотя в некоторых аналогичных проектах их приходится создавать десятки тысяч.

Новое качество -- гибкость

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

Однако, затем, в срочном порядке команде пришлось заняться разработкой нового сервиса для начисления пеней за просрочку регистрации. Дело в том, что в начале 2003 года законодательство в этой области поменялось, но внести изменения в унаследованные системы не было уже никакой возможности. А тем временем сотрудникам департамента приходилось делать все расчеты вручную, затрачивая массу времени и усилий. Команда проекта задействуя уже отработанную схему быстро создала 20 новых правил для новых начислений. Менее чем за месяц было автоматизировано начисление пеней -- а это 60 тысяч операций ежедневно!

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

На последнем этапе этого проекта новая система должна будет взять на себя начисления по всем оставшимся типам транспортных средств. Тестирование показало, что сервис в состоянии обрабатывать до 400 тыс. транзакций в день. Централизованная, сервисориентированная архитектура облегчила департаменту интеграцию с современными системами, а это позволит без проблем реализовать открытый доступ через Интернет. "У нас теперь есть сервис начисления платежей, доступ к которому возможен по нескольким каналам, -- говорит Алан Деммин. -- В будущем мы планируем реализовать часть функциональности унаследованных систем в Web-архитектуре, и эти сервисы прекрасно впишутся в общую картину".

Слишком мало времени для инноваций

Когда руководители проектов в департаменте транспортных средств принимали решение о выборе новой технологии для устранения задержек, они понимали, что ступают на неизведанную территорию. Но они не знали, что в открываемом ими ящике Пандоры окажется два серьезных инновационных проекта. "Главный полученный урок заключается в том, что мы осознали необходимость закладывать в графике больший запас времени, -- говорит Джерианн Сайц. -- Затраты времени на проект были явно занижены".
Переход на централизованную систему, обрабатывающую бизнес-правила, сам по себе был очень сложной задачей: приходилось мыслить по-новому, и это вызвало определенные задержки. Кроме того, в исходном технико-экономическом обосновании ставилась цель решить прикладные бизнес-задачи, но в конце 2001 года проект перешел во вторую фазу, когда департамент изменил архитектурные требования и потребовал реализовать централизованное, основанное на сервисах решение. Это усложнило развертывание инфраструктуры, так как помимо реализации прикладных задач пришлось развертывать сервер приложений IBM WebSphere.

По мнению Джерианна Сайца, ретроспективный анализ показывает, что модернизацию инфраструктуры и развертывание IBM WebSphere можно было реализовать как отдельный проект. Но "сдвоенный" проект теперь приносит и двойные дивиденды. Бизнес-менеджеры и аналитики получили возможность быстро модернизировать правила в соответствии с изменениями в законодательстве, практически не дожидаясь окончания проекта. И все же основной вывод таков: слишком мало времени было выделено на два серьезных инновационных проекта.