When an organization decides to reimagine a large Pega estate, the first plan usually looks like a code project: pick a target, convert or rebuild the flows, test and cut over. Budgets and timelines are set on that basis.
A few weeks in, the team typically finds that nobody can say with confidence what the existing application does, why it does it, or which parts people still use. The main difficulty is not the code. It is knowing what to build.
The Two Halves of the Requirement
The first half is the rules. Years of investment sit in case types, flows, decision logic, validations and screens. Rewriting without them means rebuilding from memory, which captures what people recall and misses what they do not.
The second half is behavior. What people do in the application differs from what it is configured to do. Steps get skipped, work moves to a side spreadsheet, and a screen built for one purpose is used for another. A rebuild that copies the configuration also copies the workarounds, because the configuration was written around them.
Both halves are needed, and they have to be reconciled. The comparison of configured and observed behavior is where the findings are: paths nobody takes, steps nobody planned, and rules people routinely bypass.
The screen above is from the Pyze demo environment. It drills from a step in a process into every application used on the same case, then into the interaction detail for one of them. This is the behavioral half of the requirement, based on observation.
Limits of Workshop-Based Discovery
The conventional way to gather requirements is to interview people. This works for a small number of journeys. For an estate with hundreds of flows, discovery by interview takes weeks per journey, subject matter experts are in demand elsewhere, and different people describe the same flow differently.
Even optimistic per-journey estimates, multiplied across several hundred flows, produce a discovery phase longer than most sponsors will fund. A more practical approach is to read the estate directly and use workshops to confirm findings.
A Single Engine With Two Inputs
Pyze Modernization Intelligence takes two inputs: what the application is configured to do and what people do. It reverse engineers the rules, flows, case types, screens and data model directly from the platform, recovering the business intent from the application itself. It reconciles that with observed behavior to find gaps, workarounds and unused paths. It then generates the outputs a program needs:
- A rationalization map that states, journey by journey, what to reimagine, consolidate or retire.
- Business requirements, product requirements and technical design documents per journey, ready for review, with each requirement traced to evidence.
- Build artifacts for the target platform, generated from your own components and patterns.
- A measured baseline of adoption and productivity, so that results after the change can be compared with the state before it.
The engine runs inside your environment with models you have approved. There is no public endpoint and nothing leaves your network.
Results From Prior Engagements
Two anonymized examples show the shape of the result.
A large US health insurer had a whole Pega application ingested: about 2,700 rules, about 570 flows and 17 case types. For a case type, business requirements, product requirements and technical design were generated in about two days from a configured environment, with a live server running inside the customer environment.
At a tier 1 card issuer, a moderate-complexity journey was measured flow by flow. Getting to production code took 52 days manually and 17 days with Pyze, and 592 hours of effort against 136. That is about three times faster per flow. The same issuer’s acquisitions transformation ran three times faster with 66% less effort.
These are results on other estates. For a new estate, the working projection is 50 to 60% faster to production than a manual rebuild, and it remains a projection until it has been confirmed in the first wave. We recommend running the work wave by wave: take a first set of journeys, measure the acceleration on your own flows, and decide based on the measured result.
Where to Go Next
- See the full approach on the Pega modernization page.
- Explore Modernization Intelligence and how it reads rules and behavior together.
- Read how the gap between configured and observed behavior becomes the requirement set: Using the Gap Between Configured and Observed Behavior as a Requirement Set.