Pega Application Architecture Interview Questions and Answers
Application Architecture is one of the most important areas for a Pega Senior System Architect, Lead System Architect, and Pega Architect interview.
At a junior level, interview questions may focus on individual Pega rules and features. At a senior architecture level, interviewers want to understand why you choose a particular application structure, class hierarchy, Ruleset strategy, reuse model, and integration architecture.
This guide covers the most important Pega Application Architecture interview questions using a practical Alpha Bank example.
The goal is not just to memorize definitions. Each answer explains the architectural thinking, Pega rules and features involved, implementation techniques, and the kind of answer you can give during a real interview.
In This Article
- How do you design a Pega application from scratch?
- What is your approach to application architecture in Pega?
- How do you identify business capabilities before creating Case Types?
- How do you decide the application hierarchy?
- What is an Application in Pega?
- What is an Application Version?
- What is a Ruleset?
- What is a Ruleset Version?
- What is the difference between an Application and a Ruleset?
- What is the difference between Application hierarchy and class hierarchy?
- What is the difference between Application inheritance and class inheritance?
- What is a Built-On Application?
- When would you create a framework application?
- When would you avoid creating a framework application?
- How do you structure an enterprise Pega application?
- How would you architect a large banking application in Pega?
- How would you separate Work, Data, and Integration classes?
- Why would you create separate Work, Data, and Integration layers?
- What would your class hierarchy look like for a banking application?
- Why would you use Alpha-Banking-Work, Alpha-Banking-Data, and Alpha-Banking-Int?
- Why shouldn't the application name necessarily appear in the class hierarchy?
- How do you decide whether something should be a Work class or Data class?
- How do you decide whether something belongs in an Integration class?
- How do you prevent an application from becoming tightly coupled to a system of record?
- How do you design for reuse?
- How do you prevent overengineering?
- How do you design an architecture that supports multiple business lines?
- How do you design an architecture that supports future applications?
1. How do you design a Pega application from scratch?
I start with the business capabilities rather than immediately creating Case Types. I identify the business outcomes, actors, business objects, processes, systems of record, integration requirements, security requirements, and reusable capabilities. Then I design the application hierarchy and class hierarchy before implementing the individual Case Types.
My approach
- Understand the business problem.
- Identify business capabilities.
- Identify business data and business objects.
- Identify the work that requires a Case lifecycle.
- Identify systems of record and integrations.
- Design the application hierarchy.
- Design the class hierarchy.
- Separate Work, Data, and Integration responsibilities.
- Identify reusable rules and components.
- Implement Case Types and processes.
- Define security, deployment, and versioning strategy.
Example: Alpha Bank
Suppose Alpha Bank wants to automate loan origination.
Business Capability
|
+-- Loan Origination
|
+-- Customer Verification
+-- Credit Assessment
+-- Document Verification
+-- Risk Assessment
+-- Approval
+-- Funding
I then identify the important business objects:
Customer Loan Loan Product Credit Report Document Account Collateral
Some of these become reusable Data Types, while activities requiring a lifecycle, assignments, SLAs, and auditability become candidates for Case Types.
Pega rules and features involved
- Case Types
- Data Types
- Data Pages
- Decision Tables
- Decision Trees
- When Rules
- REST/SOAP integrations
- Application and Ruleset configuration
- Access Groups and Roles
2. What is your approach to application architecture in Pega?
My approach is capability-first, data-aware, reuse-oriented, and loosely coupled. I separate business work from reusable business data and integration services. I place common functionality at the lowest appropriate reusable layer and keep business-specific functionality close to the implementation application that owns it.
I evaluate architecture across several dimensions
- Business capabilities
- Business data
- Case/work model
- Application ownership
- Class hierarchy
- Integration boundaries
- Reuse
- Security
- Deployment
- Future specialization
If Alpha Bank has Retail Banking, Commercial Banking, and Wealth Management, I do not automatically create three completely independent applications.
First I identify what is genuinely common:
- Customer
- Identity verification
- Document services
- Notifications
- Credit services
Then I separate the capabilities that are truly specific to each business line.
3. How do you identify business capabilities before creating Case Types?
I distinguish between business capabilities, business objects, and work. A capability describes what the organization needs to be able to do. A Case Type represents a unit of work that needs a lifecycle, ownership, processing, and often auditability. Not every business activity should become a Case Type.
Example
The business requirement is:
"Automate loan processing."
I break this down into:
Loan Origination | +-- Customer Verification +-- Credit Assessment +-- Document Verification +-- Risk Assessment +-- Approval +-- Funding
I then determine which activities require actual Case management. For example:
Loan Application --> Work / Case Credit Review --> Work / Case Customer --> Data Loan Product --> Data Credit Score --> Data
This prevents an application from becoming overloaded with unnecessary Case Types.
4. How do you decide the application hierarchy?
I determine the application hierarchy based on business ownership, organizational boundaries, reuse, specialization, and deployment needs. I put genuinely reusable capabilities at an appropriate higher level and keep implementation-specific functionality close to the application that owns it.
A simplified enterprise structure might look like:
Enterprise
|
+-- Division
|
+-- Business Unit
|
+-- Implementation Application
I do not create additional organizational or framework layers just because Pega supports them. Each layer should have a clear purpose.
5. What is an Application in Pega?
A Pega Application is a logical collection of configuration and Rules that delivers a business solution or set of related business capabilities. The Application Definition identifies the application's Rulesets and built-on applications, which together determine the rules available to the application.
Example
Alpha Loan Application Alpha Customer Service Alpha Claims Alpha Retail Banking
An Application is not the same as a Ruleset or a class. It is a higher-level construct that organizes the solution and its Rule dependencies.
6. What is an Application Version?
An Application Version represents a particular version of an application's configuration and Ruleset stack. It allows an organization to manage application changes in a controlled manner while preserving previously released versions.
Example
Alpha Loan | +-- Version 01.00 +-- Version 01.01 +-- Version 02.00
Application versioning is closely related to Ruleset versioning. Pega provides techniques such as Lock and Roll and Skimming for managing application evolution.
7. What is a Ruleset?
A Ruleset is a container used to organize and package related Pega Rules. It provides a mechanism for managing, versioning, securing, and deploying related Rules.
Examples of Rules stored in Rulesets
- Case Type rules
- Flows
- Data Types
- Decision Tables
- When Rules
- UI rules
- Integration rules
- Correspondence
- Validation rules
AlphaLoan AlphaLoan-Data AlphaLoan-Int AlphaCommon
An Application can reference multiple Rulesets.
8. What is a Ruleset Version?
A Ruleset Version is a specific version of a Ruleset. It contains the Rules available for that particular version and participates in Pega's Rule resolution and application versioning model.
AlphaLoan:01-01-01 AlphaLoan:01-02-01 AlphaLoan:01-02-02 AlphaLoan:02-01-01
| Part | Purpose |
|---|---|
| Major | Significant application or functional evolution. |
| Minor | Enhancement or intermediate release. |
| Patch | Smaller correction or maintenance release. |
In an enterprise environment, older released versions are normally protected through appropriate locking and release-management practices.
9. What is the difference between an Application and a Ruleset?
| Application | Ruleset |
|---|---|
| Represents the business solution/application context. | Organizes and packages related Rules. |
| Can reference multiple Rulesets. | Contains the actual Rules. |
| Can be built on other Applications. | Can be reused by Applications. |
| Defines the application configuration and stack. | Defines a versioned collection of Rules. |
Application = the solution and its context.
Ruleset = the package that contains related Rules.
10. What is the difference between Application hierarchy and class hierarchy?
Application hierarchy describes how applications are composed and built on other applications. Class hierarchy describes how Pega classes inherit Rules from parent classes. Application hierarchy is about application composition; class hierarchy is about Rule inheritance and reuse.
Application hierarchy
Alpha Retail Banking
|
+-- Built on Alpha Banking Common
|
+-- Built on Enterprise Services
Class hierarchy
ALPHA-BANKING-WORK-LOAN
|
+-- Parent:
ALPHA-BANKING-WORK
The two hierarchies interact, but they solve different architectural problems.
11. What is the difference between Application inheritance and class inheritance?
Application inheritance is achieved by building one Application on another Application. Class inheritance occurs between Pega classes. Application inheritance determines which application-level assets and Rulesets are available, while class inheritance allows a class to reuse Rules from its parent classes.
Application inheritance
Alpha Retail Loan
|
+-- Built On
|
+-- Alpha Banking Common
Class inheritance
ALPHA-BANKING-WORK-LOAN
|
+-- inherits from
|
+-- ALPHA-BANKING-WORK
Application inheritance answers: "What application capabilities am I building on?"
Class inheritance answers: "What Rules can this class inherit from its parent?"
12. What is a Built-On Application?
A Built-On Application is an application used as a foundation for another application. The higher-level application can use the capabilities and Rulesets provided by the application it is built on.
Alpha Loan Application
|
+-- Built On
|
+-- Alpha Banking Common
|
+-- Built On
|
+-- Alpha Enterprise Services
Built-on applications are useful when there is genuine reusable application functionality. However, I avoid creating unnecessary application layers because every additional layer adds maintenance and dependency considerations.
13. When would you create a framework application?
I create a framework application when multiple implementation applications genuinely share a substantial business model, Case structure, processes, data model, and common behavior. The shared functionality must be significant enough and stable enough to justify maintaining a separate reusable application layer.
Example
Alpha Bank USA
Alpha Bank Canada
Alpha Bank Europe
|
+-- Shared Banking Framework
If the three implementations share:
- Core Case Types
- Common business objects
- Common lifecycle
- Common processes
- Common rules
then a framework application may be appropriate.
14. When would you avoid creating a framework application?
I avoid creating a framework application when the reuse is small, speculative, or based only on the possibility that another application might exist in the future. In that situation, I prefer a simpler implementation with modular reusable components.
"We might need another application in the future, so let's create a framework now."
That is not enough justification for a framework.
Questions I ask
- Do multiple applications actually exist?
- Do they have a common business model?
- Is the shared functionality substantial?
- Will the shared functionality be centrally owned?
- Does specialization justify the additional layer?
15. How do you structure an enterprise Pega application?
I structure an enterprise Pega solution around business ownership and reuse. I separate Work, Data, and Integration responsibilities and place genuinely enterprise-wide assets at the appropriate enterprise level. Business-specific functionality remains closer to the implementation application that owns it.
Example enterprise structure
ALPHA
|
+-- Enterprise
| |
| +-- Data
| +-- Integration
| +-- Common Services
|
+-- Banking
|
+-- Retail
| |
| +-- Work
| +-- Data
| +-- Int
|
+-- Commercial
|
+-- Work
+-- Data
+-- Int
16. How would you architect a large banking application in Pega?
For a large banking organization, I would use a modular enterprise architecture. I would separate enterprise data and integrations from business-specific Case Types, define organizational layers only where they provide value, and use reusable services and Data Pages to prevent duplication.
ALPHA ENTERPRISE
|
+-- Enterprise Data
| |
| +-- Customer
| +-- Account
| +-- Product
|
+-- Enterprise Integration
| |
| +-- Customer
| +-- Core Banking
| +-- Credit Bureau
| +-- Documents
|
+-- Banking
|
+-- Retail
| |
| +-- Account Opening
| +-- Consumer Loan
| +-- Dispute
|
+-- Commercial
|
+-- Business Account
+-- Commercial Loan
Example Pega architecture
Case
|
+-- Data Page
|
+-- Data Layer
|
+-- Integration Layer
|
+-- System of Record
This prevents individual Case Types from implementing their own versions of the same customer, account, or integration logic.
17. How would you separate Work, Data, and Integration classes?
I use Work classes for business work and Case Types, Data classes for reusable business objects, and Integration classes for interaction with external systems. This creates clear responsibilities and makes the architecture easier to reuse and maintain.
ALPHA-BANKING-WORK | +-- LOAN +-- ACCOUNTOPENING +-- DISPUTE ALPHA-BANKING-DATA | +-- CUSTOMER +-- ACCOUNT +-- LOAN +-- PRODUCT ALPHA-BANKING-INT | +-- COREBANKING +-- CREDITBUREAU +-- DOCUMENT +-- PAYMENT
Typical rule placement
| Layer | Typical responsibility |
|---|---|
| Work | Case Types, processes, lifecycle, assignments, SLAs, Case-specific behavior. |
| Data | Data Types, Data Pages, reusable business objects and business data behavior. |
| Integration | Connectors, external service interaction, mappings, integration-specific logic. |
18. Why would you create separate Work, Data, and Integration layers?
I separate these responsibilities to reduce coupling, improve reuse, establish clear ownership, and make the application easier to maintain. A Customer should not belong to a Loan Case simply because the Loan Case uses it, and a Core Banking API should not be implemented directly inside every Case Type.
Highly coupled design
Loan Case | +-- Customer API +-- Core Banking API +-- Database logic +-- Customer data +-- Loan process +-- UI
Better architecture
Loan Case
|
+-- D_Customer
|
+-- D_Loan
|
+-- D_Account
|
+-- Integration Layer
|
+-- Core Banking
The Case focuses on business processing while the Data and Integration layers handle their respective responsibilities.
19. What would your class hierarchy look like for a banking application?
I design the class hierarchy based on business ownership, reuse, and specialization. I do not simply copy the application name into every class. The class hierarchy should represent meaningful Rule inheritance.
ALPHA
|
+-- BANKING
|
+-- WORK
| |
| +-- LOAN
| | |
| | +-- PERSONALLOAN
| | +-- MORTGAGE
| |
| +-- ACCOUNTOPENING
| +-- DISPUTE
|
+-- DATA
| |
| +-- CUSTOMER
| +-- ACCOUNT
| +-- LOAN
| +-- PRODUCT
|
+-- INT
|
+-- COREBANKING
+-- CREDIT
+-- DOCUMENT
For example, a Mortgage Case can inherit common loan behavior from
ALPHA-BANKING-WORK-LOAN while adding mortgage-specific behavior.
20. Why would you use Alpha-Banking-Work, Alpha-Banking-Data, and Alpha-Banking-Int?
These classes establish architectural boundaries between work, business data, and external system interaction. They can also act as reusable parent classes for more specific classes.
Alpha-Banking-Work
Alpha-Banking-Work
|
+-- Loan
+-- AccountOpening
+-- Dispute
Common Case-related behavior can be placed at the appropriate Work level.
Alpha-Banking-Data
Alpha-Banking-Data
|
+-- Customer
+-- Account
+-- Loan
+-- Product
These represent reusable business objects.
Alpha-Banking-Int
Alpha-Banking-Int
|
+-- CoreBanking
+-- CreditBureau
+-- CustomerService
This provides a clear place for integration-specific behavior.
21. Why shouldn't the application name necessarily appear in the class hierarchy?
Because an application name and a class hierarchy serve different purposes. The application name identifies the application solution, while the class hierarchy defines Rule inheritance and reuse. A class hierarchy should represent business relationships and specialization rather than simply mirror the application name.
For example
Suppose the application is:
Alpha Retail Loan Application
I do not necessarily want:
Alpha-Retail-Loan-Application-Work Alpha-Retail-Loan-Application-Data Alpha-Retail-Loan-Application-Int
Instead, I may have:
ALPHA-BANKING-WORK ALPHA-BANKING-DATA ALPHA-BANKING-INT
and specialize only where there is a real inheritance requirement.
22. How do you decide whether something should be a Work class or Data class?
I ask whether the object represents work performed by the organization or reusable business information that multiple processes consume. If it needs a lifecycle, assignments, ownership, SLAs, or Case processing, it is likely Work. If it represents a reusable business object, it is likely Data.
| Question | Likely classification |
|---|---|
| Does it have a Case lifecycle? | Work |
| Does it require assignments? | Work |
| Does it require SLA processing? | Usually Work |
| Is it a reusable business object? | Data |
| Is it shared by multiple Case Types? | Usually Data |
Example
Loan Application --> Work Credit Review --> Work Customer --> Data Account --> Data Loan Product --> Data Address --> Data
23. How do you decide whether something belongs in an Integration class?
If the functionality primarily represents communication with an external system, I consider an Integration class or Integration layer. This can include REST or SOAP connectors, authentication, request and response mapping, external system-specific transformations, and integration services.
Example: Credit Bureau
Loan Case
|
+-- D_CreditScore
|
+-- Integration Layer
|
+-- Credit Bureau REST API
The Loan Case should understand the business concept "Credit Score". It should not need to know every implementation detail of the external Credit Bureau API.
Pega features that may be involved
- Data Pages
- REST Connectors
- SOAP Connectors
- Authentication profiles
- Data Transforms
- Integration classes
- Error handling and retry mechanisms
24. How do you prevent an application from becoming tightly coupled to a system of record?
I prevent tight coupling by keeping system-of-record implementation details behind appropriate Data and Integration boundaries. The Case should work with business concepts rather than directly manipulating the external system's technical representation.
Bad architecture
Loan Case | +-- Direct REST call +-- Direct SQL +-- Core Banking field names +-- Core Banking response structure
Better architecture
Loan Case
|
+-- D_Loan
|
+-- Integration Service
|
+-- Core Banking
Useful Pega techniques
- Data Pages
- Data Types
- Data Transforms
- REST/SOAP Connectors
- Integration classes
- Service abstractions
- Canonical business objects where appropriate
The Case should depend on a business-level contract, not on the technical structure of the system of record.
25. How do you design for reuse?
I identify assets that have multiple legitimate consumers and place them at the lowest common layer where they can be reused without introducing unnecessary coupling. I avoid creating shared components simply because they might be reusable someday.
Potential reusable assets
- Data Types
- Data Pages
- Decision Tables
- Decision Trees
- Common validations
- Integration services
- Common UI components
- Correspondence
- Common Case processes
- Business rules
Example
Suppose the following Case Types all need Customer information:
Loan Credit Card Account Opening
Instead of implementing customer retrieval three times, I would evaluate a reusable Customer Data Type and Data Page.
26. How do you prevent overengineering?
I use the simplest architecture that satisfies the current business requirement while allowing reasonable future evolution. I avoid speculative frameworks, unnecessary abstraction layers, and reusable components that have no real consumers.
Five questions I ask
- Who consumes this component?
- Is the reuse real or theoretical?
- Who owns the component?
- Will the abstraction remain stable?
- Does the additional layer reduce complexity or increase it?
Example
If only one Case Type consumes an external service today, I do not automatically create multiple abstraction layers just because another application might eventually use it.
Avoid unnecessary complexity:
Enterprise Framework
|
Integration Framework
|
Service Abstraction Framework
|
Service
Instead, I create a clean integration boundary and introduce broader reuse when actual consumers and ownership justify it.
27. How do you design an architecture that supports multiple business lines?
I identify enterprise-wide capabilities first and then separate business-line-specific functionality into appropriate implementation applications or organizational layers. Shared functionality is centralized only when ownership and reuse are clear.
Example
ALPHA ENTERPRISE
|
+-- Customer
+-- Identity
+-- Documents
+-- Notifications
|
+-- RETAIL BANKING
| |
| +-- Account Opening
| +-- Consumer Loan
|
+-- COMMERCIAL BANKING
| |
| +-- Business Account
| +-- Commercial Loan
|
+-- WEALTH MANAGEMENT
|
+-- Investment Account
+-- Advisor Service
The important architectural decision is determining which capabilities truly belong to the enterprise and which belong to an individual business line.
At the same time, do not force business-specific behavior into an enterprise layer just because multiple applications happen to exist.
28. How do you design an architecture that supports future applications?
I design around stable business capabilities, reusable data, and service boundaries rather than today's specific Case Types. I identify assets likely to be shared, keep them independent from individual implementations, and avoid speculative framework layers.
Example
Today Alpha Bank may have:
Loan Application
Tomorrow it may add:
Credit Card Mortgage Personal Loan Business Loan Account Opening
A reusable architecture can provide:
ALPHA ENTERPRISE | +-- Customer +-- Account +-- Product +-- Identity +-- Document +-- Credit +-- Notification | +--------------------------------+ | +-- Loan Application +-- Credit Card Application +-- Mortgage Application +-- Business Loan Application
Each future application can consume the appropriate enterprise capabilities instead of rebuilding them.
A good architecture creates clean boundaries and makes future change easier without creating unnecessary layers before they are needed.
How to Explain Pega Application Architecture in an Interview
If the interviewer asks: "How do you approach Pega application architecture?"
A strong answer is:
"I start with the business capabilities and core business data rather than immediately creating Case Types. I identify which activities represent actual work and which objects are reusable business data. Then I design the application and class hierarchy based on ownership, reuse, and specialization.
I separate Work, Data, and Integration responsibilities so that Case Types are not tightly coupled to data sources or systems of record. I use Data Pages and integration services to establish appropriate boundaries. I place reusable assets at the correct enterprise or business-line level, but I avoid creating framework layers simply for future-proofing. Finally, I consider Ruleset versioning, security, deployment, and the application's long-term maintenance model."
Application Architecture Mental Model
A simple way to remember the architecture discussion during an interview is:
1. BUSINESS CAPABILITIES
|
v
2. BUSINESS DATA
|
v
3. WORK / CASE TYPES
|
v
4. APPLICATION STRUCTURE
|
v
5. CLASS HIERARCHY
|
v
6. WORK / DATA / INTEGRATION
|
v
7. REUSE & SPECIALIZATION
|
v
8. RULESETS & VERSIONING
|
v
9. SECURITY & DEPLOYMENT
Key Pega Rules and Features to Know
| Pega Feature | Why it matters in architecture |
|---|---|
| Application | Defines the application solution and its configuration context. |
| Ruleset | Organizes and packages related Pega Rules. |
| Ruleset Version | Provides versioning and controlled evolution of Rules. |
| Class Hierarchy | Supports Rule inheritance and specialization. |
| Application Hierarchy | Defines how applications are composed and built on one another. |
| Work Classes | Contain Case-processing and business-work behavior. |
| Data Classes | Represent reusable business data and business objects. |
| Integration Classes | Organize external-system interaction. |
| Data Pages | Provide reusable access to business data and help isolate Cases from data sources. |
| Decision Tables | Externalize business decisions from process logic. |
| Decision Trees | Represent branching business decisions. |
| When Rules | Provide reusable conditional logic. |
| Built-On Application | Allows applications to use capabilities from another application. |
| Application Versioning | Supports controlled application evolution. |
| Lock and Roll | Supports creation of new Ruleset versions while protecting released versions. |
| Skimming | Supports creating a new Ruleset version by promoting/copying Rules into a new version. |
Final Takeaway
At the architect level, Pega Application Architecture is not about memorizing the names of rules. The interviewer wants to understand whether you can take a business problem and turn it into a maintainable Pega architecture.
The strongest architectural answers usually connect:
Business Capability
+
Business Data
+
Case / Work
+
Application Structure
+
Class Hierarchy
+
Integration Boundaries
+
Reuse
+
Security
+
Deployment
=
Maintainable Pega Architecture
When answering architecture questions, explain both what you would build and why you would build it that way. That distinction is often what separates a developer-level answer from a Senior Architect or Lead System Architect answer.
This article is intended for Pega architecture learning and interview preparation. Exact screens, terminology, and available features may vary by Pega Platform release and application architecture.
No comments:
Post a Comment