In principle, any physical model should have a corresponding logical model that represents a business’s own view of its needs in a technology-agnostic way. When it comes to data, that ideally consists of a business glossary and some sort of visual representation of the relationships between the business concepts defined in the glossary.
In my experience, most businesses don’t have a well-structured and up-to-date logical data model in place, if they have one at all. In fact, expertise in running a business does not equate to expertise in describing the taxonomy of the business and many subject matter experts are poorly trained in how to articulate their data needs.
What’s more, I have never worked on a Pega project where the physical data model was based on a logical one (before I explained the need for it, that is). I think that’s partly because Pega’s approach does not seem to pay any attention to logical data modelling (see my appraisal of Pega’s Direct Capture of Objectives approach). However, if you don’t have a meaningful taxonomy that describes clearly and unambiguously the nature of the concepts your business cares about, how can developers possibly build you a software solution that accurately represents those concepts?
When you are using a Pega Framework, such as Financial Services Industry Foundation 7.21, it comes with a ready-built class structure. However, as with any “off the shelf” solution, if you deploy it without checking to see whether it fits your needs, you are likely to run into problems. Adjusting process flows in a framework after the solution goes into production is relatively painless. However, adjusting the very structure of the underlying physical data architecture is costly once the solution goes into production and the longer you leave it, the more incorrectly-structured data it accumulates. Once a physical data architecture is in place, there is no “tweaking” it if it is wrong because it is the very foundation of the application. Fixing it involves significant refactoring and data migration. It is far more expensive than taking the time to get your data model right in the first place.
The ideal way to do a gap analysis between your business’s data needs and the capability provided by a particular technology solution is to compare your logical data model with the logical data model that underpins the technology solution. However, while Pega refers to its Financial Services Industry Foundation 7.21 entity relationship diagram as a “logical” model, Pega’s model is specific to its own technology and is therefore a physical model. Logical models are technology-agnostic.
I have created an A2 size entity relationship diagram (in Visio 2013 – download it here) that represents the kind of logical concepts that underpin the Pega FSIF 7.12 physical model. If you are a Pega Business Architect feel free to use it and adapt it to your needs. This version 0.1 focuses on the core concepts of Party, Account and Asset and in order to produce it I drew on my experience in modelling for financial services clients. You may have some questions regarding the cardinality of some of the relationships (e.g., why a particular relationship is “zero-to-many” instead of “one-to-many”). If so, feel free to contact me for an explanation.
I have attempted to normalise this model as much as possible but when you add all the attributes needed by your organisation, you may find it normalises further. You will notice that several entity types on this diagram correspond to a single data class in Pega. This is because physical data models are often de-normalised for performance reasons.
As usual, challenges and comments are welcome.
Kind regards.
Declan Chellar
I can guess most of the relations but opening the model in LibreOffice every relation is a many-to-many.
Thanks, Luc.
The relationships, in particular the cardinality, would have to be adapted to whatever business reality you wanted to model. The ones I’ve put in place are meant to be a generic, educated guess, based on my experience at different organisations. With that in mind, I don’t think it matters if LibreOffice changes the cardinality.
Declan