The Solution Designer role is not something Pega introduced very recently. It was unveiled towards the end of last year, and Pega Academy content around the role was made available at the same time.
My first impression was that this looked like a renewed version of the traditional Pega Business Architect role, redesigned to fit more closely with the Pega Blueprint delivery approach.
The Solution Designer is expected to play a much stronger role during discovery: understanding the business problem, shaping the solution, identifying the right case types, personas and data, and making sure the application starts in the right direction before development begins.
This change also reflects a wider shift in Pega’s messaging.
For the past few years, the message was largely –
Every new Pega application should be built using the Constellation UI design system.
Now, it is gradually becoming:
Every new Pega application should start with the Pega Blueprint delivery phases.
Of course, Blueprint still generates a Constellation-based application in the background. Constellation has not disappeared. But Blueprint is clearly taking more of the center stage when Pega talks about discovery, application delivery and AI-assisted development.
If you look at recent announcements, PegaWorld sessions and the Infinity ’26 roadmap, the focus is increasingly on Blueprint and AI-assisted application development.
The reality is that Pega roles are evolving. And this is not limited to Business Architects. It affects everyone, from System Architects to Lead System Architects.
The T-shaped architect
One concept I learned from my previous projects is that a good architect should always be T-shaped.
The vertical part of the “T” represents your depth in one core area. The horizontal part represents the wider knowledge you develop across related areas.
For example, as a Pega Solution Architect, my technical depth is mainly in Pega engineering and architecture. But the breadth comes from other areas such as:
- Enterprise architecture principles
- Business and domain knowledge
- Infrastructure and cloud
- Security and integrations
- Delivery and stakeholder engagement
This combination is what helps an architect move beyond simply knowing how to build something in Pega.
A useful comparison is the increasingly popular Forward Deployed Engineer, or FDE, role.
If FDE is a completely new term to you, you may need to spend a little more time following the AI space 😉. It has become one of the latest buzz roles, gradually overtaking even the “AI Engineer” title.
The FDE role is generally expected to cover discovery, scoping, system design, implementation, testing and production rollout.
So it is not purely a development role. It is not purely an architecture role either. You need to be both technical and non-technical at the same time.
For an FDE, the technical depth may come from full-stack software engineering and AI engineering. The breadth usually covers business processes, integrations, security, cloud, adoption and customer engagement.
You can visit this Pega blog to learn more about the FDE Vs Solution Designer role
What are the Solution Designer and Solution Builder roles?
Coming back to Pega, Pega did not introduce an FDE role just to follow the current trend. Instead, it has been very deliberate in positioning the Solution Designer and Solution Builder roles.
To understand these roles, it helps to look at the three main phases of the Blueprint delivery methodology:
- Blueprinting
- Authoring
- Value activation
The Blueprinting phase is where most of the business-facing conversations happen. This includes discovery, requirement clarification, identifying outcomes, designing case types, defining personas and shaping the data model.
There may still be architectural discussions during this phase, especially around integrations, reuse, security and enterprise standards. Those decisions will often involve Lead System Architects and other senior technical stakeholders.
Once the Blueprint is agreed, the application moves into the Authoring phase, where the actual solution is built and refined. This is where most of the detailed technical implementation happens.
Traditionally, we would expect:
- Pega Business Architects to lead the discovery and requirement-definition activities
- System Architects and Senior System Architects to lead the application implementation
- Lead System Architects to govern the overall solution and technical direction
With Blueprint-driven delivery, those boundaries are becoming less rigid.
The Solution Designer is not simply a renamed Business Architect. The role is expected to take greater ownership of shaping the solution in Blueprint, validating business outcomes and ensuring that the proposed design is ready for authoring.
The Solution Builder is expected to take the approved Blueprint and turn it into a working Pega application using AI-assisted development, configuration and engineering skills.
This is why the names actually make sense!
Designer and Builder, instead of only Business Architect and System Architect.
Personally, I like the naming. It describes the actual responsibility more clearly.
Why introduce new roles?
The new roles are appearing because the delivery model itself is changing.
When applications start from Blueprint, some of the work traditionally performed by Business Architects, System Architects and even Lead System Architects begins to overlap.
The Solution Designer is expected to work much closer to the application design itself, not just prepare requirements and hand them over.
Similarly, the Solution Builder is not expected to wait passively for fully written user stories and then create rules one by one. The role requires more involvement in interpreting the Blueprint, refining the application and using AI-assisted capabilities to accelerate delivery.
So the new roles are not only about changing job titles. They represent a change in responsibility and in the way Pega applications are expected to be delivered.
Will Solution Designer and Solution Builder replace the existing roles?
To be honest, as of August 2026, most Pega clients are still not using Blueprint as the primary delivery mechanism for every application.
So we are not fully there yet.
Many projects are still following more traditional delivery models, with Business Architects, System Architects, Senior System Architects and Lead System Architects working in their familiar responsibilities.
However, the direction in the Infinity ’26 roadmap is becoming clearer.
Pega has already indicated that a Solution Builder certification is coming, positioned below the Lead System Architect level.
This strongly suggests that Solution Builder is not just a temporary title or an informal project role. Pega appears to be building a formal learning and certification path around it.
I have not yet seen the same level of explicit certification detail for Solution Designer, but I would not be surprised if we eventually see dedicated certifications for both roles.
At the same time, I do not expect the System Architect and Senior System Architect roles to disappear immediately. They will likely remain during the transition because the existing certification structure, project staffing model and customer adoption cannot change overnight.
But over time, those roles may evolve, merge or gradually become less prominent as Blueprint-driven delivery becomes the default.
Among the existing roles, I believe the traditional Pega Business Architect role may face the biggest change first.
That does not mean business architecture skills will no longer be needed. In fact, those skills may become even more important. But the role may evolve from documenting requirements and creating user stories into actively designing the solution inside Blueprint.
What happens to the Lead System Architect role?
I do not see the Lead System Architect role disappearing anytime soon.
But I do see it evolving significantly.
The future LSA cannot remain someone who only guards technical governance, reviews rules and approves architecture decisions after the design has already been completed.
The LSA will need to act as the bridge between Solution Designers and Solution Builders and remain involved across the entire delivery lifecycle.
That means participating in discovery, challenging assumptions, helping shape the Blueprint, making early architectural decisions and ensuring that the application can scale beyond the first release.
The changes to the Infinity ’25 LSA exam already point in this direction. Candidates are expected to start from Blueprint, design the application and then build it. That is much closer to the actual end-to-end responsibility expected from a modern LSA.
In some ways, the LSA role may evolve closer to the FDE model – someone who combines discovery, solution design, deep engineering knowledge, stakeholder engagement and production responsibility.
What this means for existing Pega professionals
The important takeaway is that technical depth in Pega will continue to matter, but technical depth alone may no longer be enough.
Solution Designers will need enough technical understanding to know whether a proposed solution is practical, scalable and aligned with the platform.
Solution Builders will need enough business understanding to interpret the Blueprint correctly and avoid blindly implementing what is written.
Lead System Architects will need both.
This brings us back to the T-shaped model.
Your depth may still be in Pega engineering, but your breadth needs to expand across business, domain knowledge, AI, cloud, security, integrations and adoption.
The role names may change. The certifications may change. The delivery methodology will certainly change.
But the people who continue to grow will be the ones who can connect the business problem, the solution design and the actual implementation.
The future Pega expert will not be someone who only knows how to build rules inside a studio.
It will be someone who can understand the problem, design the right solution, build it effectively and help the customer realize value from it.
