Definition of Technical Architecture
Technical architecture refers to the design of the application itself. One of the key advantages of building with Pega Platform™ is the ability to design your application and reuse key components across multiple microjourneys™ and channels, even other applications. With this flexibility, when it comes time to change something, you can do it once. You want to leverage Pega Platform features in the technical design of your application.
Technical design considerations
Technical design begins in the Prepare phase and is refined during the Build phase. The lead system architect (LSA) drives the technical design activity to ensure that the application you build makes the best use of out-of-the-box features and reuse. The LSA focuses on establishing a high-level technical design and implementing the foundation components for the solution.
Foundation components include creating the initial definition of the case types, personas, and data objects for any microjourney prioritized within the release.
The LSA works with the product owner, business architect, user experience designer, and client-side technical architects to agree on a high-level design that meets (current and future) business goals and aligns with the customer's existing technical infrastructure.
As part of the application design activity, the LSA ensures best practices in these areas:
- Application structure
- Data model
- Case design
- User access and security
- Deployment and DevOps
- User experience/User interface
The LSA is also responsible for the technical quality of the application. Pega Express™ best practice is to automate the unit and scenario testing to ensure the quality of the build and set up DevOps pipelines to streamline the integration of changes in your application. The LSA is responsible for ensuring that the application structure is organized to support automated testing. For more information on testing, see the Pega Academy topic Crucial testing approaches.
Before creating the application (see our Senior System Architect course for more information), the LSA works with the product owner and business architects to understand the reach of the application within the organization. Based on this input, the LSA ensures the application is designed to support both immediate and longer-term business goals.
Business input is key because the Pega Platform enables you to organize your application using the same dimensions as the business. You can reuse common policies and procedures while accommodating the differences between products, regions, channels, and customer segments.
This flexibility is achieved by layering applications on top of each other. Doing so results in a Situational Layer Cake, comprised of four levels:
For another perspective on the importance of the Situational Layer Cake, view this Partner Spotlight Talk in Pega Community.
Caution: Failing to understand the reach of the application within the organization may limit your opportunities for reuse.
In the following image, click the + icons to learn more about each of the four layers in the Situational Layer Cake.
Example application structure
A clothing retailer consists of two brands of stores. One brand focuses on the upscale clothing market, while the other brand runs a value-oriented chain of stores. Each brand must manage returned items. The retailer can develop a generalized application that manages clothing returns in the framework layer. Each brand can then create an implementation layer to customize the returns process. Each customized application contains brand-specific assets, such as styling and policies.
The technical design decisions taken in the Prepare phase can reflect an application structure in the following layers:
Starting at the top working down through the layers:
- The highest layers are the Implementation layers (one for each store) that sit side by side on top of the Framework layer. Each implementation layer is specific to each store includes Upscale Brand and Returns specialization.
- Beneath the Implementation Layers is the Framework layer that contains common technical components for the Returns Process. The Framework layer sits above the Organization layer.
- The Organization Layer sits above the Pega Platform layer and contains the common technical assets for all areas of the business. This sits low down in the layered application so it can be used by any Process or Store that needs to reuse it.
- Finally the Pega Platform Layer resides at the bottom, allowing all residual functionality to be used by the layers above.
Applications require data of some sort sourced either from within the enterprise or external to the organization.
- Data sources within the organization – Identify data stored within Pega Platform applications and other legacy systems within the organization.
- Data external to the organization – Identify data stored in third-party software systems or applications.
You start your data model by determining what data elements are stored within existing systems. In total, you consider data from three sources: Pega, company, and external data.
When considering the design decisions regarding data, there are three aspects to keep in mind:
- The enterprise data model – Data applicable at the enterprise level and available for all applications developed or configured within the enterprise
- The application data model – Data maintained within the application
- The standing data model – Data that needs a lookup or reference data source
Note: Lookup/reference data can be sourced from external services or systems of record or internal reference tables. Ensure that there is a single source for reference data. It can get very complicated to track different versions of data if lookup data is maintained in multiple locations. While working on the data model, keep in mind the assignment of appropriate data types and length of each data item.
Example data model
A company, MyDebt, offers debt solutions to persons who are in financial difficulty. MyDebt has a Pega Platform application called DebtSol that provides a capability for the frontline debt caseworkers to take calls from individuals and offer debt solutions to address their current difficulties. The solution is designed to record details about the individual and their current financial situation, for example, debts, income, expenditure, and assets, and then use business rules to offer a solution to address their debts.
The data model for the application reuses an existing enterprise-class data model to record the individual's personal details and has identified a data model specific to the DebtSol application.
In the following image, click the + icons to view the example data model.
User access and security
Authentication in the Pega Platform ensures that only users and systems with verified identities can access resources such as web pages, APIs, and data.
Examples of authentication include:
- User logins
- Platform requests to external services
- External service requests to the platform
Consider and choose an appropriate authentication mechanism and configuration for the operator records to accounts for the organizational hierarchy, workgroups, and work queues. You can use authorization or access control features in Pega Platform to restrict user actions.
Review the three basic authorization models upfront with your team to decide which is applicable to your project.
- Role-based access control (RBAC)
- Attribute-based access control (ABAC)
- Client-based access control (CBAC)
It is also important to review and determine which items within the Security Checklist apply to the project context during the Prepare phase.
Pay special attention to the following:
- Authentication scheme
- Access groups/roles
- Organization structure
- Timeout configuration
- Security of file uploads
For any sensitive or personally identifiable information data items, apply appropriate security to protect the user's configuration and access, such as encryption, obfuscation, or controlled access.
For more information about application security, see the Pega Academy topic Security Checklist.
Pega Platform supports a range of integration standards and communication protocols, allowing you to focus on your application's business requirements rather than on connectivity issues. Review and validate that, for each integration component, you have appropriate details for configuration and delivery.
For example, ensure you have visibility, understanding, and clarity concerning the following aspects related to each integration component:
- URLs per environment
- Cloud or on-premise repository or third party (content management)
- SSL/TLS – versions
Deployment and DevOps
Deployment of the application is performed throughout the project's life cycle to migrate the application through the different environments, from development to staging to production. The client-side IT department and your technical team must agree on an approach to managing the work within the development environment and how best to deploy the application. Include DevOps from the start of the project.
The LSA leads DevOps discussions during the Prepare phase to ensure adherence with Pega Express best practices - ensuring technical quality and speed of delivery. In these discussions, the LSA establishes the application structure and Dev Ops best practices for the Pega application technical team.
Note: DevOps is a set of practices that bridge application development and operational behavior to reduce time to market without compromising quality and operational effectiveness. It encourages a culture of collaboration between development, quality, and operations teams to reduce or eliminate barriers through fundamental practices such as continuous integration, continuous delivery, and continuous deployment.
Using the Pega Express deliver approach, adopting a DevOps approach to application development means that the developers use the best practice of working in branches to configure their updates to the application and define deployment pipelines to migrate the application from one environment to another. Full deployments should be configured from the very start. This means that the application as a whole is migrated from one environment to another, rather than incremental packages.
Applying this best practice ensures that the deployment package contains a cumulative collection of all rules within the application and the data, but, gives flexibility as it only deploys what has changed since the last deployment.
DevOps pipelines should be configured with all recommended checks and balances including:
- Security checklist
- Guardrail compliance
- Execution of unit and scenario test
- Assure the quality of the application as it is migrated from one environment to another
Note: DevOps pipelines are configured with the Deployment Manager. In addition, the approach to packing the application for deployment should also be established at the start. As part of this, binding data instances to rulesets and applications should be also be configured.
Define a clear reporting strategy from the outset to ensure that the Pega Platform application is designed to meet both the business operational and management reporting needs. Often, organizations require Pega Platform applications to supply data to their existing enterprise data warehouse solutions.
It is a best practice to extract data from your Pega Platform by using the page extract tool, Business Intelligence Exchange (BIX). Identifying this requirement upfront influences the configuration of data objects in the Pega Platform application and the interface solution used to integrate with the data warehouse.
Here are key design issues to decide upfront when dealing with data extraction:
- Frequency of extraction (such as Daily/Weekly)
- Transaction extraction design (each transaction or cumulative EOD transaction)
- Extraction history
- All properties or specific properties
- Extract format (CSV, XML or DB)
User interface (UI) architecture forms part of the technical design of the application.
UI covers the following:
- Best practices to adopt during the project
- Working practices for the team
At the start of the project, the UI Solutions developer, working collaboratively with the Product Owner, Lead Business Architect, Lead Systems Architect, and tester, leads several sessions to define the UI architecture. These early decisions ensure that the UI is easy to maintain, consistent throughout the application, and adheres to UI best practice.
The UI Solutions developer considers:
- Design systems
- Skin reuse (such as branding and styling)
- Non-functional requirements
- Web self-service architecture
- Governance processes
Beginning with Pega Platform version 8.3 you have a seamless way to accelerate your UI using Cosmos. For more information on how Cosmos helps to create a premier user experience, take a look at the TechTalk on Pega Community, Accelerate your workflow with Cosmos UI.
Note: With the growing trend of globalization, the UI must consider the application's reach across languages and cultures. This factor goes beyond the translation of the screen text and functions into different languages and includes changes to user experience design to align with reading styles and cultural needs. Understanding the reach of the application in this regard will ensure that the UI configuration also takes this into account during user story elaboration, build configuration, and test.
In the following image, click the + icons to learn more about UI.