Several weeks back I blogged about things gone bad in database design. It has gotten considerable discussion on LinkedIn. A common theme emerged that is not a surprise. Many data architects find themselves disengaged from the application development lifecycle.
Becoming engaged in application development is not as simple as putting a sign out and saying “Hey, I am here and ready to model your data.” Often the most obvious things we need to do are right under our nose but remain unseen. These are usually the things we can control and affect the change we want to see.
This past week I read an interesting article on the Harvard Business Review on how to improve business writing. About half way through, I realized how much this advice parallels what a data architect can do to improve their data modeling skills. Here are the author’s six points rephrased and refocused for a data architect audience.
- Think before you model. Time to market for a data model is becoming increasingly shorter. Invest time playing with the model with pen and paper before committing it in a modeling tool. Once the model is in the tool, spend some more time perfecting the design before seeking the input and approval of others.
- Give a focus to your model. Position the entities most critical in the design front and center if at all possible. Our eyes are trained to find a point of focus and work out from that point. The orientation of your entities should support his design principle to be more readable.
- Model concisely for readability. Model thoroughly but focus on the objects needed to support the design. That means using subject areas and eliminating related entities on the fringe of the data requirements. Metadata should also be concise and easy to read.
- Speak like your audience. The Harvard Business Review article is spot on with avoiding jargon and $10 words. Translate the business data requirements into data model objects that are recognizable and in the business speak of your clients. It is OK to change their words for an enterprise perspective. Just be sure they are words the enterprise understands.
- Read what you model. We proofread our business correspondence, but do we proofread our data models? A data model should tell a story. Can you identify and relate to your main subjects? Can you follow your storyline with your relationships? Does your model presentation look good and make sense? Good modeling is good storytelling.
- Hone your data modeling skills. Good modeling involves developing a repeatable consistent technique. Consistency makes the data architect’s life easier. It also makes the data architect’s message, the data model, easier to understand when the audience has the same familiarity. Good modeling skills acknowledge user design input and changes in methods and technologies. Keep it fresh to keep it relevant.