February 13, 2017 at 10:42 pm
Comments posted to this topic are about the item The Power of the Data Model
February 14, 2017 at 2:45 am
Hi David,
I fully agree with you. Models are the best way to communicate with business experts and also to make sure that we understand what we are doing. If someone cannot explain something in a simple way, let's say in a diagram in a piece of paper and in a couple of minutes, it is most likely that he doesn't understand what needs to be done.
Kind regards,
Paul
February 14, 2017 at 5:45 am
David,
Appreciate your insightful article. Would you be interested in posting a photo of the 15 circle diagram your friend gave you? When you say it is near the birth certificates of your children, that says "this is important." Learning from those who have preceded is a treasure. By the way, I began my "computing" days as a 10 or 11 year old on a Commodore 64, typing in code from RUN magazine. Still remember my first PC-compatible computer that my dad bought me, and how weird technology is that it cost as much as it did - 40MB HDD and all - and yet how much I learned.
Thanks for the wisdom and history of this post!
John from the US
February 14, 2017 at 6:28 am
Great article, David!
I hope to reach the point where I can form such useful models. And, there's always something to be said about learning from a higher mind. I still have trouble slowing down my "Let's get from A to Z" brain just to express a plan in words that others can understand.
I wanna see that model! 😀
Kindest Regards,
Mike
February 14, 2017 at 7:26 am
David ... I could heartily agree until I got to the part about the data model being owned by someone outside of IT. I believe that entities should be owned by organizations outside of IT, but not the data model. There is the notion of "system of record" where Department A owns entity "John" and Department B owns entity "Mary". If Department C comes along and wants to create "Fred", but Fred is basically the same as John, then you don't have to fight for what is right. Department A will do it for you and you can be the peacemaker showing Department C how to get to the data.
February 14, 2017 at 7:32 am
Would you be interested in posting a photo of the 15 circle diagram your friend gave you?
Agreed. As interesting as I found the article, the lack of any kind of picture leaves it short, in my view. I can say after reading this that a good model is important, but I can't say after reading this that I have a picture of what you had in mind. It's not always a cliché that a picture is worth a thousand words.
February 14, 2017 at 8:01 am
The 15 circles and relationships diagram makes perfect sense to me. My son and I have an ongoing joke that every training class, every conversation, every tutorial, all bypass step one which gives foundational understanding of the situation, grounding principles that one should return to time after time. For example I see programming as inputting text into a GUI and persisting it to disk. It is basically moving text around. The deeper we get into the internals of SQL Server the more we lose touch with reality and the purpose for the applications users are running.
February 14, 2017 at 8:44 am
I would have loved to show the diagram however I am not 100% sure about the rights to reproduce it are. It's a shame because it was quite skillful in circling most things back through entities called "Need" and "Customer" and that alone got the Pavlovian response from business managers.
I am still not sure whether it was a brilliantly expressed emphasis on our prime objectives or a cynical piece of NLP to get what the modeller wanted. Again, that uncertainty and the fact that it worked either way was part of the brilliance of the piece.
Oh, and I'll see your Commodore 64 and raise you one Vic20😉
February 14, 2017 at 8:50 am
I would have loved to show the diagram however I am not 100% sure about the rights to reproduce it are.
If you paid the consultant to do the work, it's yours to do with as you please. If for some reason it is still uncertain, I will say again that some kind of diagram to illustrate an otherwise interesting article would be very helpful to understanding. The lack of some kind of illustration is a significant shortcoming.
February 14, 2017 at 10:31 am
No mean spirit intended, but I'm not a big fan of legends based on blind trust. I too made it through the article hoping to see some proof of the Great Modelling Allegory. But alas, just another story about what we all hoped could be shared, could be true, or not.
February 14, 2017 at 12:22 pm
AZJim - Tuesday, February 14, 2017 7:26 AMDavid ... I could heartily agree until I got to the part about the data model being owned by someone outside of IT. I believe that entities should be owned by organizations outside of IT, but not the data model. There is the notion of "system of record" where Department A owns entity "John" and Department B owns entity "Mary". If Department C comes along and wants to create "Fred", but Fred is basically the same as John, then you don't have to fight for what is right. Department A will do it for you and you can be the peacemaker showing Department C how to get to the data.
A true conceptual model wouldn't/shouldn't be concerned with System of record, At most you should be worrying about functional boundaries from a vocabulary point of view: what this data actually represents; why is it important. Who (and by who I mean what business function) "cares" about it: who creates it, who needs to know about it, what kinds of things might happen to it.
I actually agree with David on this one - the conceptual model belongs to the business. The logical and physical might live over in IT, but they are in support of the conceptual.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
February 14, 2017 at 12:37 pm
Matt Miller (#4) - Tuesday, February 14, 2017 12:22 PMAZJim - Tuesday, February 14, 2017 7:26 AMDavid ... I could heartily agree until I got to the part about the data model being owned by someone outside of IT. I believe that entities should be owned by organizations outside of IT, but not the data model. There is the notion of "system of record" where Department A owns entity "John" and Department B owns entity "Mary". If Department C comes along and wants to create "Fred", but Fred is basically the same as John, then you don't have to fight for what is right. Department A will do it for you and you can be the peacemaker showing Department C how to get to the data.A true conceptual model wouldn't/shouldn't be concerned with System of record, At most you should be worrying about functional boundaries from a vocabulary point of view: what this data actually represents; why is it important. Who (and by who I mean what business function) "cares" about it: who creates it, who needs to know about it, what kinds of things might happen to it.
I actually agree with David on this one - the conceptual model belongs to the business. The logical and physical might live over in IT, but they are in support of the conceptual.
Yes, having the business draw a picture using a proper conceptual entity relationship diagram is a lot better than having to parse their requirements as narrative from 120 stream of consciousness emails. It also forces the business to resolve conflicts between themselves by collaborating on a deliverable, rather than the development team being confronted with 3 conflicting versions of the requirements.
I'm all for it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 15, 2017 at 1:24 am
I enjoy discussions about abstract models, partly because that's my primary area of expertise, and partly because there aren't enough of them!
In any case, I agree that a good conceptual model can lead to a shared, unified language across the whole enterprise - IT and non-IT both included, and that this is one of the highlights of a good model. Sometimes it really does come down to the apparently - but not actually - simple task of naming things correctly. Clear, precise names mean clear, precise concepts in dicussion, which promotes in clear, precise requirements and clear, precise solutions.
On the other hand, I'm not so certain about the model itself being something that non-IT people need be exposed to directly. There's a sort of common misconception that data modeling is something anyone can do on intuition alone. And, sure, anyone *can* look at a business, its process and entities, and come up with some kind of model. But it takes actual expertise and experience to come up with a correct model.
What do I mean by correct? I mean one with is, in fact, a representation of the subset of reality being modeled, and which also (and therefore) contains no internal contradictions. Reality, after all, entails no contradictions. Therefore if the model does, then the model is not a representation of reality.
Sure, sometimes this is trivial. But sometimes it is not, and being able to see when it is not is a skill, and it is this skill which requires expertise and experience. One needs to be able to look "through" the model and see all of the logical consequences of what has been wrought. I have found, in the past, that exposing business people to the model directly will result in them making suggestions regarding changes directly to the model - "let's put this column over here instead", or "this seems complicated, can't we just do x?", or "Why is inventory separate from asset? They're the same". (no, they're not), or "Why is customer separate from account? They're the same too" (no, they're not either). This is not a situation you want to be in. What the business people should be telling you about are the functional requirements, the business processes, and so on. They are absolutely not qualified to build, or critique, a data model as such.
February 15, 2017 at 1:49 am
As I start to dive more and more into the NoSQL realm, I'm actually inclined to disagree with the typical modeling practices being more important. The amount of time spent on modeling and maintaining that model in certain scenarios can be extremely tedious, slow, and expensive in certain situations.
Dumping data into a big bucket after conforming and validating it just seems more painless and flexible. "All your data, whatever it may be, for or against the model, now exists here. Have fun!" I really like the sound of that, but not without a price. What you fail to do on the back-end can transfer to the front-end. However, shifting that power of defining the model on the back-end to the front-end is surprisingly better for those who are not database professionals. That's because now, they can model the data on the front-end any way they want and fully control it.
February 15, 2017 at 2:23 am
xsevensinzx - Wednesday, February 15, 2017 1:49 AMThat's because now, they can model the data on the front-end any way they want and fully control it.
Could you elaborate on how this works a little more?
It seems to me that this is a really dangerous state of affairs - and I'll set aside the obvious problem of different users creating different models with different semantics.
Over my career there have been countless occasions on which someone in the business has come over to IT looking for "help with a query". You listen to their problem, and you start to wonder what their actual end goal might be. When you ask about this, you discover that what they are trying to do with the data will not actually give them the information they need to achieve the end goal - often it will give them something totally misleading. So, sure, the business person gets the query they want, but it actually sends business decision makers down precisely the wrong path!
I could list off dozens of examples of this, but let me just use the most recent couple (abstracted for anonymity). Take a business spread across multiple locations. An analyst would like to see inventory utilization over 12 months across these various locations. So they grab the current inventory location and sum sales over 12 months. What's wrong with this picture? Inventory can move between locations over time! This is the kind of error pure business people tend to make. They have to work so hard just to do the analysis itself that the don't have any leftover concentration to consider all of the details and consequences of what they're doing.
Second example: Let's take the average performance of each location. Now we want to get the overall performance of inventory across the company as a whole. Well, we've alreay got this nice summary, so let's just average that one. It's easy for everyone to see how the single company wide figure was produced from the individual locations. Except that the analyst just averaged an average, producing a meaningless number. This report then goes up to the board, who makes decisions about what the company needs more (or less) of based on that number. Again, the analyst was so overloaded by having to try to come up with the specific structure of the problem that they didn't consider the meaning of what they were producing.
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply