Subscribe to DSC Newsletter

Rules for building a Data Product in IT organizations

In my consulting work in the Enterprise IT space, I am seeing a definite trend of growing interest in Data Product/Advanced Analytics Design and Development which is becoming increasingly mainstream. Even as I view this a positive, it comes with its own set of perils and pitfalls that will need to be avoided.  

Enterprise IT Application Development is often bureaucratic and involves multiple and redundant levels of management through the design, development and testing phases. Conflicting requirements from multiple stakeholders can make even the simplest of development efforts an intractable effort. For example, enforcing standardization is an underlying premise in most Enterprise IT Initiatives. In my experience standardization efforts undertaken without creating context and meaning around the standardization for the end users is self defeating in the long run. While Agile practices are in vogue and show some promise, they are a long way from dealing with the fundamental issues involved when dealing with large teams. Users want personalization and technology to solve their problems. This is particularly true in the area of Advanced Analytics and Data Products. 

The Enterprise IT organizations I refer to here are not software product companies like Microsoft, Google or Facebook. They are typically IT organizations within Service companies like Banks, Retailers, Health Insurance Providers, Utilities and so on.

In his book "Data Jujitsu: The art of turning data into a product" , DJ Patil gives some simple guidelines which are very applicable  to Advanced Analytics Design and Development within an Enterprise which I have listed below and added my own observations.

  • Rule 1: Start with the problem, not the data. Spend time trying to learn if anyone wants or needs your product. This involves spending time with the end user and understanding the Usage Scenarios and Use Cases that drive the need and seek to understand how the product would benefit the User.
  • Rule 2: Start simple and stay simple for as long as possible. This is especially applicable to Data Products which tends to start simple and become complex. If a Predictive Analytics solution can be built using Excel and a few data sources, try to build that one and test it with the End User before moving on to more complex implementations.
  • Rule 3: Make getting the data into a usable form the first priority. One of the biggest challenges of working with data is getting it into a useful form. Once again, engage the user where possible, through for example interactive UIs,  to make this happen at the front end instead of relying on a complex backend.
  • Rule 4: Keep looking for quick wins and leverage humans where possible. Break down the task into small portions that humans can do. Utilize the feedback you get from the manual workaround solution to build more expensive and time consuming automated solutions.
  • Rule 5: Focus on keeping the data actionable by the End User or as DJ Patil calls it Avoid "Data Vomit" flooding the user with a barrage of data that may not be immediately relevant. Instead use the maxim "Less is More" and keep the data exposed to the User concise and relevant.

While many of the rules listed here may seem like common sense to adopt and follow, in my experience, more often than not this is not the case and is something all of us would be well served to keep reminding ourselves about.

Views: 1051

Comment

You need to be a member of Data Science Central to add comments!

Join Data Science Central

Videos

  • Add Videos
  • View All

© 2019   Data Science Central ®   Powered by

Badges  |  Report an Issue  |  Privacy Policy  |  Terms of Service