- SYSTEM INTEGRATION
Why system integration needs its own place
Additionally integration needs a new awareness
- •
- Hans-Jürgen von Henning
– Abstract
Challenges and risks of integration projects
Integration projects not only entail risks, but above all pose a whole series of challenges for IT organizations. A clear integration mindset is key to enabling organizations to recognize, understand and address the series of challenges and risks modern integration entails. Integration is the act or process of uniting different things. The term also stands for connecting a multiplicity of individuals or groups together, culturally and socially.
According to the dictionary, integration means the inclusion or incorporation into a larger whole. However, the term also stands for connecting a multiplicity of individual persons. Or to weld groups together into a cultural or even social unit.
What is System Integration?
Any organization integrating a (new) software system into an existing application landscape must overcome common challenges: Because here, too, the systems involved not only speak different languages (Java, Cobol, PL/I, etc.), but to make matters worse, they also speak different dialects (such as UTF-8 vs. EBCDIC).
Guiding questions for system integration
- What are the challenges that lead to integration difficulties?
- What constitutes effective integration?
- What principles and solutions can we derive from integration?
The habitat (such as server, cloud, clients) and form of communication (such as synchronous or asynchronous; REST, SOAP, File, or MQ) considered for the systems involved can also vary widely. The system "cultures" and the professional understanding depicted there can differ significantly. One possible consequence: even a functioning technical integration would not be functional from a business perspective. But why should integration also be easier in software systems than in other ecosystems?
Integration Management has a place in modern IT organizations
Market demand for new, digital business models is leading to significant increases in overall system networking. Corporate boundaries are changing and adapting to a market that wants the ability to innovative business models. At the same time, systems are becoming increasingly specialized, in the form of microservices and large, modular systems. In addition to large, increasingly modular systems, microservices are gradually gaining acceptance.
High complexity: integration forms a discipline in its own right
For integrations, initially, company specific needs and opportunities come into focus. Individual changes are possible within defined limits, depending on the offer. For integrations, on the other hand, highly individual starting situations apply in principle. These determine the integration requirements and require integration to be understood and pursued as a discipline in its own right. Key Factors to consider:
- Existing application landscapes
- Company-specific integration targets
- Appropriately designed products and processes
- New collaboration and business models
- and many other aspects.
Solutions
Why the Insurance and Finance industries need system integration?
The majority of companies in the banking and insurance sectors have a clear need to optimize their IT. These firms in particular are confronted with aging IT landscapes comprising individual, isolated IT systems and databases. Gradually, sustaining legacy, non-networked entities become increasingly expensive as the system continues to age.
Many current architectures hamper projects that aim to implement digital business models and automate processes. This is the conclusion of the Lünendonk IT Study 2020. According to the study, one in three digital and IT decision-makers surveyed considers a branching, complex IT landscape in their company to be an obstacle to digital transformation. Only 26 percent of respondents perceive the influence of high IT complexity on the implementation of digital transformation as "less strong".
Integration evolution shapes integration paradigms - three concepts in flux
Peer-to-peer leads to individual errors and new system interaction dependencies
Software integration started with so-called peer-to-peer integrations. In these P-to-P integrations, all systems are directly connected "point to point". The number of connections required grew significantly. In extreme cases, each system has a connection to all other systems.
But this is exactly what is becoming a bigger problem with a growing number of (smaller) systems and services. Systems and services must all be integrated, after all. The disadvantage is that the integration logic is distributed across all the systems involved. Integration has no place here, but an unmanageable number. As a result, integrations take on an individual character with equally individual sources of error and dependencies on - newly emerging - head monopolies.
Hub-and-spoke architectures make integrations manageable
In the subsequent evolutionary stage, hub-and-spoke or bus architectures concentrated integration at a central point. A typical representative of this is the enterprise service bus (ESB) system. The advantages of this topology are that it drastically reduces the number of connections and the systems are decoupled from each other by the central integration solution (loose coupling). Integration hat hier einen Ort.Integration has a role here.
However, this advantage also brings with it the biggest disadvantage of ESB systems: they are not designed to support the individual requirements of multi-partner, emerging business models. Consider the likelihood that a group of as yet undetermined partners will agree on a cost-intensive, proprietary system that entails vendor lock-in by the respective manufacturer. Ultimately, they look like monolithic,proprietary octopuses in the infrastructure.
Logical-Hub-Mindset combines the best of two worlds
A logical hub architecture combines the best of both worlds: the limitless flexibility of peer-to-peer architecture with the rigor of unified integration architecture. Like hub-and-spoke architecture, all integrations are concentrated - logically - at one point. Integration has a valuable role here.
The "logical center" of a logical hubcollects a set of uniform, but independent integration adapters. Together, these act like a logical ESB. The individual integration adapters, implemented as microservices, can be distributed to a wide variety of environments.
The spectrum here ranges from on-premise and (multi-) cloud installations to iPaaS or SaaS solutions. The implementation is technology agnostic. In practice, however, it will be based on a defined set of different, preferably open source, technologies This keeps systems maintainable. It also reduces dependencies. Architecturally, this set can be changed at any time. And it can be gradually adapted to further technological developments. The logical concentration of integrations in one place has significant advantages: All integrations follow the same architecture and design rules. This effectively prevents head monopolies. In addition, an organizational framework is formed. This can be used for a coordinated (further) development of all integration solutions as well as the required infrastructure. Last but not least, an open integration architecture enables collaboration with different partners. What's more, it even favors such constellations.
Integrations take place at different levels
Integrations can basically take place on and between completely different architecture layers: A variety of integration scenarios can be worked out. This is also illustrated by the following graphic:
These integration solutions take into account conceptual, technological and platform aspects
The following three perspectives are crucial for integration solutions:
Conceptual View: Integration patterns provide approaches to solutions
Typical integration problems can be solved by applying a large number of integration patterns. In their compendium "Enterprise Integration Patterns"- the standard work on integration patterns - authors Gregor Hohpe and Bobby Woolf define 65 integration patterns that form a so-called pattern language ("words"). These, in turn, can be used to compile more complex patterns ("sentences").
Technological View: Frameworks help to make technologies usable in a uniform way
Integration technologies required for implementation are the focus here. Depending on the integration requirements and the systems involved, these are very different technologies. So-called integration frameworks emerged: the best known is Apache Camel. It ensures that the multitude of technologies used can be used in a uniform manner.
Platform View: Integration platforms secure the operation of integration solutions
In choosing an integration platform, IT organizations must define which integration scenarios are expected and required. This definition shows clearly what platforms are suited to a company’s needs. Integration frameworks provide a powerful basis for the development of integration solutions. However, they do not represent operable integration platforms. This requires many other components for the secure operation of the solution. Integration platforms such as an enterprise service bus (ESB) or logical hub architecture provide support here. ESBs are limited here to the use of the infrastructure supported in each case.
Central integration platforms such as an ESB, for example, are limited here to the use of the infrastructure supported in each case. Thus, the question quickly arises as to how many integration architectures we want to deploy for different integration requirements. And it is important to determine how flexible the platforms need to be in order to avoid constantly causing further heterogeneity in the rapidly changing technology landscape and a world full of innovative business models.
Contact Person
Hans-Jürgen von Henning
Partner IKOR GmbH info-finsure@ikor.one +49 40 8199442-0„New, usable potential requires new approaches to solutions and further development“
