Center-out business architecture case study

FSG's current legacy applications were implemented using other technologies, and their architectural styles are working fine. The front-end channels of FSG include a call center application used by CSRs, a web application that is used directly by their end-users, and a chatbot application to answer common customer questions. Every channel gets the information directly from the source as required, so there is no common layer for all front-end channels. The back-end systems include an on-premises database, an on-cloud database, an enterprise resource planning (ERP) system, and a mainframe system. The data access and persistence logic were written to be vendor specific.

The following figure shows the architecture, including the three front-end channels and four back-end systems. The colored lines show how data access and persistence from the front-end to the back-end systems are direct, without any abstract layer. This represents the tight coupling between the front-end and back-end systems.

However, the newly formed Center of Excellence (COE) team has identified several potential limitations with these legacy applications:

Problem 1:

FSG's top-down approach works well with channel-specific communication in the current scenario. However, in the future, FSG might introduce a new channel to keep up with its business competition, which would require writing new code. It could become tedious and difficult to maintain channel-specific code, with a subsequent chance of little or no consistency in communication across channels. Additional channels would also need to be built from scratch, as there is no opportunity to reuse capabilities implemented in other channels.

Problem 2:

FSG's bottom-up approach of using database vendor-specific logic to access and print the data means that there is no logic for a data virtualization layer. Although the current setup of the database and dependent applications is working fine, if the database vendor changes the data access protocols, FSG must rewrite the code for storing and accessing the data. If any new database system is added, additional code has to be added as well.

FSG's COE team has proposed the use of Pega’s Center-out business architecture, as in the following figure:

The solution to Problem 1 in the existing architecture is to use Pega Platform™ to build all the applications. The business rules engine, processes, and policies are available to all channels and interfaces, creating a truly omnichannel experience. Microjourneys™ implemented in the Center-out business architecture can also be configured to be delivered to additional channels.

For instance, if FSG wants to add Alexa as a new channel, then it is just a question of adding components and providing application access to Alexa. Comparatively, this is quick and straightforward.

Pega Platform also provides the Pega Digital Experience (DX) API. FSG can deliver user experiences with their preferred front-end technology, without duplicating the implementation of the user interface. Pega components can be rendered in FSG's native technology but can still understand the Pega components' available actions.

The solution to Problem 2 is to use the Pega Live Data virtualization layer. Use a Pega Data Page to connect to back end systems. Any change in the back end systems will not impact the presentation layer and business logic layer.

For instance, a data page in Pega Platform can have two connectors, connecting to two different back-end systems. We can switch between data sources as required without impacting other parts of the application. The FSG case study clearly shows the benefits of the Center-out business architecture. For more information about Pega's Center-out™ approach, read Center-out Business Architecture.

Check your knowledge with the following interaction: