Микросервисы. Стирание границ между бизнесом и разработкой

Привет! В продолжение своих статей на тему микросервисов, решил выделить важный вопрос отношений разработки и бизнеса в целом.

Почему важны взаимодействие бизнеса и разработки?

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

Оперативно — часто значит, что мы (бизнес) говорим на одном языке с разработкой.

«Говорить на одном языке» — именно этого очень часто (всегда) не хватает большенству IT структур. Конечно, всех проблем не исправить, ведь продукты в мире IT есть разные, и методологии применяемые в качестве обобщения контекста между бизнесом и разработкой эффективны для одной, но в то же время, не эффективны для другой, хотя продукты из одного IT мира так скажем.

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

Так вот, Микросервисы — конечно не панацея, но решить данную проблему вполне вольна.

Каким образом микросервисы решают данную проблему?

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

Так вот, в микросервисной архитектуре, чаще иерархия такая что (очень сокращенно, но думаю должно быть понятно)

1. Топ‑менеджмент передал аналитике необходимые данные для обработки

2. Аналитика приняла решения и выстроила схему взаимодействий и проработала решения

3. Передала разработке…

И в данной цепочке, поскольку аналитика говорит с разработкой на одном и том же языке, что и бизнес с аналитикой, есть возможность вверх по этой «пищевой» цепочке от разработки вернуть необходимые данные/вопросы/все что угодно до самого топ менеджмента, без эффекта сломанного телефона.

Естественно, все мы живем в идеальном мире, где все так и происходит =)

Так же, факт того что наше приложение по сути разбито на отдельные бизнес модели (доменные модели, если угодно) и аггрегаторы, и это понимают в первую очередь не только разработчики, это так же решает эту саму проблему. Конечно, по большому счету эту проблему решает не столько микросервисы, сколько решил её дядюшка Эрик Эванс, со своим DDD, но «смешав в стакане эту гремучую смесь, можно получить вполне корректный напиток».