It is harder than you might imagine to uncover the truth about how an organization uses and works with its data. Surely, you ask, isn't it just a matter of asking your stakeholders and business sponsors? From my long experience, only if you are lucky, and it is a rather special organization.
As an IT person, you can't discover the truth of how a business works with its data from your IT colleagues. You have to talk to the business at large. However, as you wander the corridors in your serious glasses, sober suit and polished shoes, attempting to work out how data is handled, you will soon come to recognize a familiar look of panic in the eyes of a member of staff who clearly has no real understanding of their organization's data. You should also expect, occasionally, to be deliberately confused or even misled.
Why would you be misled? In any organization, many of the staff have an ingrained fear of the 'bod from IT'. Managers in any organization will extol their enthusiasm for any business initiative, but in their hearts probably dislike change. They know that the organization may benefit but they as individuals probably won't. If an IT initiative succeeds gloriously, it means upheaval. There will be a reshuffling and there is a danger that their place in the pack will fall, in favor of newcomers to the organization. It is likely to de-skill them and make their special knowledge less valuable.
There are a whole range of tricks, both conscious and unconscious, that are used by business managers to mislead the IT people who are tasked with delivering a business application. Maybe I've been unlucky, but in the course of deriving a data architecture for an application, I can confidently expect to have my work sabotaged in a number of subtle ways. We are, after all, dealing with humanity under pressure.
Were it not for this, the task of understanding the way that any enterprise works would be simple. In order to create a database that performs well, and that allows reasonably easy and rapid modification, you just have to understand the data before you create any code. It isn't just the way that data is structured, but the constraints on it, the way it is audited, reconciled, retained, secured, protected, updated and maintained. If the data is organizational, you have to immerse yourself in the whole organizational culture and understand better than anyone else the numerous ways that the data is used. Data-governance has to precede development.
If you persevere through the many stages of bafflement, however, there comes a moment when it all suddenly slots into place. What had seemed too complex for any one human brain, suddenly seems almost embarrassingly simple. At that point, you can confidently make your first-cut database design. There is only one truth and no room for creativity in designing relational databases.
The alternative is to 'evolve' your understanding. In its original meaning, evolution meant testing and adapting your model in the face of reality. What is fine for the birds and bees doesn't work for databases because, in many businesses, reality is in short supply.
Phil Factor.
