Отличная статья, прекрасный язык изложения, прочиталось на одном дыхании! Чувствуется продуманный концепт переноса верхнеуровнево. Интересует несколько деталей: как я понимаю речь идет о плавном переезде без остановки бизнеса заказчика? Если да, то мы обязаны понимать, что просто взять разом и все перенести не получится. Соответственно мы переносим часть критически - важного функционала в плане данных объектов и строим по объектной модели бизнес-процессы в рамках уже новой системы, но вот пока мы строим эти БП, люди продолжают работать в старой системе. Данные добавляются, копятся, возможно правится объектная модель (по запросам юзеров или старым тикетам), и вот нам уже снова нужно делать перенос данных. Возможно ли как-то избежать двойного(тройного и т.д.) переброса данных? Как осуществить наиболее плавный переезд максимально незаметно для заказчика? Какая система будет "дергать" API первой и в рамках какой будет прописываться маппинг объектов?
Спасибо! По поводу плавности переезда - в целом последовательность шагов будет одинаковая для любой скорости, в зависимости от того на сколько быстро на переехать будут появляться нюансы. Например если систему отключают прямо завтра, то миграция данных пройдет безболезненно - за ночь все перенесли, а вот с интерфейсами явно возникнет беда, и долго придется работать с чем то собранным на коленке. Если говорить о плавном переезде в разрезе переноса данных есть несколько вариантов. 1. Выбрать точку отсчета - все что до посчитать историческими данными и перенести их как есть (если объектная модель это предусматривает) 2. Реализовать интеграцию со старой системой и на этапе раннего старта с определенной переодичностью данные в новую систему выгружать (т.е мастер система старая) Здесь мы при хорошем раскладе уже получим насыщенный данными препрод , где можно в том числе тестирование проводить 3. В момент перерезания красной ленточки - запуска в прод данные в новой системе будут уже актуальными и интеграцию можно будет отключить. В целом между шагом 2 и 3 можно увеличивать переодичность обновлений.
Отличная статья, прекрасный язык изложения, прочиталось на одном дыхании! Чувствуется продуманный концепт переноса верхнеуровнево. Интересует несколько деталей: как я понимаю речь идет о плавном переезде без остановки бизнеса заказчика? Если да, то мы обязаны понимать, что просто взять разом и все перенести не получится. Соответственно мы переносим часть критически - важного функционала в плане данных объектов и строим по объектной модели бизнес-процессы в рамках уже новой системы, но вот пока мы строим эти БП, люди продолжают работать в старой системе. Данные добавляются, копятся, возможно правится объектная модель (по запросам юзеров или старым тикетам), и вот нам уже снова нужно делать перенос данных. Возможно ли как-то избежать двойного(тройного и т.д.) переброса данных? Как осуществить наиболее плавный переезд максимально незаметно для заказчика? Какая система будет "дергать" API первой и в рамках какой будет прописываться маппинг объектов?
Спасибо!
По поводу плавности переезда - в целом последовательность шагов будет одинаковая для любой скорости, в зависимости от того на сколько быстро на переехать будут появляться нюансы. Например если систему отключают прямо завтра, то миграция данных пройдет безболезненно - за ночь все перенесли, а вот с интерфейсами явно возникнет беда, и долго придется работать с чем то собранным на коленке.
Если говорить о плавном переезде в разрезе переноса данных есть несколько вариантов.
1. Выбрать точку отсчета - все что до посчитать историческими данными и перенести их как есть (если объектная модель это предусматривает)
2. Реализовать интеграцию со старой системой и на этапе раннего старта с определенной переодичностью данные в новую систему выгружать (т.е мастер система старая)
Здесь мы при хорошем раскладе уже получим насыщенный данными препрод , где можно в том числе тестирование проводить
3. В момент перерезания красной ленточки - запуска в прод данные в новой системе будут уже актуальными и интеграцию можно будет отключить. В целом между шагом 2 и 3 можно увеличивать переодичность обновлений.