Login
Register
Member Insights
Michal Usak, Director Business Consulting at CGI, discusses the importance of matching integration strategies and architecture foundations with external partners and looks at how this can be achieved.
Michal Usak, CGI
Composable architecture and external parties: BSS integration patterns with external realm
Telecommunication architectures do not exist within a vacuum. There is large array of external applications connected to any telco stack. From brand partners, through re-sellers, to value added services (VAS), service providers, and mobile virtual network operator (MVNO), and various other partner types, all these subjects use the networks of telecommunication providers.
These parties may have different security, data, workflow, and development lifecycle related requirements than internal clients within a given IT stack. These dependencies form constraints of certain domain driven, and choreography-based orchestration patterns.
As response to such constraints, composition of TM Forum APIs may be required.
The current discussion on composable architectures originates in comparison of 2 main patterns, differing in the degree of flexibility, standardization, and re-usability.
The more traditional approach to IT stack architecture was having all clients communicate via one unified service bus. This was historically the case with on premise, and within the last decade as well cloud based middleware solutions.
The idea of the pattern was, that all the clients only must know and communicate with one singular system, orchestrating any further communication to other APIs, knowing all end-to-end flows, and encapsulating complexity of API versioning, and web service parting to serve individual client’s needs.
The advantages can however become, depending on the perspective, as well the drawbacks. Hence a domain driven, choreography-based architecture, where each server system knows and communicates with all impacted client systems directly, became the (aspired) norm in stack architecture blueprints. This pattern removes single point of failure in integration, allows for granularity, and selective changes of each web service, without any impact on other web service calls, and processes.
Centralization usually remains on infrastructure level in the form of API gateway responsible for authentication, authorization, and observability process standardization.
Table 1 - comparison of choreography and orchestration impacts
Table 2 - comparison of functional dimensions
The optimal choice between choreography and orchestration depends on various factors, including:
While it is quite possible to manage choreography within an organization, as soon as external parties must be integrated, certain differences apply.
In terms of governance, external realm may be ruled by different sets of guidelines, then an internal IT organization. Joint set of governance principles along with the below dimensions, agreed between organization and external parties, is required to support any integration architecture.
Table 3 - Steering dimensions
As external parties may not be legally, and are not technically, part of the IT stack, considering of above dimensions may lead to specific challenges.
External parties may be represented by desktop clients, web portals and mobile apps. Each of these has specific UX and security considerations.
As well, certain external parties have specific constraints related to authorization, process control and business workflows which require client specific composition.
Orchestration of multiple web services in desired sequence, as well as non-standardized API design patterns and documentation, can be a challenging task for the external client. It requires strong alignment of development lifecycle between internal stack development teams, and external party organization, along above technical, and processual dimensions.
Standard industry business process modeling and notation (BPMN) software arrives with OOTB available orchestration workflows. Similarly, back-end domains strive to harmonize local resources into TM Forum compliant APIs.
This form of composition serves to support such requirements, as both external and internal clients can rely on the use of the same standard APIs and workflows.
External parties may not be allowed to be privy of the workings of an internal stack, due to security reasons, or increased complexity.
Similarly, external parties may have different delivery process lifecycle duration and hence cannot keep “pace” with internal development changes on API level.
This influences the need for API state model encapsulation, and API version de-coupling between the internal, and external realm.
It is advisable to segment partner types based on their specialization, standardization, and delivery abstraction needs.
Dimensions such as degree of risk, existing legal agreements, and partner technical maturity can be helpful in such considerations.
Table 4 - Composition applicability matrix
Consequently, a matching integration strategy, and architecture foundation should be devised for each partner.
