Center-out business architecture

Software architecture is to outline the essential and high-level components required for an application. Architecture also describes the dependency and interaction between the application components. Choosing the correct architecture helps achieve the required swiftness and scalability in an application.

As a lead system architect (LSA), you need to provide business solutions for business problems by defining the broadly focused architecture. In general, software architecture is composed of three layers, as shown in the following image:

In Pega applications, the Center-out™ business architecture is a fine-tuned software architecture to deliver customer and business outcomes. It gives meaningful results fast and sustains the architecture into the future by avoiding the Top-down and Bottom-up approaches' mistakes.

The Top-down approach designs the applications specific to the channels of interaction. One of the most significant disadvantages of the top-down approach is implementing the same presentation layer logic multiple times to deliver a consistent experience across channels.

The Bottom-up approach designs product-centric implementation. The risk with bottom-up is that each system has its view of the data used by its applications. Legacy systems built in silos attract duplicates of data held in other systems. The same data may be in multiple systems. Also, different parts of data about a single business entity (a Customer) may be in different systems, with no one solution able to provide a single view of the complete entity.

The Center-out approach brings business and IT together to focus on the business outcome and rapidly innovate solutions. Teams can deploy enterprise-grade solutions in weeks or days, collaborating from a shared low-code platform with design-thinking best practices baked in.

The Center-out approach is about:

• Focusing on the Microjourney™ objectives
• Identifying when engagement with a channel is needed to complete a step
• Identifying what data is needed to, or updated by, completing a step

It takes Pega-model-based configuration tasks to “activate a channel” and “connect to a data source” to complete the implementation, rather than:

1. “Developing a web solution,” which too quickly fails to consider how the same solution could be delivered as a mobile app, chatbot, or be used as a component of another application using APIs;
2. “Implementing a new SAP module,” which is limited to the business units that use SAP and may have a limited view of data available from the enterprise.

Designing Pega applications starts with the Center-out approach. The five steps of this architecture are organized around enterprise customers and outcomes.

1. Start with a brain – Manage the intelligence centrally: Business outcomes should be guided by real-time customer information; rules are consistently enforced, and every recommended action is on target.
2. Get the work done – Focus on outcomes, align your process: Use case management to manage, automate, and improve work by applying a Microjourney approach that is implementing a part of the customer journey tied to a specific outcome.
3. Connect up to channels – consistent experience: Keep the front-end logic and back-end logic coordinated using Pega’s digital experience API. Changes are dynamically reflected without recoding.
4. Connect down to data – keep logic nimble: Reach into back-end systems and pull-out important data without adding complexity. The virtualization layer is called Pega Live Data. Pega Live Data allows users to quickly and easily define the data required to build the apps they need and then access that data in their running application – all without having to worry about how and where the data is stored and accessed.
5. Ready to scale – Manage variation: Pega's Situational Layer Cake™ helps to adapt Microjourneys for different customer types, lines of business, geographies, and more. Start small and fast. Scale big, broad, and stay future proof

Front Stage Group (FSG) is a large service provider company that facilitates event-related services such as event-booking, hotel-booking, and shuttle services. FSG provides services to customers coming from different regions using different channels for communication. Their database system is a combination of modern and legacy databases to hold the data. Current legacy applications of FSG implemented using other technologies, and architectural styles are working fine. The front-end channels of FSG include, a call center application used by CSR, a web application used by end-user directly and a chat bot application to answer customer FAQ’s. Every channel gets the information directly from the source as requried, there is no common layer for all front-end channels. The back-end systems include on-premises database, on-cloud database, ERP system and a mainframe system. The data access and persistence logic are written vendor specific.

The newly formed center of excellence (COE) team has anticipated a few potential limitations with these applications. They are explained as:

Problem 1: The top-down approach of FSG works well with channel-specific communication in the current scenario. FSG may introduce a new channel to withstand the business competition, which requires writing new code. It may become tedious and tough to maintain channel-specific code, with chances of less or no consistency in communication across channels. The addition of new channel needs to be built from scratch as there is no opportunity to reuse capability implemented in other channels.

Problem 2: The bottom-up approach of FSG is using database vendor-specific logic to access and print the data. There is no data virtualization layer logic. The current setup of the database and dependent applications are working fine. However, if the database vendor changes the data access protocols, FSG must re-write the code for storing and accessing the data. If any new database system is added, some more code has to be added as well.

A newly-formed FSG-COE team has proposed Pega’s Center-out business architecture.

The solution to problem 1 (in the existing architecture) is using Pega 8.x to build applications. The business rules engine, processes, and policies are available for all channels and interfaces. It provides an omnichannel experience. Microjourneys implemented in the center-out business architecture can be configured to be delivered to additional channels.

For example, if Alexa has to be added as a new channel, then it is just an addition of components and providing access to the application to Alexa; it is quick and straightforward.

Pega also provides the Pega Digital Experience (DX) API. Clients can deliver user experiences using their preferred front-end technology without duplicating the implementation of the user interface needs. Pega components can be rendered in their native technology and can understand the Pega components' available actions.

The solution to problem 2 (in the existing architecture) is to use the Pega Live Data virtualization layer. The data model used by the Pega application is not dependent on the data model used in the systems of record. Based on the condition, it can go to the required database system to access the data. Data save plans help store back the updated or new data without depending on how and where the data is coming.

For example, a data page in Pega 8.x can have two connectors, one with REST and another with SOAP access protocols, that out to two different back-end systems (or SOR systems), a condition is evaluated to use the required source.

The case study of FSG clearly shows the benefits of the center-out business architecture. For more information about the Center-out™ approach, see Center-out Business Architecture.