Архитектура информационных систем для менеджеров. Миграция или интеграция?

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

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

Однако от предложения об объединении систем отказаться, как правило, не так-то просто. Формулируется оно достаточно настойчиво и озвучивается не айтишниками, а руководством компании. Попытки убедить руководство в том, что новая система плохая вряд ли возымеют должный эффект. Обычно, конкурирующая система уже должным образом «продана» руководству. А в ответ на ваши замечания по отсутствующему функционал, вам непременно пообещаю эту систему доработать в точном соответствии со всеми вашими требованиями (Я уже писал, что случится это в лучшем случае годика через три, да и требования ваши будут трактоваться совсем не так, как вы того ожидаете).

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

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

Архитектура информационных систем для менеджеров. Миграция или интеграция?: 6 комментариев

  1. А где здесь обещанный повод для ссор с коллегами по цеху?

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

    1. Это потому, что Вы работаете в цехе горячего литья. А кто-то работает в цехе штамповки, и им тоже надо куда-то девать продукцию, в том числе отштампованную из бракованных болванок

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

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

    Есть коллеги которые в результате сделок M&A годами интегрируют с десяток ключевых систем, а есть коллеги, в том числе из других отраслей, которые со скоростью ~ 1.5-2.5 месяца мигрируют приобретенные компании на целевые платформы всего лишь выполняя миграцию на уровне данных.

    В упомянутой книге Брукса говорится о важности отделения архитектуры системы от реализации, выделении подсистем и модулей, что не противопоставляет и не говорит о преимуществах интеграции (в современном понимании) над миграцией. Замечу что первый вариант книги был издан в 75 году, с поправками – в 86/96 году. Т.е. про интеграцию в современном ее понимании (SOA) еще практически ничего не было известно.

    В целом то, базовые принципы софтверной архитектуры, сервисной, корпоративной не особо и различаются. Слабая связанность компонентов и подсистем, асинхронность, масштабируемость – все это применимо к любой из них. Ничего не меняется со времен издания трудов GoF, Фаулера и не противоречит методологиям SOA/EA. Меняется лишь уровень абстракции, появляется больше слоев, форматов, протоколов.

    В вопросе интеграция vs. миграция я бы не противопоставлял одно другому, а исходил из следующих основных групп критериев, которые в разных ситуациях имеют различные веса:
    1. value / cost benefit analisys (стоимость, скорость, ресурсы)
    2. риски
    3. функционал целевой платформы
    4. возможности переиспользования (открытые интерфейсы, стандарты, включая индустриальные)

    Веса определяются совместно с LOB-ами. При этом по отдельным группам критериев вес оценки LOBs может быть больше веса оценки архитектора/CIO/IT-подразделений.

    Результирующий бенчмарк и будет ответом на вопрос миграция vs. интеграция в _каждом_ конкретном случае.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *