Integrating Solutions and Their Business Impact

Application integration has evolved, transitioning from architectures where all systems communicate with each other, known as spaghetti architecture, to what we have today: the establishment of integration buses, data normalization, and data modeling for integration, as well as the establishment of integration patterns.

In today’s technological world, including the cloud, even more technologies and tools have been enabled, which in turn has led to the development of better integration practices. Specific integration protocols have emerged, such as:

• SOAP
• HTTP-based REST API
• HTTP-based GraphQL

If you stop to think about the evolution of this text from the first paragraph to these letters, you can appreciate that the fundamental change is a paradigm shift, moving from disorder and lack of standardization (spaghetti) towards organized standardization. The reason: order saves time, and standardization prevents confusion.

All these efforts to standardize application integration involve a lot of effort, including the importance of understanding the need for defining and establishing a proper practice for application integration and this idea must be understood by the project team members and the rest of the project participants.

On many occasions, we have seen that each application team taking part in a bigger solution focuses on meeting and developing only its component requirements. Therefore, the integration phase is seen as something generic, where the destination applications only need to comply with a standard integration format and the proposed API. All of this leads to superficially defined the below list of items during the design phases:

• Integration patterns between applications
• Definition of data models governing integration
• Detailed analysis of the fields needed to be sent from application A to B, which generally causes a lot of rework, and the less attention you pay to these details, the more rework is generated.

As mentioned above, the previous point generates, in later stages of the project, rework since situations like the following usually appear:

• Missing fields, meaning information that system A does not send to B. For example, information that in the testing phase is identified that the CRM is not sending to the billing system, or the billing system does not send to the ERP, information later necessary for electronic invoicing, accounting, proper charge collection, etc.
• Incompatible formats, there are many of these, but the most common example is date format. System A defined YYYY-MM-DD, and system B defined YYYY-DD-MM. This causes problems in future processes that depend on the date, such as cut-off dates, for example. MM/DD is not the same as DD/MM. The first would be January 3rd, the second would be March 1st, almost two months difference due to such a simple error. This error could even go into production if tests are not exhaustive.

Therefore, considering a space in the project plan and solution definition for application integration ensures the minimization of these and other common errors, as well as allows:

• Standardizing how applications will communicate in the future, simplifies the analysis phases if the new requirement adheres to established integration statutes or standards. More importantly, allowing for a sustainable architecture over time that allows for adaptation to the future.
• Ensuring optimal performance of the solution from the start of the project, is achieved by defining appropriate integration patterns between components. We have seen, for example, where choosing online communication for a system that is designed to receive a high level of transactions causes services to fail at peak times of the month, causing a loss of business continuity. Something that could have been avoided simply by integrating through queues and not processing everything online in real time.

At CONGERO, we understand the importance and the need for application integration. That’s why among our strengths and capabilities you can find the integration area, the development of application integration, both on-premises applications and cloud solutions, as well as the implementation of integration frameworks or tools. We understand the importance of defining the correct integration patterns for situations such as:

• Orchestration of service provisioning orders: You have an order that involves setting up the service on various platforms or orchestrating activations and notifications in various satellite systems. In these cases, information standardization is fundamental, as well as understanding if the best integration method is online, fire and forget, queues, pub-subs, etc.
• Information mediation: This is a very common scenario, where a source of information serves information to various destinations, or various sources serve a destination. Especially in the latest scenario, several sources, and one destination, it is a good practice to standardize information, define a format, and a normalization integration layer to standardize concepts, formats, etc. So for example, if you have a telco that has several platforms and in one platform a field is called contract, in the other phone number, in the other account, but all serve the same and only purpose at the business level, then your mediation layer will call it, say, contract identifier, and from then on all the information consumers will understand that that is the use they must give to that field, no matter where it comes from or how the other system names it.
• Cloud application integration, whether cloud to cloud or one cloud, each provider, especially the most important ones in the industry, has defined and made available to their customers’ data processing tools that serve various purposes, real-time communication (lambda, google functions for example), streaming (stream analytics, AWS MSK, Kinesis, Google Data Flow, datastream, etc), batch processing (data proc for example), understanding when to use each one is fundamental in developing a sustainable solution architecture over time.

Over time, we have become true masters of integration, for both our solutions and third-party solutions. The reason: We understand the importance of order and standardization, and we understand the influence of these aspects and their impact on the business.

How does all of the above translate into business:

The IT area will be able to respond more quickly to the natural evolution of the business, as its technology and architecture are designed for the future, for flexibility and change. Imagine an architecture where everything is tied, and integrated in such a way that to make a new legal requirement comply, you need 5 months of implementation, and it turns out that the change is just adding one more field to the invoice. Why 5 months? the business team will ask, and the answer, because nobody understands the communication spaghetti between the components, but this is a secret between you (the reader) and me (the author).

Answering quickly to the business means that each of the solution components or applications teams understands the business and its role, so they understand what information to serve and make available to the business, to their stakeholders, and their final customers. Therefore, integration must serve and provide standard channels so that information can go from point A to B in the fastest, understandable, and correct possible way.

The definition of a proper integration architecture, as well as its implementation, is aimed at seeking Zero Downtime (always online), which in many cases is not achieved due to server overload errors, server slowness, and many other problems related to volume processing, something fundamentally related to customer satisfaction and service delivery quality. When you understand the workload pattern as well as the nature of the business you will be enabled to properly define how to integrate applications at each required integration point.

Join our LinkedIn network and share your thoughts!