How to properly integrate multiple systems in a company?

Question

C++ / C#

Good afternoon!

The company has several separate systems, for example, "Human Resource Management System" (Human Resources), "Help Desk System" (Support) and "Contracting System" (Contracts).
The Contracts and Support system requires data on employees from the Personnel system, and the Support system requires data on the contracts of the users who applied. And so on, in reality the number of systems > 5 and
they must be connected to each other. All systems are web systems and are developed on ASP.NET MVC.

The question is what is the best way to ensure the interaction between systems?

I am considering the following methods:

I. Service Libraries

This is the current approach.
Separate .NET service libraries are written for each provider system).
For example, a module has been created for the Kadra system, the interface and implementation of which, in a simplified form (remove ORM, other dependencies, etc.), may look like this:

public interface IStaffService 
{
  EmployeeDto GetEmployee(int id);
  IEnumerable<EmployeeDto> GetEmployees(EmployeeQuery query);
}

public class StaffService
{
  private string _connectionString { get; }

  public StaffService(string connectionString)
  {
    Ensure.NotEmpty(connectionString, nameof(connectionString));
  
    _connectionString = connectionString;
  }
  
  public EmployeeDto GetEmployee(int id)
  {
    // use _connectionString ...
  }
  
  public IEnumerable<EmployeeDto> GetEmployees(EmployeeQuery query)
  {
    //use _connectionString ...
  }
}

These libraries are hosted in the corporate NuGet and installed in the required applications. For example, the specified IStaffService will be installed via NuGet into a project with the Contract system and will be called. In general, all this is done in order not to write such a service in each system (the same everywhere). It turns out a kind of API only on the backend.

The main pros and cons of this approach:

Pros:

• Work speed. The work is carried out in exactly the same way if these methods were written in the system itself;
  
• Simplicity of emulation for tests.
  

Minuses:

• Obviously, the client system using such a service must have access to the database, since you need to specify the ConnectionString;
  
• Duplication of business logic is possible - once in the system used, the second time in its service module;
  
• When fixing the logic of a method, you need to update the NuGet package on all systems that use it and redeploy these systems to prod.
  

Now this current solution is subject to strong doubts in its further use due to the described disadvantages.

II. REST API

API in every system. And accordingly, consumer systems pull the methods of this API to receive data.

The main pros and cons of this approach:

Pros:

• Complete encapsulation of business logic. Everything that concerns the system is written only in it. You don't need to do any third-party libraries for this;
  
• Unlike the previous method, if the logic of some API method is corrected, there is no need to update something in other systems. They both used the API method and use it, only now it receives the correct data.
  

Minuses:

• Work speed. network costs. Data is exchanged over the network in json format;
  
• In the implementation in which I now imagine it, in order to connect the Contracts system, it began to consume the Frames system API - it is necessary not only to register endpoint, client_id and client_secret in the Contracts system, but to enter similar information into the Frames. It turns out that if a new consumer appears, you also have to make changes to the supplier system (to its configuration).
  

III. Enterprise Service Data Bus (ESB).

Take MassTransit/NServiceBus/EasyNetQ and RabbitMQ/Kafka and implement messaging between systems.
But to be honest, this whole story with queues seems too cumbersome for the current conditions.

The question is:

Colleagues, please share your thoughts or best practices - How to connect N systems (provided that the systems are not very large), which approach is better to use? Perhaps you should do something differently?

Thanks for the help and advice!

Answer 1

All options are valid in their own way and there is no "correct" path here.
1. The problem may arise if the system database changes or some additional validation is needed
2. It seems ok, but you need to add and maintain methods in each API, and monitor compatibility
3. An additional link in the infrastructure. You will have to spend money on deployment and support, and pay with delays.
I would choose the API option, as it seems to be the most adequate in terms of price / quality ratio.

Answer 2

Hello,
The problem exists in almost all enterprises, but usually these are different systems, such as 1c for frames, self-written c # according to documents, and some kind of ready-made open-source support system in php. Your version is that everything is written on the same technology, use it, wrap it in the library nuget.
About esb - all queues are used for data synchronization. That is, a certain employee in your frames has changed, it is not saved directly in the database, but through a queue. Other systems are also subscribed to this queue, and the employee entity is updated in all systems that store duplicates of the data they need. As you understand, there are a lot of overheads and emergency situations. This needs to be monitored and somehow restored / downloaded data. Nevertheless, this is the most correct option, because otherwise data synchronization is done with hacks through views / jobs / storages and as soon as they don’t do it disgustingly. In general, if you have enough skills - do it, there will be independent working applications.
As for communicating through api, there are no problems with some small and atomic operations. Problems start when _distributed transactions_ are needed, google about it, how it is implemented and evaluate how much harder the development will be. The second problem here is reports, stupidly joins. You need to unload some kind of consolidated information from one system, you do, but you only have user IDs in it. Either you send these IDs to the personnel service and get detailed information for each, or for each such request, you generally load the full list of users. And then they also say that you need to exclude data on users during their absence. Again, this data is in the personnel service and, in general, you need to sculpt some kind of big snowball not from snow. Okay, if it's a question with reports,
According to the shared services option, I support it because of its simplicity:
You need to store connection strings in each project - this is not a problem
. You don’t need to duplicate business logic, take it out to shared services as well.
Both servers will need to be updated if there is a bug in the common service. Here the conversation, obviously, is about a "bug on the production" - because of the common code, there will be a bug on both productions. Okay, how often do you have such situations and how long does it take to update two sales instead of one?

Answer 3

Only one system, and no more! At least from the user's point of view. If we talk about implementation, it is better to proceed from the characteristics of the company and systems. Usually, managers act as data carriers between systems and do just that and get paid for it.
If in a smart way, then you need to layer the systems into components, then combine the same components (for example, a database) into one + think over a competent API that is convenient for all systems.