Preparing for Complex Integrated Project in CII Entities

Despite the fact that integration projects are always associated with certain risks and challenges, a modern company can hardly avoid them, as business development and the company’s competitiveness in the market depend on it. However, business software developer Bercut claims that the process can be more manageable and predictable if you approach it smartly at the planning stage.

Bercut, a Russian developer of a hybrid integration platform and business digitization partner with more than 28 years of experience in integration projects, shares its knowledge of how to be fully prepared for the implementation of such projects. In particular, how, by following certain rules and tested methods, to mitigate potential risks for the business, shorten the project timeframe and get the expected result in a user-friendly solution.

Demand for Integration

One of the most topical trends in the market, which penetrates all sectors of the national economy and has affected almost all existing business segments, is the import substitution trend. It has particularly affected critical information infrastructure (CII) entities, including financial institutions, telecom operators and other organizations. Today, most of these entities use Oracle DBMS, however, as of January 1, 2025, the government regulator requires them to switch to domestic software. For this purpose, companies will need to replace not only the technology stack, but also part of the equipment. Therefore, the substitution of a foreign product is a chance to review and implement a new approach to building the IT infrastructure of the company, where new integrations will play a significant part. 

But not only the trend towards import substitution encourages companies to engage in complex integration projects. There are also other reasons. 

In the past, IT product architecture reminded a monolith, a single unit. The software sometimes looked like a database with hundreds of connected features, which made it harder to scale. A multifunctional system packed with hundreds of queries, scenarios and tasks required more hardware, and the high level of component connectivity complicated its adaptability. In addition, the architecture of such solutions made it difficult to support and develop them in the future: adding a new feature to the monolith required understanding the intricate interaction and digging into every detail to eliminate the components’ possible impact on each other. Analyzing these connections consumed most of the time, increasing the T2M of any integration project, complicating the implementation of new features and incident analysis. This conditioned the internal decentralization of solutions and encouraged companies to shift towards modular architecture or microservices. 

As the number of digital services and disparate systems used in the IT infrastructure landscape grew, so did their capabilities. Solutions have become more complex, inventive, and diverse, as have the technologies behind them. As a result, the issues of support and timely upgrade of the technology environment, its uniformity and integrity for easy management and scalability have become equally important as creating new products.

 Partner products and collaborations play a special part in increasing the volume of integrations in companies. They require the utilization of a large number of different systems and processes, as well as access levels for all participants.

Just like the human world, where for each role there is the most competent and professional expert, each service is best tailored to perform a specific function. This is how companies came to understand that to solve particular tasks they should use the most relevant service that does not contain unnecessary data or operations. As a result, systems are getting more atomic, customized, and the IT products that use such systems now look like a mix of microservices and business processes, including partner integrations too. As the trend grows, the challenges related to integrations, interaction protocols, their features, interfaces and transportation emerge. In fact, authorization feature can be implemented differently in different systems. Hence, we arrive at the main question of any company that wants to develop by digitization: how to simply, quickly, and yet manageably assemble all the components into one functional product that will be easy to operate and maintain in the long term.

Preparation for Integration Project

Every company planning an integration project will already have a certain set of services and systems in its IT framework. Some of them come from a vendor, some have been developed in-house, some were assembled from various products and implemented by an integrator. To avoid confusion in this diversity and to prepare for an integration project, one should follow four steps:

• First of all, think about what the company actually has. This requires an in-depth analysis and creating a list of all products and services of the company.
  
• The list should specify the purposes for which these services are used. We recommend defining their status and cataloguing them by type: active/inactive, in use/decommissioned, or perhaps under development. This way the company will have a good understanding of the current situation, of the available resources and their possible re-use in the future projects.
  
• Also, you must know the interface of each service, i.e. how they are provided. For instance, a REST microservice or a web interface. There may be non-standard proprietary protocols that will require additional work to integrate them. Without prior understanding of these specific details, it will be hard to meet the deadlines of the integration project.
  
• All projects are developed using a certain logic. The sequence of processes, such as data processing, query generation or notifications, must be implemented somewhere and described in BPM notation as a business process or Java code. The BRMS system formalizes and describes incoming events, requests and implementation principles, as well as reactions to these events through the UI.
  

This information is needed in order to take a more informed approach not only to the choice of methods for implementing new integration projects, but also to the development of each integration product.

Having a list of all microservices and components with their description and the principles of their APIs will make a significant difference in the speed of modeling an integration project. With the list and API description, it will be easier to understand which existing artifacts can be reused, thereby accelerating development and reducing T2M of every new feature.

Legacy Code

The IT environment of most companies has legacy technologies, systems or applications that are still in use. These systems have obsolete interfaces, interaction logic, protocols and design. However, companies are reluctant to abandon them for various reasons, such as cost or impracticality. Such business sectors as FinTech or telecommunications have components that utilize their own coding, tags, lengths, bit masks, etc., with specifications that barely fit on hundreds of pages. To be able to implement a microservice approach to legacy components, you need to pack legacy systems into a modern API and build a REST interface on top of it.

Enterprise service bus (ESB) can provide a uniform, common and understandable methodology for how systems interact with projects under development.

For instance, Bercut Hybrid Integration Platform, as well as many other platforms, contains a specific element, an adapter. This component serves to adapt from the uniform approach adopted on the platform to various proprietary protocols and interfaces. If a company needs to standardize interaction with legacy systems by equipping it with a modern API, the adapter will allow it to connect to services via Open API. Regardless of the code — Java, C++ or C — the adapter will convert the REST protocol calls into a set of calls, parameters and sequences as required by the proprietary system.

Security

For internal DMZ (Demilitarized Zone) products, security issues may be less critical; however, in a busy IT landscape, the authentication and authorization needs of services or processes are crucial. They influence the overall manageability and risk associated with the impact of existing processes on each other.

For example, a service is productive under a certain load and on a certain hardware. To avoid a scenario where a service is connected to a product with 10,000 requests per second ⎯ without approval of the person in charge of the service, without testing and HW reserve, causing its degradation ⎯ the systems must be isolated by means of API management systems, in particular, using the Gateway API.

The requests pass through Gateway API, and it serves for authentication and authorization. Also, Gateway API helps to limit the load and provide balance. So, when an employee needs to connect to one of the system, first they have to pass verification and authorization, hence, the load is predictable.

Benefits of Using Integration Platforms

• The majority of platforms have ready-made adapters to common technologies, such as queues or databases. Product adapters like adapters for CRM, 1C or various messengers may also be used in the solution.
  
• Different platforms have specific toolkits. They include various utilities, development environments, where employees can create adapters for proprietary systems.
  
• Platforms provide an array of related features, such as database simplification, a code generator that will provide a service or universal adapter based on database content, guaranteed delivery, encryption, long-running processes.
  
• The product built on the platform will have a uniform approach. Employees will be working with the uniform technology stack in terms of technologies, protocols, interfaces and microservices.
  
• Integration platforms are often equipped with tools to model products in the form of business processes or, as in the case of BRMS systems, in the form of event-handling scenarios, which accelerates T2M, simplifies testing and MVP creation.
  

Implement and Maintain

Sometimes a company successfully implements and launches a large integration project, but at some stage of operation a failure occurs. It becomes extremely difficult to find out the sources of the failure with so many systems. The reason is the diversity of components and methods of their management, different log writing, different formats, different level of detail.

How to avoid this?

Use platforms with uniform Operation and Maintenance (O&M) management systems, which enable the entire solution to be managed as a single entity. In such platforms, a special workplace is provided for the administrator; there the admin can see the solution scheme and monitor all nodes for operation and current load, receive failure notifications, and identify any problems. The tool provides easy and simple management, allows one to pull up the history of actions, if they caused a failure.

An integration project is much easier to maintain and operate when it is based on a uniform approach or implemented on a customized integration platform.

Conclusion

Following the four steps to organize your information will save time and money, and allow you to anticipate and prevent business risks at the early stage of planning.

“With comprehensive information about the company’s assets in the IT environment and a clear understanding which integration bus will be the basis for its development, the integration project takes on a clear and predictable form. Also, employees can focus on the practical task of creating requirements as specific use cases, organizing them into the logic of implementation, without having to jump to more complex technological levels,” comments Head of Bercut Platform Division, Konstantin Koptyaev.