Thank you

Charles

Assume that you have several (or many) separate applications running in your cloud. You want some or all of these applications to communicate. How do you do this?

From what I can see (and I do not see Amazon’s lightweight queuing as sufficient) there is a need for a memory based, inter-system messaging solution. This has to be able to be fast yet also be made transaction-friendly (there should be a demonstrable trade-off/choice – within the one solution – between reliability and speed which the user can select rather than have imposed).

Too me MQSeries is simply too plodding to be broad-based in a cloud. JMS is also probably too heavyweight. Something like RV might be more applicable.

There is an opportunity, in my assessment for someone to act and satisfy an opportunity that seems likely to grow and grow – and be applicable within private clouds, public clouds and especially hybrid public/private clouds.

Suggestions and/or comments are welcome.

One of the issues that we have been noodling (and that s being raised, even hijacked) is the relationship between BI and ‘AEP’ and whether AEP will complement BI or interfere. there is also a possible distinction between post-TP data (which is what much of BI has focused on, necessarily) and pre-TP or even new data (where AEP may offer different approaches). Much to think upon – and ideas and comments are welcome.

- Real world sensors have the ability imminently to flood databases and transaction processing
- Why users need ‘BigDB’
- The smart metering mistake that utilities, vendors and even the WSJ make
- Indra’s holistic approach to automated metering and energy efficiency
- To EA professionals and IT management: simply believing in EA is not enough

If you would like to receive a copy:

- either visit: c3bconsulting.com
- or email: requestcopy@insight-spectra.com

I have a Vaio Z – an apparently delightfully packaged, light laptop for mobile professionals. Yet this was delivered with the virtualization capability disabled (I use VMware products). Though, via a BIOS update, this has recently been rectified, the initial reaction of Sony was that nobody wanted or needed it (a ‘Sony knows best’ attitude, of the worst form). In addition, and wholly unapparent until too late, you cannot replace something as fundamental as a disk without sending it (the Vaio Z) to Sony to open up. I wish I had known. Too often on the road, action to make repairs is needed. In the fervent hope that I am not tempting fate, it would appear that Sony believes its systems will never fail (have you already forgotten those exploding batteries, Mr Sony?).

If this was not bad enough, consider how Sony handles customers. I have the Vaio Z and I have an eReader (PRS-505). They do not share the same registration system (two different platforms with no obvious connection are needed) – despite much noise about Sony Club, etc. Furthermore, the registration Web site for the eReader has disappeared (yet with no pointer to where to go instead). Plus, there appears to be no email or web-based support (my eReader is failing) in order that you have to make expensive phone calls to Sony and its slow call centers. Has Sony learned nothing about an Internet world?

Yes, Mr. Stringer: you may make snazzy other products (which I will avoid) but your company is woeful in its support of what I have bought. I am disappointed. In the professional computer world you do not compare to Dell and others (however sleek your designs).

Yes, I am unhappy. But I would be interested if any others find or have found the same? Equally I would love to hear from anyone who has found a ‘magic sauce’ which makes Sony support effective. Please tell.

I will write again about the eReader: again, great packaging but the software, the eBook support and Sony’s partners all leave far too much to be desired.

Picking up in part from last week’s dialogue with Merv Adrian, there is evidence that the traditional approach to databases may produce problems once much greater use of data is enabled. The reality is that everything is becoming intelligent. In the past sensors and real-time data were primarily used in process control and industrial or factory control using expensive Programmable Logic Controllers (PLCs). These PLCs usually existed as islands of automation that were poorly (if at all) integrated into traditional data processing or IT.

Traditional databases (and transaction systems) or their successors are about to face a flood:

- from billions of sensors which often need to pair with calibration values which are then used to ‘clean up’ raw data before presenting or storing it in calibrated form
- where sensor data frequently needs to be aggregated and used in time-series forms of analyses
- where output data often comprises a series of ‘values’ (not just a single number) in order to drive analog outputs
- in which the data will need to be converted into graphical format to show trending and correlation.

What this means is that, as more and more ‘efficiency’ is desired, so sensor data will likely dominate all other traffic. It will become the dominant driver and will make today’s databases and transaction processing – based mainly around financial actions – seem puny by comparison.

In th next INSIGHT-SPECTRA the evidence is presented by Wayne Duquaine; as he says in the conclusion: “One way to think about this is that the analysis of sensor data has similarities to Business Intelligence – except on steroids”.
[To obtain a copy of INSIGHT-SPECTRA, email requestcopy@insight-spectra.com]

In the original dialogue published in Pund-IT on November 4th, the title was different: ‘A Dialogue: Traditional RDBMSs Stagnate as Analytical Event Processing (AEP) Emerges from the Shadows’. The difference matters. I was not trying to suggest that RDBMSs will disappear. Far from it: they will continue. Instead I was trying to explore the issue that Event Processing and the capability to analyze are moving so fast forward that they will remove the ‘crown of importance’ that RDBMSs have enjoyed for so long – a change in relative importance.

In the next INSIGHT-SPECTRA (www.insight-spectra.com – scheduled for publication later this month) a fuller discussion of both RDBMS and AEP than was possible in the Dialogue will appear. [For a copy, please email requestcopy@insight-spectra.com]