A tool that will help keep your business young

Business is often compared to a living organism: it is born, grows, grows old and dies. But business has a pleasant difference from, for example, a person: it is much easier to rejuvenate them, while for people, the issue of eternal youth remains sensitive (and unresolved).

Business rejuvenation can take place at several levels. Today we will focus on the question of whether and how exactly it is possible to keep the company's IT infrastructure young so that it does not become a bottleneck for business.

‍

1. Upgradeable — in IT infrastructures, it corresponds to the ability to scale or replace existing systems with newer ones or those suitable for current business goals relatively quickly and without loss for business processes.

2. The ability to quickly transfer and process information — this is as important for IT as for the nervous system.

3. Rapid formation of new neural connections — that is, creating new integrations and revising existing ones.

4. Quick response to changes in the external environment — the market is changing, new operating rules are being formed, new restrictions and challenges are emerging, and the IT infrastructure must respond to them as quickly as possible. Otherwise, the business will become obsolete and risk closing.

5. Good memory — The closest, though not entirely accurate, analogy in IT would be event logging, i.e. “remembering” everything that happens to files and messages. In the IT infrastructure, the best option is when event logging is uniform, all events are recorded and easy to track.

Signs of a young company's IT infrastructure

In one of our previous articles, we compared the company's IT infrastructure to the nervous system. This metaphor also seems successful to us in the context of young and old business. Moreover, the properties of the young nervous system are also fully characteristic of a young IT infrastructure.

It would seem that there is nothing extraordinary — this is what businesses expect from their IT infrastructure. However, reality does not always meet the standards of youth.

Age changes

IT infrastructure is not born clumsy, heavy and poorly scalable. It becomes like this gradually — when new systems and integrations are added to the IT circuit. Any expansion of the IT infrastructure automatically increases the entropy of the system — the question is how much. And the answer to this question (and with it the secret of youth) lies in architecture.

Let's look at a couple of examples of aged e-commerce infrastructure: companies in this area are usually very significant because they operate in a market that is sensitive to changes and are forced to constantly transform.

In one case, we saw a structure in which product information moved along the next path.

Before getting to the third site, information must go through two additional systems and two additional integrations. At the same time, systems that were not originally designed for this purpose were engaged in collecting, processing and transforming information.

While there was only one site, this distribution of “responsibilities” between systems may have been justified. But in its current form, it is difficult to talk about mobility, flexibility, and fast and error-free transfer of information.

Or a classic example — an ecosystem built on the “star” principle, with point-to-point integrations.

Here, too, there is no need to talk about the rapid formation of new ties. The integration of each new system is becoming an increasingly time-consuming and time-consuming process; the slightest changes in systems or business processes generate large-scale and expensive improvements.

How is IT infrastructure aging?

Not all of a sudden and not right away. Like a person, she is not born old and at the initial stage only has the prerequisites for age-related changes. It becomes old — that is, difficult to renew, cumbersome, inflexible — over time.

• When the number of systems and integrations in the IT infrastructure exceeds the critical value. For a company with 500 employees, for example, it is quite normal to have dozens of systems in the circuit. And there are hundreds or even thousands of point-to-point integrations connecting them. With each new system and integration, the system becomes less flexible.

• When the path along which information moves is lengthened and complicated without an objective basis. The longer it is, the higher the likelihood of errors, losses and distortions of information. And there are fewer ways to track exactly where and why the error occurred.

• When the company's main business processes are tied to outdated systems in whole or in part. It seems that it is impossible to replace these systems painlessly.

Ultimately, infrastructure dies: some information blocks become impossible to change, despite changing business requirements. When making decisions about changes, businesses are increasingly looking back at the limitations of their information systems.

All this is described by the complexity curves of changes in monolithic architecture.

While there are not so many systems and integrations between them, the difference in costs for supporting integrations in service-oriented and monolithic architectures is not critical. But as the number of integrations increases and their interdependence in a monolithic architecture becomes more complex, the difference becomes more noticeable. And it only increases over time.

As can be seen from the graph, in a service-oriented architecture, the time to support integrations increases in direct proportion to their number, and in a monolithic architecture, it increases along the parabola. And if you think that your architecture is not monolithic and this problem will not affect you directly, remember if there have been any cases in your practice:

• when a change in one system affected a change in another system;

• when the interaction between systems became the object of knowledge of the finite systems themselves (i.e. upgrade such systems are equal testing the operation of other related systems, which brings us back to the previous point).

If at least one of these cases is familiar to you, you probably have monolithic architecture, even though it looks a lot like SOA/MSA.

What does the presence of a monolithic architecture lead to? Within the existing infrastructure, it is becoming difficult to change systems along with businesses. More and more time is spent on supporting systems and integrations and less time on development. To improve the situation, the company is introducing new systems or tools that meet specific needs. But in fact, such implementations do not become a systemic solution — they only tactically solve the problem for a particular department, and only exacerbate the problem.

As a result, the aged infrastructure is becoming one of the main restrictions for digital transformation, business scaling, changing the business model... and, indeed, for any more or less large-scale change in the company's life.

Possible reasons for the “aging” of infrastructure

• When the architecture was developing, which was prone to aging, the company did not think about developing IT infrastructure and planned to focus on 3-5 of the most necessary systems. But over time, business requirements forced us to review the number of systems and their functions, which was not taken into account by the original architecture.

• The alternative architecture seemed impractical and expensive; its implementation was postponed until “later”, but “later”, as the infrastructure grew, refactoring was considered expensive and time-consuming, and the scale of refinement was unaffordable for the company.

Is it possible to keep the IT infrastructure young?

Without long prefaces, yes, you can. But to do this, we will have to return to the architectural level and restructure the approach to information flow itself.

To ensure that the IT ecosystem is able to change, each system must change without regard to others and go its own way. If you decide to replace one system with another, you should do it without problems, and the scale of changes will be limited only to a specific service provided by your company.

How can this be achieved in theory?

1. There shouldn't be giant all-in-one systems. If one of your systems already works on this principle, consider what functions should be transferred to other systems that will be responsible only for them.

2. The systems must be loosely interconnected.

What is a weak connection? Everyone understands what the service does, but it uses abstract messages rather than specific messages for exchange. For example, a service needs to submit a bundling order, but other systems do not “know” in what form the final service expects the order: a file, an API, or a record in a shared table. They also don't “know” what nuances they need to provide for transforming attributes. Perhaps the service is expecting an address in the form of CLADR, and it came in as a text string. This will be a problem for the integration layer, not for finite systems.

So let's move on to the problem of weak connectivity. In service-oriented architectures (including MSA), the place to exchange messages is a critical feature. In our opinion, building an ESB layer (i.e., an enterprise service bus layer) is the most effective solution for rejuvenating an organization's IT infrastructure.

We wrote in detail about what the ESB layer is and what it provides to the company in previous articles:”Service tire as an evolutionary advantage for the company's development” and”Comparison of ESB solutions that are popular on the Russian market”. Therefore, here we will only look at how the use of ESB helps keep the IT infrastructure young.

1. The ability to upgrade. You don't need to redesign the entire architecture to add or upgrade a specific system, or connect an additional sales channel or a new supplier. You need to connect them to the ESB layer and refine the jobs (or write new ones). This is instead of dozens of integrations between systems. The gain in time and money is huge.

2. The ability to quickly transfer and process information. Let us recall a scheme with a long chain of information transfer between Bitrix and three sites. With ESB, the scheme would look like this.

The speed of processing and transmitting information in this scheme is tied to ESB, a layer that was originally designed for these actions and is focused on highload. Changes in prices, product descriptions and inventory balances are simultaneously displayed on all sales channels and do not “get stuck” in intermediate systems.

3. The rapid formation of new connections. It is much faster to think through the logic and integrate the system via ESB than to think through and write dozens of integrations for all the necessary relationships.

Point-to-point integrations are usually carried out by development teams that focus on a separate system, and they implement the integration logic through the prism of the chosen system. The situation with integration via ESB is different: the development team is focused on business logic and is only responsible for transferring information from its system to the bus and back.

4. Quick response. This point is closely related to the previous one. The faster new integrations are formed, the more quickly the company reacts to external circumstances with IT tools and the faster IT comes into line with new business processes.

5. A memory. Logging and storing information until delivery is part of the very concept of the ESB layer and is implemented using internal and external tire tools.

The ESB layer easily organizes the recording of everything that happens to information, whether it's product data, messages from marketplaces, or customer details. At the same time, the tire takes responsibility for delivering messages and stores them until they are successfully delivered. If the process wasn't completed for some reason, logging makes it possible to understand what went wrong and fix the cause, without the message itself going away.

The decision in favor of ESB

One of our clients, a major European brand of household appliances, came to us with the task of integrating them into the IT circuit PIM system for centralized storage and processing of product information. At the time of the request, the customer's IT infrastructure, which is responsible for data on goods, orders and balances, looked simply like this.

By adding a PIM system to this structure, the customer would be able to remove unusual functions from some systems and reduce the load on the online store. The local problem would be solved, and online sales channels would receive the most complete and reliable information about the brand's products: specifications, photos, descriptions, information on the availability of goods, related products, etc.

At the level of business goals, the customer thought not only about adding a new system to its IT circuit. He primarily focused on expanding his online presence and increasing sales via the Internet. Correct and sufficient product information is required for this purpose. But in the long run, the customer wanted to quickly connect new sales channels and customize data transfer in accordance with the requirements of this channel (attributes, format, etc.).

Therefore, kt.team specialists suggested that the client finalize the IT architecture and integrate an ESB layer based on WSO2 into it.

What the ESB will do:

• collect all data on products, orders, prices, balances, customers, etc. from systems that are part of the company's IT circuit;

• combine and/or convert collected data;

• transfer data to both internal systems and online sales channels.

‍

At the same time, you don't have to write dozens of integrations to connect a new sales channel — several jobs will be enough.

WSO2 is a low-code platform with a graphical interface. Therefore, the customer will not need to contact an IT company for new integrations — business analysts or managers with a sufficient level of competence will be able to create an integration.

At the same time, it will take several times less time to integrate the new marketplace.

The architecture, which focused on an online store, is contrary to the task of keeping the IT infrastructure young. After all, in such an architecture, an online store would be assigned unusual functions: data bus, PIM, etc. Secondly, the inevitable replacement of the central element — that is, the online store itself — during rejuvenation would become as difficult and expensive as possible.

We would also like to note that an ESB bus and a message broker are not the same thing.

We often notice that Kafka, RabbitMQ or code-first tires are put on a par with low-code ESB. This is fundamentally wrong. Only systems that allow the growing IT department to test any integrations can be considered modern tires. This is part of the modern definition of an integration tire as much as the modern idea of a car includes not only the engine, transmission and seats, but also air conditioning, sound system, ABS and much more.