Consider the principles presented in this webinar for future projects, future releases and commencement of new features. Also be mindful of introducing a "new way" of doing something whilst the "old way" continues to require support & maintenance. This is prone to introducing confusion to the delivery team, and will likely not deliver return on investment.
For example, assume you currently have a Case Type data model that is tightly coupled to your Physical Data Model. This may have an embedded page or page list of *-Int-* class instances that reflect database column names, relational database structures (e.g. a Customer embedded page and a separate CustomerAddresses page list), or integration message fields.
A preferable data design would be a Logical Data Model (*-Data-*) class of Customer (containing a page list of Addresses) and a single auto-populate property that Refers to a D_Customer data page. The business case for refactoring the existing Case Type and the resulting data migration for (millions of?) existing cases to yield a "nicer data architecture" is unlikely to be funded.
The next Case Type to be implemented (whose data model doesn't exist yet) that references Customer data could however pioneer an improved data design leveraging the principles discussed in this webinar.