When, Why, and How to Start Data Modeling

So when, why, and how to start Data Modeling in your project?

First off, I am in many projects where non-technical people do not understand their data or even how to document it. There is no reason to "be afraid" of this subject as anyone can do this.

Data Modeling in UML does NOT require you are technical, a data architect or developer, or even follow the conventions of data development, management, or documentation. This only requires a basic understanding of your "Modeling Tool" which could be PowerPoint, Visio, Lucidchart, Draw.io or the myriad of offers out there today.

The Tools

Out of the dozens of "drawing tools" I have used over the decades, I prefer Sparx Enterprise Architect (EA). Sparx EA allows me to draw anything using UML and CASE techniques. In addition, I can put as much intelligence and information under my drawing elements as I want or need, and to continue to update and manage this intelligence. Plus, this intelligence is in a SQL database where I can reuse in other tooling and purposes.

All we need to do is listen to the requirements, assumptions, and stakeholders and make references in our model elements. We can reverse engineer their current data sources (Excel, Databases, or even Word Documents) and incorporate (import) into our Sparx EA platform.

When to Data Model

As Soon As Possible (ASAP)! I usually start data modeling the first day of engagement. During the "Needs Assessment" where we are collecting assumptions, business requirements, rules, and how things are done "today" in that business (current mode of operations, CMO, PMO) and attempting to understand the future mode of operations (FMO), needs, and targeted outcomes, architecture, and software.

Why to Data Model

"Everything is Input" is necessary to capture and understand the current customer's (stakeholders) needs. We cannot or should not miss anything, as this is all "intelligence" and intelligence is "data". From Actors, to Actions, and Achievements, these are nouns and verbs necessary to drive any project, program, or delivery.

We should always start with "Data"!! With data, everything falls into place. A "User Story" form is "Actor", "Action", and "Achievement", where Actor our your "Nouns", Action are your "Verbs", and Achievements are your pronouns, adjectives, conjunctions, interjections, and articles. We cannot forget "Acceptance Criteria" as this is critical to validate stories, testing, quality, and more.

Thus collecting data about data or intelligence is an important reason of why to data model.

How to Data Model

We can data model anyplace we can capture the stakeholder's data and intelligence. However, if you write on paper, draw in PowerPoint, or simply draw boxes, it is difficult to reuse and repurposes the intelligence and time spent.

Just start with boxes and lines, then add attributes, and that is most of the work product. If you are modeling data, we need to understand how the "data" is "connected". If we are using boxes as "classes" we need the "attributes" and the  "functions" or operations on the attributes. These are things that any non-technical stakeholder can do.

The more technical stakeholders can think about primary and foreign keys necessary to relational data approaches, as well as how we may index, filter, and access needed data. Such data modeling does NOT need to be exact (in the beginning of scope collection) and can be cleaned up later in Solution Approach, Design, and Development/Implementation.

Following these steps, and in Sparx EA, we can start adding more intelligence at every level.

Closing

I needed to get this post out because I am still running into projects where the team is most often stuck in "analysis paralysis" and all the advertised tools in the industry are NOT silver bullets for such problems. If we follow a "Data First" mentality and we properly manage the "Use" or "Reuse" of the collected metadata (data about data), we can push through such analysis paralysis. There is a point where we need to stop asking questions and injecting more problems, and a point where we start delivering (acting, implementing). The beauty of the premise of "Agile" is that it is iterative. The best model for iteration was the 1986 Spiral Model. DO NOT get hung up in the Agile Manifesto that the industry keeps regurgitating. I think a good User Story that Kent Beck introduced in the 90's was the best approach to requirements engineering. Then apply nouns and verbs from such user stories into properly written Use Cases, defined by Alistair Cockburn.

Happy Modeling!

#umloperator