Monday, October 24, 2005
Good grief
Jared Still pointed this article out on Oracle-L. It is difficult to describe how astonishingly stupid this research is, as reported.
The premise of Gartner's argument is that as improvements in networking technologies eventually lead to real-time connectivity to any data, that that data is best kept closest to its natural source rather than at the intersection of a row and tuple of a database that, as it turns out, is actually little more than a remote cache. I hate to see what Fabian will make of this, I'll just point out that (in common database usage) a row is a tuple It almost certainly is for the purposes of the article.
The analysts then construct the following idea based on RFID (gotta get those buzzwords in),
Instead of walking the aisles, taking inventory of everything on the shelves, and then storing that inventory data in a database, Gartner analyst Donald and Ted say to just leave the "data" with the can of soup. Then, in the business process of restocking, the nightly, hourly or however frequently scan of all the RFID tags in the store bypasses the step of storing the inventory data in a database and goes directly to placing an order for more of that can of soup. Not only does the resulting business process come closer to achieve real time timing, but a step is eliminated from the process. Said the analysts "if I only have a millisecond need for persistence, processor and memory can handle that. The data ends up existing for less time than it takes to store the data."
A nice clue here that these guys are java guys - the word persistence occurs almost nowhere else.
So here we go, a couple of store restockers walking the aisles at one in the morning, got their java X-Pad fired up scanning the stock a tin of soup at a time wirelessly making a round trip for each can of soup at a time to a remote server that doesn't bother to record the information anywhere other than in memory and the next day their boss gets the new stock delivered. In fact this is surely overcomplicated, as neither the store nor the supplier, nor the credit agency nor the logistics company, nor the sub-contractors ever know how much they have, how much was ordered or where it was going. As the store owner never knows how much he sold, where or to whom let's just cut out the middle men altogether - don't walk the store, don't bother working out how much stock you have (needs a change to GAAP but hey this is investor insight) and just order random things, deliver random things, issue random invoices and pay random amounts.
Ok that's not true - apparently there is an important caveat,
The analysts also identified the one caveat where databases will continue to play an important role: where, for reporting purposes, retention of historical data is a requirement for exercises such as long term analytics. Some data will need to be kept. But not all.
Now you and I might see this as a suggestion that companys like for example tescos and wal-mart might need some data warehousing and BI. Not apparently
"The press can quote us," said Feinberg. "We're debunking BI. It's not an application anymore. It's a service that's accessed when and where it's needed and [as said earlier] the data persists only as long as we need it."
Once your query has run the data can go, no need to store it in case you run a slightly modified version next week.
That'll be fine then. Oh yes there's also a dubious 'humorous example' suggesting that there is no point in giving health care to amputees. No really, read it.
At one point, Feinberg picked a more morbid example but it really made the point of questioning how, when, and where data should persist. Feinberg rhetorically asked where his health records are better off being stored: in a database in California, on a credit card in his wallet, or a chip that's embedded in the back of his hand. The answer, as you can imagine, was in a chip in the back of his hand. It's there that the health record of Donald Feinberg stands the best chance of always being as up-to-date as possible; at least moreso than in a database across the country that a local hospital in Orlando, FL (should Mr. Feinberg require emergency care) may not be able to access (or update) in real time.
Feinberg said that we could store our health records on a credit card that gets stored in our wallets, but that in that location, the data is already further away from its source than it needs to be. Feinberg talked about how people can become separated from their wallets in the course of an emergency and then jokingly talked about how, if we become separated from our hands, we may have a problem that's too serious for our health records to be of much help.
12 Comments
The premise of Gartner's argument is that as improvements in networking technologies eventually lead to real-time connectivity to any data, that that data is best kept closest to its natural source rather than at the intersection of a row and tuple of a database that, as it turns out, is actually little more than a remote cache. I hate to see what Fabian will make of this, I'll just point out that (in common database usage) a row is a tuple It almost certainly is for the purposes of the article.
The analysts then construct the following idea based on RFID (gotta get those buzzwords in),
Instead of walking the aisles, taking inventory of everything on the shelves, and then storing that inventory data in a database, Gartner analyst Donald and Ted say to just leave the "data" with the can of soup. Then, in the business process of restocking, the nightly, hourly or however frequently scan of all the RFID tags in the store bypasses the step of storing the inventory data in a database and goes directly to placing an order for more of that can of soup. Not only does the resulting business process come closer to achieve real time timing, but a step is eliminated from the process. Said the analysts "if I only have a millisecond need for persistence, processor and memory can handle that. The data ends up existing for less time than it takes to store the data."
A nice clue here that these guys are java guys - the word persistence occurs almost nowhere else.
So here we go, a couple of store restockers walking the aisles at one in the morning, got their java X-Pad fired up scanning the stock a tin of soup at a time wirelessly making a round trip for each can of soup at a time to a remote server that doesn't bother to record the information anywhere other than in memory and the next day their boss gets the new stock delivered. In fact this is surely overcomplicated, as neither the store nor the supplier, nor the credit agency nor the logistics company, nor the sub-contractors ever know how much they have, how much was ordered or where it was going. As the store owner never knows how much he sold, where or to whom let's just cut out the middle men altogether - don't walk the store, don't bother working out how much stock you have (needs a change to GAAP but hey this is investor insight) and just order random things, deliver random things, issue random invoices and pay random amounts.
Ok that's not true - apparently there is an important caveat,
The analysts also identified the one caveat where databases will continue to play an important role: where, for reporting purposes, retention of historical data is a requirement for exercises such as long term analytics. Some data will need to be kept. But not all.
Now you and I might see this as a suggestion that companys like for example tescos and wal-mart might need some data warehousing and BI. Not apparently
"The press can quote us," said Feinberg. "We're debunking BI. It's not an application anymore. It's a service that's accessed when and where it's needed and [as said earlier] the data persists only as long as we need it."
Once your query has run the data can go, no need to store it in case you run a slightly modified version next week.
That'll be fine then. Oh yes there's also a dubious 'humorous example' suggesting that there is no point in giving health care to amputees. No really, read it.
At one point, Feinberg picked a more morbid example but it really made the point of questioning how, when, and where data should persist. Feinberg rhetorically asked where his health records are better off being stored: in a database in California, on a credit card in his wallet, or a chip that's embedded in the back of his hand. The answer, as you can imagine, was in a chip in the back of his hand. It's there that the health record of Donald Feinberg stands the best chance of always being as up-to-date as possible; at least moreso than in a database across the country that a local hospital in Orlando, FL (should Mr. Feinberg require emergency care) may not be able to access (or update) in real time.
Feinberg said that we could store our health records on a credit card that gets stored in our wallets, but that in that location, the data is already further away from its source than it needs to be. Feinberg talked about how people can become separated from their wallets in the course of an emergency and then jokingly talked about how, if we become separated from our hands, we may have a problem that's too serious for our health records to be of much help.
12 Comments:
If I sell a can of soup I won't be able to scan it on the shelf at midnight... it's gone! - so how I can I order what I don't know I had? ;-)
And if this is the end of BI - perhaps I should not apply for the global director of BI job at my firm... gosh I'm worried
And if this is the end of BI - perhaps I should not apply for the global director of BI job at my firm... gosh I'm worried
Ah, but the new super-aware networked systems noticed the delivery via the loading bay and the sale via the till, as well as being able to track, from space, the movements of the soup can stolen by a former datawarehouse consultant to feed his family.
I'm still confused though - how does it know when to order, and how many cans, if none of this is stored anywhere? I guess you just issue a query and the RFID network simply reports all the soup cans out there and how full they are, and displays a nice map.
I noticed one of the conclusions was "Develop new applications for DBMS independence". Sigh. Will they ever think of developing new applications for client-side development tool independence?
I'm still confused though - how does it know when to order, and how many cans, if none of this is stored anywhere? I guess you just issue a query and the RFID network simply reports all the soup cans out there and how full they are, and displays a nice map.
I noticed one of the conclusions was "Develop new applications for DBMS independence". Sigh. Will they ever think of developing new applications for client-side development tool independence?
I remember the days when .com companies where crashing. The financial analysts from many big companies kept saying that the market would turn around the 'next quarter' and asked people not to worry. After a few quarters of not turning around, they started saying market would turn around following half and finally the market was totally bust and the uncertainty was gone there was no need for analysts. It was clear for public that it was a goner.
My feeling is that in computer field also the big companies have to keep saying something to keep their business afloat and to attract attention: "Hey, Look at me, I am a player in this field".
Sometimes the management comes up with theories like this telling the world of their research and findings.
My feeling is that in computer field also the big companies have to keep saying something to keep their business afloat and to attract attention: "Hey, Look at me, I am a player in this field".
Sometimes the management comes up with theories like this telling the world of their research and findings.
# posted by 
: 5:33 PM, October 25, 2005
: 5:33 PM, October 25, 2005
Yes, that would be life imitating predictive art or something. Some magazine editors had recently listed the top magazine covers of the last century, and that was one of them. Another was one of my personal faves, the National Lampoon "Buy this magazine or we'll shoot this dog." I still have it.
That Gartner article reminds me of the Sorcerer's Apprentice segment of Fantasia. Gee-whiz wow technology, ignoring functionality.
What is missing in such a usage is boundary conditions - say a store adds a new product, it doesn't move because the people who want it already go elsewhere. So the store gets rid of it (I've seen this happen with kid's favorite Juicy-Juice). But of course, that is a Pollyana view. In reality, stuff is on store shelves because manufacturers pay for shelf space. Except in walmart, where the store forces the manufacturers to cut costs to get shelf space (and I wouldn't be surprised if they extort money from the manufacturers too). In the end, someone has to make an "intelligent" decision about what is on the shelf, and you can't do that without a database.
Someone on oracle-l mentioned jit car manufacturing - they seem to have missed that GM spun off Delphi, and is now having to support Delphi in its bankruptcy - and a similar thing is happening to Ford, too. VW went through this a few years ago with some nutcase VP, too. Jit works fine as long as parameters don't change, but it can fail catastophically with one small broken pipe.
Sometimes the old ways are the good ways.
Some data doesn't need persistence - crash box data in your car, for instance, just needs to keep the last 30 seconds or so. Where you need a database is to keep all that crashed box data when it is recovered.
xwegif
That Gartner article reminds me of the Sorcerer's Apprentice segment of Fantasia. Gee-whiz wow technology, ignoring functionality.
What is missing in such a usage is boundary conditions - say a store adds a new product, it doesn't move because the people who want it already go elsewhere. So the store gets rid of it (I've seen this happen with kid's favorite Juicy-Juice). But of course, that is a Pollyana view. In reality, stuff is on store shelves because manufacturers pay for shelf space. Except in walmart, where the store forces the manufacturers to cut costs to get shelf space (and I wouldn't be surprised if they extort money from the manufacturers too). In the end, someone has to make an "intelligent" decision about what is on the shelf, and you can't do that without a database.
Someone on oracle-l mentioned jit car manufacturing - they seem to have missed that GM spun off Delphi, and is now having to support Delphi in its bankruptcy - and a similar thing is happening to Ford, too. VW went through this a few years ago with some nutcase VP, too. Jit works fine as long as parameters don't change, but it can fail catastophically with one small broken pipe.
Sometimes the old ways are the good ways.
Some data doesn't need persistence - crash box data in your car, for instance, just needs to keep the last 30 seconds or so. Where you need a database is to keep all that crashed box data when it is recovered.
xwegif
Moron Walmart inventory and X-box kiosks: http://www.dvorak.org/blog/?p=3141#more-3141
# posted by : 11:43 PM, October 25, 2005
: 11:43 PM, October 25, 2005
Did anyone bother to tell these guys that their little example was a DB anyway???
Store = DB
Can = data
Guy with PDA = Query
lol...perhaps im just alone but i thought it was rather enlighting to see a "Gartner Expert" come out with such garbage. Common sense is a foreign concept to these two it seems.
Store = DB
Can = data
Guy with PDA = Query
lol...perhaps im just alone but i thought it was rather enlighting to see a "Gartner Expert" come out with such garbage. Common sense is a foreign concept to these two it seems.
# posted by : 12:51 AM, October 26, 2005
: 12:51 AM, October 26, 2005
I'm wondering what happens if the store burns to the ground. I trust they will keep at least one backup copy of the store up to date in a different location?
I would think the whole thing was a sophisticated spoof, if it wasn't so typical of the sort of "blue sky thinking" these idiot organisations spew up on a regular basis.
Post a Comment
I would think the whole thing was a sophisticated spoof, if it wasn't so typical of the sort of "blue sky thinking" these idiot organisations spew up on a regular basis.
