Как выбрать решение по интеграции?

Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территорию подвинься щенок, не задавай мне такие вопросы!

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

Попробуем разобраться вместе.

Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ, подозрительно на которые нет ответов. Как-то на проекте я спросила, почему купили шину IBM, а не ORACLE? Мне сказали, тсссс! Молчи! Нашему инвестору IBM красивую презентацию показали и ужин устроили и ещё то, чего мы не знаем. И не говорим вслух...
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!


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

И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.

Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:

✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.

И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.

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

👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀

#интеграция #челлендж #выборрешения