Дело в том, что бизнес не формулировал каких-то конкретных НФТ. Была задача - уйти от outsource разработки в пользу собственной, чтобы быстрее двигать задачи силами внутренних разработчиков (сейчас сторонние команды могут сказать, что у них все разрабы на другом проекте, и что приступят к нашей задаче через неделю и т.п.). Для этого надо поменять текущую архитектуру. Как минимум, перенести все BBF на нашу сторону (пусть в виде отдельных сервисов или контроллеров к имеющемуся API). Фронты же менять можно будет потом и постепенно.

Если совсем расплывчато, я бы обозначил НФТ так (не очень конкретно):

1. Хорошая масштабируемость (при росте кол-ва клиентов, т.е. работы и трафика от них => та же производительность). P.S. Бизнес такой, что рост клиентов постепенный и плавный. Тут резких скачков, как правило, нет.
2. Безопасность на таком уровне, чтобы критически важные модули были изолированы.

Подскажите, о чем еще надо подумать? Какие конкретно вопросы задать бизнесу, чтобы наиболее безболезненно потом строить новую архитектуру?

Бизнес про НФТ не знает, для него это матерные слова. Бизнес знает, сколько он готов потерпеть если сервис упадёт и сколько он готов внести заново руками если БД умрёт навсегда и придется восстанавливаться из бэкапа... Остальное - это как сапёр с завязанными глазами. 😄

То есть мы сами себе НФТ определяем?)

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

>Бизнес знает, сколько он готов потерпеть если сервис упадёт и сколько он готов внести заново руками если БД умрёт навсегда и придется восстанавливаться из бэкапа.

Это и есть НФТ.

На своих разрабов есть управа, на чужих - нет

Вам так кажется. Пока их мало и они работают по небольшому потоку заявок. Загоните себя на тушение пожаров в итоге.

Опять, если у вас сервсов мало, то я ошибаюсь. Но если много, будет так, как я говорю.

Тут нужно все очень сильно менять, а не перезжать на собственный отдел с написанием НФТ.

Исходя из прошлого опята, бизнес готов терпеть падение сервиса порядка нескольких минут (что вроде более чем достаточно для его поднятия в большинстве случаев). А вот смерть БД - такого еще не было, хотя ежедневные бэкапы БД делаем.

Очень сильно, это как, например?

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

Это все довольно дорого, если ваш бизнес не есть ИТ услуги.

У нас уже который год не могут выбить финансирование на расширение штата программистов, а вы про CIO с SRE)

В том то и дело, что не ИТ

CIO, кстати, есть

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

Так outsource'у тоже платить приходится. И работу они оценивают недешево

Он понимает в требованиях, разработке, инфраструктуре, проектном уравлении, итил, сервисах для компании, архитектуре, моделе данных (все сразу и на приемлемом уровне). А главное в капризном ИТ персонале?

Само с собой, но переезд на "свое", стоит дороже первые года три. Потом можете на плато выйти, если собрать команды и уметь с ними работать. Что тоже риски.

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

Я риски озвучил. Дальше двигайтесь как считаете нужным. Тут вопрос "Зачем". Цель предприятия увеличить выработку, сократив запасы и излишние операции. Ну и сбыт.

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