How Business Architects play a greater role in Pega Constellation
A new way of building software requires a new way of working together
A Dutch mobility services provider supports hundreds of car dealerships in offering and administering warranty products. Every day, large volumes of warranties are issued, updated, and processed. To accelerate innovation, standardize business processes, and give the business greater influence over the development of new functionality, the organization decided to implement the Pega platform. The implementation was carried out in collaboration with BPM Company. From the outset, the organization chose Pega Constellation and embraced its modern development approach. This new way of working—bringing the business and IT closer together—lies at the heart of this customer case.
The role of a Business Architect in Pega Constellation
Jeroen Memelink is a Business Architect at BPM Company. He helps organizations translate their business processes into working solutions on the Pega platform. Together with his colleague Jordi Recasens, he builds on the technical foundation previously established by the Lead Business Architect. Their collaboration and division of responsibilities illustrate how the role of the Business Architect is fundamentally changing within Pega Constellation.
Memelink: “What appeals to me most about this project is the way we collaborate. Many organizations still follow the traditional Pega approach, where a Lead System Architect largely determines how new functionality should be designed. They create the design, build the initial prototype, and then the development process begins.
Within Pega Constellation, that focus is increasingly shifting toward the Business Architect. That is exactly the direction Pega envisions. By bringing the business closer to the development process, solutions can be delivered more quickly and are better aligned with real-world business needs.”
The beginning of the process
“Within Constellation, the process comes first, with the technology following to support it. The organization uses Pega across three key business domains. The Sales team supports dealerships in issuing new warranties. Claims is responsible for processing warranty claims, while Finance handles the financial administration and invoicing. Behind the scenes, we work closely with an international development team, supported by subject matter experts and business process owners.”
From process to challenge to smart solution
“Our role also starts with the process. A good example is a recent challenge within the Sales department, where new warranties are registered every day. In practice, it turned out that information often needed to be corrected afterwards, for example because data had been entered incorrectly. However, once a warranty had been created, it could no longer be modified. The only option was to cancel the existing warranty and restart the entire process from scratch.
That approach was time-consuming, created unnecessary administrative work, and increased the risk of errors. Together with the business, we therefore proposed developing an entirely new case type: ‘Modify Warranty’. This allows employees to update existing warranties in a controlled manner, without having to restart the entire process.”
Pega Blueprint as first step
“The interesting part is not just that we are building this functionality, but how we are building it. In the past, a System Architect would typically design a solution like this. Today, however, Jordi and I build a large part of the solution ourselves. The first step is always Blueprint, where we work closely with the business to model the entire process. Together, we identify the different personas, define the process steps, capture the required data, and design the complete case lifecycle. We then translate that model almost one-to-one into App Studio.
Within App Studio, we define the entire structure of the application. We create the case lifecycle, add the various process steps, configure the data models, and make the solution largely visible to the business. By that stage, the complete functional structure is already in place. Developers no longer need to determine how the process should work. Instead, they can focus on the technical implementation, such as security, integrations, and other technical components.”
A new way of working together
“This fundamentally changes the way teams collaborate. Because the Business Architect works much more closely with the business, key decisions are made earlier in the process. We can demonstrate solutions much sooner, giving stakeholders immediate visibility into the outcome. As a result, refinement sessions are shorter because everyone already shares the same understanding. Developers also spend far less time going back to the business for clarification.
This approach benefits everyone involved. The business gains greater ownership and is able to provide feedback much earlier in the process. Developers receive a far more concrete functional design, allowing them to focus entirely on the technical implementation. For the organization as a whole, this means new functionality can be delivered more quickly, with less coordination required and significantly less rework afterwards.
The new ‘Modify Warranty’ case type is a great example of this approach in action. It not only solves a real-world business problem but also demonstrates a fundamentally new way of working together.
For me, that is perhaps the biggest change Constellation brings. Business Architects are no longer just defining requirements—they are actively building the solution. This not only transforms our role, but also changes the way organizations develop software.”
Recommend reading: ‘Why Constellation matters: Faster UX and accessibility wins’
