Executive Briefing: Dealing with device data

In 2007, a computer game company decided to jump ahead of competitors by capturing and using data created during online gaming, but it wasn't prepared to deal with the data management and process challenges stemming from distributed devices creating data. Mark Madsen shares a case study that explores the oversights, failures, and lessons the company learned along its journey.

In 2007, a computer game company decided to jump ahead of competitors by capturing and using data created during online gaming. It believed that this data could be used to not only improve the in-game experience but also improve marketing, provide insight into customers, deliver personalized recommendations, research new products, and aid product managers responsible for the product life-cycle. At the time, collecting and storing all the events generated by online game play was a novel idea. So was the idea of using this nontransactional data across multiple lines of business. The company thought its main problem would be dealing with internet-scale data. Despite some bad technology choices and major project problems, it turned out that engineering was the easy part. None of the existing development or data practices prepared the company for dealing with the data management and process challenges stemming from distributed devices creating data: business estimation problems, distributed metadata, master data in operational systems and in firmware, varied SLAs, data quality problems, varied event data, and multiple engineering teams with different skills and expectations. Mark Madsen shares a case study that explores the oversights, failures, and lessons the company learned along the way. The lessons from this project apply as much today in the post-Hadoop, -Kafka, and -Spark world as they did back then. The only part that has gotten easier is the ability to collect and store data.