A Tool for Keeping the Business Young

Business is often compared to a living creature: it is born, grows, ages, and dies. However, business has unique advantages compared to a human being, for example – a business is much easier to rejuvenate, whereas for people the eternal youth is still a point of concern (and multiple explorations).

Business can be rejuvenated on several levels. This time, let's focus on the question of whether – and how exactly — it is possible to keep the company's IT infrastructure young so that the business is not at risk for bottlenecks.

It seems as if there is nothing special about it – this is what the business expects from its IT infrastructure. However, the reality is not always consistent with the youth standards.

No IT infrastructure is born clumsy, heavy, and poorly scalable. This is what it becomes gradually – as new systems and integrations are being added to the IT contour. Any expansion of the IT infrastructure automatically increases the system's entropy – the question is to what extent. To answer this question (and crack the secret of youth) we should take a look at the IT architecture.

Let's consider a couple of examples of an aged e-Commerce infrastructure – as a rule, these companies are very indicative, because they work at a change-sensitive market and have to adapt.

In one of the cases, we came across a structure where the product information was moving as described below.

Before it's loaded to a third-party website, the information passes through two additional systems and two additional integrations. Meanwhile, data collection, processing, and transforming is performed by systems that were not originally designed for this.

Such an allocation of responsibilities to different systems was quite justified as long as there used to be only one website. But in its current form, the mobility, flexibility, fast and error-free transmission of information are hardly optimal.

Or, another classic example – an ecosystem with point-to-point "star" integrations.

In this case, the quick formation of new connections is also problematic. The integration of each new system becomes a longer and more time-consuming; the slightest changes in systems or business processes require large-scale and expensive improvements.

It's not rapid or immediate. Just like a human, it is not born old and at the beginning it only has preconditions for age-related changes. It becomes old – in other words, difficult to update, clumsy, inflexible  over time.

Eventually, the infrastructure dies – some data blocks become immutable, despite the ever-changing business requirements. When deciding on a change, the business takes into account all the limitations due to its data systems.

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

As long as there are not so many systems and integrations between them, the difference in the integration support costs in service-oriented and monolithic architectures is not critical. But as the number of integrations is increasing, and their connections in a monolithic architecture evolve and get more complex, the difference becomes more noticeable. And over time, things are getting worse.

As you can see from the graph, in a service-oriented architecture, the time for integrations support increases in direct proportion to their number, whereas in a monolithic one it grows parabolically. And if you think that your architecture is not monolithic and that's not your case, try to remember if you've ever dealt with the following situations:

If at least one of these cases is familiar to you, most likely, you do have a monolithic architecture, though it might be very similar to SOA/MSA.

As a result, the aged infrastructure becomes one of the main obstacles for digital transformation, business scaling, business model changes... and for any more or less large-scale change in the company's life.

Without preamble – yes, it is possible. But, you will have to go back to the level of architecture and change the very approach to the information movement.

To ensure the IT ecosystem's capacity for change, each system must have capacities for change and independent development. If you want to replace one system with another, ensure that it can be implemented without problems, and the scale of changes will only apply to a specific service in your company.

How to ensure it in theory?

So, let's proceed with the problem of weak connections. In service-oriented architectures (MSA included) a message exchange location is of critical importance. We believe that the creation of ESB layer (i.e. enterprise service bus layer) is the most effective way to rejuvenate the company's IT infrastructure.

Previously, we've talked about the ESB layer and advantages it gives to a company in the related articles: "Service bus as an evolutionary advantage for company's development" and "Comparison of Popular ESB solutions". Therefore, here we'll only describe how the ESB use helps keep the IT infrastructure young.

One of our clients, a large European brand of household appliances, approached us with the task of integrating a PIM system for centralized storage and processing of information about goods into the company's IT contour. Here's the simplified diagram of client's original IT infrastructure, which processed data about goods, orders and balances.

Adding a PIM system to this structure could help the customer to remove extra and untypical functions from some of the systems and reduce the load on the online store. The local task would be solved, and the online sales channels would receive the most complete and reliable information about the brand's products, including technical parameters, photos, descriptions, information about the product availability, related products, etc.

At the level of business goals, the customer was not only thinking about adding a new system to company's IT contour. First of all, he focused on expanding his online presence and increasing online sales. This requires the provision of correct and sufficient information about the products. But in the long term, the customer wanted to be able to quickly add new sales channels and independently configure data transmission in accordance with the requirements of a new channel (attributes, format, etc.).

Therefore, kt.team specialists offered the client to improve the IT architecture and integrate an ESB layer based on WSO2 into it.

The tasks for ESB:

Instead of writing dozens of integrations to connect a new sales channel, all you need is several jobs.

WSO2 is a low-code platform with a graphical interface. Therefore, the customer will not necessarily need to contact an IT company for new integrations – integrations can be developed by business analysts or managers with enough competence.

Integration of a new marketplace will become significantly less time-consuming.

The architecture, which is centered around the online store, is contrary to the task of the IT infrastructure youth preservation. After all, first off, such an architecture implies that the online store would be assigned some untypical functions: data bus, PIM, etc. And secondly, the inevitable replacement of the central element – in our example, the online store itself – for the sake of rejuvenation would become extremely complex and expensive.

We would like to emphasize that the ESB bus and the message broker are not the same thing.

We often find that Kafka, RabbitMQ or code-first buses are equated with low-code ESB. This is fundamentally wrong. Only the systems that allow the IT department to check any integrations in a growing IT contour can be considered modern buses. All these are considered an integral part of a contemporary integration bus the same as apart from having standard engine, transmission and seats, a contemporary car would be equipped with air conditioning, speaker system, ABS and much more.

Do you want to get more useful materials?
Subscribe to our newsletter!

News of the world of design and development, articles, and our latest cases.We write about complex things in simple words — without ads or spam.