Миграция данных
В рамках импортозамещения — обычное дело. Данные из импортной системы А мигрируют в новую отечественную систему Б. И в целом тут надо разобраться, что мигрировать и в какой последовательности. Есть первая очередь, вторая, третья. Например, данные по клиентам. Клиенты бывают разных типов: юридические, физические, можно отдельно ИП, и у каждого типа будут свои атрибуты — обязательные и необязательные параметры. Возможно, не все данные клиентов будут перенесены в отечественную систему в силу разных обстоятельств. Например, в Equation сложный ID клиента, который отечественной системе может быть не нужен, и 20-значные счета связаны с 13-значными номерами счетов для реализации работы с полупроводками. В новой системе 13-значные счета вряд ли понадобятся. Определились с параметрами, поняли их бизнес-смысл...
Теперь надо понять, где нужные параметры взять в старой системе. Что делать, если в новой системе, например, в коробочном решении, параметр есть, а в старой нет? Думаю, тут понятно: ничего не мигрируем. Интереснее, если можно вычислить тот или иной параметр на основании атрибутов в разных таблицах — тут надо уже подумать. Если поле просто есть в старой таблице, то нужно не забыть про его формат: если дата будет начинаться с указания века, оно вам точно надо? А валюту вы как будете в новой системе вести: "RUB", "RUR", "810"/"840"? А как и кем спроектирована отечественная система? Архитекторами, системными аналитиками, своими или вендором? Вот проектирование — вещь уже интересная. Но если у вас готовая коробка от вендора, куда надо просто смигрировать данные, то тут ТЗ становятся стандартными и однообразными.
Таких проектов по миграции достаточно много, и они будут и в 2025 г., и в 2026 г., судя по новостям из СМИ. Но есть пару минусов: участники таких проектов могут не использовать Mermaid, PlantUML, Offset Explorer, Kibana, так как им просто не надо это на проекте. Но проекты по миграции краткосрочные: мигрировали данные, подкорректировали ошибки — и всё, новая система заработала, проект закрыт. Проекты по миграции относятся к специфичным: где вы не проектируете OpenAPI, не описываете US, UC, не строите диаграммы последовательности. Если у вас специфичный проект, вам будет полезен мой курс — инструменты системного аналитика. В него я вложила те знания, которые мне очень пригодились на проектах.
Как вы? Работали с миграцией данных? Да- 👍, нет - 🙈.Если есть интересный опыт — делитесь в комментариях.
А ещё сегодня второй день зимы☃️
В рамках импортозамещения — обычное дело. Данные из импортной системы А мигрируют в новую отечественную систему Б. И в целом тут надо разобраться, что мигрировать и в какой последовательности. Есть первая очередь, вторая, третья. Например, данные по клиентам. Клиенты бывают разных типов: юридические, физические, можно отдельно ИП, и у каждого типа будут свои атрибуты — обязательные и необязательные параметры. Возможно, не все данные клиентов будут перенесены в отечественную систему в силу разных обстоятельств. Например, в Equation сложный ID клиента, который отечественной системе может быть не нужен, и 20-значные счета связаны с 13-значными номерами счетов для реализации работы с полупроводками. В новой системе 13-значные счета вряд ли понадобятся. Определились с параметрами, поняли их бизнес-смысл...
Теперь надо понять, где нужные параметры взять в старой системе. Что делать, если в новой системе, например, в коробочном решении, параметр есть, а в старой нет? Думаю, тут понятно: ничего не мигрируем. Интереснее, если можно вычислить тот или иной параметр на основании атрибутов в разных таблицах — тут надо уже подумать. Если поле просто есть в старой таблице, то нужно не забыть про его формат: если дата будет начинаться с указания века, оно вам точно надо? А валюту вы как будете в новой системе вести: "RUB", "RUR", "810"/"840"? А как и кем спроектирована отечественная система? Архитекторами, системными аналитиками, своими или вендором? Вот проектирование — вещь уже интересная. Но если у вас готовая коробка от вендора, куда надо просто смигрировать данные, то тут ТЗ становятся стандартными и однообразными.
Таких проектов по миграции достаточно много, и они будут и в 2025 г., и в 2026 г., судя по новостям из СМИ. Но есть пару минусов: участники таких проектов могут не использовать Mermaid, PlantUML, Offset Explorer, Kibana, так как им просто не надо это на проекте. Но проекты по миграции краткосрочные: мигрировали данные, подкорректировали ошибки — и всё, новая система заработала, проект закрыт. Проекты по миграции относятся к специфичным: где вы не проектируете OpenAPI, не описываете US, UC, не строите диаграммы последовательности. Если у вас специфичный проект, вам будет полезен мой курс — инструменты системного аналитика. В него я вложила те знания, которые мне очень пригодились на проектах.
Как вы? Работали с миграцией данных? Да- 👍, нет - 🙈.Если есть интересный опыт — делитесь в комментариях.
А ещё сегодня второй день зимы☃️