The Buck Stops Somewhere

Busting down silos is nothing new to anybody who’s suffered through 1990s-style reengineerings. The goal of these efforts was eliminating the waste and duplication that occur when organizations are composed of dedicated units. For instance, if you want to cross-sell new products to existing customers, it’s hard to do that when each product has its own sales organization.

The same can be said with software. Large enterprises are likely to have multiple ERPs, CRMs, and back end databases. There’s also functional duplication or multiple APIs even within single applications. And if you’re a large middleware vendor, you’ll probably have multiple mechanisms for integrating applications, processes, or data.

With emergence of SOAs, it’s become thinkable to tie bits and pieces from the same system, or disparate systems, together into so-called composite applications. You can use third party tools, like business process management systems to tie things together, or you can buy prepackaged composite apps, like SAP’s xApps.

And if you take SOA seriously, you start thinking about breaking down those packaged software monoliths into federated services that could loosely couple with whatever else is out there. In other words, SOA gives best of breed a new lease on life.

Oracle’s Fusion architecture is being designed to decouple enterprise apps into services. SAP’s Enterprise Services Architecture (ESA) forms the blueprint on how its apps will be exposed. However, exposing apps as services that can readily integrate with third party offerings does not mean that SAP, Oracle, et al are ready to cede account control. Just the opposite – they intend to play the hub in larger playing field. Remember, SAP and Oracle, and all the smaller fry that they gobbled up, dominated because customers voted overwhelmingly against best of breed. At the end of the day, they wanted one throat to choke.

Could the story be any different for middleware? Theoretically, with standards, like Java EE or the various WS-web services protocols, it is more thinkable to plug and play generic pieces of software plumbing compared to dealing with pieces of a business process. And in middleware, you’ve got a lot more open source around.

Last week, BEA unveiled a new strategy that could deconstruct much of its WebLogic, AquaLogic, and Tuxedo lines into componentized services that could be bundled at run time. Unfortunately, the branding is pretty confusing (a mélange of microService Architecture, SOA 360, and Workspace 360), but the message is fairly straightforward. OK, for now it’s mostly vision. Over the next few months, BEA will start filling in some of the blanks.

To some extent, BEA’s WebLogic product already conforms to this vision. It offers a choice of frameworks to perform various chores, such as object/relational persistence. With the new mSA architecture, those options would be exposed as services that you could plug and play. For instance, by deconstructing its offerings, you could cram just the pieces of WebLogic that you need inside the tiny footprints that are typical at the edge of network.

Composite apps might deconstruct software as we know it. Yet, regardless of whether it’s middleware or applications, customers still expect one player to be more equal than others – because somebody’s gotta vouch for the integration.

Ajax on the Server?

We spoke earlier today of some of Ajax’s growing pains. As you might recall with Java, it was originally pitched as a language that could be written once and run anywhere. Then it morphed into a deployment platform for the middle tier. Ironically, while Microsoft’s Bill Gates for a number of years derided Java as just a language, a similar evolution occured with Microsoft’s own Visual Basic language once the .NET framework emerged.

The fact is, there’s a natural tendency in this industry for scope creep. That of course is likely to be one of the hurdles that Ajax will face as the community takes itself more seriously.

So we look with interest at Coach Wei’s comment that one of the ideas spelled out in the OpenAjax Alliance’s mission statement white paper might distract the group off its core mission.

Specifically, he writes that the idea of server-side Ajax could distract the community from its core mission: developing Ajax as a more robust, interoperable rich web client.

Looking at the history of the JCP, whose agenda epitmized scope creep, our early sense is that Coach may have a point.

Herding Cats

Has Ajax become a victim of its own success?

Using readily available technologies, the Ajax folks have proven that their relatively simple methods not only work, but can open up significant new business opportunities for the web.

The good news? Hundreds of low-cost or free tools are available to design Ajax pages. The bad news? Hundreds of low cost or free tools. The problem? Most carry their own frameworks, tags or approaches to coding Ajax.

While the individual pieces of Ajax are standards, the way they are used isn’t. Until recently, that wasn’t an issue. Who cared if the JavaScript for your web page was different from mine when the pages we were developing were each self-contained?

The problem is when you do mashups that mix and match bits and pieces of Ajax from a bunch of web pages. Admittedly, the problem has been somewhat contained until now because popular targets, like Google Maps, enforce their own Ajax style. If you want to mashup a Google Map, you’d better be able to read Google’s tags.

But given the fact that there are relatively few technical barriers to doing mashups with other Ajax web pages floating around, you’ve got some potential interoperability problems on your hands.

Last spring, roughly a dozen vendors formed the OpenAjax Alliance to cut through the interoperability riddle. Today that group has grown to over 50 members and is christening a website, publishing a mission statement. In a couple weeks, they plan to elect a board of directors. Can the attorneys be far behind?

Their first task is developing a hub to mediate the chaos of a couple hundred tools and frameworks. At run time, the framework would provide a place to register Ajax libraries, invoke them, and check for potential conflicts with other libraries that might be trying to call the same web page objects. But what’s missing here is a methodology for resolving conflicts that inevitably are going to arise – that’s going to have to be addressed.

OpenAjax came together in a spate of idealism recalling Linux of 5 – 6 years ago. The resemblances are more than coincidental. Nobody owns either technology, it’s accessible, you can get them practically for free, and there’s still lots of room to do your own thing. Back at LinuxWorld 2000, we recalled Linus Torvalds praising “the good fragmentation” that came about when open source made the entire Linux community one virtual research lab, spawning rapid innovation. That’s what the OpenAjax folks hope to emulate.

Given the independent, grass roots natures of both technologies, developing standards looks akin to herding cats. But as dispersed and chaotic as Linux development appeared, at the end of the day there was an arbiter who decided what went into the kernel.

At some point, something’s gotta give with Ajax standards. Just as happened with Linux, de facto or formal standardization will displace the fragmentation. OpenAjax can serve as a clearinghouse for vetting API candidates. But at some point, somebody’s got to play the heavy.