IBMintroduced the Type 285 electric bookkeeping and accounting machinein 1933.
Ryan Betts, from the WebSphereDataPower team, turned me on to a paper, written by JimBarton- CTO and co-founder of Tivo,called Tivo-lution.The paper was inspiring as it confirmedthe motivations and aspirations that I've had ever since I led IBM'sacquisition of DataPower in 2005. In the paper, Bartondescribes the challenges in making complex systems usable and how "purpose built" computer systems areone answer to the challenge.
|Oneof the greatest challenges of designing a computer system is in makingsure the system itself is “invisible” to the user. The system shouldsimply be a conduit to the desired result. There are many examples ofsuch purpose-built systems,ranging from modern automobiles to mobile phones. |
We in IBM are all over this! Heck. The name of ourcompany implies we get it. International "BUSINESSMACHINES". As this photo illustrates, IBM has a longhistory in building purposed machines, like this 1933 Type 285 - Electric bookkeeping and accounting machine. I canimagine this puppy being delivered to an accountant, plugging it in,andaway they go. They didn't have to worry about hard drivecapacity, operating system levels, compatibility between middlewarevendors, or application functionality. It just did thejob. I can also imagine it followed the 80/20rule. It probably didn't do 100% of what all accountants needed. But itprobably did 80% of what all accountants needed, very well. Andyou just dealt with the remaining 20%, or learned to live without it.
"Business Machines, Again". This is my inspiration. Tivo gets it. IBM getsit... And our customers are starting to really buy into it in a bigway. It's all about time-to-value and total cost ofownership/operation. And appliance like our WebSphereDataPower XI50,deliver on these attributes.
At the extreme, purpose built systems, like a Tivo DVR and a XI-50, arebuilt from the ground up for their purpose. While theymight use off the shelf parts, like an embedded Linux OS, it isimportant that all part are "right sized" for thejob. Right-sizing source code, in a hardware applianceis more like firmware (withstrong affinity to the underlying hardware) thanit is software. As such, the Tivo-lution paper describesthe need to ownevery line of source code to ensure the highest level of integration andquality:
|byhaving control of each and every line of source code.... |
Tivo would have full control ofproduct quality and development schedules. When the big bug huntoccurred, as it always does, we needed the abilityto follow every lead, understand every path, and track every problemdown to its source.
The Tivo team even modified the GNU C++ compiler to elimiate the use ofexceptions (which generate a lot of code that is seldom used) infavor of rigid checking of return code usage in thefirmware. DataPowersimilarly contains a custom XMLcompiler that generates both standard executable code, for its generalpurpose CPUs, as well as custom code for the (XG4)XML coprocessor card.
A physical appliance has the unparalleled benefit of being hardenedforsecurity. Jim talks about this in his Tivo paper.
|Security must be fundamental to thedesign... |
We wanted to make it as difficult as possible, within the economics ofthe DVR platform, to corrupt the security of any particular DVR.
RichSalz,who has led the Security work for DataPower and now is our chiefprogrammer for DP, has taught me the meaning of "tamper proof"appliances (or more precisely "tamper evident". Like the 1982 Tylenol scare, we can't stop you from opening the box, but we can protect you, if someone does). In fact, the physical security characteristicsmake the DPXS-40, one of the only technologies some of our moststringent customers will ever consider putting in their networkDemilitarized Zone (DMZ). If a DP box is compromisedand opened, it basically stops working. An encrypted flashdrive makes any configuration data, including security keys, verydifficult to exploit. "DP is like the roach motel, privatekeys go in, but never come out", is the way Rich describes one of thetamper proof qualities of the XS-40.
But the truth is, DP is not a DVR. DP is a middlewareappliance. Middlewareis a tricky thing to make an appliance outof. Middleware is enablingtechnology and by its nature is not specific to any application orvendor. The Tivo appliance is a very specific application(TV/guide) which makes it somewhat easier to constrain.
|Remember, it’s television. Everybody knowshow television works. |
Television never stops, even when you turn off the TV set. Televisionsnever crash.
Hence, thechallenge (and the art) in building a middleware appliance involvesproviding the right amount of constraint, without rendering theappliance useless. For example, DP does not run Javacode (which is the primary means of customizing much of the WebSphereportfolio), instead it uses XML as the primary mode of behaviorcustomization. So, at some level, DP is not programmed, butinstead it is configured. Now, for those who have used XML(and its cousin XSLT), you know that it's more than configuration;however, it is a constraint over Java programming, which has unboundedlevels of customize-ability. Adolfo Rodriguez, who leads theintegration of DP into the WebSphere family, has been bridging this gap(of special to general purpose) very effectively. He and thisteam recently added features to DP to allow it to seamlessly connect toIBM mainframe software (e.g., IMS and DB2) as well as addingcapabilities to manage a collection of appliances as if they were one.
We are blessed in IBM to have a very healthy general purpose softwarebusiness. Our WebSphere/Java-based middleware is the posterchild for general purpose middleware (i.e., write once, run almosteverywhere). However, there is a place for businessmachines - purposed built devices that focus on providing the 80 partof the 80/20 rule. We are heading down this path in abig BLUE way.
But there is more...
What about Virtual Appliances, you ask?
I recently was asked this question at a conference. My kneejerk response was that the term "virtual appliances" was anoxymoron. You can't have something be virtual and be anappliance at the same time.(e.g., a virtualtoaster, producing virtual toast ?) However,I've been working with my team on some ideas in this space and havebegun to chill out a bit on the oxymoron thought.
You see, solving for the 80% case (of 80/20) is a goodthing. Making more of the system "invisible" tothe end-user by constraining the problem space is a great techniquethat can be applied at multiple levels. My friend, Frank Kenny,from Gartner, shows a picture of a spectrum that I think makessense. At oneend of the spectrum (the non-appliance end) you have CDs (install anddo what you will), at theother end of the spectrum (the appliance end) you have purpose built- physical appliances. As you progress from CD to hardened psychical appliance, you canconstrain and add more purpose along the way- inincrements. Perhaps you can say a virtual appliance is somepoint on this spectrum half way between CD and Toaster. Again, I am starting to see the merit here; especially inenabling users to quickly get going with a complex software platform(development and test). By making choices andpre-configuring and hardening the environment for specific task, andexecuting specific application topologies and patterns, we can helpjump-start the process of application development and test in asignificant way. We are heading down this path in abig way as well... more blogging on this topic later.
Business Machines, both physical and virtual, have their place. As we continue to make strong strides towards introducing technologiesthat make interacting with your middleware systems as fluid asinteracting with your television set. Yeah, we have a lot of workto do, but we have a vision and we are making strong strides towardsmaking it a reality.