Center-out business architecture case study

FSG’s existing legacy applications are implemented on several non‑Pega technologies, and each system continues to operate according to its original architectural style. The front‑end channels include a call center application for customer service representatives, a web application for customers, and a chatbot that responds to common questions. Each channel retrieves information directly from its respective source system when needed.

There is no shared layer that unifies these front‑end channels. The back‑end systems include an on‑premises database, a cloud‑hosted database, an enterprise resource planning system, and a mainframe. Data access and persistence logic relies on vendor‑specific code across these systems.

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 an abstract layer. This direct connectivity results in tight coupling across the architecture

The newly formed center of excellence (COE) team at FSG has identified several limitations and maintenance bottlenecks in the legacy applications:

Problem 1:

FSG's top-down approach works well with channel-specific communication in the current architecture. In the future, FSG might introduce a new channel to remain competitive. Adding channels requires new implementation work. Maintaining channel‑specific code can become difficult to maintain and inconsistent across channels. Additional channels would also have to be built from scratch, because there is no opportunity to reuse features implemented in other channels.

Problem 2:

FSG's bottom‑up approach uses vendor‑specific database logic to access and show data, and the architecture does not include a data virtualization layer. The current approach continues to function; however, if the database vendor changes its access protocols, FSG must update the code that stores and retrieves data. Adding a new database also requires additional custom code

The COE team at FSG proposes using the Center-out® business architecture, as shown in the following figure:

The solution to Problem 1 is to use Pega Platform™ to build all the applications. The business rules engine, processes, and policies are available to all channels and interfaces,which creates an omnichannel experience. Microjourneys® implemented in the Center-out business architecture can also be configured to be exposed to additional channels, without any channel specific implementation.

For example, if FSG wants to expose customer inquiries in a conversational self-service channel, authors can expose the corresponding workflow through Digital Messaging channel configuration without re-implementing chatbot specific logic.

Pega Platform enables user experiences through the Pega Digital Experience (DX) API. FSG can deliver user experiences with a preferred front‑end technology without duplicating user‑interface implementation. Pega components can be rendered in native technology while continuing to support available Pega actions.

The solution to Problem 2 is to use the Pega Live Data virtualization layer. Use a Data Page to connect to back-end systems. Changes in the back‑end systems do not impact the presentation layer or business logic layer.

For example, a Data Page in Pega Platform can have two connectors, connecting to two different back-end systems. Authors can conditionally 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, see Center-out business architecture.

Check your knowledge with the following interaction: