eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Real-time information systems are seductive because they offer so many ways to quantify what they can do. This creates a powerful temptation to focus on technical comparisons among competing offerings. But that can be a distraction from more meaningful comparisons.
For example, its easy to compare the update time for analytic results, following arrival of new data, between one real-time suite and another. In this respect, real-time goals are like security goals; defining them in technical terms can pave the way for an expensive but irrelevant war of specification sheets. As I explained last week in Chicago at the Real-Time Enterprise conference, developers must think of real-time requirements in terms of business needs. They must think of the payoffs versus the costs of satisfying those needs.
If they focus on technology alone, they may be led to buy overly costly technology because comparing one set of specs with another is easier than understanding the actual needs of today or the likely operating environment of tomorrow.
Its much less exciting to dig down into business functions, and the audiences that each IT function serves, to decide how close to zero latency each piece of a real-time enterprise IT suite needs to be. Worse still, its just boring old engineering to ensure that every piece of the system is capable of returning some kind of result within its specified response time, even when key parts of the problem involve third-party networked services.
The proper definition of a real-time system must go beyond the form “normally returns a result in this much time,” even though this is the common way of defining a real-time design compared with a merely fast IT installation. Rather, whats needed is something more like: “definitely returns a result in time to support these business goals; employs these strategies for degrading precision or timeliness to meet that need for prompt response; and provides these warnings and options to users when circumstances create such trade-offs.”
You wont find off-the-shelf systems offering specs that look like this; you have to think out this approach to fit your particular business strengths and your customers concerns.
Before beginning tomorrows real-time initiative, it will pay to figure out the resources on which an enterprise IT architecture leans most heavily. For example, do customer service systems become saturated at predictable times? Is it practical to introduce some kind of pricing mechanism for these resources—not a dollar amount, necessarily, but perhaps a prioritized process that provides superior service to ones best customers? Technologies are emerging to meet this need; for example, XML-based Web services can be expedited by XML hardware accelerators that consider the source of a request and stratify quality of service according to a business rule.
What must not happen, in the pursuit of real-time performance, is any slackening of controls on what data the enterprise collects and to whom it reveals it. Managers can get swept up in the marketing pitch for a digital dashboard that shows them exactly whats happening and where. Just the other day, I heard a Wal-Mart executive who was enthusiastic over the ability to determine, store by store, how many cans of chili he had sold in the last 10 minutes.
Well and good, but who else might be able to determine—for example—which prescriptions were filled in the time that a particular customer was observed to be at the pharmacy counter? Consider the implications. Maintaining customer confidentiality is not just a good idea, its increasingly the law. Real-time IT can unwittingly make it harder.
Its also pointless to invest in real-time data acquisition, analysis and reporting unless youre also going to re-evaluate your model of who makes decisions based on that flow. It would be wasteful to enable decision-making on a time scale of minutes, then hobble the system with a planning process that thinks in months. It would be foolish to have data available at a store-by-store level when no corresponding decisions can be made at anything below the level of an entire region.
The technology is there to drown you, quite cost-effectively, in data. Have your kayak ready, and think about how youll shoot the rapids before you get to that white water.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.