Get some respect in data management
Leave the model behind
Having worked in the data-management field for more than ten years, the most common complaint I've heard voiced by data architects is: "Why don't we get more visibility, respect, and funding?" Data managers and architects often feel like second-class citizens compared to their counterparts programming new applications, using new tools and techniques.
While I'd be the first to argue the benefits of the fundamentals of a strong data architecture, I'd also suggest that if no one is listening, then maybe there's a reason.
What is the appeal of these new technologies and techniques to your management, and how can you use them to your advantage instead of lamenting their arrival?
The pride of any data architect is their data model. Walk into the offices of any data management group and you are sure to see one or more data models printed and pinned to the wall. Usually created in an entity relationship modeling tool, these models show the detailed relationships and cardinality between core business entities (customer and product, for example) and are based on the mathematical principals of relational algebra. In that sense, a data architect should have pride in his or her work - a good data model is a technically difficult thing to create.
But, and this might hurt the architect to hear, no one else cares about your data model as much as you do! Yes, I've come out and said it - no one but you wants to see that huge model that's printed on your wall.
You can take heart, though, because many stakeholders inside your organization are interested in how the contents of that model will affect them. You just need to talk to them using their language. For example, I'm sure the chief executive would want to know that the flashy new online sales system limits a customer to buying only one product at a time (based on constraints in the data model). Bring that information to the CEO, and you're sure to get attention. Show them your data model, however, and you'll be shown the door.
So, the issues become how to capture the attention of the business side, and to gain their understanding and appreciation.
Make it understandable
A data model contains core information and business rules about an organization. Take that relevant information and share that in a format users will understand. Export the relationship constraints to (heaven forbid!) Microsoft Excel.
Every business user understands Excel - they won't read a data model, but the same information processed in "their language" will register. Reduce the number of data entities to a basic "conceptual" data model that shows just the core information users need. The more it looks like a Visio model, the more likely a business sponsor will read it.
Make it pretty
The success of the internet was based largely on adding intuitive, visual ways to browse and view information. XML is becoming a de-facto standard for data management and transfer via the web. While, in many ways, XML can fall short for a robust data management solution, one of the appeals of the XML architecture stack is its inherent ability to visually format information. In other words, make it pretty, put it on the web, and people will read it.
Remove the battle lines
Let's face it, many specialty areas of IT become a "religion". Camps and factions form within the organization. The entity relationship modelers won't deign to speak to the UML modelers, and vice-versa. The XML and app dev camps won't bother to model at all - "go away and let us code" is their mantra. While each of these areas has its technical strengths, the core business rules and information in any of these models can be shared easily between groups. Most entity relationship modeling tools have the ability to export to both UML and XML. Use those features to share information with the "other side".
Share and share alike
Traditional data management based on entity relationship modeling and DBMS storage is valuable, but at its core, it's just storing information, and information can be stored and shared in many formats.
An apple is a fruit whether we call it "apple", "pomme", or "mela" - it's just a different word for the same concept. By the same token, core business information be can expressed in an entity relationship model, a UML model, an XML document, or an Excel spreadsheet.
The OMG standards body is becoming hip to this in its creation of the Information Management Metamodel (IMM), which is an attempt to link all of these diverse models into a single, core metamodel for information exchange. The success of a standard such as this will hopefully pave the way for improved information exchange and the breaking down of the walls between the IT factions.
Embrace the new
So, data architect, don't complain about these new technologies encroaching on your space - use them to your advantage. Use the web and XML/HTML to publish information to your audience. Give the application developers class diagrams and/or XML schemas to help them get their job done faster. Use office tools to communicate to your business sponsor. And, ultimately, keep that data model on your wall for yourself.®
Donna Burbank has more than 12 years' experience in data management, metadata management, and enterprise architecture. Currently leading the strategic direction of Embarcadero Technologies architecture and modeling solutions, Donna has worked with dozens of Fortune 500 customers worldwide and is a regular speaker at industry events.
Sponsored: DevOps and continuous delivery