IBM to Cisco: Get back down in the weeds

At first glance, IBM's announced intention today to buy XML optimization appliance maker DataPower smacks of trying to accelerate the adoption of SOA and head off any pesky performance hiccups along the way. But a deeper look portends an even bigger fish to fry with the deal -- for IBM to move quickly to head off Cisco on the road to managing the intelligent IP business networks of the future.

DataPower uses server appliances to manage the burgeoning XML streams inside and increasingly between enterprises and service providers. DataPower, a venture back company funded in 1999 in Cambridge, Mass., sets up, in effect, ancillary IP networks that target XML traffic with enhancements for security, acceleration, any-to-any transformations, and rules-based intelligent routing.

IBM will now parachute these capabilities within its WebSphere family of SOA infrastructure and applications deployment and integration solutions. It's kind of an odd fit, yet makes beautiful sense. It's odd because these are appliances -- locked-down hardware boxes -- that will now be part of a family of software products. It's beautiful because it augments so well IBM's offensive formation of WebSphere, Tivoli, DB2, and Rational. You might say IBM just picked up an offensive coordinator, one that can call the plays in real time.

IBM's Robert LeBlanc, general manager of WebSphere in the IBM Software Group, says we should expect to see significant integration between Tivoli's access and ID management capabilities and the DataPower solution set. That means a Tivoli front end to customizable processes for service level agreements and  tiered approaches to performance triage, not to mention policy-driven applications behavior.

We should also expect that WebSphere Web services messaging and deployment systems will leverage DataPower appliances to provide a mission critical blitz to those applications, data flows, and integration paths that require prioritization. I'd like to see more on how the WebSphere Information Integrator (nee DB2) capabilities can add optimized routing inferences from the data headers, not just the logic in the applications and/or management logic.

The buy is tactical and strategic. Tactical because IBM, in a race with HP and BEA, needs to make sure the road to SOA is paved smoothly for those enterprises and service delivery businesses that are just now moving from pilot to infrastructure-level deployments. The worst thing that could happen as companies test SOA generally is for the subsequent XML traffic to bog down the works and provoke a pull-back on the rate of SOA adoption. Even worse would be security snafus.

The DataPower deal is also strategic, because the vendor and solution provider that can get their appliance boxes physically placed throughout the distributed data centers of the biggest IT deployers will have a magnificent advantage. These boxes will prove their mettle and ROI on babysitting the rash of XML, sure, but they can also quickly move up the value chain for such chores as VOIP and policy-based business network behavior and granular access/provisioning control.

Cisco with its AON initiative is also seeking to put its boxes physically around corporate networks to build out a business-grade IP control function that separates intelligent and secure messaging flows from all the other less hygienic IP traffic across the "public" networks. With AON, is Cisco muscling in on IBM, or now with DataPower, is IBM muscling in on Cisco? Neither, really. It's a new race from different positions of strength to the next level of packet network-enabled applications and services performance management.

From DataPower's management and corporate board bios, we can see, however, that networking is the wellspring from which its SOA acceleration appliances arose. Now the race is on see whose box is going to tame the wilds of XML swamped datacenters -- IBM's boxes optimized to the application infrastructure, or Cisco's boxes optimized more generally to the packet flow and switching.

In the most demanding uses, you may want both, but if I were the datacenter architect I'd get my applications and data act together first, then go on to optimize the network (if it's still necessary).