Thursday, December 15, 2005
Sun May Open SeeBeyond, Provide Google with Servers
I've been privy to two seemingly credible rumors this week, both circumstantially involving Sun Microsystems.
Open SeeBeyond
The first is that Sun may be planning to open-source the code for the recently acquired SeeBeyond middleware/integration product.
On the one hand, this follows the same open source / paid support model that Sun appears to be migrating to, having opened the source to its Solaris operating system via the OpenSolaris project. This would be an unbelievable boon for developers attempting to adapt non-Java components to their J2EE systems - SeeBeyond has an impressive suite of adapters for a wide variety of non-Java and legacy systems (COM, DCOM, mainframe, .NET, CORBA, etc).
At the same time, its adapters are unique in the industry, and one of SeeBeyond's key competitive advantages over systems like WebMethods - it is this fact that gives me some pause in completely putting stock in this rumor.
Google Turns to Sun for Servers
The second rumor is a tad less believable than the first, but potentially amazing if it plays out to be true - Google has apparently approached Sun about migrating their legendary server farm over to Sun hardware.
This poses a ton of questions - would Google conduct a mass migration, or migrate through attrition as servers die off and need to be replaced? Would Google rely on Sun's latest Niagara chipset, or stick to the x86 architecture and use Opterons or some other AMD offering? Obviously, Google wouldn't move their highly customized OS (based on the Linux kernel, w/a custom file system, node communication, etc) to Solaris, making the AMD chipset the more likely candidate. Still, this would be a huge win for Sun, giving much credibility to the abrasive marketing campaigns they've launched against competitors such as Dell (looks like Dell is Sun's new MS, doesn't it?).
As much as I disdain churning in the Rumor Mill, these two pieces of insider information seemed to good to pass on. Only time will tell if either manifests.
Open SeeBeyond
The first is that Sun may be planning to open-source the code for the recently acquired SeeBeyond middleware/integration product.
On the one hand, this follows the same open source / paid support model that Sun appears to be migrating to, having opened the source to its Solaris operating system via the OpenSolaris project. This would be an unbelievable boon for developers attempting to adapt non-Java components to their J2EE systems - SeeBeyond has an impressive suite of adapters for a wide variety of non-Java and legacy systems (COM, DCOM, mainframe, .NET, CORBA, etc).
At the same time, its adapters are unique in the industry, and one of SeeBeyond's key competitive advantages over systems like WebMethods - it is this fact that gives me some pause in completely putting stock in this rumor.
Google Turns to Sun for Servers
The second rumor is a tad less believable than the first, but potentially amazing if it plays out to be true - Google has apparently approached Sun about migrating their legendary server farm over to Sun hardware.
This poses a ton of questions - would Google conduct a mass migration, or migrate through attrition as servers die off and need to be replaced? Would Google rely on Sun's latest Niagara chipset, or stick to the x86 architecture and use Opterons or some other AMD offering? Obviously, Google wouldn't move their highly customized OS (based on the Linux kernel, w/a custom file system, node communication, etc) to Solaris, making the AMD chipset the more likely candidate. Still, this would be a huge win for Sun, giving much credibility to the abrasive marketing campaigns they've launched against competitors such as Dell (looks like Dell is Sun's new MS, doesn't it?).
As much as I disdain churning in the Rumor Mill, these two pieces of insider information seemed to good to pass on. Only time will tell if either manifests.
Friday, December 09, 2005
IUPUI HCI Project Evaluation
I was recently invited again by Dr. Tony Faiola through Mike Kelly to participate in the final project evaluation for Tony's HCI (Human-Computer Interface) Prototyping grad course at IUPUI. Several other industry professionals participated as well; Mike Kelly, freelance tester, professional speaker/writer; the CEO of a Business Process Optimization firm out of Chicago, as well as another professor of HCI from Purdue University.
The course itself grouped students into three mini-corporations, each charged with creating a non-functioning prototype of a personal communications device; the device should have features such as phone, wireless web access, photo, video, etc.
Two of the three student groups focused on creating cell-phone style devices targeted at corporate users. One group in particular had a unique method of adjusting the phone so that it is more appropriate to use during a video conference. The other corporate-targeted group discovered a way to make video camera work with a portable more intuitive. The third group targeted their device towards the more casual user, though their main point of interface distinction was a bit odd.
I won't discuss details of their projects in this medium, out of respect for each group; I'm not certain if any of them will try to bring their ideas to market, and wouldn't want to hurt their chances. I will say that it is fascinating to view the final output of these groups; there were certainly some design mistakes at work, but some real interface gems as well. In any event, it was a pleasure to participate in this exercise for another semester, and I look forward to the opportunity to work with Dr. Faiola in the future.
The course itself grouped students into three mini-corporations, each charged with creating a non-functioning prototype of a personal communications device; the device should have features such as phone, wireless web access, photo, video, etc.
Two of the three student groups focused on creating cell-phone style devices targeted at corporate users. One group in particular had a unique method of adjusting the phone so that it is more appropriate to use during a video conference. The other corporate-targeted group discovered a way to make video camera work with a portable more intuitive. The third group targeted their device towards the more casual user, though their main point of interface distinction was a bit odd.
I won't discuss details of their projects in this medium, out of respect for each group; I'm not certain if any of them will try to bring their ideas to market, and wouldn't want to hurt their chances. I will say that it is fascinating to view the final output of these groups; there were certainly some design mistakes at work, but some real interface gems as well. In any event, it was a pleasure to participate in this exercise for another semester, and I look forward to the opportunity to work with Dr. Faiola in the future.
