Sunday, January 17, 2010

You need it real time? Really? Real Time???

Business intelligence and executive dashboards are all the rage soon to be complimented, if not already, by customer dashboards. Although I'm no ERP specialist I get involved in all kinds of projects and one of the most glaring inconsistencies I face is the demand for real time data that changes daily or even weekly.

First we need to drop the term real time and focus on the term most recent. Real time to a guy like me from the plant floor automation/data acquisition/embedded systems/engine control module world means something TOTALLY different. Real time means just what it says, in the moment. No delays.

Second business people need to think about data with the fourth dimension of time. Why ask for a data update when the data hasn't changed? Whenever I hear the request for real time data I push back by asking "How often does the data change?" Sometimes it's hourly, sometimes periodic throughout the day. Most often its daily or weekly. Rarely does the data change minute to minute. More important to understand is how the data drive a decision. In one project we grabbed real time service data when all the executives needed was an hourly update. In return that hourly update was used to perform daily staffing analysis, and even then only when the service data exceeded set boundaries. Since the designers never asked, it was just assumed the data had to be real time. We changed from a real time posting to the executive information portal to an exception based alert and made everyone's life that much easier. This is one of hundreds of examples from healthcare to consumer packaged goods to retail that I have in my work history.

Why is this a big deal? Speed costs. It does in racing and it does in technology. The faster you want to go the more it's going to cost you. In IT we're not doing our jobs if we comply with the request just because the business "wants it". When we load up systems with unnecessary requests we slow everyone down; the opportunity cost of bad design. A great architectural option is the data intermediary which sits between the application and the data store to cache query and service results (if the data hasn't changed, the service response won't either)

Educate the business, add the time dimension to all data, and consider how the data drives decisions when building interfaces, services, reports, and dashboards. And the added side benefit? Less complexity!

No comments:

Post a Comment