When Apple launched the iPhone 5, much was made of the new features of IOS6. One of which was the new maps application. This was lauded as "A beautiful vector based interface" and "Everything's easy to read and you won't get lost".
Although the application functioned well, the data it used was far from effective. Unlike the hype, people started to 'get lost'. One thing is patently clear. Apple had not conducted any data quality analysis of the databases that the maps application consumes.
All databases are models of reality. The discipline of data quality is to ensure that the database is the best model possible. It is obvious that the maps database was not checked against reality to ascertain whether it was an accurate or complete model.
An independent analysis of a sample of the Apple Maps (using the Canadian province of Ontario) provided some interesting stats. Of the 2028 place names in Ontario, 400 were correct, 389 were close to correct, 551 were completely incorrect, and 688 were missing.
Apple did not gather this information. It acquired the street and place data from Tom-Tom (the vehicle satellite navigation company) and integrated it with other databases. Despite strenuous denials of culpability by Tom-Tom, the facts show that the location data experienced by the users was missing or incorrect.
To say that this has undermined the reputation of Apple is a large understatement. It prompted a public apology by the CEO, Tim Cook.
So could Tom-Tom and the other suppliers of maps data have knowingly supplied incorrect data to Apple? Probably not. Surely Apple had data quality measurement in place? The results suggest not. Only 19.7% accurate place names and 33.9% of place names missing.
When entering into agreements with 3rd party suppliers of information it is imperative that data quality standards are insisted on as part of the commercial agreement - with penalties for non-compliance. As the results of this little mess between Apple and their suppliers show, you may be able to outsource responsibility, but not accountability.
Hi Rich. The Apple incident is indeed a very good example of what may go wrong when emphasis on functionality gets far more focus than emphasis on data.
ReplyDeleteIt is hard to believe that Tom-Tom has provided bad data of the magnitude. My guess, and guessing is so delightful free of accountability, is that something has gone wrong when transforming the raw data from the Tom-Tom data model to the Apple data model. It is often seen that such a process may corrupt data and leave out data that may not be placed properly in the receiving model.
Hi Henrik, Yes, it is very easy for buyers to be sucked into pretty icons and slick user interfaces and overlook the data. And yes, I agree that Tom Tom are unlikely to have made errors on such a grand scale. My hunch is that the problems happen when they join the databases together. Poor referential integrity could cause many of the problems. I often think that the inappropriate use of inner joins can exclude a lot of information as well. Off the top of my head, other reasons could be over-zealous fuzzy-matching, poorly constructed surrogate keys, using actual data as primary keys and lack of standardisation. The list is endless. Most of the problems in the first video arise from the poor overlay of the maps onto the places. This would definitely be an Apple problem, as they would be the ones who are doing this matching.
DeleteEither way, they have not checked the results of their target model effectively enough.