Microservices: Blurring the Lines Between Business and Development

Hello! In continuation of my articles on the topic of microservices, I decided to highlight the important issue of the relationship between development and business in general.

Why is the interaction between business and development important?

In a rapidly changing market and growing customer expectations, successful (and not only) companies must strive for flexibility and adaptability. High-quality interaction between business and development allows promptly respond to changing customer demands and market trends, thereby maintaining competitiveness.

Promptly often means that we (the business) speak the same language as the development team.

“Speaking the same language” – this is what most IT structures often (always) lack. Of course, all the problems cannot be fixed, because the products in the IT world are different, and the methodologies used as a generalization of the context between business and development are effective for one, but at the same time, not effective for the other, although the products are from the same IT world, so to speak.

If we move a little away from the topic, I would like to say that often in such situations there is a chain in the form of managers who accept information in the language of business, and give out information, for example, for development in another language, and often a broken phone comes out.

So, Microservices are certainly not a panacea, but they can solve this problem quite well. free.

How do microservices solve this problem?

By and large, the rigor of this architecture allows us to reduce communication gaps between business and development, because if we are talking about, for example, a monolithic architecture, design and development often occur according to the hierarchy of “we have accepted what needs to be done, we are developers, we do it” – and when it comes time to ask a question from development to business, the business says that it does not understand anything, and let's explain it to fingers. (not always natural, I don't want to say that there are projects with monolithic architecture that don't do this, but we all understand that it's often the other way around)

So, in a microservice architecture, the hierarchy is usually like this (very abbreviated, but I think it should be clear):

1. Top management transferred the necessary data to the analyst for processing

2. Analytics made decisions and built a scheme of interactions and worked out solutions

3. Transferred to development…

And in this chain, since analytics speaks to development in the same language as business speaks to analytics, there is an opportunity to return the necessary data/questions/whatever up to top management along this “food” chain from development, without the effect of a broken phone.

Of course, we all live in an ideal world, where everything happens like this =)

Also, the fact that our application is essentially divided into separate business models (domain models, if you like) and aggregators, and this is understood primarily not only by developers, this also solves this very problem. Of course, by and large this problem is solved not so much by microservices, as it was solved by Uncle Eric Evans with his DDD, but “by mixing this explosive mixture in a glass, you can get a completely correct drink.”