In a recently hosted podcast for Enterprise Management 360˚, Donna Burbank spoke to several experts in data modeling and asked about their views on some of today’s key enterprise data questions.
The session provided lot of insight into how data is transforming businesses in today’s marketplace, and some great ideas to help other businesses looking to do the same. You can listen to the podcast on the Enterprise Management 360 website here – and as a taster, we’ve pulled out some highlights.
Danny Sandwell, Product Manager at erwin (www.erwin.com)
Simon Carter, CEO at Sandhill Consultants (www.sandhill.co.uk)
Dr. Jean-Marie Fiechter, Business Owner Customer Reporting at Swisscom (www.swisscom.ch)
Hosted by: Donna Burbank, CEO at Global Data Strategy (www.globaldatastrategy.com)
The sample analogy that I generally use is that of a blueprint for your house – you wouldn’t build your house without a blueprint. When you look at that blueprint, first-off there’s great information for the people who are building the house; where should the foundation be, what are the measurements, what do they need to build, cut, nail together?
But then there’s more to that blueprint, because there’s also interfaces that are defined in there. The people who are going to be hooking you up to gas, water and electricity in the home, they know where those pieces are, what the details are behind those, and they can understand that. But then when you look at the blueprint, think of the end-user; think of the person who is going to be living in that house and hiring people to decorate – they can also use that blueprint to give people that same information but in their perspective.
To me, that’s what a data model is for a database, or a data source, or a data architecture. It’s a view in great detail, visual in nature, but with many different contexts, and many different perspectives for the different stakeholders that might be working with that data.
I talk about a data model being like a map to help you navigate through your data landscape, with data entities instead of places, and relationships instead of roads. And as with a map, there are different types for different purposes.
People have street maps, site plans, navigation charts, and there’s also different scales or levels of details. So, in a similar way, a data model can use symbols to represent different concepts with your data, and it has the detail relevant to its purpose, and that’s important.
And an important companion to that graphical element, the visualization of the model, is the data dictionary which describes the elements in the map in a similar way to how a gazetteer describes places on a geographical map. So, taken together, these are useful documents to detail where you are, where you want to be, and how to get there as far as your data is concerned.
Simon and Danny give a very good idea of what a data model is. And for us who are more technical, we talk with the business and show them a representation of the data or information reality within the company. We can tell them we have customer information and it is related in this way and that way with incident information or inventory information, and it makes it very easy for the non-technical people to understand why somethings are not possible when they ask “give me a report with this and that”.
We can say “look, this is how the data is kept within the company. We don’t have any relationship between that part of the data and that other part of the data, so we cannot put together a report or analysis on that data.”
So, it helps us when we talk with business people to make them understand how the data is represented, or the information we store is represented within the company.
Yes, we use it for that. We do a lot of design of the business part of the Data Warehouse or Business Intelligence based on the data model. We work with the business people and based on the data model, they suddenly say “oh ok, I can have that information linked with that other information on the same report, that’s what I want.”
It also helps if somebody says “I want that information”, then we go back to the source systems and ask them to keep that information and send it to us. So, we use it for documentation, we use it to talk with the business people, and to get the business requirements aligned with what we can offer technically.
Yes, as long as they understand the concepts; customer, contract, inventory, and you explain to them where to find it in the data model. They suddenly see that the data is inter-related, or that the data is completely separated and it has no relationship. It helps them understand what they can get together, and what belongs together, and what doesn’t belong together.
We’ve had lengthy discussion where some people wanted to see information on incidents related to a certain contract and we said “look, we don’t do that. Incidents are related to a customer not a contract, so you can’t have a contract-level report on incidents.” And when they see the data mode it helps them realize the limit where we can have stuff or we can’t have it.
There’s a common taxonomy categorizing models into three types; business, application and implementation. Business models are descriptive of the current or required business data. Application models represent a technology-agnostic design for the efficient storage and retrieval of the data described in the business models. Implementation models add the necessary technical data for a specific target technology. And while the Application model is often associated with a software application, it could just as easily be for a new business process design, for example.
So, that’s how we describe the types of models, and yes I would agree with Jean-Marie was saying. It is a communication tool with the users, as long as you have an understanding and can speak to that at the right level, you can actually talk to the business people about their data.
I’ve seen a real trend over the last few years. You know we’ve been in this business for a while and our experience, especially back in the day, would be trying to get a business person to help construct that data model and try to get their time. You schedule the time they don’t show up.
What I’m seeing is the ownership of the model and the data modeling process being co-owned now between IT and the business, because the business is seeing the value. It really helps them get into something that’s complex, understand it, talk in their terms, and be able to contribute to the overall health and welfare of the data of an organization. So, as data becomes more democratized, it’s not just the end-users using the data model to understand it, they’re actually participating. And we’re seeing more business people in the process of building that model and really putting some skin in the game.
So, to me, it should be a business function first, before it becomes a technical function. Because until we understand the business and how it aligns to the business, we can’t make some of the key decisions on how we’re going to implement it, and how we’re going to align it with any applications that might be serving the business.