Monthly Archives: April 2010

Go to any vendor conference and it gets hard to avoid what has become “The Obligatory Cloud Presentation” or “Slide.” It’s beyond this discussion to discuss hype vs. reality, but potential benefits like the elasticity of the cloud have made the idea too difficult to dismiss, even if most large enterprises remain wary of trusting the brunt of their mission systems to some external hoster, SAS 70 certification or otherwise.

So it’s not surprising that cloud has become a strategic objective for VMware and SpringSource both before after the acquisition that put both together. VMware was busy forming its vCloud strategy to stay a step ahead of rivals that seek to make VMware’s core virtualization hypervisor business commodity, while SpringSource acquired CloudFoundry to take its expanding Java stack to the cloud as such options were coming available for .NET and emerging web languages and frameworks like Ruby on Rails.

Following last summer’s VMware SpringSource acquisition, the obvious path would have placed SpringSource as the application development stack that would elevate vCloud from raw infrastructure as a service to a full development platform. That remains the goal, but it’s hardly the shortest path to VMware’s goals. At this point, VMware still is getting its arms around the assets that are now under its umbrella with SpringSource. As we speculated last summer, we would see some of the features of the Spring framework itself, such as dependency injection (which abstracts dependencies so developers don’t have to worry about writing all the necessary configuration files) might be applied to managing virtualization. But that’s for another time, another day. VMware’s more pressing need is to make vSphere the de facto standard for managing virtualization and vCloud, the de facto standard for cloud virtualization (actually, if you think about it, it is virtualization squared: OS instances virtualized from hardware, and hardware virtualized form infrastructure).

In turn, Salesforce wants to become the de facto cloud alternative to Google, Microsoft, IBM, and when they get serious, Oracle and SAP. The dilemma is that Salesforce up until now has built its own wall garden. That was fine when you were confining this to CRM and third party AppExchange providers who piggybacked on Salesforce’s own multi-tenanted infrastructure using its own proprietary Force.com environment with its “Java-like” Apex stored procedures language. But at the end of the day, Apex is not going to evolve into anything more than Salesforce.com niche development platform, and Force.com is not about to challenge Microsoft .NET, or Java for that matter.

The challenge is that Salesforce, having made the modern incarnation of remote hosted computing palatable to the enterprise mainstream, now finds itself in a larger fishbowl outgunned in sheer scale by Amazon and Google, and outside the enterprise Java mainstream. Benioff conceded as much at the VMforce launch yesterday, characterizing Java as “the No. 1 developer language in the enterprise.”

So VMforce is the marriage of two suitors that each needed their own leapfrogs: VMware into a ready made with existing brand recognition, and Salesforce for getting access to the wider Java enterprise mainstream.

Apps written using the Spring Java stack will gain access to Force.com services such as search, identity and security, workflow, reporting and analytics, web services integration API, and mobile deployment. But it also means dilution of some features that make Force.com platform what it is; the biggest departure is away from the Apex language stored procedures architecture that runs directly inside the Salesforce.com relational database. Salesforce trades scalability of a unitary architecture for scalability through a virtualized one.

It means that Salesforce morphs into a different creature, and now must decide whom it means to compete with because it’s not just Oracle anymore. Our bets are splitting the difference with Amazon, as other SaaS providers like IBM that don’t want to get weighed down by sunk costs have already done. If Salesforce wants to become the enterprise Java platform-as-a-Service (PaaS) leader, it will have to ramp up capacity, and matching Amazon or Google in a capital investment race is a hopeless proposition.

It’s no April Fools joke: NUMMI, the pioneering joint venture of GM and Toyota, is closing its doors today. NUMMI proved yet another bold new beginning that met its doom

Its fate reminded us of another such failed startup. Back in 1987, we wrote a story for Managing Automation magazine about Volkswagen’s closing of its New Stanton, Pennsylvania. plant under the headline, “The End of a New Beginning” (our article is not online, so we pointed to a NY Times filing). It was the tale of a successful foreign automaker opening a beachhead and creating jobs in the Rust Belt, only to find that it could not replicate the success of the original Beetle for a new generation.

Ironically, VW’s American foray fell victim to the inroads of Japanese automakers who cashed in on American demand for better quality cars. It was the very wave that spurred the Toyota’s pioneering joint venture with GM at the latter’s highly troubled Freemont, California plant. The joint venture, New United Motor Manufacturing Inc. (NUMMI), was born of Toyota’s need for a partner to help it learn how to replicate its famed production system with an American workforce, and GM’s need to learn Toyota’s secret sauce.

Sadly, that same tagline fits a sorry occasion for today, which marks the closing of NUMMI, the former GM/Toyota joint venture in Freemont. California. NPR’s This American Life ran an excellent account of NUMMI’s quarter century and its demise. The story is painful for GM, which drank the Kool Aid too little and too late, for Toyota, where success has bred sloppiness, and for the NUMMI workers. Having visited the plant for a series of articles on NUMMI’s adoption of a supervisory system to automate some of their quality assurance practices, we also are feeling the pangs.

We met the people on the plant floor who internalized the practice of Kaizen; when we visited the plant in 1992, NUMMI-made Toyota 2×4 light pickups, Toyota Corollas,, and GM Geo Prizms were ranked 1st, 8th, and 12th in customer satisfaction, respectively, by JD Power. The plant was one of the few US sites to increase production during the recession of the early 90s. NUMMI’s production peaked in 2005.

The plant represented a hope that American grit, determination, and know-how could rise to the challenge of offshore manufacturing. If the Japanese could apply the lessons of Juran and Deming, why could we turn around and do the same?

The reason we were there was because growth overwhelmed the staff’s ability to continue tracking quality and scheduling operations manually. With Toyota’s philosophy that empowered workers knew best how to manage the assembly line, impetus for the project to implement computerized systems for managing operations came from the rank and file, not from top management. The computer-integrated monitoring system (called CIMS) project was lead by the assistant maintenance manager, not by plant senior management. Bidders initially couldn’t believe that authority for approving bids for a 6-figure project would rest with such an operating level group.

It was a weird confluence of history: an up and coming automaker giving a competitor the chance to learn its secrets of success. But NUMMI’s success wasn’t easily replicated inside GM. For starters, it relied on Toyota’s automotive parts supply ecosystem, which was already compliant with Toyota’s Kaizen practices; additionally, the labor contract was changed. Neither of those conditions existed elsewhere inside GM. The company lacked a master plan to apply lessons being handed it on a golden platter. The company didn’t get serious until Jack Smith – one of the people who helped negotiate the NUMMI agreement – became CEO in 1992; and even then, change faced ingrained resistance from workers, unions, plant management, and suppliers. Booming SUV business in the 90s concealed the skeletons still inside GM’s closet.

NUMMI wasn’t GM’s only blown opportunity; it had a chance to reinvent the car plant with a similar worker empowerment scheme at Saturn. After being incubated under Roger Smith in the 80s, Saturn’s death spiral began as GM failed to invest in the product and transferring production to other plants run along traditional adversarial lines, and failing to invest in new models to broaden the line.

GM’s impending bankruptcy caused it to pull out of NUMMI last year; now Toyota, which has seen its sails trimmed by the recession, has followed suit as it retrenches to its non-union manufacturing base concentrated in the Sunbelt. This is occurring as Toyota, ironically, faces quality issues of its own as the company let some of its famed Kaizen practices slide in the face of growth.

America ironically built itself up through determination and grit; back in the 1980s, the thought was that if we could roll up our sleeves, apply American ingenuity and the American spirit, that we could triumph over adversity. Or in this case, embrace world-class quality and we would become magically competitive again. But our luck ran out when trade barriers came down and the world grew flat. Until the recent wave of plant closings, the world had roughly twice the automotive production capacity that it needed, with most of it in the wrong places (e.g., located in mature rather than growing markets).

NUMMI succeeded by the old rules of the game, but in a market where demand was sinking faster than supply, NUMMI’s isolated west coast location away from the hub of the industry (now located mostly along I-85 in the south) sealed its fate. NUMMI gave Toyota its stepping stone into the US market, but it was a beachhead no longer needed.

The irony is that Toyota has surpassed GM in more ways than one. It has not only become the world’s largest carmaker, but as recent headlines of bungled recalls have revealed, has also adopted much of GM’s sloppiness.

Insights on the world of Information Technology — Views expressed here do not reflect the opinions of Ovum.