Yes indeed, this isn't your father's DP department anymore, and what falls under the umbrella of "application development" is awfully wide-reaching. IBM has always tried to provide a comprehensive set of tools for any computer needs your company might have, and to that end, they provide tools for just about any application development task. And for a brief moment, they were all called Workplace!

Welcome to the Workplace; We've Got What You Need

The naming is somewhat incidental. Some called it IBM Workplace, some Lotus Workplace, and some even IBM Lotus Workplace. As far as I can figure, the technically correct term was IBM Workplace, even though the product line fell under Lotus software. The important point is that Workplace was not Notes/Domino. And therein lay a lot of the confusion that surrounded the Workplace product line. Although Workplace was designed to interact with Domino (for example, a Workplace Managed Client plug-in allowed Version 7 of the Notes Client to run in Linux), it seemed at least for a while that the Notes client, if not the Domino sever itself, was more of a legacy integration strategy, with the long-term goal being to move entirely to the Workplace product line.

However, that was then and this is now. What was new a year ago is now on the great discard pile that contains so much great IBM software. I'm not going to spend a lot of time trying to decide whether this is good, bad, or indifferent. I quit that sort of head-banging-against-the-wall futility with the demise of OS/2, arguably the greatest desktop operating system ever designed. At IBM, the fittest does not always survive. And no, this in no way is meant to say that Notes/Domino is an inferior product. Quite the opposite; Notes/Domino continues to reinvent itself and position itself as a great product line. I hope to be able to do a more comprehensive review of what's available in a future article. But today, I want to focus on IBM Workplace and those pieces that still exist.

Before I discuss functionality, however, we have to review the state of application development in the new millennium. If you're an old-school guy like me, you grew up with the concept of a centralized IT framework. You had a server, and users ran programs on the server. The architecture changed a bit throughout the decades, going from batch processing to online transaction processing to client/server to browser-based applications, but in general your business processes ran on some sort of server and you logged into the server to perform your business functions.

Then, off in a separate little world, were your office automation functions. These constituted a completely separate work flow typically centered on the production and distribution of documents. These tasks were a direct outgrowth of the old typewriter days, and for quite some time were all but ignored by the "mainstream" data processing departments. In fact, only one company—Lotus—really identified the need to standardize document generation and flow. That makes sense, since from the get-go Lotus was all about office documents. Lotus' capabilities for collaboration and networking have historically been unmatched; even Microsoft Office is more about document creation and less about collaboration and distribution.

When Technology Worlds Collide

However, for the last 10 years or so, a real change has been occurring in the workplace (no pun intended). It definitely snuck up on us more "traditional" application developers, who primarily saw paper documents as something to be scanned and stored. At most, we might be cajoled into writing a mail-merge processor to create form letters, but in general those of us who wrote business rules using (theoretically) orderly databases couldn't be bothered with the messy text and pictures of (cough, cough) "office documents."

And then came "work flow." Somewhere along the line, somebody realized that the same basic transformation that turned business rules into software applications could be applied to business processes. Fundamentally, the concept was the same; business rules typically started out as things written on paper, anyway. I remember participating in one of my first BPCS installations and seeing how the shop floor control system at this rather large plant worked: It consisted of paper, several corkboards, and a whole lot of push-pins. Our job was to translate all of those bits of paper into "operations" that could then be entered into BPCS. Document management is the same idea. Many processes in the life cycle of a document can be automated. Things like content management, approval, and publishing can all be automated and controlled via a centralized system. Merge this with all of the other aspects of office automation (calendars, email, instant messaging, conferencing, et al) and you have "collaborative software."

And this is where we old-school application developers tend to get lost: Once you integrate content management into your systems, you forever change the face of "application development." That's because, to the user, information is information. Back in the old days, "automating" say, a hot list of customer orders, meant creating a hot orders file and writing a hot orders file maintenance program and a hot orders file inquiry program and then having someone maintain the hot orders file into the file so that other people could use the inquiry program. The amount of work required to implement such a system often meant that this sort of task slipped into the "offline" processes: Somebody wrote an impromptu little Word or Excel document, put it on the network drive, and told other people where the document was. And while it was being used as a production object, as far as the business rules developers were concerned, this file was out of sight and so out of mind.

And in the real world, we know what happens next: This impromptu file, with no controls and no monitoring—and possibly no security or backup either—becomes one of the fundamental, mission-critical objects in your system, and one of your core business indicators (in this case, customer satisfaction) relies on the contents of this document. And one day it gets deleted, and at that point the firings begin....

The New World of Workplace

I mentioned Notes/Domino a while ago. Lotus Notes and Lotus Domino epitomize the entire workflow concept. From the ground up, these products are all about office automation and embrace the idea of a document. You don't enter data into relational database files and then generate documents as an afterthought; with the Lotus products, you write documents and store documents and distribute documents in their native format.

Lotus is fundamentally different from the rest of the world in that it tries to have a master copy of a document that is shared by everyone while at the same time the software has an underlying concept of replication in which that same shared document is replicated across multiple servers. While this sounds mildly schizophrenic, it's really not. This approach accomplishes two things: Having a single master reduces the number of copies of a document (in the Microsoft world, you simply send your document via email to a distribution list, and everyone gets their very own copy), while replication allows for disconnected processing should your connection to the outside world fail for any reason and also automatically keeps any copies synchronized. While replication was perhaps more important in the 1980s when networks were unreliable, the idea still has merit today. You can lose an entire server in a Lotus installation and simply plug in a new one and let it rebuild itself from the other servers in the network. It's that level of self-healing that makes Lotus so appealing to administrators even as users rail against the counter-intuitive interface.

So how to address this? Well, one option is to fix Lotus, a task IBM has executed admirably via the Hannover interface. Hannover is the code name for what is now Version 8 of the Lotus Notes Client. If you've haven't seen this new version (you can view a demo here), you really don't know what Notes looks like. In fact, I'd say that if, like me, you used an older version of Notes, you are operating under a very deficient view of the software. The Hannover interface is, in a word, sexy.

Around the same time, though, IBM introduced the IBM Workplace product suite, and this has caused quite a bit of confusion. As recently as February of last year, I wrote that IBM was its own worst enemy as far as its desktop and office automation strategy went, and it seems that I was right.

Application Development in a Workplace World

Originally, I had planned on writing an article detailing how the various Workplace components worked together to create a new application development methodology. At one point, IBM had components that could range up and down the development scale, from the high-level Rational development products (used to construct traditional business applications) down to the IBM Workplace Builder, a product targeted at power users with no programming skills. In the brave new world of collaborative systems, IBM was creating a real choice in application development. The Builder product was a portal-like environment that allowed non-programmers to combine pre-built components into working desktops. Other tools allowed someone to build those components, while still others provided basic workflow for document processing.

The idea was to provide the ability to tailor not only your business processes, but also your application development process based on your needs. A power user could easily set up a collaboration space for a team—no need for a programmer. Data began to be treated transparently, independent of its format. Purely human-derived information such as marketing points could be put into a word processing document, which could then be shared, with changes as strictly controlled as any relational master file.

For a while, the idea was to use WebSphere Portal as the framework upon which these applications were built. Much of the Workplace line worked hand in hand with Portal. That made sense, because the whole J2EE portal concept is built around small application components that can be combined and configured by non-technical people. However, I think there has been an industry aversion to rushing willy-nilly to the browser-based software concept. While a number of benefits exist, the look and feel and responsiveness of a well-designed thick (or rich) client simply can't be equaled by a browser.

And perhaps the largest argument in favor of portals—that the portal design allows easy customization by the user—is rendered considerably less compelling by the power of the Eclipse platform upon which the Hannover interface is built. Again, I highly recommend that you take a look at the Lotus Notes 8 demonstration I linked to earlier; the interface is as polished as anything you'll see in an OS-specific interface, but because it's Eclipse-based, it will run anywhere.

The Unspoken Benefit

This leads us to the elephant in the room that nobody talks about but that I think may have been a primary impetus behind the continued development of the Workplace concept: Workplace ran on Linux. In Barry Kline's recent article, he outlines the relationship between IBM and Linux, and nowhere was this love affair more evident than in the Workplace suite. Obviously, applications that are Web-based, as many of the Workplace components are, do not depend on the client operating system and so are sort of by default enabled for Linux.

More important, though, is the rich client technology. Linux by itself cannot break the Microsoft stranglehold on the desktop primarily because Microsoft owns the office automation space with the Microsoft Office application suite. Pretenders such as Open Office have attempted to establish themselves within that niche, but until now, none have made any serious headway. A lot of that is probably due to the fact that these suites don't really add much to the paradigm; they're simply replacements that run on other operating systems. If you're already committed to Linux, then Open Office is an obvious choice, but Open Office in itself is not a compelling reason to dump the Windows platform. Back in the '80s and even the early '90s, we had a saying: Nobody got fired for buying IBM. In today's desktop world, the same holds true for Microsoft. It takes a strong IT manager or some compelling corporate business need to choose Linux, especially if you already have a lot of Windows and Office in your shop. And trying to replace highly responsive thick-client applications with browser-based versions simply doesn't fly in most shops.

And I think this was one of the reasons that both the Workplace product line and the Lotus line were simultaneously developed, at least until now. While the Lotus Notes/Domino product line is very powerful in its own right, Notes was pretty much a Windows-only proposition for quite some time. Domino provided a Web interface client, but the Notes client itself was Windows-based. Notes 7 did provide Linux capabilities via a plug-in to Workplace, and the Eclipse-based Hannover interface is by definition cross-platform, so that issue is moot and may well be the reason most of the Workplace family is being put to pasture. With the advent of a rich-client Notes/Domino interface, administrators can now provide users with a powerful, seamless desktop experience delivered from a centralized server. And now your developers can write small, sophisticated components that the users can configure into their desktop environments—on the operating system of your choice.

Add the powerful workflow capabilities of Notes/Domino, something that Microsoft is just beginning to address, and you have a feature-rich content management system that has no rival in today's marketplace.

It is this integration of the Eclipse rich-client user interface, whether delivered through Workplace or through the evolving Notes/Domino products, that may be just the impetus that some companies need to switch some or all of their users to Linux (or gadzooks, Mac OS/X!). The pervasive, device-independent nature of the Eclipse platform (I haven't even touched on Eclipse in your cell phone) is sort of a virtual machine for user-interface programming. Combine that with the content management and application development capabilities of the Workplace suite (which we hope are picked up in other products), and you suddenly have an environment where users are empowered not only to build their own applications but to use them where they choose.

While I'm not proclaiming the end of Microsoft just yet, I think this could get very interesting....

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at joepluta@plutabrothers.com.