The engagement and practicality of data architect techniques

Artists have techniques. Chefs have techniques. The potter has techniques. Data architects likewise have techniques. No matter what your profession, you use techniques that help you get your job done. Our techniques give our personal signature to whatever we create.

This week I tuned in the Dataversity CDO Vison webinar, Ends vs. Means – The Role of Data Models and Other Key Artifacts. Speakers Kelle O’Neal and John Ladley discussed the role of data models and other data artifacts in application development. In the webinar, the speakers shared a short and sweet quote that got my attention and should capture the attention of other data architects.

“Engagement over technique” – Kelle O’Neal

Engagement defines success in the internet age. Websites use analytics and the data footprint we leave behind to engage us by targeting our visit and spending more money. Your employer likely uses data to optimize customer engagement and improve the corporate bottom line.

Engagement for data architects translates into anticipating our business partner needs. We must talk the talk they talk. Our work must be engaging and easy to understand. This is where our techniques can get in the way. Is the data model, our signature technique, engaging? Does it talk the customer’s talk? Data architects have many techniques to make sure the data model speaks to their business partner.

Beyond the data model, there are other deliverables that engage the customer. Business information requirements, business glossaries, data dictionaries, Visio data flows and other artifacts depict information requirements and business processes that customers understand. Data architects can use these tools to engage their business partners.

“Practicality trumps technique” – John Ladley

Practicality is the fine line data architects walk between satisfying our customer needs while meeting the requirements of our IT methodology. Most contemporary methodologies are more practical. Agile development is a prime example. Artifacts are created if they are needed and when they are needed.

Our customers are just as overworked as the data architect working on their business solutions. They are happier and engaged when the data architect delivers what they need when they need it. Data architects may need to tweak their methods to meet the customer’s expectations. The data architect job is not to only model data but to tell the story of data. Telling that story can take many forms and through many iterations.

Practicality may involve creating required IT artifacts including data models outside of the customer’s view. That goes in the face of many methods that require customer sign-off of the data model. I challenge data architects to use other artifacts to verify the business information requirements with their business partners.

Data architects can be engaged and practical with a little creativity in expanding changing their techniques. For many years, our work involved sitting in a conference room validating a data model with our business partners. I like John Ladley’s and Kelle O’Neal’s approach of creating the IT architectural deliverables in the background while presenting the IT deliverables in artifacts that are targeted to and speak to the business audience.

This is a fundamental shift I believe data architects must make to their techniques to be a valued team member and meet the ever growing demand of understanding data and telling the data story to the enterprise.

Tom Bilcze

Leave a Reply

Your email address will not be published. Required fields are marked *