Data modeling has become unimportant to software consumers as organizations operate more software packages and develop less custom software. Similarly, some software producers have forgotten what data modeling is and what its business value is under the ongoing pressure to deliver new releases faster using an Agile development process. Here’s a reminder.
Software development without data modeling
Agile software development focuses its attention on stories that are a powerful method for describing the functionality required to support various business processes. Too often, the associated data is treat disrespectfully like a poor cousin. New columns are simply added to the data model, with little analysis, as they’re discovered as a by-product of elaborating the stories.
This neglectful approach to the data model has tragic consequences when the application performance becomes unacceptably slow, the access model needs an upgrade or a major functionality enhancement is looming. In all these situations, the shortcomings of the underlying data model will greatly increase the effort, cost and risk associated with addressing the new expectations for the application.
We can avoid these risky, expensive situations when software developers pay a little more attention to the data model to deliver software faster with lower sustainment costs. Now data modeling is contributing business value. Let’s elaborate on this idea.
Achieve clarity
The data model is the bridge that produces shared understanding among project staff that originates from different disciplines, exhibits various levels of understanding and widely varying experience. For example, we can agree on the definition of a customer by agreeing on the primary key, the list of attributes and the associated foreign keys.
This modeling approach is superior to endless wordsmith debates that occur when we try to define a customer using a series of sentences. Using the data model to achieve clarity adds business value by reducing the risk of producing an incomplete, misleading or unusable system.
Balance attention on process and data
Describing the data that a business process manipulates through its steps improves the accuracy of the process definition. For example, if the customer sales history is supposed to be used by a business process but isn’t accessed by any step, that’s a strong indication that the process definition is incomplete.
Recognizing that disconnect during design makes it fast and cheap to correct. Balancing the attention given to process and data produces a more complete design that leads to higher quality software. This balance adds business value by reducing the risk of major rework in development projects when misunderstandings are uncovered much too late during testing.
Understand project scope boundary
Every data model ends somewhere. If its current end doesn’t reach the project scope boundary, then there’s remaining work. If the current data model ends somewhere near the edge of the known universe, then the data modeler has been carried away by the excitement of the work. For example, if the data model does not consider versioning of the attribute values of key entities, then it isn’t sufficiently complete to support the project scope.
Quickly forming an understanding about how well the scope of the current data model covers the expected functionality adds business value by providing important insight into the remaining uncertainty of the software development project. That uncertainty can be used to describe project risk to the project sponsor.
Estimate data model completeness
During design, the data model should become progressively more complete as attributes and foreign keys for all the entities are defined. For example, if a process step is dependent on a customer type value and that attribute hasn’t been recognized in the data model, correcting that oversight improves the completeness of the data model.
Quickly estimating the approximate percent complete of the data model adds business value by providing useful insight into the completeness of the overall design and the per cent complete of the software development project. That per cent complete can be used to forecast a reasonable cost at completion.
If you want to learn more about this topic, consider watching this webinar: Unlocking Business Value through Data Modeling and Data Architecture.
Can you share more ideas for how data modeling adds business value to your software development projects?
