BOD: Batch On Demand
This whole event driven thing is pretty much on the mark methinks. But the critical issue about real time is that it often imposes huge overhead on the system when its not entirely necessary. Its like the reverse of true batch - that is, it actually can reduce the overall efficiency of the system slowing down legitimate users (like customers) from doing legitimate things (like buying stuff!) while the system fritters away cycles generating a real time report.
One of the great things about batch on demand for BI on massive datasets is that it can give you snapshots at regular intervals (ie: daily) of very detailed and complex information. Then if there is an emergency or some other intense need to have quasi real time data, reports can be invoked on demand. Whilst the data is not truely real time it does give a level of flexiblity in the business whilst attempting to proivide the best allocation of processing and infrastructure resources.
The real issue is how you architect either your real time or batch process. Generally complex reports across massive datasets can either take 1. arseloads of time to run or 2. arseloads of processing power to happen quickly. I have seen lots of strategies like partial caching (blended data warehousing mixed with real time data sources) and loads of other approaches - but whats the easiest way to manage this resource consumption issue whilst maintaining simple to understand business logic in your reports? (Remember reports are generally painful to read code at the best of times)
At the end of the day the hardware manufacturers have actually created something of a renaissance in batch processing due to their focus on multiple cores. Why? Whats the easiest way to think about threading? Um, batch!
Whilst there has always been an option to use multithreading in enterprise applications, both languages and hardware have made the use of mutiple threads very attractive and easy to do. The beauty and power of multithreading with batch is that it separates the processing strategy from the code.
We can have a thread priority set high enough to force a single processor affinity and redline it - or lower the priority of it so much that it will take the slops if things are busy with the rest of the system. No matter what we choose to do, the strategy gives two clear benefits: 1. It seperates efficiency issues from code 2. It allows real-time interaction with the processing pipeline though a management interface (ie: JMX or MOM) to adjust how much processing power the batch process is taking.
Even though I have concentrated on batch for reporting, there can be similar benefits for other data interchange requirements. Of course there are also many more complexities too - this is where a real time SOA shines!