Towards Healthy Software

Jon Udell has a great post on the need for higher levels of software quality, and the tools that might help us get there.

UPDATE: After re-reading Jon's post, I feel compelled to point out that healthy software isn't just about tools. Anne Thomas Manes, the research director for our Application Platform Strategies service, has been saying something a lot lately that's relevant to this topic: Successful SOA implementations will have as much (if not more) to do with policy and governance as technology. Anne says that many enterprises will end up wasting a lot of time and money in 2005 with SOA projects that fail due to poor governance.

Tools can certainly help with accountability; they’re crucial in fact. But to be accountable, you need clear policies that define the things for which developers must be accountable, and to whom they are accountable. (There also must be consequences for failing to comply, which is the hard part of governance.) Many organizations have bad habits that are deeply ingrained in the way they work. For the sake of expediency, they take an isolated view of software projects and a “whatever it takes to get it done” mentality. We can all understand the need to get things done: Movement is far better than perfection.

But we live in a new world. The old ways won’t necessarily work in this new world. When organizations ignore the need for governance and accountability, it’s not just quality that suffers. Security and long-term cost-effectiveness (wheel reinvention occurs with alarming frequency in most companies) quickly go right out the door as well. So it may actually be good news that the new world in which we find ourselves poses some dire consequences for organizations that don’t start acknowledging these new realities.

In order to realize the vision of distributed systems, software development communities must rebalance the equation that incorporates expediency, efficiency, security, and quality. As we’ve been saying, SOA is a mind set. It’s a way to approach software development and it must become a part of the organizational dynamic, not just a new way for developers to implement the same inefficiencies and problems that Jon (and others) laments.

So Who's Darth Vader and Princess Leia?

Richard Monson-Haefel’s report “The Rebel Frameworks: J2EE Open Source Alternatives and Supplements,” which we recently published in the Application Platform Strategies service, is getting a good bit of attention, such as here and here.

WS-Discovery Workshop

By way of Jeffrey Schlimmer's blog: Canon is hosting an interoperability workshop on WS-Discovery.

WS-I releases Web services interoperability profile

Here's an InfoWorld story on the release of the Basic Profile 1.0 document by the Web Services Interoperability Organization. This is a significant step forward for Web services because it addresses the sometimes ugly truth about standards. Most standards specifications leave a lot open to the interpretation of the implementer, which often creates interoperability problems between different implementations. Profiles add the specificity necessary to ensure interoperability between implementations. The fact that BEA, IBM, Microsoft, Sun, and a host of other companies are committed to implementing the basic Web services specs -- SOAP, WSDL, and UDDI -- according to the profile underscores the reality of the Web services framework. Additional profiles on security are forthcoming and they, along with interoperability testing, create the very real possibility of widespread interoperability based on Web services standards.

Novell and Ximian

On Monday, Novell announced that it is acquiring Ximian, a Linux software developer best known for the GNOME and Mono projects. (GNOME is a graphical user interface, and Mono is an open source implementation of C# and the Common Library Infrastructure, or CLI, components of Microsoft's .NET framework. Microsoft turned those components over to ECMA some time ago, and they're now open ECMA standards. Ximian also has a set of office productivity applications, including an Outlook-like email/calendaring/contacts application.)

 

This is an interesting move, from several different perspectives. On one hand, Ximian was struggling to keep its doors open. So simply by virtue of the fact that Ximian can continue its efforts, the transaction is of benefit to the open source community. All indications are that Novell intends to let GNOME development continue unchanged, for example, which should stabilize the project and keep it going.

 

The Mono Variable

 

The Mono project is both one of the most interesting things about Ximian and one of the biggest variables in the acquisition. The combination of Web services standards and open source software promises to fundamentally change the nature of the enterprise application integration problem. But Mono's role in creating the combination of open source software and Web services has been a bit unclear.

 

Because it provides an open source implementation of the CLI on which Microsoft based .NET, many people assume (incorrectly) that Mono could allow developers to port Windows-based .NET applications to Linux. But Mono doesn't include all of the class libraries that make .NET a usable framework. Microsoft didn't turn these over to ECMA and owns patents and copyrights on their implementation. Due to that fact, some (including me) have wondered exactly what value the Mono project provides.

 

But, Anne Thomas Manes, our esteemed research director for the Application Platforms Strategies service, has an interesting idea: What if Mono became the foundation for a fully open source application server/runtime? What if someone took the Jakarta code, converted it to C#, combined it with the Mono runtime, and added some additional class libraries? You could have a truly open source application server/runtime that competes with both .NET and Java. (Both .NET and Java have open source implementations of some portions of their platforms, but not all of the core components necessary to create an fully open source alternative are available.)

 

This is pure speculation, of course; such an effort would require strong leadership and relentless focus, on par with the focus and leadership within the core Linux community. And it's unclear if Novell intends to do anything of the kind. But it shows the potential that the Mono variable holds. As I said, however, it will take some strong, visionary leadership, and the appropriate backing, to realize that potential. 

 

Novell's Strategy

 

And that brings us to the other hand: the parties involved in the transaction. Novell recently announced its intention to put all of its services on Linux is part of an overall strategy to make all of its services truly cross-platform, available on a variety of operating systems. eDirectory has been available on multiple operating systems for some time, and Novell has been slowly but surely moving its other services away from a dependence on the NetWare OS. Novell has made it clear that Linux is one of the most important platforms in that strategy.

 

In other words, Novell's Linux strategy is the clearest signal yet that Novell is finally facing the fact that the NetWare OS-as opposed to the services that run on it-is an architectural dead end. (Chris Stone hinted in a News.com story that Novell may soon stop making major revisions to the OS.) (Note: See the more recent post regarding Novell's response to that story.) Over the last 20 years, Novell has made many attempts to turn the NetWare OS into an application platform, but never succeeded. Novell now intends to leverage all of the effort behind Linux, and is backing up that claim with the Ximian acquisition

 

On the whole, that's a good idea. One could even argue it's a few years late. (I do wonder, however, how wise it was to hint that future NetWare development will halt before all the products necessary to replace NetWare are not just available, but gaining customer acceptance.) In that light, the decision to put some muscle behind Mono, GNOME, and other Ximian efforts could be a positive thing. Especially if Novell can help turn Mono into something more than the interesting, but largely academic exercise it is today.

 

The Track Record Counts

 

Still, one can't assess such things without considering Novell's track record. In the past, Novell made ill-advised acquisitions (such as WordPerfect and Unix Systems Labs) in its well-documented war with Microsoft. Novell has backed off the frontal assault strategy of late. But given Ximian's assets-a Linux graphical UI, office productivity software, and an Outlook competitor-some customers may assume that Novell intends to compete with Microsoft on Microsoft's turf again. Several press articles have taken that angle.

 

I don't think that's Novell's primary intention, but even if it's a secret hope, it's a big mistake. Novell's core identity management business-which is doing well-has to support two acquisitions that have yet to show any real return: Cambridge Technologies and SliverStream. Even the perception that Novell is opening a third front, battling Microsoft on the desktop, would be damaging and could hinder Novell's ability to execute. And Novell doesn't have a good track record with acquisitions.

 

So, Novell has something to prove here: that its leadership can rally the necessary resources around these efforts, combine the Mono project with the tools and Web services technology it gained through the SliverStream acquisition, and help the Linux/OSS community create a Web services platform. Ultimately, Novell will have to help the Linux/open source community combat the platform strategies of BEA, Microsoft, and IBM, and to a lesser degree, Sun. Given Novell's track record, the resources aligned against it, and the enormity of the task at hand, Novell is a dark horse in the race at best.

An olive branch or mud in your eye?

According to this article in InfoWorld, Sun has decided to participate in the WSBPEL technical committee within OASIS. It's too early to tell if this is just an attempt to monitor what the competition is up to or a genuine effort to move things forward. At this stage, it's probably a combination of both. But it's at least a promising sign.

 

As I said in a recent post, BPEL seems to have the momentum, and OASIS has a better track record of late in getting standards out of committees and into the world than the W3. At a minimum, Sun appears to be hedging its bets, which isn't a bad idea. While I can understand Sun's consternation over IBM's and Microsoft's ability to drive the standards process, the truth of the matter is that the sooner we get an open, royalty free choregraphy standard, the better off all three vendors will be. If that's the outcome of this, it will be a case of "all's well that ends well." If Sun's joining the WSBPEL TC leads to more disruption and confusion, then it will damage everyone, including Sun. Here's hoping.

 

Later: This article on News.Com says that Oracle plans to attend the initial meeting as well, and joined the TC last week. I certainly hope that this is as positive as it appears. (Since Microsoft walked out on the WSCI meeting, however, the cynic in me has his doubts.)

Magic bus

Just after I wrote and posted my Burton Group web site column on how identity management systems can ride the Web services "bus," I saw Jon Udell's excellent InfoWorld column on a related subject. I wholeheartedly agree with his position that the simplicity and openness of Web protocols is a substantial advantage.

 

As Jon points out, the bus metaphor is rapidly spreading, and for good reason. Hardware busses, such as the standard PC bus that helped start the PC revolution so long ago, allow add-on components users plug into their machines to communicate with the host system and each other. EAI vendors have long used the message-bus metaphor to describe their message-oriented middleware products. By providing a software bus, these systems allow applications and services to communicate on as as-needed basis, usually in a loosely coupled, asynchronous fashion. The only problem is that EAI products don't support a standard bus, which means applications that want to communicate must use the same MOM products to communicate.

 

The Web services framework can change all of that by creating a standard software bus. XML and SOAP have given us the foundation. WS-Security gives us the security envelope for SOAP. And if the vendors can come together on a standard reliable messaging spec for SOAP, we'll have most of what we need for that standard software bus. Once applications and services and communicate via  a standard bus in both a reliable and secure fashion, the possibilities, as Udell points out, are enormous.

 

Later: Jon Udell expands on his InfoWorld column in his blog.

You bet your BPEL (on OASIS)

In a previous post, I pointed to the argument over business process definition as one of the fragmentation points in the Web services standardization effort. It's an example of how several issues converge to create problems and potential roadblocks for what the vendors often say they want and what enterprise customers desperately need-interoperability between application platforms. As I see it, the primary issues shake out like this:

 

• Whether IBM, Microsoft, and the "other vendors they invite to play depending on what they're working on" decide to submit their work to a standards body
  
• Which standards body they'll submit the proposals to, and the potential fragmentation and overlap between the efforts of OASIS and the W3C
  
• Whether the technology on which the emerging "standard" is based will be available royalty-free, and how it relates to any given standards body's policy on patents and intellectual property
  
• Whether Sun and Oracle, both of which have turned opposition to whatever Microsoft wants into a vocation, whether it's a good idea or not, will somehow come to agreement with Microsoft and IBM to create a real standard

These aren't in any particular order, and each takes its turn at being a driver for press coverage or a pithy quote or two. But they're all in full effect around the workflow and business process definition standards that have been the subject of so much contention lately.

 

On the business process front, however, BEA, IBM, and Microsoft took a first step toward clearing things up this week by announcing their intention to submit the Business Process Execution Language for Web Services (BPEL4WS) to OASIS. All three vendors, each having contributed to the protocol's development, have agreed to make the technology available royalty free. (And as Phil Wainewright points out on the Loosely Coupled Weblog, they're also submitted version 1.1, which should clean up some problems with the spec.) So that clears up two out of the four issues, or least one and most of another.

 

Along with Oracle, Sun submitted the Web Services Choreography Interface (WSCI), a competing proposal, to the W3C. So both OASIS and the W3C are working on business process definition standards, further highlighting the fragmentation between these two groups. And with Sun and Oracle lining up behind WSCI, the battle lines are clear.

 

Given the W3C's glacial pace-and its insistence on developing the Semantic Web-OASIS has gained a great deal of favor lately as the place to take Web services standards, and BPEL4WS is only the latest example to prove the point. Also, all indications are that companies like Siebel and SAP will line up behind BPEL4WS as well in this week's announcement. If BEA, IBM, and Microsoft build support for the standard into their platforms, and other major enterprise application vendors support it their products, BPEL4WS could well become a de facto standard on its own, especially if developers can use it royalty-free. IBM, BEA and Microsoft constitute a huge chunk of the application server and tools markets, and so have considerable leverage in forcing the issue. So it seems that BPEL4WS could well be a slam dunk. But I'm not sure that Oracle and Sun plan on going quietly into that good night on this one. We'll see.

 

Similar skirmishes are building in other areas. The argument over reliable messaging is particularly troubling, since IBM and Microsoft are working on a protocol that competes with work already under way at OASIS. And while we're making progress on Web services security, it's unclear if WS-Federation, which IBM, Microsoft, and VeriSign are working on, will compete with SAML and the Liberty Alliance specs, both of which now call OASIS home. We hope to shed some light on both issues at Catalyst this year in San Francisco.

The Semantic Web Draws Fire

This article on the InternetWeek site is typical of the coverage of the Semantic Web, and I agree that the W3C's efforts in this area seem a bit orthagonal to customer needs right now.

 

I recently heard Tim Berners-Lee talk about the Semantic Web at PC Forum, and the concepts are intriguing. It makes intuitive sense that, at some point, data becomes the Web, becoming more important than the application. For that to happen, data must become more self-descriptive, enabling systems to understand data across ad-hoc connections, with no a priori knowledge of schema and semantics.

 

While intuitively sensible, however, that ideal seems to be a long way off. Today, Web services is getting the attention because it promises to solve a real problem: interoperability and integration across applications that enterprises have now. Even when they have a priori knowledge of schema and semantics, application integration is simply too hard. Our clients are telling us that they want to solve that problem, and quickly.

 

While the W3C folks stress that the Web services and Semantic Web are complementary, it seems to me that the Semantic Web is too far out in front of what enterprises need now.

Security and Reliable Messaging Please

This article in InfoWorld is indicative of two important things in the on-going development of the Web services framework.

 

First, we're making some progress on security. A year ago, everyone was criticizing the total lack of security standards in the Web services framework. While we don't have a complete framework, vendors and standards bodies have been feverishly working on security standards, and we've made progress. The fact that folks now feel compelled to say that reliable messaging standards are "just as important as security" is a sign that we've made some progress.

 

Second, we've got a long way to go before the Web services framework can displace the vendor-specific and closed protocols that comprise message-oriented middleware solutions today. Yes, the Web services framework has the potential to unite the two most common approaches to application integration-remote procedure calls (RPCs) and message-oriented middleware-in one, standards-based framework. But the current battle over a reliable messaging standard for SOAP is a major problem. This story references the WS Reliable Messaging protocol that BEA, IBM, and Microsoft are working on, but those vendors haven't submitted their work to any standards body. Meanwhile, the OASIS technical committee is basing its work on the Sun proposal, without any involvement from BEA, IBM, or Microsoft.

 

Seeing these vendors argue over this baseline standard is like watching automobile manufacturers argue over the chemical composition of asphalt. The longer they argue, the longer they'll delay what they say the want: widespread deployments of Web services for mission-critical applications. The fact is that Sun doesn't want IBM and Microsoft to get their way on every standard. But between them, BEA, IBM, and Microsoft constitute the vast majority of application server market share. If they agree on a protocol and start shipping product, it could become a de facto standard. But in the meantime, the dust-up will cause confusion and slow things down, which is to no one's advantage.

One down, two to go (for now)

After a lot of wrangling that, at least from my point of view, seemed unnecessary and guaranteed to caused dissension amongst the Web services vendors, Sun is finally has a board seat on the WS-I. Now if they can just solve the broo-ha-ha over the choreography and reliable messaging protocols, we can move on to the next argument.