Websites can be complex things and these days they often link to a myriad of other websites, off-line systems and databases.
Lets take as a example a customer record of “John Smith”
Is that the same as “Mr John Smith”, “JOHN SMITH”, “J. Smith”, “John B Smith”, “Mr Smith”, “Smith .J”, “Mr J Smith” or “Mr J B Smith”.
It is an excellent question. If your answer is “who cares?”, I am glad I don’t work for your company.
On the website the account might display “JOHN SMITH”, on sales ledger it is “J Smith”, on Customer database it is “Smith .J”.
Which is right.
At one level they are all right, but what happens when the website shop checkout needs to interrogate the customer database and then record to sales ledger?
If we dont have a uniform naming convention then confusion reigns and Mr Smith gets annoyed because the widgets he ordered never turned up.
Now clever computer programmers running in each of those database systems can force data into UPPERCASE or lowercase or CamelCase (love that word) or do a million more complex translations on bits of data. However the fundamental question that rarely gets asked is “should they?”.
Imagine fetching a thousand customer records and applying 10 rules to each one. Even if a rule takes just half a millisecond that is still 5 seconds of hanging about. In big organisations those seconds rapidly mount up. Servers run slowly and reputations are ruined. And what happens if a problem occurs? Hunting down the problem is so much harder (and more expensive) to resolve when we are not really sure what the data ‘should’ say.
Now I mentioned a ‘naming convention’ so couldn’t all systems translate ALL names into camel case with surname first? Yes they could but that slows everything down with every system checking every piece of data each time it is requested. Furthermore if a new naming convention is brought in there is a lot of work needed to change everything.
This is where ‘Single Point of Authority’ as a concept really helps. If we as an organisation arbitrarily decide that one database is the right one, then when that database communicates with other databases, these other databases should never change the format they receive. If they need to display it differently they can do that but when communicating with another database they should always send data in the original format as received from the ‘Single Point of Authority’.
It is a simple concept but is ultimately very powerful.
Going back to Mr Smith, let us decide that the Customer Database is the Single Point of Authority for the naming convention of customers. Now we can ensure all systems talk to each other using that convention. Regardless of how fancy the graphic design department get about display customer names on the website; regardless of whether they want the name displayed in uppercase, lowercase or Ancient Egyptian hieroglyphics when the website talks to any other database, sending Mr Smith’s data should always be done in the originally received format .
If a customer name is wrong, then it needs to be corrected in one place only and that correction will then flow through to all other databases seamlessly.
Databases, associated websites and intranets run a heck of a lot faster when Single Point of Authority methodology is adopted because all those thousands of computer code snippets are for the most part not needed.
How do you start using a Single Point of Authority.
Here is the really good news. It doesn’t require anything except for everyone to agree where the Single Point of Authority is for any piece of data. A simple spreadsheet helps but that is all you need. Do it and make everyone’s life a little easier.
