Composable architecture and external parties: BSS integration patterns with external realm and transition architectures during IT transformations

1. Introduction

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.

2. Architecture example

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.

3. Comparison of impacted architecture dimensions

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.

3.1. Impact on composition

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.

4. Closing thoughts

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:

4.1. Market power of partners: Is given end point provided to dozens, or thousands of external parties?

In case of Value-Added Services, such as push notifications, standardized end point with singular version control may be the only option, as nothing else would be manageable for a large set of external parties. Such services require only a limited set of APIs to be called, hence any “choreography” is easily executed.

In case of few dozen brand partners and re-sellers, potentially harnessing large portion of the market revenue, business risk in case of service interruption is larger. Similarly, complexity of product registration workflows may be significantly larger as complex chains of API calls have to be executed by each external system. In such as case, encapsulation hidden behind workflow management system may be in order.

4.2. Legal agreements on development process, security guidelines, and compatibility obligations.

If being a partner means to comply with Stack wide architecture policies, then more complex integration patterns, and related flexibility may be allowed, as the modus of working follows similar pattern as for internal clients.

If the contractual agreements do not allow for enforcement of architecture compliance, the architecture requirements of given stack must be encapsulated behind a middleware, to avoid security and integration gaps.

4.3. Partner technical maturity.

If the partner is not able to support complex architectures, or modern integration patterns, middleware is required to fulfill architecture requirements, like in point 2 above.

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.