Managed chaos is the IT landscape of the future

Managed chaos is the IT landscape of the future. Formation of micro-teams, restructuring of business processes, creation of an API-centric architecture.

How the IT department can respond to the challenges of the times. In recent years, the challenges facing real businesses have become less and less predictable. The current situation requires business and IT departments to respond more quickly to constant changes.

How to deal with this state and how can IT departments keep up with all external requests?

In addition to external challenges, a common ecosystem contributes to the joint treasure, within which all large and medium players are trying to predict the future, trying to survive, continue their development, and build their own internal ecosystems.

How is IT responding to these challenges?

The main basis on which we rely when implementing the strategy for technology departments is the task of forming micro-teams. This idea is far from new, but its essence is that the final decision on a particular issue can be made within the microteams themselves, and not after the issue reaches higher levels in the corporate hierarchy throughout the organization. string.

The decentralization of decision-making leads to the fact that the microteam has full right and proper authority to make final decisions and is itself responsible for them. And this is the number one challenge for IT departments in the 21st century.

This concept has obvious advantages:

Any problem is solved much faster and you are not stuck in the “bottleneck” of decision making at the highest level. Micro-teams can do mini-releases independently, meaning work on a large broken IT product can be done in parallel, rather than sequentially, greatly speeding up the process.

The right to make decisions allows microteams to conduct constant experiments within themselves, which means that they have the opportunity to find optimal solutions for the development and maintenance of IT products.

At the same time, microcommands can and should be interchangeable: if one fails, the others don’t depend on it and continue to work, and it will take several times less time to replace a microcommand than to replace a large command.

The second task is the formation of a corporate IT architecture that allows the company to introduce new services as flexibly and quickly as possible and successfully solve new problems, regardless of the degree of turbulence in the market as a whole.

In this sense, the so-called microservices architecture has proven to be the most effective, in which the orchestration of the interaction between systems located in the IT landscape of a certain company is carried out on the basis of APIs.

Interaction between microteams, product teams, and any other teams already occurs at the API contract fulfillment level. Furthermore, the API-centric architecture is the solution to any product problem.

The question arises, how are various products implemented on such an architecture? Due to the fact that the final implementation at each API point can be replaced at any time, the company has the opportunity to use the products of one software manufacturer today and another tomorrow, three days later, and so on.

Because API-centric architecture implies that the API contract doesn’t change, but the implementation behind it can. This is how a certain API façade is built, in which everything can be changed quickly without damaging existing processes and the environment.

At the same time, the technological radar must be formed based on what the situation will be like in 3-7 years. The turbulent state you are in now will not go away during this time.

Therefore, any architecture must be built in such a way that all possible changes within it can be implemented without interfering with the operation of the rest of the environment. This is perhaps the most important point.