Все новости от 28 апреля 2003 г.

Тернистый путь миграции

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

Действительно, зачем нужно приобретать сразу четыре продукта от различных компаний-разработчиков (Great Plains незадолго до включения в MBS слилась с Solomon Software, а Navision — с Damgaard)? А ведь именно наличие смешанных архитектурных решений в нынешних продуктах предопределяет повышенную сложность будущей миграции.

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

Гораздо более правомерно предположить, что их заменит один универсальный высокомасштабируемый продукт (скорее всего, в разных изданиях типа Standard, Professional, Enterprise). При этом я бы не стал ожидать от него какой-то повышенной функциональности по сравнению с нынешними. Почти уверен, что огромные инвестиции в разработку (около 200 млн. долл. в текущем финансовом году) пойдут не на расширение функций, а на создание самой платформы, унификацию продуктов для конечного пользователя, их более жесткую привязку к приложениям Microsoft.

Успех этих продуктов на рынке будет определяться сочетанием добротного качества с традиционными для Microsoft методами продвижения. Например, можно ожидать, что в состав очередной Windows войдет “маленькая настольная бухгалтерия”. Более серьезные версии займут свое место в Small Business Ser-ver и SQL Server и будут поставляться с компьютерами в OEM-варианте, а внутренний механизм системы появится в виде набора SDK.

Какая из существующих архитектур ляжет в основу будущей MNBF? Вполне возможно, что никакая, но вероятнее всего — Great Plains. Хотя бы потому, что она работает на американском рынке, раньше вошла в MBS и к тому же ее разработчики еще два года назад составили команду, начавшую создание новой версии.

Ориентация на MNBF не означает, что Microsoft прекратит поддержку старых продуктов. Но мы хорошо знаем цену клятв о пожизненных гарантиях со стороны поставщиков, тем более Microsoft, жесткая позиция которой при смене версий хорошо известна. Далеко за примерами ходить не нужно, стоит лишь вспомнить драматичную историю (еще не законченную!) миграции с Visual Basic от версии 6.0 к .NET, хотя речь тогда шла об огромной базе унаследованных приложений, созданием которых занимается не менее 2—3 млн. разработчиков в мире.

Проблемы будущей миграции очевидны. Ведь для ERP-решений, созданных на базе систем-конструкторов, трудности возникают даже при обновлении версии в рамках одной архитектуры (тут можно обратиться к примеру перехода от версии 7.x к 8.0 платформы “1С:Предприятие”). А теперь представьте, что придется переносить код с разных внутренних языков программирования, преобразовывать систему объектов, модифицировать форматы данных и пр.

Но я далек от мысли сравнивать переход к MNDF с апокалипсисом. Нас ждет непростой, но в то же время довольно обычный для софтверной индустрии период смены технологий. И вопрос только в том, как подготовиться к нему и как минимизировать затраты на его преодоление. А пока можно сделать только общий вывод из сказанного: пользователи MBS должны быть готовы к форсированному переходу на платформу .NET, а впоследствии — к регулярному ускоренному обновлению не только версий, но и базовых технологий.