What we learned importing a Blueprint-designed application into AIM at a retail bank — and why the value came from somewhere unexpected.
Most Blueprint conversations I hear focus on one question: is it worth doing? The implicit assumption is that “worth doing” means a smooth, end-to-end experience where the generated output lands cleanly in your application. That is a reasonable expectation. But it is also the wrong measure.
On a recent implementation at a European retail bank, we used Blueprint together with Pega’s AIM (Alert Investigation Management) industry solution. The import process was not frictionless. But the value it delivered was real — and it came in ways we did not fully anticipate at the start.
Here is what we did, how we did it, and what actually made the difference.
The Starting Point: AIM as the Foundation
AIM is a Pega industry solution with a substantial OOTB (out-of-the-box) application model. Any Blueprint work done on top of it needs to respect that model — not override it. That is the first design constraint worth internalising before you start.
To create a usable starting point for Blueprint, we:
-
Created a new application built on AIM as a full copy of the OOTB solution.
-
Used the Application Signature tool to extract the application structure.
-
Imported that extract into Blueprint alongside the business requirements — a process diagram and a set of text documents describing the target operating model.
This gave Blueprint a foundation that was grounded in reality: the OOTB AIM case types, plus the actual client requirements. The result was a Blueprint that was already partially aligned with what we needed to build, rather than a blank-canvas model we would need to pull toward AIM later.
Cleaning Up and Refining — The Collaborative Phase
The first Blueprint run was not clean. Some case types came through duplicated. The Blueprint contained artefacts that were not relevant to this specific implementation. This is expected, and it is not a problem — it is the starting point for a more important activity.
With the project team, we cleaned up the Blueprint to contain only what was relevant. Then, gradually, we brought in more people: business stakeholders, enterprise architects, and client-side subject matter experts. With each session, the Blueprint became more precise.
This phase turned out to be one of the highest-value activities of the project. Within a few weeks of kickoff, we had a structured, end-to-end view of the future state — and we had walked every major stakeholder through it. Not through a PowerPoint. Through the Blueprint itself, with real case types, real process steps, and the actual structure of the AIM model visible throughout.
Blueprint’s most advertised value proposition is productivity: compress months of development into weeks, generate a working application from requirements. That is real, and it is measurable. But on this engagement, the more significant outcome was harder to put on a slide: risk front-loading.
The stakeholder sessions did not just create alignment. They surfaced integration questions that would otherwise have emerged months later — and the specifics are worth spelling out, because “integration questions” undersells it.
The client had a moderately complex System of Record architecture: event-driven data flows, scattered across multiple SoRs without a single clean access pattern. Understanding how client data would actually flow into the AIM application — in an event-driven way, respecting the constraints of that architecture — required several dedicated architecture sessions. We mapped the data flows, identified the gaps, and made a set of design decisions that had downstream implications for almost everything else.
None of that is unusual. What was unusual is that we did it in week 3, and we did it with full knowledge of the business process implementation. On a typical engagement, that class of question surfaces after the team has been building for two or three months — at which point the cost of the answer is dramatically higher, because you are unpicking decisions rather than making them. The Blueprint-driven stakeholder sessions created the conditions for early discovery. That is the value worth measuring.
The Final State Before Importing
Before we touched the Pega application, we made deliberate decisions about what we were importing and why.
For OOTB case types: Most of the cases we planned to keep close to OOTB. In Blueprint, they look slightly different from the actual AIM artefacts — the visualisation is representative, not pixel-perfect — but close enough to communicate intent. For these case types, we noted separately the specific steps where customisations were planned. The Blueprint served as a map for where we would deviate, not a replacement for the OOTB artefacts themselves.
For custom case types: Several case types were entirely custom — as expected, replacing the OOTB placeholders in AIM. These were defined end-to-end in Blueprint with full process flows and played back to the business before a single line of configuration was written.
The Import Strategy: Two Branches
This is where execution discipline matters. We did not import everything the same way. The whiteboard diagram below captures the core decision: the OOTB case types and the custom (Blueprint-originated) case types required fundamentally different handling.
Main Branch — OOTB Case Types:
-
Imported the OOTB case types from Blueprint to get generated screens for the steps where customisations were planned.
-
Deleted the generated case type rules and saved over them with the actual OOTB case types from AIM.
-
Deleted generated flows, views, and data model artefacts that were not needed.
-
Included custom steps with generated flows and views; updated data model references.
-
Included generated business conditions; updated data model references.
The logic here: we wanted the Blueprint-generated screens as a starting scaffold for custom steps, but we wanted the underlying case type structure to remain true OOTB. Mixing them required a deliberate sequence of import, delete, and replace operations.
Separate Branch — Custom Case Types:
For the Research Task-derived case types (we defined 8 in total), we imported them into a separate branch and used the Blueprint-generated flows directly. There was no OOTB case type to preserve — but that did not mean the class structure was unconstrained.
We still needed to preserve correct class inheritance. Using the class refactoring tool, we structured all 8 custom Research case types to inherit from a single shared Research class, which in turn used directed inheritance to the OOTB Research class in AIM. This kept the custom case types cleanly within the AIM class hierarchy rather than floating independently — which matters for upgrade path, data model consistency, and long-term maintainability.
Final alignments: After the branch work, a small number of additional classes required moving to better conform with AIM’s OOTB class structure. The data model also required cleaning. This is housekeeping — expected and manageable if you plan for it.
What Actually Delivered Value
The import process was more involved than I expected going in. I will be honest about that. But the value was real, and it came from two distinct sources:
1. Risk front-loading — the value that does not show up in the demo.
The integration architecture problem existed before we opened Blueprint. It would have been discovered regardless. What Blueprint changed was when — and when matters enormously to project cost and risk.
Resolving an architecture question in week 3, before a single sprint has committed to a data model or integration pattern, costs a few sessions and a whiteboard. Resolving the same question in month 4, after eight sprints have built on assumptions that now need revisiting, costs significantly more — in rework, in delay, and sometimes in credibility with the client.
Within a few weeks of kickoff, we had a Blueprint representative enough of the OOTB model to be credible, and specific enough about the custom steps to be meaningful. Walking all stakeholders through it — business, enterprise architects, delivery — created the conditions where the hard questions surfaced early. That is not easy to quantify on a business case, but it is very easy to feel the absence of when it does not happen.
2. Generated assets for custom processes that actually got used.
For the completely custom case types, Blueprint-generated flows, views, and data model artefacts gave the team a concrete starting point. This is the scenario where Blueprint’s value is most direct: you design the process, you import it, and you have something to build on rather than something to build from scratch. For 8 custom case types, that is a meaningful reduction in early-sprint effort.
Practical Guidance for Teams Considering This Pattern
A few things I would do differently — or do more deliberately — on the next implementation:
-
Know when to regenerate vs. when to iterate. After the first Blueprint run, make a deliberate call: if the output is significantly off from what you expected, adjust the inputs — requirements documents, process diagrams, the Application Signature extract — and run Blueprint again. If it is close enough to be workable, start iterating within it: changing stages and steps, removing what is not needed, refining the structure. Both paths are valid; the mistake is spending time iterating on a Blueprint that was fundamentally misaligned from the start. Blueprint’s AI assistant can accelerate the iteration path considerably.
-
Decide your OOTB vs. custom classification before you start the Blueprint. The import strategy diverges significantly depending on this. Knowing it upfront shapes how you design in Blueprint and how you plan the import sequence.
-
Treat the cleanup phase as a feature, not a bug. The first Blueprint run will not be clean. Use the cleanup as a stakeholder workshop. It is the right time to make decisions about scope and inheritance, and the right people should be in the room.
-
The Application Signature extract is worth doing properly. The quality of what Blueprint has to work with depends on the quality of the extract. A properly structured AIM copy as the starting application gives Blueprint meaningful context.
-
Branch discipline is non-negotiable. OOTB and custom case types need separate branches. Mixing them creates reconciliation work that is much harder to manage than keeping them separate from the start.
-
Preserve class inheritance even for custom case types. The directed inheritance to OOTB classes is not optional — it protects upgrade path and data model consistency. Plan for the refactoring work upfront rather than treating it as cleanup.
-
Budget for final alignments. Class restructuring and data model cleanup are not signs that something went wrong. Plan sprint capacity for them.
Closing Thought
Blueprint is not a code generator in the traditional sense. It is most powerful when you treat it as a structured design and risk management tool — one that happens to produce importable artefacts as a side effect.
On this engagement, the biggest return was not the generated screens or the imported flows. It was the integration architecture work that happened in week 3 instead of month 4 — at a fraction of the cost, with full context, and before any downstream decisions had locked in. The productivity gains are real and measurable. But this is the value that is harder to put on a slide and easier to regret not having.
That is the outcome worth designing for.