What is this substack about? Here is the list of best ideas from the first 25 issues and the Table of Contents.

We could list about a dozen different stakeholder groups that are concerned with something around database modeling:

• Software development managers;

• Database administrators;

• Physical storage management;

• Storage budgeting;

• PII compliance (GDPR etc);

• Financial compliance (SOX etc);

• Payments compliance (PCI DSS etc);

• Software developers;

• DevOps;

• Internal compliance;

• Security;

• Data scientists;

• Knowledge management specialists;

• anything else?  please leave your comment in the comment section!

If you’re interested in this substack, you’re probably from one of those groups.  Sometimes you may have more than one role.  Sometimes you’re aiming to change into a different role.  Sometimes you want to better understand people from another role or you want them to better understand you.

Software development managers

Let’s begin with discussing the concerns that software development managers have that are relevant to database modeling.  In the future posts we’ll be able to analyze technical decisions in terms of those concerns, and that would hopefully help us solve at least some of them.

Development velocity and agility is one of the foremost interests.  When you have multiple teams working on different features, you want them to be as independent as possible.  You want to prevent one team from blocking other teams, and you want to eliminate teams’ dependencies on other roles, such as database administrators.  Examples:

• Two teams working on independent features may both want to extend the database schema, adding new attributes, links or even entities.  You want them not to wait for each other if possible.

• Any particular team that wants to change or extend the database schema needs to experience as little red tape as possible, in terms of permissions, approvals and compliance.

Onboarding people: teams also need to be extended, and that means that you need to introduce new people to the existing teams, or even to create whole new development teams.  You want those people to learn how the system works, and how the data is organized.  You want those new people to become effective as quickly as possible.   How to document the database?  What kinds of texts need to be written for efficient onboarding?  The database modeling policy should also be clear, with specific advice for commonly occurring cases.

Schema change scalability.  Requirements change, and the database schema must constantly evolve, and the process of evolution too must be scalable.  Your teams may need to work on multiple schema changes and data migrations simultaneously, and you don’t want them to wait for one another: engineering practices must support this.

Schema migrations stability.  Extending the database schema, migrating data, changing database technology, creating derived data representations: there would be dozens, hundreds and even thousands of such changes over the years.  Ideally you want everyone in your development organization to be able to execute this kind of changes in a safe, reliable and well-understood manner, and not to reinvent established solutions without need.

Data access maturity.  You want to have a reliable way of reading and writing from and to the database, available to software developers. It should be tolerant to mistakes, it should be easy to learn (see “Onboarding people”).  It should efficiently handle the common data tasks. All programming languages and systems used in the company need to be supported, to prevent stagnation of some parts of the stack.

Understanding storage.  You want your developers to understand the capabilities and limitations of database server software and hardware, and also the concerns of other stakeholders from the list above.

Technology migration.  No data storage stack is final, no matter how much you’re invested in it at the moment.  Some day you will need to migrate from something that you’re now migrating to.  All of the concerns listed above would still be relevant during the time your technology stack radically changes: velocity, speed of onboarding, org-level scalability, reliable data migrations, understanding the new storage system, etc.

This list of concerns is probably incomplete: please leave your comment in the comment section!

In the following post we’re going to return to the general theory of database migrations.  After that we’ll continue with the discussion of stakeholders.