Have you been talking dirty to your developers? I am not talking about the four-lettered profanity. I am talking about the lightning words that ignite emotions and actions by their very presence.

Yesterday I attended a seminar on Big Data, the Cloud, No SQL and Agile presented by Karen Lopez. It seems like buzzword bingo, but it was quite insightful. One of the points that arose during the day was that new technology followers see terms associated with traditional data modeling as being dirty words, words associated with unproductivity and work counter to their new methods.

I have chosen five terms near and dear to data modelers that strike a sensitive nerve in many new technologists. Let’s examine how to turn the dirty talk into sweet talk in our customers’ eyes and ears.

  1. Metadata – Metadata offers great value in today’s data oriented world. Object definitions and characteristics propagate from the data model to many tools. Metadata is documentation in the eyes of many new technologists. They see it as a do it as you have time deliverable. Data modelers should make sure metadata story cards are framed in the terms of end deliverables on analytical reports, glossaries and help systems. Associating them to hard deliverables gives metadata a place in the inventory of must-do deliverables.
  2. Data Governance – To many the idea of governance translates to a long and convoluted approval process that sucks away sprint time. Governance cannot be ignored. It must be streamlined. Involve data stewards early and align their processes with the sprints. Data governance can be worked on incrementally with delivery in sync with the sprint. Your business partners need to be educated and be on-line with faster and more incremental delivery cycles. As with metadata, governance needs visibility in story cards and sprints.
  3. Data Models – I know that data model has been a dirty word before the advent of Agile and Big Data. Modelers may have earned some of that distain in our long history of over-modeling and analysis paralysis. Here is a two pronged approach to turn the tide in favor of data modeling. First, Develop a method to incrementally deliver a data design that allows you work 1-2 sprints ahead of the team while not compromising the design. Secondly, avoid solely speaking about the data model. Give the developer what he needs. It may be a report or spreadsheet extracted from the model. Keep the model as a deliverable but speak to the team’s key deliverables they need from you.
  4. Data Modeler – The words data modeler, data architect or database designer may well be on your business card. Unfortunately, the title pegs us a one trick pony. Looking objectively at the title, it says we have one sole purpose in our job. Agile likes to brand each of us as being flexible as Gumby on a project. We know that is not true. It is a good idea to translate the job title into a project role, such as database designer, metadata analyst and business data analyst that aligns to the deliverable. Use these role names as you incorporate your work in the sprint. It gives visibility to your breath of responsibilities and makes your involvement easier to understand.
  5. Enterprise Model – Many new methods look at software development from a “solve the problem at hand” perspective. Data modelers are paid to “solve the problem at an enterprise level”. The 2-3 year build an enterprise model approach is dead today. However, you can work from an enterprise perspective in short sprints. Sell the approach that you need to be on a subset of the team that works 1-2 sprints ahead. This buys time to see an enterprise pattern develop over a longer period of time. In the end, you should be developing reusable components that can be used across the enterprise.