Хочу поделиться с заказчиками(пользователями) информационных систем одним маленьким секретом. Только сразу убедительно прошу, когда вы будете пользоваться этим секретом, пожалуйста, на меня не ссылайтесь. Не хочу лишний раз ссориться с коллегами по цеху. Договорились? Тогда рассказываю.
В деятельности любого подразделения рано или поздно наступает такой момент, когда ему начинают предлагать перенести свои бизнес-процессы или операции в другую информационную систему. В принципе это нормальная ситуация. Информационные системы устаревают и периодически нуждаются в замене. Кроме того, жизнь любой компании представляет собой постоянные изменения организационной структуры, зон ответственности, слияния и поглощения. Количество информационных систем неуклонно растет. Затраты на их развитие и поддержку, в отличии от ИТ-бюджетов организаций, увеличиваются, так что ИТ тоже заинтересован в консолидации информационных систем. В общем, полностью избежать переездов из одних информационных систем в другие, скорее всего, не получится. Однако народная мудрость гласит, что один переезд хуже двух пожаров. И опытные пользователи информационных технологий отлично понимают, что замена информационной системы не сулит ничего хорошего. Часть имеющегося функционала потеряют, данные перенесут некорректно, пользовательский интерфейс усложнится (якобы в целях унификации бизнес-процессов), количество ошибок возрастет, да и работать новая система будет медленнее, чем старая. Кроме того, доработки, которые раньше делались исключительно для вас теперь попадут в общий список запросов на изменения и договариваться о приоритетах вам придется теперь с другими бизнес-заказчиками. Закончиться это может тем, что необходимые именно вам доработки получат невысокий приоритет и встанут в конец длинной очереди. Хорошо если вы дождетесь их реализации годика через три.
Однако от предложения об объединении систем отказаться, как правило, не так-то просто. Формулируется оно достаточно настойчиво и озвучивается не айтишниками, а руководством компании. Попытки убедить руководство в том, что новая система плохая вряд ли возымеют должный эффект. Обычно, конкурирующая система уже должным образом «продана» руководству. А в ответ на ваши замечания по отсутствующему функционал, вам непременно пообещаю эту систему доработать в точном соответствии со всеми вашими требованиями (Я уже писал, что случится это в лучшем случае годика через три, да и требования ваши будут трактоваться совсем не так, как вы того ожидаете).
В этой ситуации, единственное, что вам сможет реально помочь, так это интеграция приложений. В конечном счете, руководство, желающее видеть все свои операции в единой системе, иметь общую отчетность и управлять едиными бизнес-процессами, можно понять. Но миграция всех пользователей, данных и бизнес-процессов в одну систему это не единственное решение. Настаивайте на том, чтоб система, выбранная в качестве целевого решения, не реализовывала ваши требования, а предоставляла программные интерфейсы, позволяющие получать из вашей существующей системы всю необходимую информацию. Если новая система, действительно, технологически современна, то она способна предоставить такие программные интерфейсы. Если целевая система не может этого сделать то, скорее всего, у вас намечаются определенные проблемы. Руководители приходят и уходят, а внедренные ими приложения остаются. Основная беда монолитных систем не в том, что они не содержат некоторого необходимого функционала. Функционал можно доработать. Проблема в другом. Количество программистов, способных согласованно развивать тот или иной продукт ограничено. Не может сто человек одновременно дорабатывать один и тот же код. Они просто не сумеют договориться. Этот факт известный еще с семидесятых годов прошлого века и отлично описанный в книжке Фредерика Брукса «Мифический человеко-месяц». Потому архитектура хороших систем представляет из себя набор слабо-связанных модулей, синтегрированных через программные интерфейсы. Каждый модуль развивается независимо от других небольшой командой. Такие системы изначально предназначены для интеграции(иногда еще используют термин интероперабельны) и легко вписываются в существующий ИТ-ландшафт организации.
О методах интеграции приложений я уже неоднократно писал в этом блоге (см. сообщения интеграция приложений, управляемая событиями архитектура) и не буду сейчас на этом останавливаться. Главное понимать, что для задачи унификации бизнес-процессов миграция операций и данных в общую информационную систему не является единственно возможным решением.