Member Insights
Following on from a previous article, Michal Usak, Director Business Consulting at CGI, delves deeper into BSS integration patterns for external partners in composable architectures, highlighting transition strategies during IT transformations based on partner needs and constraints.
Composable architecture and external parties: BSS integration patterns with external realm and transition architectures during IT transformations
In previous article we have discussed need for specialization, standardization and delivery process abstraction on high level. This article addresses the topic in more detail.
Before we proceed, let us follow a practical co-existence of 2 main integration strategies for external parties.
In the below example is typical TM Forum architecture example demonstrating hybrid approach to specialization and standardization, depending on the domain and use case.
Figure 1 - Hybrid approach (complexity encapsulation)
External client is shielded from full impact of all back-end changes, and consequences of back-end architecture via an external party orchestration layer on the Channel Domain.
The amount of overall web service calls to execute a simple registration can be thanks to orchestration layer reduced in comparison to internal clients which handle “channel orchestration” locally in FE apps.
API versioning, development lifecycle, and authentication dependencies may be encapsulated behind partner orchestration layer.
The effect of composition is partially shared by both external and internal realm clients in some cases. Details follow below.
The above examples of composable architecture vary in application of below categories.
Table 1- Composable architecture dimensions
In the table above we specified certain selection criteria. Let us describe them in detail.
The below table compares the relative complexity increase for external realm, and internal clients, depending on where the composition occurs.
Table 2- Composable architecture impacts
Pattern (I) enables shared branding across channels/partners if applied.
In cases, where the external parties were used to domain agnostic composite services, complexity increase is present, and combination with pattern (II) and (III) may be required.
As composition handled within COTS products in case of (IV) and (V) has zero net complexity increase impact, it is considered a proffered pattern in either architecture.
This is a factor when deciding on complexity encapsulation, as decision must be made, whether to place the encapsulation in the channels, or back-end domains.
Both options hides complexity from external clients. Back-end encapsulation can have as well internal use.
Complexity encapsulation in channels in case of (VI) and (VII) lowers integration complexity on partner side and again allows for “2 speed” delivery organization. Minor version and Patch changes are not communicated to channels domain, which applies a tolerant reader pattern and ignores any unknown fields in communication with external realm.
Filtering of major version changes for 1 and 2 is possible as well, while causing E2E capability constraints for any external realm related use case. As such, it is not endorsed and if executed, should be accompanied by application logic change on back-end domain side as well.
Whether to move more towards complexity encapsulation in channel layer, or on domain side to enable more flexible integration based on partner or organizational needs, or to hide complexity, may depend on following factors:
Reaping of benefits of modern event driven micro service architecture is easily achievable within the internal realm.
Applicability of the benefits to external realm requires rigorous prior analysis of partner capabilities.
Middleware required to maintain architecture compliance and legal agreements may be needed, which would limit the advantages of choreography patterns.
Analysis of external realm is hence advices prior to any large transformation hoping to capitalize on modern stack architectures.