It’s easy to fall into a comfortable repeatable work life. It is ingrained in my work philosophy to structure, standardize, componentize and reuse as much as possible. That seems a logical thought process to gain better efficiency.
A problem with becoming overly structured is that focus is on the minute details while missing the bigger picture. You can’t see the forest for the trees. It is good to periodically take a step back and gain a bigger perspective. Here are five things for data architects to watch out for when examining their work processes.
- Focusing more on the end than on the beginning. Analytics organizes and delivers vast amounts of data to the desktop. The ability to effectively analyze and recognize patterns in vast amounts of historical data gives an enterprise a distinct advantage in the marketplace. Data architects are immersed in enabling data analytics. Care must be taken to understand the lineage of a piece of data. That involves understanding its source, movements and transformations, and quality of the data element before it is modeled in a data mart or warehouse. Modeling for analytics begins by tracing data back to its source of entry.
- Modeling using incomplete analysis. Much emphasis is placed on delivering software in a faster cycle. Speeding up data analysis is difficult. Projects are often forced to perform “just-enough” analysis to move the project forward. Unchecked through the project’s life-cycle, this leads to a poorly performing design that makes no one happy.It is important to understand every entity, attribute and relationship that is committed to the data model. In the “just-enough” scenario, this may mean keeping tabs on the suspect and poorly defined objects. A model can be worked in agile-like sprints but care must be taken to reconcile the unknowns before the final design is committed to the database.
- Not questioning the sacred cows. When you work in an environment that is structured, standardized, and componentized, there are bound to be sacred cows. These are the things that bring order to an otherwise lawless land. They are probably not that sacred. I am not advocating doing away with standards. I am advocating questioning those standards where appropriate. Allow new technology and methods to influence design work. Abandon the “we have always done it that way” mentality. Do away with the sacred cows and develop methods that are timely, realistic and repeatable while delivering models in a standard manner.
- Data is not at the table. This is case of you don’t know what you don’t know. A typical enterprise may have more than 10X the resources on the development side of the house than in the data side of the house. Projects can easily move through development with no, little, or too late data architect involvement.Fixing this starts with data modeling being integrated into the development methodology and IT resources understanding the importance of sound data analysis and design. This involves data architects working closer with development teams including defining tasks, timelines, and attendance at project meetings and standups.
- Flying under radar. Data modeling and administration can be a thankless job. Developers and IT team members who are more visible to end users often get the glory and recognition. Data architects are technical animals. Our analytical personalities tend to not embrace soft skills. Tooting our own horn is more than just a feel good thing. Our visibility means that we are at the table more frequently. Our work is recognized and valued. Data design and data modeling is on the radar screen rather than being invisible.