In the world of software development, it’s easy to get lost in the “how.” Stakeholders often come to us with a fully-formed solution in their minds: “I need a text field, a button, and a table to search for a customer.” While it’s tempting to start building that screen, are we solving the right problem?
In a recent Pega User Experience Expert Circle webinar, Specialist Solution Consultant, @SENIT emphasizes a fundamental shift in application development: stop starting with the user interface and start with the business outcome. When teams focus on the UI first, they often build brittle solutions that address symptoms rather than the core business need.
Watch the video (9 minutes) →
What you will learn
From “I Want a Button” to a Business Outcome
Tim addressed a classic scenario where a stakeholder comes with a pre-defined solution: “I need a text field, a button to run a search for a customer, and a table to show the results for selection.”
He explained that this is a UI design, not a business outcome. The first step is to distill this request to its fundamental purpose. By asking “why,” the true goal is uncovered: “I need to link this case to a customer.”
This simple, powerful statement of outcome changes the entire development approach. Instead of building UI components, the focus immediately shifts to the data model.
The Data Model Is the Key
With the outcome defined, the next logical step is to determine what the data model needs to support it. To “link this case to a customer,” the case requires a field that can hold that relationship. This is where the concept of a data reference becomes critical. By adding a data reference field for the “Customer” to the case, you create the necessary foundation. Only after this is established should the UI presentation be considered.
Understanding Key Data Concepts
To clarify this data-first approach, Tim broke down the essential data modeling concepts in Pega:
-
Embedded Data: This is data that lives within the case itself and gives it structure. It’s not sourced from an external system of record. Tim used the example of capturing a list of family members for an insurance policy. This information is unique to that specific case.
-
Data Reference: This is used for data that exists externally to the case, with its own lifecycle and identity (e.g., a patient record stored in a central database). The Pega case only stores a unique identifier (like
Patient ID). The full patient details are only retrieved from the source system when the workflow needs them, ensuring the information is always current. -
Combining Embedded Data and Data References: The real power comes from combining these concepts to model complex business realities. Tim illustrated this with a multi-level hierarchy:
-
A case has a list of family members (an embedded data list).
-
Within each family member record, there is a list of selectable healthcare plans (a list of data references).
-
This hybrid model allows you to capture unique, case-specific information (the family members) while linking to standardized, externally managed data (the healthcare plans) in a structured and efficient way. By starting with this robust data model, the UI configuration becomes a far simpler, more declarative process.
By defining the outcome and anchoring it in a solid data model first, developers can deliver more flexible, maintainable applications faster.
