Who's Integrated and Who's Not?

Minyanville isn't a site I read with much frequency. There's a piece linked from Oracle's Yahoo! page that can't go unremarked. Tech press is so tech ignorant. I think it's because so much of tech press is made by freshers, who've no memory of tech history nor any evident reading of it. If something is new relative to yesterday, it must be new incarnate. Not often true.

So, in the piece, the author makes a big deal of Oracle's fully integrated offerings versus Salesforce.com's a la carte (or may be it isn't?) menu. Having been in the packaged software business for most of my adult life (not using Oracle, though), I've been on both sides of the vertical integrated package software world; as maker and buyer. What doesn't happen is that

[Intel and Oracle] both have a long history of over-serving their customers -- of selling comprehensive, high-performance products that almost never get used to their full potential.

That's not how it actually works. Yes, the vendor will have as many parts as it thinks it can sell profitably. But, no, those parts are not woven together as a single quilt. The clients do buy some core module (oft times described as some number of integrated modules, but that can't be disassembled). After that, it's a matter of adding what you need, if and when you need it. HR functions are most obvious. Most of the time the real sticking point is the semantics of the core: how does it do the accounting, how does it do the product assembly, and so forth.

Then, the author contradicts himself

Although the cloud possesses the aura of technological freshness, in many ways, it's a throwback to the days of mainframes, when computing was so expensive that sharing it was necessary. Today, the great recession has once against brought expense to the forefront, and raised difficulties for the old over-serving approach.

Sound familiar?? It should. It's been the driving theme of this endeavour from the beginning. Now, whether it makes sense to out-source such a business model isn't driven by the semantics, but by cost and security. Cloud providers can only make money (and the author asserts that they don't, yet) if they can acquire the hardware in greater bulk discount than their clients. For generic Mom & Pop clients, they likely can. For the Fortune X00, not so much. A private cloud is just the old glass house with 3270's, just longer wires. Even if cloud vendors target M&P by the thousands, being able to provision new resources in a snap of the fingers means the cloud vendor has the inventory on site. That costs money. Being able to spread the load to keep all the hardware loaded, but not overloaded, requires that usage spikes be uniformly distributed (with countervailing troughs) over some span of time and space. Also, not likely in the real world. Whether the continuing security breaches are just a flash in the pan, or a true issue remains to be seen. Given that EULAs are always in favour of the vendor, a backlash is inevitable.

The one lever that cloud has: explicit non-ownership of software. Most EULAs (without a source license), are just rental agreements, but without a lot of teeth. Whether real clients will accept rental with teeth has yet to be determined.

Moreover, the author fails to distinguish among the eras of computing:
- mainframe with terminal, where application code (COBOL/RPG/PL1 and files) is executed on mainframe (with some rudimentary editing on a dumb terminal, possibly)
- client/server, where application is partially/wholly executed on client and files stored on server (the engineering workstation on LAN)
- the *nix (and Windows, to a lesser extent) database (usually RDBMS, but not commonly relational schema) with VT-X00 terminal
- webby client/server, where the application is in a browser and is mostly executed on client; data is commonly in RDBMS but not relational
- post industrial computing, where much of "new" development is infotainment, sometimes coerced as business support; RDBMS, if used, is file image

To the extent that smartStuff is limited to using its smarts to manage its screen, we're back to mainframe semantics or *nix/database/VT-X00. As I've been arguing from the beginning. Then, the issue becomes whether we revert to 1960s COBOL (file storage) style mainframe development for applications, or move forward with RDBMS in Organic Normal Form™ as the basis. Angry Birds may make some people some money and attract the bulk of freshers for employment, but it isn't relevant to how Oracle Applications (and their presumptive replacements) are built. To replace an existing Oracle Application (using Oracle as universal surrogate for legacy applications) means having a superior (for some definition of "superior") industrial application. Oracle has been slurping up its clients (who wrote those verticals for end users) with abandon for about a decade. Does the world need yet another GL? Not if it's just a re-hash of the thousands made since 1960. So, Oracle buys its clients in the realization that new ones aren't clamouring at the door. Micro (corporate) growth with macro (economy) stagnation. And the freshers go off to make some other pointless iStuff app. Just repeating COBOL/VSAM structure won't be enough. Touch based, and therefore disaggregated data based, versions mean either leveraging ONF™ RDBMS or writing the equivalent in code/files from scratch. Today's news that Facebook is re-inventing relationalism is kind of quaint. The young-uns never know. I'll be a quid that, like nearly everything else on the net, it will soon turn into a porn dating mechanism.