BizTalk Server: уроки одного интеграционного проекта

По мотивам этого топика, я написал обобщающую статью. Она называется Domain Standards and Integration Architecture (на английском).

Хочу с вами поделитьсяч опытом. Я расскажу про один из недавних контактов. Очень хотелось бы узнать ваше мнение.

У этого заказчика BizTalk Server используется давно и успешно. Один из проектов – “Производство и поставка деталей и комплектующих”. Такой типичный интеграционный проект, состоящий из множества интерфейсов. Проект действительно большой, около 50 BizTalk Server приложений. Но что делает его действительно большим, в смысле количества кода, так это использование EDI и Oagis форматов данных.

Для примера возьму одну среднюю по размерам Oagic XML  схему, ProcessPaymentStatus. Размером она в 874К, состоит из порядка 10 тысяч элементов и атрибутов.  И это именно средняя по размерам схема, есть и много большие.

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

На этапе тестирования выплыли проблемы с производительностью. Преобразования данных с такими сложными схемами неизбежно вылились в заторы в их обработке.

Приложения выводят во “внешний мир” данные в EDI формате, а для между внутренними приложениями данные передаются в формате Oagis.

Настал момент, когда менеджемент задал давно ожидаемый и фундаментальный вопрс, “Сколько можно срывать сроки? Сколько раз можно сдавать ненадежный код? Как ускорить работу?” Причем под работой понималось не только скорость работы приложений, скорость продвижения данных от системы к системе (если не забыли, мы сейчас обсуждаем интеграционную систему), но, прежде всего, скорость разработки. Любые изменения в существующих приложениях производились слишком медленно. Бизнес протребовал ускорить модификации интеграционных приложений. Разработчики не поспевали за изменениями в бизнесе. Совершеннейшая чепуха в изменениях бизнес-процессов выливалась в недели и месяцы в разработке.

И тут один из новых разработчиков удивился одному факту. Заказ детали, по идее, может состоять всего из нескольких атрибутов: номер детали, количество, дата и время заказа, идентификатор заказчика и что-то там еще. Но почему тогда по системе бродит громадный заказ, состоящих из многих сотен полей?????? Разработчик был не опытный консультант, который на его месте бы сказал «Ничего невозможного нет!» и принялся бы за работу. Разработчик был молодой и неопытный, поэтому он и задал этот глупый вопрос.

Ну мы то — опытные разработчики, поэтому знаем ответ на этот вопрос. Ответ: потому что этого требует схема документа. На первоначальном этапе при вводе в систему заказ дополняется всей доступной информацией. Потом этот заказ преобразутеся в наш внутренний формат, попутно обрастая еще сотнями полей. На базе этого заказа создаются другие документы, каждый их которых набивается сотнями и сотнями всевозможных значений. Благо имеющиеся EDI и Oagis схемы сделаны феноменально детальными. Про размер схем я уже говорил.

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

Наш юный разработчик заметил, что, если мы попробуем заказать деталь без копьютера, вручную, мы обойдемся совершенной малостью. (Тут он не ошибся, пара наших партнеров так и работают, без компьютера.) Почему же наши приложения требуют все эти массивы данных?

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

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

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

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

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

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

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

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

Теперь во время разрабоки мы постоянно задаем себе вопрос “Так ли уж нужен этот элемент данных в нашем сообщении?” И только после абсолютно утвердительного ответа этот элемент становится частью сообщения.

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

Как же так случилось, что проекты с настолько явным просчетом в архитектуре удовлетворяли всех так долго?

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

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

7 комментариев

Filed under BizTalk, Заметки, Integration Architecture

7 responses to “BizTalk Server: уроки одного интеграционного проекта

  1. Dmitry

    Читается как поэма :)) Американцы раньше всех начали автоматизировать свои бизнесы, и раньше всех поэтому получили «зоопарк» в ИТ-подразделении. Удивительно, сколько сил и средств положено на эти задачи «скрещения бульдога с носорогом». И восхмтительно, сколько лет это удается. В России лет десять уже считается лучшим подходом замена кучи программ (и екселей)) одной большой ERP-системой (1С, SAP, Dynamics). С объектно-ориентированой архитектурой. Там дублирование данных минимизировано изначально. Но самое смешное, Лёня, это то что описанные тобой проблемы в большинстве случаев нарастают и в ERP. Скорость и качество модификации функционала, сложность и ресурсоемкость требующихся запросов, сотни гигабайт малопонятных вспомогательных данных, неизбежнось скрытых некорректностей в данных, необъятность потребностей в тестировани — и другие «печеньки». Причиной я считаю заведомый проигрыш стратегии бесконечного эволюционного улучшения. Надежное лечение знаю только одно: полный реинжениринг всех процессов под предлогом внедрения новой платформы, с отказом от большинства старых программ. Каждые 5-7 лет.

    • Leonid Ganeline

      Дима, спасибо за комментарии. Да, они раньше начали, плюс больше ресурсов в это вкладывают. Где наш 1С-овец трудится, в таких же условиях здесь трудятся несколько девелоперов, а то и несколько команд. Соответственно больше всего наделано. А так как 1С-овской монополии на мозги нет, то звери разные бегают по этому лесу.
      Отказ от этого звиринца и покупка нового стоит так дорого, что проще новый бизнес сделать, чем открутить имеющиеся программы и заменить новыми.
      Следуют принципу «если не сломано, то чинить не надо».
      Это чревато. Любые модификации проходят все дороже и дороже, качество их все хуже и хуже. Тут и наступает кирдык, т.е. реинжиниринг.
      Это все известно и понятно.
      А мы можем на этом паравозе ехать только постоянно задавая гамлетовский вопрос, как переделать то, что сейчас работает, на базе новых технологий. Нет смысла переделывать, если не будет в разы лучше. И прежде всего быстрее и проще в разработке.
      Сейчас много чего нового появилось, но, если смотреть на весь процесс, то BizTalk пока еще на вершинке. Что удручает. Вот попробовал Boomi, дыры во всем процессе, начиная с адаптеров и мап, кончая тупым покрытием систем и протоколов. Сколько лет Altova специализируется на мапинге, а все никак до BTS мапера не дотянется. Обидно. С 2006 года в BTS мало что поменялось (много чего прикрутилось, это да), а все никак конкуренты не дотянутся.😦

      • Dmitry

        Лёня, я вот этого не понимаю: «покупка нового стоит так дорого, что проще новый бизнес сделать, чем открутить имеющиеся программы и заменить новыми.». Почему дорого? Софтина тут и там одна и та же, стОит тоже примерно одинаково. Ну ставки специалистов немного повыше — но не в разы, как я понимаю. Тут не все 1С внедряют, не говоря о том что у 1С только софт дешевле.

      • Leonid Ganeline

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

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

    • Leonid Ganeline

      Дима, вот, кстати, Питер Хинтженс стоит на тех же позициях, что и ты. Что надо переделывать, делая все заново. Простые улучшения вряд ли помогут🙂 Один из великих людей в мире распределенных систем.

  2. Dmitry

    Я-то был уверен, что эта мудрость к нам из Америки пришла :-O И убеждал своих клиентов, что это «мировая практика».
    Может правда приехать к вам поделиться передовым опытом😉

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s