Skip to main content

The evolution of enterprise architecture

Large enterprises rely on thousands of business rules to determine how they process customer requests, claims, orders, and cases. These rules define eligibility checks, approval thresholds, pricing, and routing. The way an enterprise organizes these rules influences how it builds, changes, and governs its systems.
Across different eras of enterprise architecture, enterprises have used different approaches to organize business rules, from centralizing them to distributing them across systems. Each era addresses specific challenges but can introduce others. Understanding this progression provides context for the Center-out® Agent Architecture.
As you examine each era, consider where the business rules reside and whether they are centralized or distributed.

Era 1: The monolith

Early enterprise systems used large, single applications that often ran on mainframes. These applications contained business logic, data, and user interfaces in one system.
This centralized design provided consistency because the application maintained one set of business rules. However, the design made changes more complex. Even a small rule change could require teams to modify and retest the application. Adding new channels could also require changes to the application.

Era 2: Client-server

Client-server systems moved the user interface to desktop computers while servers managed data and some business logic. As a result, business rules could reside in both the desktop application and the server.
This distributed design gave applications more flexibility, but it could create multiple copies of the same business rule. When a rule changed, teams had to update each copy to keep the business logic consistent. This duplication increased the complexity of managing business rules across systems.

Era 3: Service-oriented architecture

Service-oriented architecture (SOA) organized business functions into reusable services, such as customer lookup and credit checks. An enterprise service bus (ESB) connected these services.
This approach reduced duplication by making business functions available as shared services. However, business logic became distributed across multiple services. Changes to a shared service could affect multiple systems that used that service, and integrations could become more complex. In some implementations, the integration layer also managed parts of the process flow, making the complete process more difficult to understand.

Era 4: Business process management

Business process management (BPM) shifted the focus from which system owns a rule to which process owns the work. BPM systems modeled the process, its steps, and its rules in a workflow engine that operated separately from user interfaces and back-end systems.
This approach made the process visible and enabled teams to change the process in one place. It also moved process logic toward the center of the architecture, an important step toward the Center-out approach. However, decisions and data could still reside in other systems, leaving some business logic distributed across the architecture.

Era 5: Microservices and event-driven architecture

Microservices architecture organizes applications as small, independently deployable services. Each service manages its business logic and data. In an event-driven architecture, services can communicate through asynchronous events. For example, an order-placed event can trigger shipping, billing, and notification services without requiring one service to wait for another.
This approach gives teams greater independence to develop and deploy services. However, it also distributes business logic across many services. Different services can apply business rules independently, making it more difficult to see the complete customer journey and understand how rules work together across services. This distribution also increases governance complexity.

Era 6: Distributed AI agents

AI agents extend the event-driven architecture by using information to make decisions and initiate actions in other systems. Multiple agents can operate independently and in parallel.

The following figure shows an event-driven architecture extended with distributed AI agents.

Event Driven Distributed AI Architecture

Distributing decision logic across agents creates a new risk. When each agent holds its own decision logic, the enterprise can receive different answers to the same question. Business policies can spread across many agents and services, making decisions more difficult to audit and policies more difficult to apply consistently. Autonomy increases, but central control decreases.

The gap that remains
Across these eras, a pattern emerges. Centralized architectures concentrate business rules, which support consistency and governance but can increase the complexity of change. Distributed architectures give systems and teams greater independence but can spread business rules across the architecture.
Enterprises need both centralized governance of business decisions and flexible ways for channels, applications, services, and agents to use those decisions.

Center-out: A good fit for governed decisions

The Center-out Agent Architecture places Case Management, workflows, business rules, decisioning, data access, AI, and governance at the center of the enterprise. Channels and agents use this shared logic rather than maintain separate copies of it.
The Center-out approach is like building a business capability once and letting new channels reuse it. Some practical consequences are:

  • A web portal, a mobile app, an email bot, and an AI agent can all use the same claim-approval rules.
  • Pega Live Data Agents™ connect to legacy and modern systems without rebuilding them.
  • Pega Application Agent™ can invoke AI agents at specific steps of a trusted workflow, so AI works inside governed processes.

Each era of enterprise architecture addresses a problem while leaving other challenges unresolved. As AI agents multiply, the need for consistent, governed decisions increases. The Center-out approach provides a practical answer: enterprises can build applications on Pega Infinity™ with Case Management, business rules, and governance at the center, while channels and AI agents reuse the shared logic.
For organizations where consistency, auditability, and compliance matter, the Center-out approach provides a foundation for governed agentic applications.

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.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice