Center-out business architecture
Software architecture is an outline of 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 figure:
The diagram above shows the three layers of software architecture: Presentation, Application and Business Logic, and Data Access. The Presentation Layer includes channels such as portal, mashup, and mobile. The Data Access Layer includes local and external data sources. The Application and Business Logic Layer is the heart of the Center-out Business Logic Architecture strategy. Business logic should be implemented in the center, not spread across layers.
In Pega applications, Center-out™ business architecture is a fine-tuned software architecture that delivers customer and business outcomes. It gives meaningful results fast and sustains the architecture into the future by avoiding the mistakes of the Top-down and Bottom-up approaches.
The Top-down approach designs the applications that are 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 implementations. The risk with bottom-up is that each system has its own view of the data used by its applications. Legacy systems built in silos attract duplicates of data held in other systems. The same data can then be in multiple systems. Additionally, different parts of data about a single business entity (for example, a customer) can 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 complete a step, or is 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:
- “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,
- “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, as shown in the following figure:
- 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.
- 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 implements parts of the customer journey that are tied to specific outcomes.
- 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.
- 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.
- 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 and broad, and in doing so, stay future proof.
Current architecture of Front Stage Group
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 from different regions using different channels for communication. Their database system is a combination of modern and legacy databases. 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 used by their end-users directly, and a chat bot 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, 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, a newly formed center of excellence (COE) team has determined that there are 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 less 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 data virtualization layer logic. Although the current setup of the database and dependent applications are working fine, 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, more code has to be added as well.
Proposed Center-Out architecture
Because of these problems, FSG's COE team has proposed the use of Pega’s Center-out business architecture.
The solution to problem 1 in the existing architecture is to use Pega Platform™ version 8.x 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 example, 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 could 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 Pega data page to connect to backend systems. Any change in the backend systems will not impact presentation layer and business logic layer
For example, a data page in Pega Platform 8.x can have two connectors, connecting to two different backend system, we can switch between data sources as required without impact 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:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?