Rational’s message, which is that software is the invisible glue of smarter products, was much more business grounded than its call a year ago for collaborative software development, which we criticized back then as more like a call for repairing your software process as opposed to improving your core business.

The ongoing name changes in the conference reflect Rational’s repositioning, which the Telelogic acquisition closes the circled. Two years ago, the event was called the Rational Software Development Conference; last year they eliminated the word “Development,” and this year replaced “Software” with “Innovate.” Vanishing of Software from the conference title is consistent with the invisible glue motif.

Software is the means, not the end. Your business needs to automate its processes or make better products in a better way. Software gets you there. As IBM’s message is Smarter Planet, Rational has emphasized Smarter Products rather than “Smarter Business Processes. It’s not just a matter of force fitting to a corporate slogan; Rational estimates compound annual growth of its systems of systems (ergo, mostly the Telelogic side of the business) to be well into the double digits over the next 4 – 5 years, compared to a fraction of that for its more traditional enterprise software modernization and IT optimization businesses.

Telelogic played the starring role for Smart Products. The core of the strategy is a newly announced Integrated Product Management umbrella of products and services for helping companies gain better control over their product lifecycles. Great lead, but for now scant detail. IBM’s strategy leverages Telelogic’s stakehold with companies making complex engineered products with other assets such as IBM’s vertical industry frameworks. We also see strong potential synergy with Maximo, which completes the product lifecycle with the piece that follows the product’s service life.

IBM’s product management strategy places it on a collision course with the PLM community. IBM lays claim to managing the logical constraints of product development – coming from its base in requirements and portfolio management. By contrast, IBM claims that PLM vendors know only the physical constraints. The PLM folks – especially PTC – are developing their own counter strategies. For starters, there is PTC’s plan to offer Eclipse tooling that will start with its own branded support of CollabNet’s open source Subversion source code repository. Folks, this is the beginning of a grudge match that for now is only reinforcing the culture/turf divides demarcating software from the more traditional physical engineering disciplines.

Rational also introduced a workbench idea which is a promising way to use SOA to mix and mash capabilities from across its wide portfolio to address specific vertical industry problems or horizontal software development requirements. The idea is promising, but for now mostly vision. These workbenches take products – mostly Jazz offerings – and mash them up using the SOA architecture of Jazz framework to create configurable integrations for addressing specific business and software delivery problems. We saw a demo of an early example that provided purpose built integrations that provided role-based views for correlating requirements to functional and performance tests, through to specific builds that would be accessed through tools that BAs, testers, and developers use. On the horizon, IBM Rational is planning vertical workbenches that apply Rational tools with some of its vertical industry frameworks addressing segments such as Android mobile device development, cybersecurity, and smarter cities.

The idea for the workbenches is that they would not be rigid products but instead configurable mixes and matches of Rational and partner content, through interfaces developed through OSLC, IBM’s not-really-open-source community for building Jazz interfaces. A good use for IBM’s varied software and industry framework portfolio, it will be challenging to sell as these are not standard catalog products, and ideally, not customized systems integrations. Sales needs to think out of the box to sell these workbenches while customers need assurance that they are not paying for one-off systems integration engagements.

The good news is that with IBM’s expanding cloud offerings for Rational, that these workbenches could be readily composed and delivered through the cloud on much shorter lead time compared to delivering conventional packaged software. Aiding the workbenches is a new flexible token licensing system that expands on a model originated by Telelogic. Tokens are generic licenses that give you access to any piece of software within a designated group, allowing the customer to mix and match software, or for IBM to do so through its Rational Workbenches. IBM is combining it with the idea of term licensing to make this suited for cloud customers who are allergic to perpetual licensing. For now, tokens are available only for Telelogic and Jazz offerings, but IBM Software Group is investigating applying it to the other brands.

So how do you cost justify these investments for the software side of smarter products? Rational GM Danny Sabbah’s keynote on software econometrics addressed the costing issue based on Rational’s invisible glue, means not end premise. We agree with Sabbah that traditional metrics for software development, such as defect rates, are simply internal metrics that fail to express business value. Instead, Sabbah urges measuring business outcomes of software development.

Sabbah’s arguments are hardly new. They rehash old debates over the merits of “hard” vs. “soft,” or tangible vs intangible costing. Traditionally, new capital investments, such as buying new software (or paying to develop it) were driven by ROI calculations that computed how much money you’d save; in mist cases, those savings came form direct labor. Those were considered “hard” numbers because it was fairly straightforward to calculate how much labor some piece of automation would save. Savings are OK for the bottom line but do nothing for the top line. However, if you automated a process that would allow you to shorten product lead time by 3 weeks, how much money would you make with the extra selling time, and by getting to market earlier, how much benefit would accrue by becoming first to market? Common sense is that all other factors being equal, getting a jump in sales should translate to more revenue, and in turn, bolster your competitive position. But such numbers were considered “soft” because there were few ways to scientifically quantify the benefits.

Sabbah’s plea for software econometrics simply revives this debate.

But neither Software AG’s or Tibco’s moves approach the scope of Sterling Commerce’s footprint in B2B trading partner management, a business that grew out of its heritage as one of the major EDI (electronic data interchange) hubs. The good news is the degree of penetration that Sterling has; the other (we won’t call it “bad”) news is all the EDI legacy, which provides great fodder for IBM’s Global Business Services arm to address a broader application modernization opportunity.

Sterling’s base has been heavily in downstream EDI and related trading partner management support for retailers, manufacturers, and transportation/freight carriers. Its software products cover B2B/EDI integration, partner onboarding into partner communities (an outgrowth of the old hub and spoke patterns between EDI trading partners), invoicing, payments, order fulfillment, and multi-channel sales. In effect, this gets IBM deeper into the supply chain management applications market as it already has Dynamic Inventory Optimization (DIOS) from the Maximo suite (which falls under the Tivoli umbrella), not to mention the supply chain optimization algorithms that it inherited as part of the Ilog acquisition which are OEM’ed to partners (rivals?) like SAP and JDA.

Asked if acquisition of Sterling would place IBM in competition with its erstwhile ERP partners, IBM reiterated its official line that it picks up where ERP leaves off – but that line is getting blurrier.

But IBM’s challenge is prioritizing the synergies and integrations. As there is still a while before this deal closes – approvals from AT&T shareholders are necessary first – IBM wasn’t about to give a roadmap. But they did point to one no-brainer: infusing IBM WebSphere vertical industry templates for retail with Sterling content. But there are many potential synergies looming.

At top of mind are BPM and business rules management that could make trading partner relationships more dynamic. There are obvious opportunities for WebSphere Business Modeler’s Dynamic Process Edition, WebSphere Lombardi Edition’s modeling, and/or Ilog’s business rules. For instance, a game changing event such as Apple’s iPad entering or creating a new market for tablet could provide the impetus for changes to products catalogs, pricing, promotions, and so on; a BPM or business rules model could facilitate such changes as an orchestration layer that acts in conjunction with some of the Sterling multi-channel and order fulfillment suites. Other examples include master data management, which can be critical when managing sale of families of like products through the channel; and of course Cognos/BI, which can be used for evaluating the profitability or growth potential of B2B relationships.

Altimeter Group’s Ray Wang voiced a question that was on many of our minds: why AT&T would give up Sterling. IBM responded about the potential partnership opportunities but to our mind, AT&T has its hands full attaining network parity with Verizon Wireless and is just not a business solutions company.

But coming atop the recent announcements of VMforce, along with key acquisitions of Gemstone, and to a lesser extent, RabbitMQ, we’d have to agree with VMware’s CTO Steve Herrod that VMware’s acquisition of SpringSource has not slowed the company down. Congrats to SpringSource’s Rod Johnson for keeping the momentum going under VMware’s watch, and hats off to VMware for making it all happen.

Short but sweet (we’re behind with report deadlines for our day job), SpringSource’s cloud strategy is to become as ubiquitous as possible. Grab every potential Java PaaS platform in sight, do end-arounds with IBM and Oracle who have barely placed their feet inside the door for Java development platforms as a service. Their move reminds us of Duane Reade, the well-known Manhattan pharmacy chain whose long-time strategy was to saturate every street corner location to crowd out rivals like CVS and Walgreens out of the market; as a desperation maneuver, Walgreen finally bit the bullet and snapped up Duane Reade, but in deference to its New York brand recognition, kept the name.

But given that Google app Engine is not exactly a mainstream enterprise platform (Google still struggles to understand the enterprise), for SpringSource the announcement carries more light than heat. The move nonetheless brings a halo effect to Google’s Apps Engine, which becomes more extensible with the Spring framework and with cool extras like Spring Roo, which eliminates a lot of coding legwork and is a good match for Google’s Web Toolkit, which provides a warmer, fuzzier, but more importantly simpler way to piece together web apps. More importantly, it means you can now write and run something meaningful on Google App Engine without having to rely on Python. It provides clever potential upside for Google’s newly announced Apps Engine for Business.

SpringSource’s strategy is an end-around, not only to IBM and Oracle, but also to VMware itself. The latest announcement vindicates in part VMware’s strategy for SpringSource, which we believe has been about building the de facto standard Java cloud platform. While we give hats off toe VMware for accelerating SpringSource’s expansion of its middleware stack and cloud strategy, VMware has been slower to leverage SpringSource internally, whether it be with:
1. Promotion of vCloud. That’s remains more a future bet for leapfrogging VMware past the increasingly commoditized hypervisor business, leveraging its market-leading virtualization management technologies to establish them as de facto standards for managing virtualization in the cloud.
2. Cross-fertilizing SpringSource’s dependency injection capabilities into virtualization, with the idea of simplifying virtualization in the same way that the original Spring framework simplified Java deployment.

Tibco is hardly alone in voicing such messaging. IBM’s Smarter Planet and Progress Software’s Operational Responsiveness are also about the need for systems that think on their feet. Yet Tibco’s DNA gives it a unique claim to this space as the company was born around fast reliable, messaging. Two years ago, Tibco CEO Vivek Ranadive made the case for event-driven predictive intelligence. Now Tibco is talking about the need, in global marketing head Ram Menon’s words, “to humanize the story better.” That’s always been a stretch for this technology-driven company whose vision has long been driven by a shy, technology centric CEO. Towards that goal, Tibco is taking a step or two forward, but unfortunately also a step back.

The good news is that Tibco is fleshing out it’s “Power of Now” tagline. We saw the first of a new series of simple, straightforward visual ads with short statements of business outcomes, like how Tibco’s event processing helps defense agencies clear the fog of war, underscored by the tagline.

Then Tibco unveiled a new tag line, the Two-Second Advantage, which makes the case if that you have just enough information quickly enough, you don’t need the complete picture to make the right decision. Tibco’s on a roll there, a message backed up by the surprisingly irreverent Ronald K. Noble, the brash New Yorker who heads Interpol, who made the case that such an advantage can have life or death implications in crime fighting, especially when it comes to border control.

The problem is that just when you’ve thought that Tibco finally has gotten on message, it reverts back to its geeky self and steps on top of it. The latest case is its CEO’s Enterprise 3.0 concept that, when debuted in front of a room of analysts, floated like a lead balloon.

His numbering is over simplistic and cuts against popular perception: Ranadive terms Enterprise 2.0 as client/server, rather than the social computing weave that is now seeping into enterprise systems – including Tibco’s. But bloggers of record Sandy Kemsley and Brenda Michelson summed it up best. Kemsley: “Enterprise 3.0 is becoming a joke amongst the analysts attending here today (we’re tweeting about staging an intervention)…” Michelson:” We like the 2 second advantage message, but “Enterprise 3.0” doesn’t resonate, it won’t be meaningful to Business Execs and CIOs.”

Tibco doesn’t need new messaging, it just has to bring out the best of what it already has. It can humanize “The Power of Now” by appending the question, “What does it really mean?” And from that, “The two-second advantage,” and all the business cases that manifest it, become the logical response.

‘Nuff said.

With acquisitions and organic product development, Tibco’s portfolio is broader than ever, and not surprisingly, this year’s event carried announcements of a large number of product upgrades and introductions. For us the highlight was ActiveMatrix BPM, which finally puts Tibco’s business process management engine on the same Eclipse development platform and runtime as the rest of Tibco’s service orchestration products. As a completely new product (this is not iProcess, which becomes Tibco’s legacy BPM offering rooted from the original Staffware acquisition). This is a major development for a vendor that has accumulated a large portfolio of individual products over the years, with the harshest critique being the need for multiple runtime engines: ActiveMatrix, iProcess, BusinessWorks, Rendezvous, EMS, etc. The new BPM offering fills a critical gap in the SOA-oriented ActiveMatrix product family.

Our critique here – as with IBM – is that the use of Eclipse as the design time platform appeals more to developers than business stakeholders. But the fact that ActiveMatrix BPM is intended to be an execution platform means that so-called nirvana of having business people design their own business processes is the type of stuff that you do when in a room with a whiteboard. Fortuitously, Tibco does have something in the works, as it previewed Design Collaborator, a new process definition tool that suspiciously resembled IBM BPM Blueprint; we hope that Tibco designs it so that it could feed BPMN models into ActiveMatrix BPM so it doesn’t become a dead-end product.

There were other introductions, such as the none-too original, retro-named PeopleForms (which sounds like the name for one of Oracle’s legacy PeopleSoft offerings) that for now only churns out SharePoint-like forms-driven apps as a beta. PeopleForms addresses a low end of the market not served by Tibco, developed by what’s left of the old General Interface team; eventually this will be beefed up into something more useful with workflow. We also hope that there might be some rationalization with Design Collaborator, so that this product doesn’t wind up becoming a standalone curiosity.

But the most profound impression came from an acquisition that Tibco completed only in March. Our award for best-of-the-day award from the analyst sessions was demonstration of Netrics, a tiny 15-person outfit out of Princeton, NJ that has developed a patented, algorithmic pattern matching program that really fleshes out the “two-second advantage message’ in providing proximate matches that should be “good enough: to make decisions. Netrics’ technology assigns algorithms as metadata that scores the identity of names or people or things; using that metadata, it quickly reduces large data sets to find probable matches. Those probable matches can be filtered to include or exclude misspellings and typos. Netrics’ technology has ready applicability to identifying event patterns and golden copies of data – and as such, Tibco’s initial plans are to incorporate the technology into Tibco Business Events (their CEP offering) and Master Data Management. On the horizon, it provides a pattern matching approach that complements text mining that is often used in national security applications.

Netrics is not a replacement for data quality – that remains a major gap ion Tibco’s product suite. While the two-second advantage implies having data that is “good enough,” when you perform event processing and must make snap decisions. But over the long haul, you’ll need the kind of feedback loop and reality check on those decisions that business intelligence provides – and for that, you’ll need data that is better scrubbed.

SpringSource’s Rod Johnson told us that he was planning to acquire such a technology even before VMware came into the picture, but make no mistake about it, VMware’s presence upped the ante.

SpringSource has been looking to fill out its stack vs. Oracle and IBM ever since its cornerstone acquisition of Covalent (which brought the expertise behind Apache Tomcat and bequeathed the world tc Server) two years ago. Adding Gemstone’s Gemfire becomes SpringSource’s response to Oracle Coherence and IBM WebSphere XD. The technologies in question allow you to replicate data from varied sources into a single logical cache, which is critical if those sources are highly dispersed.

So what about VMware? Wasn’t SpringSource planning to grow its stack anyway? There are deeper stakes at play: VMware’s aspiration to make cloud and virtualization virtually synonymous – or at least to make virtualization essential to the cloud – falls apart if you don’t have a scalable, high performance way to manage and access data. Enterprises using the cloud are not likely to move all their data there, and need a solution that allows hybrid strategies that will invariably involve a mix of cloud- and on premised-based data resources to be managed and accessed efficiently. Distributed data caching is essential.

So the next question is why SpringSource, as a historically open source company that has always made open source acquisitions, buy open source Terracotta instead? Chances are, were SpringSource still independent, it probably would have, but VMware brings deeper pockets and deeper aspirations. Gemstone is the company that sold object-oriented databases back in the 90s, and once it grew obvious that they (and other OODBMS rivals like Object Store) weren’t going to become the next Oracles, they adapted their expertise to caching. Gemfire emerged in 2002 and provided Wall Street and defense agencies an off the shelf alternative to homegrown development or a best of breed strategy. By comparison, although Terracotta boasts several Wall Street clients, its core base is in web caching for high traffic B2C oriented websites.

Bottom line: VMware needs the scale.

There are other interesting pieces that Gemstone brings to the party. It is currently developing SQLFabric, a project that embeds the Apache Derby open source relational database into Gemfire to make its distributed data grid fully SQL-compliant, which would be very strategic to VMware and SpringSource. It also has a shot-in-the-dark project, MagLev, which is more a curiosity for the mother ship. Conceivably it could provide the impetus for SpringSource to extend to the Ruby environment, but would require a lot more development work to productize.

Obviously as the deal won’t close immediately, both entities must be coy about their plans other than the obvious commitment to integrate products.

But there’s another angle that will be worth exploring once the ink dries: SpringSource has been known for simplicity. The Spring framework provided a way to abstract all the complexity out of Java EE, while tc Server, based on Tomcat, carries but a subset of the bells and whistles of full Java EE stacks. But Gemfire is hardly simple, and the market for distributed data grids has been limited to organizations with extreme processing needs who have extreme expertise and extreme budgets. Yet the move to cloud will mean, as noted above, that the need for logical data grids will trickle down to more of the enterprise mainstream, although the scope of the problem won’t be as extreme. It would make sense for the Spring framework to extend its dependency injection to a “lite” version of Gemfire (Gemcloud?) to simplify the hassle of managing data inside and outside of the cloud.

It’s a thought that crystallized as we bounced impressions of this year’s IBM SOA Impact event with colleagues like Dorothy Alexander and Marcia Kaufman, who shared perceptions that, while this year’s headlines or trends seemed a bit anticlimactic, that there was real evidence that customers were actually “doing” whatever it is that we associate with SOA.

Forget about the architectural journeys that you’ve heard about SOA; SOA is an enterprise architectural pattern that is a means to an end. It’s not a new argument; it was central to the SOA is dead debate that flared up with Anne Thomas Manes’ famous or infamous post of almost a year and a half ago, and of the subsequent debates and hand wringing that ensued.

IBM’s so-called SOA conference, Impact, doesn’t include SOA in its name, but until now SOA was the implicit rationale for this WebSphere middleware stack conference to exist. But more and more it’s about the stack that SOA enables, and more and more, about the composite business applications that IBM’s SOA stack enables. IBM won’t call it the applications business. But when you put vertical industry frameworks, business rules, business process management, and analytics together, it’s not simply a plumbing stack. It becomes a collection of software tools and vertical industry templates that become the new de facto applications that bolt atop and aside the core application portfolio that enterprises already have and are not likely to replace. In past years, this conference was used to introduce game changers, such as the acquisition of Webify that placed IBM Software firmly on the road to verticalizing its middleware.

This year the buzz was about something old becoming something new again. IBM’s acquisition of Cast Iron, as dissected well by colleagues Dana Gardner and James Governor, reflects the fact that after all these years of talking flattened architectures, especially using the ESB style, that enterprise integration (or application-to-application, or A2A) hubs never went out of style. There are still plenty of instances of packaged apps out there that need to be interfaced. The problem is no different from a decade ago when the first wave of EAI hubs emerged to productize systems integration of enterprise packages.

While the EAI business model never scaled well in its time because of the need for too much customization, experience, commoditization of templates, and emergence of cheap appliances provided economic solutions to this model. More importantly, the emergence of multi-tenanted SaaS applications, like Salesforce.com, Workday and many others, have imposed a relatively stable target data schema plus a need of integration of cloud and on-premises applications. Informatica has made a strong run with its partnership with Salesforce, but Informatica is part of a broader data integration platform that for some customers is overkill. By contrast, niche players like Cast Iron which only do data translation have begun to thrive with a Blue Chip customer list.

Of course Cast Iron is not IBM’s first appliance play. That distinction goes to DataPower, which originally made its name with specialized appliances that accelerated compute-intensive XML processing and SSL encryption. While we were thinking about potential synergy, such as applying some of DataPower’s XML acceleration technology to A2A workloads, IBM’s middleware head Craig Hayman responded to us that IBM saw Cast Iron’s technology as a separate use case. But they did demonstrated that the software of Cast Iron could, and would, literally run on DataPower’s own iron.

Of course, you could say that Cast Iron overlaps the application connectors from IBM’s Crossworlds acquisition, but those connectors, which were really overlay applications (Crossworlds used to call them “collaborations”), have been repurposed by IBM as BPM technology for WebSphere Process Server. Arguably, there is much technology from IBM’s Ascential acquisition focused purely on data transformation that also overlaps here. But Cast Iron’s value add to IBM is the way those integrations are packaged, and the fact that they have been developed especially for integrations to and from SaaS applications – no more and no less. IBM has gained the right sized tool for the job. IBM has decided to walk a safe tightrope here; it doesn’t want to weigh Cast Iron’s simplicity (a key strength down) with added bells and whistles from the rest of its integration stack. But the integration doesn’t have to go in one direction –weighing down Cast Iron with richer but more complex functionality. IBM could go the opposite direction and infuse some of this A2A transformation as services that could be transformed and accelerated by the traditional DataPower line.

This is a similar issue that IBM has faced with Lombardi, a deal that it closed back in January. They’ve taken the obvious first step in “blue washing” the flagship Lombardi Teamworks BPM product, which is now rebranded IBM WebSphere Lombardi Edition and bundled with WebSphere Application Serve 7 and DB2 Express under the covers. The more pressing question is what to do with Lombardi’s elegantly straightforward Blueprint process definition tool and IBM WebSphere BlueWorks BPM, which is more of a collaboration and best practices definition rather than modeling tool (and still in beta). The good news is that IBM is trying the right thing in not cluttering Blueprint (now rebranded IBM BPM Blueprint), but the bad news is that there is still confusion with IBM’s mixed messages of a consistent branding umbrella but uncertainty regarding product synergy or convergence.

Back to the main point however: while SOA was the original impetus for the Impact event, it is now receding to a more appropriate supporting role.

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.

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.

We’ve always been pretty bullish on what OSGi could do. It allows your server footprint to be truly dynamic – you can deploy and kill runtime components at will without taking the whole mess offline. There’s a potential sustainability appeal to any technology that helps reduce footprint – as less apps mean less server, less power, and less space.

Interestingly, OSGi could provide a lot of the elasticity at the appserver level that virtualization promises for OS images and cloud promises for application deployment. And there’s the rub – OSGi is hardly the only path to keeping your webfarm footprint contained. Significantly, while the goal is the same for each strategy – you only want as much resource as you need – they all take different ways of getting there. OSGi is a developer decision that addresses which application or middleware modules (or functionality) do you actually want running at any time, while virtualization and cloud are largely IT operations decisions pinpointing images and choice of what and how much infrastructure to provision.

Although the goal is common, the choice of strategy differs based on where elasticity is needed; furthermore, these are not all or nothing decisions. Conceivably, if you have a highly variable application that requires, not only different amounts of processing capacity, but different functionality at different times, then OSGi could complement your virtualization and/or cloud strategies. Let’s say you process market feeds, the composition and mix of which changes by time of day and which trading centers are active around the globe. Or your organization is number crunching end of period reports. Those are a couple possibilities.

The problem is in knowledge and awareness. For most IT customers, OSGi is a black box. It’s the way that WebSphere and WebLogic are architected. But that makes a difference to the vendors, not the customers because they don’t know how to provision OSGi bundles and there are no best practices for bundling bundles into bigger pieces that can be identified as tangible modules. There is still a lot of OSGi misinformation and still a lot of debate out there. Of course, while virtualization and cloud are much better known, there’s plenty of hype and debate about cloud, and concerns about unchecked use of virtualization.

So a couple years after OSGi gained critical mass vendor acceptance, there remains a lack of tooling for configuring OSGi servers, not to mention best practices for deploying them. SpringSource, one of the first to develop an OSGi server, has now donated the technology to Eclipse as reference implementation in Gemini, with Virgo becoming the technology development project. SpringSource’s commercial direction is tc Server, which commercializes the tiny Tomcat servlet container; as of March 8, VMware is pushing tc Server through its channels and for the next couple months, is giving away two production CPU licenses and 60 days evaluation support to VMware customers.

SpringSource’s fork in the road symbolizes the existential dilemma facing OSGi: if your goal is to simply reduce your web container footprint, 10-MByte Tomcat containers should do just fine. It scales out quite nicely as well, with LinkedIn serving 40 million web pages daily on Tomcat. So again, we ask, why do we need OSGi?

Give us your answers.

Maybe their professors weren’t that absent minded and their approach not so pedantic after all, as the company has been on a winning streak for the past ten quarters, scoring 25% growth last year as the rest of the economy (and software industry) tanked. Tilting against windmills, the company scored big gains among established clients across financial services industries, who used Pega’s process “solution frameworks” covering areas such as loan origination and underwriting; wholesale banking, and retail bank account opening.

Pegasystems is on the right side of history, having embraced vertical frameworks. That’s an approach that you also find IBM taking. In business for roughly 25 years, Pega’s sales didn’t take off until it began rolling out a series of templates or frameworks that provided a 60% solution, eliminating the need to model commodity processes from scratch.

Either way, Pega’s success belies our observation that vertical templates are the future of enterprise applications — using the framework as a raw template, they will be composed from existing applicaitons and data sources rather than written or implemented as a packaged applicaiton from scratch.

Growth last year added $35 million to the company’s cash cushion, leaving it with a nice healthy $200 million in the bank. But cash in a consolidating industry is trash when your rivals are either acquiring or getting acquired left and right. As so the question was what would Pega do with its cash.

We now have the answer: Pega announced yesterday its intent to acquire Chordiant, whose specialty is dissecting, analyzing, and optimizing a company’s experiences with its customers. The deal, at $167 million in cash, actually nets out to about $116 million when you factor Cordiant’s $51 million cash position. Pega’s solicited offer trumped an abortive unsolicited $105 million offer back in January from CDC, an aspiring Hong Kong-based enterprise applications provider. Chordiant has come down a few notches over time, with business flattening to $75 million last year, down from $115 million a couple years ago. Pega’s $5/share bid about 10% of the company’s 2000 dot com peak, but a 30% premium over its current valuation.

Pega got a good deal, and Wall St. agreed, as shares of both companies rose on the heels of the announcement. It reflects the fact that Chordiant provides Pega two opportunities: (1) Deepen its presence in financial services accounts by going into the front office, and (2) gain a new beachhead in telecom where it currently has bit a single critical mass client. Although telco could broaden Pega’s addressable market the deal wouldn’t work if the solutions weren’t complementary.

Pegasystems offers a highly sophisticated, rules-driven approach to defining, modeling, and executing business processes. It offers roughly 30 industry specific templates, and well over a dozen cross-industry frameworks such as customer process management, control and compliance, procurement and so on.

By contrast Chordiant covers what it calls “customer experience management,” which tracks customer interactions and offers predictive analytics for optimizing cross-selling, upselling, or customer retention strategies, or for predicting risk or churn. It also offers vertical templates for financial services, healthcare, and telecom. Chordiant’s predictive analytics have adaptive capabilities where the rules can change based on trends in customer response; if a promotion offer proves not as attractive as initially forecast, the rules can adjust the algorithm to reflect reality.

The potential synergy is where Chordiant optimizes customer-facing front office processes while Pega’s BPM frameworks optimize the corresponding back office processes such as loan origination. On paper, it looks like yin and yan. But there are basic architectural differences between the products, as decision management consultant and author James Taylor has pointed out. Keep in mind that Taylor has traditionally been skeptical of Pega’s approach to embedding rules inside its process engine, rather than loosely coupling the two. But he makes valid points that Chordiant handles rules differently from Pega, that the potential synergy between the two is great, but that the company need to take care that technical differences do not “derail the technical integration or cause the merged company to merge its operations without merging its products.”

So on paper, Pega has made a sound deal. As the company is not yet experienced in digesting acquisitions of this size, its success in consummating the Chordiant acquisition will become a predictive indicator of the company’s ability to survive and grow in a consolidating market where it will be expected to make more such deals.