I'm currently reading Michael Hugos' book titled Building the Real-Time Enterprise and it made me wonder about my own company and how ready we are for Real-Time. Hugos defines Real-Time Enterprise as:
"A real-time organization is a company that has learned to operate in a continuously changing and coordinated manner with its suppliers and customers. A real-time organization receives, analyzes, and acts on a steady stream of information that describes its market environment and its internal operations."
I work in the banking and finance industry which has relied on automation and Information Technology (IT) for as long as computers have been available. In fact, the finance industry spends more on IT, as a percent of revenue, than any other industry according to Forrester Research. Yet, a substantial amount of our internal IT solution space is geared around time-based or batch processes.
As we move forward in time, especially as on-line banking and customer growth penetrate more and more time zones, the fundamental concepts that led banking 40 years ago into 'nightly processes' will have to give way. Our industry will need to operate in real-time, because phrases like 'end of day', and 'nightly cycle', and 'maintenance window' simply have no meaning in a 24 hour world.
The finance industry is not alone in coming to grips with real-time processing. I was at a conference this year and heard Dean Hager, CIO for Lawson Software tell a pertinent story contrasting the police departments in St. Louis and London. Hager and family live temporarily in London, although he is originally from St. Louis. He was anxious to visit friends and family on a recent trip to the States and on his return to the airport was apparently traveling in excess of the posted speed limit. His high velocity excursion was interrupted by the flash of colorful lights, quasi melodic tones, and a local constable.
Most of us know the drill from here, with the exchange of government documents, the quiet non-verbal pleas for lenience, and the unavoidable "thanks Officer", delivered with appropriate sincerity. In this case, however; the process actually ended quite well for Hager, as the officer allowed him to proceed on his way, albeit at a slower pace, without a citation. Before leaving, Hager decided to check his mobile phone for any email messages from his airline to see if his flight was delayed.
Among his new mail was a notification from the British Motor Vehicle agency that his other car (driven by his wife) was just photographed running a red light in London. The email was accompanied by a picture, a court summons, and a bill for the offense.
Consider the contrast between the scenario in the US, where the police office had to wait in hiding for a speeder, pull them over, take all the risks associated with a traffic stop (videos abound on YouTube), and then after an hour of work the event ended without a citation, i.e. collecting any fees for the state on behalf of the trouble/expense of maintaining speed control. Meanwhile in Britain, the governement was able to issue a bill for services rendered (traffic enforcement) with zero risk to an officer, in real time with sufficient data to counter any arguments.
I'll leave the whole big brother, cameras in the sky debate for another time. Additionally, the roles could be reversed as there are cities in the US that use cameras and places in Britain that do not - so this is not a US versus Britain conversation. For now let's concentrate on the two business models. Which one is more effective as a revenue generation solution? Which one is safer? Imagine how many lost opportunities happen when an officer is processing a single speeder.
In Hager's real world example we get to see the impact of a conventional business model compared to a real-time model.
Even though our banking systems still need to rely on batch processing for many of our functions, we should be thinking about solutions that operate continuously. So, for instance; let's say you are building, buying, or deploying a system that receives data from a batch process. Ask yourself - even though the upstream process is batch, does your new process have to be batch? Could the new solution be deployed to operate in real time, even though initially it will only get used in spurts, i.e. when the batches are ready. Later, when the upstream batch process changes to a continuous flow, your system will already be able to handle it. In other words, don't propagate time-based/batch architecture unless it is necessary.
What examples of real time systems do you have?