Data Modeling and the Pega Business Architect

As Pega BAs, we’re concerned with more than just process and user experience; we’re also vitally concerned about data. And that requires us to develop strong skills in data modeling. Let’s talk about what a data model is, how it contributes to solution delivery, and how to build a quality data model in Agile Studio.

We hope you understand we couldn't get to every question during our Q&A session, but we'd like to provide answers to as many as we can.

Check them out below:

Why should a Business Architect build a data model? Isn’t that the LSA’s job? 

The model for which Business Architects are responsible is different from the model for which the System Architect is responsible. 

The conceptual model for which the BA (Business Architect) is responsible is only concerned with business entities - it is a higher level of abstraction than the logical model. This allows us, as BAs, to focus on core concepts like important entities and their relationships. Since the conversation is primarily concerned with business concepts, the BA is best positioned to initiate this discussion with the business about their data, and as such, be responsible for this model.  

The Lead System Architect (LSA) is responsible for implementing the data model in Pega and the conceptual data model forms the starting point for that collaboration between business and IT in the task of developing the Pega Logical model. 

Do Business Architects really need to care about all these types of data models? 

As mentioned above, the Business Architect is responsible for the conceptual data model, and this provides input to the other models that the LSA is responsible for (logical & physical), so it is important to know how to set up the conceptual model.  

That said, the Business Architect does not create a conceptual data model and simply hand it over to the System Architect to implement. As with everything else in Pega, the line between business-related activity and implementation-related activity is a balancing act so it is our responsibility to work hand-in-glove with our System Architects to make sure that the data model we are implementing does everything it can to serve the business now and in the future. 

For more information on data modeling, try out the following modules and missions on Pega Academy 

• Creating a data relationship | Pega Academy  (part of the Business Architect mission)    

• Data Modeling | Pega Academy  (part of the Lead System Architect mission)    

• Data model design | Pega Academy  Data model design 

You said that you can use a data model to confirm your understanding of a process with stakeholders. Why show data models to the business? They won’t understand them. 

With the right explanation from the Business Architect, business stakeholders will understand the conceptual model. I would go even further; this is not something that the BA should create in isolation and then show to the business; it is an artifact that should be created together. The business stakeholders are the ones that understand their context the best, and their involvement is invaluable in achieving a well thought through model. 

When should we do data modeling, is it at the same time as we do User Stories and refinement? 

Your initial data model starts as you gain your understanding of the business process you need to support. This work typically begins during the Prepare phase of our delivery approach, Pega Express™.  We recommend you start early, during your Sprint 0 or the equivalent initiation phase of your project. 

Remember that as Business Architects, we talk to the business about processes and data at the same time. This continues throughout the delivery cycle, including user story refinement sessions, so you can expect to review and update your conceptual data model whenever you discover a need for change.  

Ideally, we build the model as we work on stories.  This makes it easier to consistently refer to data attributes across stories so that you can avoid situations where a data element is called one thing on one story and called something different on another.   

Does the Data & Interfaces section on the case designer impact the Logical Data Model? The Physical Data Model? Both? 

The Data & Interfaces section is a representation of the logical data model. This model gives some information on the physical data model as well, but not all that detail is represented here, especially with regards to the storage of data in different locations and the way they are connected to your application. 

Why spend all that time designing upfront? Isn’t agility all about building things quickly and seeing what works? 

We are not proposing you need to do all the design work up front. That said, the level of detail needed for the conceptual data model is also the level of detail needed to understand the business context to make informed decisions on what should be built. We do not have to design everything, but a little time spent in data design can save a lot of time later when you find that you must make major, difficult changes because you did not fully understand the business’ data needs. 

If you store data in Pega, how easy is it to get data out of Pega or push it in ?

Pega offers a robust set of capabilities to build connectors to bring data in and services to send data out, which can cover many different use cases. With regards to the data models, this means that in many situations we can stay close to the concepts and needs of the business. That said, there are always exceptions. For example, if you know that you will be receiving data from a third-party source, it may be wise to model that data as it is defined by the third party. 

The first time I tried to model data it turned into spaghetti. What would you recommend? 

Modeling data is both an art and a science and it takes practice, so do not worry that your early models do not look the way you would from the start. The best way to model data is to do a lot of it. Learn from people who do it well, ask questions, and ask for feedback on your models. There are patterns that make good modeling much easier, and you will learn them over time. Just do not be discouraged because you cannot learn them all at once. 

What about the questions we need to post to the stakeholders/business to get the right model to be constructed as when we are starting the project we don't have the right info or view 

We consider the data model as a living document, so we recommend putting our thoughts into the model and then use that model when talking with the business about our initial best guess and seeking confirmation or correction. Having the diagram before we build in Pega helps the business visualize their data and with that the gaps in their processes and/or data they may not have considered. It also helps the technical team by having a clearer description of the expectations for the implementation. All of this helps to mitigate the risk of rework due to misunderstandings in the preliminary stages of a project. Of course, as the project progresses more insights are obtained and things may need to change, but with an initial visualization in place, it makes it easier to understand the impact of the change and make the appropriate decisions on the next steps. 

Often when you configure a data model into Pega many attributes are not mapped as DB columns but as a BLOB; is it not only a technical aspect... which suggestions on that?  

From a BA perspective, you normally do not need to worry about getting properties exposed, that is a technical function - as such we would not expect to see this documented in the conceptual model. However, if you are aware of reporting needs, those can influence the data model and may reveal more about the relationships between entities.  At the same time, we might compare the stated reporting requirement with the outcomes that the report is supposed to accomplish and might propose an alternative that makes more sense given how Pega works. 

For People new to Pega, it is important to understand that each entity in the data model does not typically have a table associated with it. We will only create tables for our work objects and will only expose embedded case data necessary for reporting, otherwise, the blob carries everything. Letting go of the details around persisting data on the work object frees us to build a data model that better represents the business relationships between things (and is ultimately better able to handle emerging business needs) without feeling pressure to force those relationships into a more compact structure (which can make the structure less flexible) simply to make the database side of things easier.   

Finally, from a hard-core data mining perspective, we should always be keeping BIX (Business Intelligence Exchange) in mind.  We should expect to be exporting our case structure to a data warehouse and a normalized database and BIX can easily take our class structure and use that to define a target database structure for use in a data warehouse.  Having a data model that shows the relationships between classes, then provides visibility to our data warehouse users about how the resulting tables relate to one another.