Should Pega Blueprint Support an Enterprise Asset Registry for Reuse?

[Sergei_Kart]

In some organizations teams maintain internal catalogs of APIs, services, and domain components. These catalogs help reduce duplication and make it easier for teams to discover reusable capabilities.

However, these catalogs are not designed with Pega in mind. They typically don’t understand Pega artifacts such as Data Pages, Data Objects, Case Types, integration rules, decision logic, or ruleset dependencies. As a result, even with strong enterprise catalogs in place, Pega Blueprint cannot currently leverage the existing Pega ecosystem when generating a new application.

This raises an important question:

Could Blueprint become more effective in mature organizations if it were able to see and reuse existing Pega modules - not just documents or legacy descriptions?

Observed Challenge

Blueprint is extremely useful in greenfield scenarios and during legacy modernization, where most design information comes from documents and existing behavior.

But in organizations that already have:

• Canonical Data Objects
• SOR integrations
• Domain-specific modules
• Approved decision rules
• Reusable process components

Blueprint currently does not detect or interpret these assets. It generates new applications, new integrations, new flows - even when the organization already has well-tested modules. Over time, this could widen the gap between generated solutions and the actual enterprise landscape.

So the question is:

How could Blueprint become more “enterprise-aware”?

Idea: An Enterprise-Level Pega Asset Registry

One possible direction is a Pega-specific registry where existing Pega modules are described in a structured, machine-readable format. The intention would not be to replace enterprise catalogs, but to complement them with Pega-native semantics.

Such a registry could allow Blueprint to:

• Discover existing modules
• Evaluate module capabilities
• Check compatibility
• Reuse canonical data models
• Reuse existing SOR integrations
• Avoid generating duplicates

This is not a proposal for a full solution - just an idea worth exploring.

What Could a “Manifest” for a Pega Module Look Like?

Here’s an illustrative (not prescriptive) example:

Data/Integration Module (Relation + CRM)

Decision Module (KYC)

These examples are conceptual and intended to spark conversation.

4. Dependency Graph: Example for Discussion

If modules were described this way, a registry could potentially build relationships like:

org.relation.master
 ├─ provides data → Relation
 └─ consumes → CRM

org.relation.kyc
 └─ depends on → org.relation.master

org.relation.onboarding.case
 ├─ depends on → org.relation.master
 └─ depends on → org.relation.kyc

Blueprint could then theoretically match user requests (e.g., “Relation onboarding”) to the modules that already exist- instead of generating everything from scratch.

But this raises further questions:

• How deep should module capabilities be modeled?
• What level of standardization would be practical?
• Who would maintain manifests?
• Could Pega automatically extract module metadata?
• Should such a registry exist per instance, per department, or enterprise-wide?

Optimizing GenAI for Rule Extraction

A key challenge in building such a registry is how to populate it efficiently. Manual maintenance is unrealistic, so automation is essential. GenAI could help—but sending raw rule definitions directly to GenAI is problematic:

• Too verbose: Rules contain technical details GenAI doesn’t need.
• Token explosion: Large flows and decision tables can exceed context limits.
• Noise vs. signal: Most content is structural, not conceptual.

Solution: Rule Information Extractor

Instead of sending full rule data, introduce a Rule Information Extractor that condenses and filters only relevant metadata before passing it to GenAI:

What to extract:

• Rule type (Data Page, Connector, Decision Table, Flow)
• Purpose/Description
• Inputs/Outputs
• Dependencies
• Domain tags
• Reusability indicators

Example condensed manifest:

This approach:

• Reduces token usage dramatically
• Improves reasoning by focusing on semantics
• Scales to thousands of rules without overwhelming GenAI

Workflow:

1. Extractor runs on Pega instance - builds condensed manifests
2. GenAI consumes manifests - generates Blueprint suggestions or registry entries
3. Architects review and refine

Final Thoughts

This is not a proposal for a finished solution- more of an invitation to explore how Blueprint might evolve to better support organizations with extensive Pega ecosystems.

If Blueprint could understand existing modules - not just documents or legacy behaviors - it might bridge the gap between generated designs and real enterprise architectures.

I’m interested in hearing how others see this:

• Does your organization face similar challenges?
• How do you manage reusable Pega components today?
• Would a Pega Asset Registry help, or introduce more complexity?
• What might a realistic version of this look like?

[NielsHeinis]

Hi @Sergei Kart, thanks for this very elaborate idea and I think you’re completely right. Blueprint is currently a great tool for getting greenfield and legacy transformation projects started but indeed, in many situations you’re adding new processes and applications to an existing landscape. So I agree that the next step for Blueprint should be that it is capable of taking the existing situation into account if you want to.

It should not be necessary to have a library of all possible rules, but in some way you want to expose the most important, reusable parts to Blueprint. I’m thinking Data Pages, Case Types, Flows. And of course already available reusable Components. I think of it as Business Services in a Service Oriented Architecture. You don’t need the exact implementation details, but you do need to know how to integrate with them, what functionality they deliver and how they behave. Some kind of a library, possibly created by combining GenAI capabilities and human involvement, could be a way of telling Blueprint what’s available.

Besides those functional rules, the Data Model is essential. Blueprint GenAI should be able to learn about the existing data model so that it can produce a data model for your Blueprint that adheres to your company data model specifics. That holds for entities as well as their details. For example, when a government organisation supports two regulations around houses in a Pega Application and you want to add a third one, Blueprint should come up with only additions to the existing model. Identification of houses for example, should be done the same way in all regulations. Ideally regardless of whether the existing processes were created using Blueprint or not.

Interested to learn if and how we might be able to help Pega to add these capabilities to Blueprint to make it even more powerful than it is already.