Peace, love, and the IBM System 360s


"Our vision for 2010 is the same as IBM's for the year 1960." So said Oracle's Larry Ellison from the stage at last week's event to celebrate his company's acquisition of Sun Microsystems.

With Sun in hand, Oracle will now take us back to the simple virtues of mainframes 50 years ago. Updated, these virtues are:

  • Simple deployment. Rather than integrate and configure a collection of software products on a server, customers install a purpose-built box with all the software installed, integrated, and configured.
  • Simple support. Rather than weave through the pointing fingers of multiple vendors, customers turn to just one to obtain support for their systems.
  • Simple reliability and performance. Because the vendor owns all of the elements in the hardware-software stack, it can "engineer-in" reliability and performance, as IBM did with the System 360.

As one Twitterer wrote today, isn't this what people want -- systems that just do what I want? Of course, but we must also recognise the evils of the mainframe sixties.

  • Monopolistic account control. IBM's predatory sales practices with its mainframes landed it in a US antitrust case that lasted 10 years. IBM prevailed, but there were no winners in that contest.
  • Plodding innovation. The explosion of hardware and software innovation that began in the mid-70s happened after IBM's mainframe monopoly era. Digital Equipment lead the charge in hardware. Cullinet, others in software. Ultimately, this innovation wave produced Apple, Microsoft, Intel, Sun, Google ... Why didn't IBM create these innovations much earlier? A monopoly defends its base first, tweaks its base second, and only then starts thinking about real change.
  • Slow solutions delivery. The mainframe era produced our jokes about IT high priests speaking arcana but holding all the keys. Mainframes were locked in special rooms to maintain their reliability and integrity, and only certain business tasks got priority. And your task usually was not a priority.

As Oracle, IBM and the other big vendors, and cloud providers like Salesforce move inevitably to integrated stacks, we can hope they will simplify today's complex systems.

But we must also identify what we risk to obtain the promised benefits. The risks are particularly vital when considering Oracle, which has gained a reputation for abusing its customers as often as it helps them.

At the Oracle-Sun event today, the conversation about the rewards and risks of integrated systems was necessarily high level, and ultimately won't do. Each customer will have to create his or her own equation when entering the brave new world of integrated systems:

[Specific] benefit = [specific] virtue - [specific] evil

We spoke today with one of Oracle's reference customers for the event who had done this math, and was ready to take the plunge for Oracle's Exadata platform (the first of its Oracle-Sun hardware-software systems).

My reading: This customer balanced the benefits of Exadata (efficiency gains) with elements to reduce the risk of abuse by the vendor (careful crafting of expectations for Oracle and Sun, growing capacity requirements, and presence of other big vendors in his architecture).

And there's more. As Oracle executives repeatedly pointed out today, most customers don't buy hardware-software stacks from single vendors today. But the model is coming. My initial thoughts on what Larry's trip back to the sixties will mean for application development and delivery pros:

  • Think of integrated hardware-software stacks as potential delivery vehicles for standardised workloads. Ultimately, hardware-software stacks will take vendors like Oracle into "build to order" systems that can be dropped into branch offices, new plants, and so on. I suspect the simpler these systems are the better they'll work.
  • Define where you've got to have choice and openness. You may have relied on Java to give you freedom of choice before. It isn't clear how much choice Java will enable in single-vendor hardware-software stacks. How will vendors let partners into these stacks? Despite Oracle's protestations, I continue to doubt it can have both best stack integration and best of breed stack components.
  • Define where you've got to have common services. Each vendor stack will bring its own database, application server, security, identity management, management, and so on. Which of these services will be the foundation for your architecture?
  • Think about archipelagos an an architectural metaphor. If you've got IBM, Oracle, Microsoft, and Salesforce as vendors, you've got four sets of islands and bridges to create an architecture with. Concepts like federation suddenly become very meaningful in this circumstance!

What do you think? Please join the conversation. If we put our heads together, we'll figure this out.

Oracle also discussed its plans for the various Sun products it acquired today. Based on today's announcements, our predictions of December 2009 are largely accurate, but there are three exceptions:

  • We expected Sun's Identity Manager to become Oracle's strategic product in that category. It is better than Oracle's equivalent product. However, Oracle is sticking with its Identity Manager as its strategic product in that category.
  • Oracle did not make a blanket commitment to support Sun's middleware products for a long period of time. The support commitments will be published on February 1, 2010 on
  • Oracle will take a run at establishing JavaFX as an alternative to Adobe Flash and Microsoft Silverlight. We predicted Oracle would kill JavaFX.

"Recommended For You"

Analysts: Sun Sparc's future unclear under Oracle Oracle acquires Sun: What it means