As Paul has mentioned, he and I are taking a look at IBM Workplace Collaboration Services. I really admire the concept that IBM is working with here: integrated email, IM, and document management all rolled together in a unified web client or rich client. IBM has an ambitious architecture for Workplace and provides the option of using third-party database, directory, and HTTP server applications. They include support for their own IBM and Lotus products, of course, but they also give the option of using Active Directory (both Windows 2000 and 2003), SQL Server 2000, and IIS 5.0. (They also support various products from Oracle, Sun, and Novell, so they are very catholic in their tastes.) The actual installation process was very easy, making Workplace a far cry from the equivalent offerings from Sun and Oracle.
My goal yesterday was to get the single-server installation working against Active Directory on Windows Server 2003, and here's where I began to notice issues. Note that my comments here are not directed toward end-user functionality. With my decade of administrative experience, I tend to look less at cost issues or end-user features and more at the following questions:
- How easy is the product to install, both in my test and production environments?
- How easy is it going to be to operate?
- How easy is it going to be to maintain?
There are some who might argue that once you get to a certain size of deployment, any solution capable of taking care of the needs of the users is going to be sufficiently complex that it all evens out. That's a lovely theory, but my experience tells me that complexity only grows. If the application starts off as complex to install in test, it is not going to get any easier in production. If fact, it will certainly get far, far more chaotic once you let real live users loose on the system.
With the following questions in mind, I can safely say I have some serious doubts about Workplace. If any IBM employees or consultants (paging Ed Brill to the white courtesy comment thread) can give me a pointer to information to address these concerns, I'd appreciate it and be more than happy to post a followup.
My first concern: the documentation is woefully inadequate.
I always notice documentation, even moreso now that I write professionally. The Workplace documentation fails to impress and actively seeks to induce high blood pressure. For example, Workplace requires specific attributes to be present in the LDAP schema. The documentation says that if you're running Active Directory "You must add these attributes to the user object class in the Microsoft Active Directory schema if they are not already defined for it." What it fails to tell you is that these attributes are pretty much all added by the RFC 2798 inetOrgPerson LDAP object c lass. While this object class was not present in Windows 2000 AD out of the box, Microsoft made it available in a freely downloadabe inetOrgPerson kit. Even more importantly, this object class was added natively to Windows 2003 Active Directory -- so if your AD forest has been upgraded to the Windows 2003 schema, you don't need to worry about this issue at all. You also don't need to worry about the next step, which is to make sure certain attributes are indexed; they all are in Windows 2003.
For the sake of argument, let us suppose that you do need to add the attributes manually because you're still using Windows 2000. The easiest way to add them are to use a pre-existing LDIF file to import the required objects and ensure the proper attributes are being indexed. Don't waste your time looking for any such LDIF files; they aren't there. The best you get is a weak and generic pointer to "the Active Directory documentation". To make it worse, they don't even give you the information you need to manually add the attributes yourself! You get exactly one piece of information: the attribute name. That's it. You don't get any of the other information you need to properly add these attributes to any LDAP service -- no OID, no syntax, nothing. How hard would it have been to add an additional sentence or two stating that these attributes are part of the RFC 2798 inetOrgPerson object class and either a) provide a link to Microsoft's download kit or b) include LDIF files for people? Presumably IBM has LDIF files, since I assume they had to make the modifications to AD in their own test labs. While adding these attributes appears to be a task unique to Active Directory (thanks to Microsoft's initial lack of support for the inetOrgPerson object), all of the supported LDAP servers (including IBM Tivoli Directory Server and Domino Directory) require some sort of index configuration, so this is a general failing of the product and not a case of picking on Microsoft users.
My second concern: there are lots of needless hoops to jump through.
Once you've got the right bits in your schema, now you have to create a mess of users and groups. Again, the documentation is pretty spotty and the online resources don't provide a lot of additional insight. IBM gives you no guidelines on what privileges these accounts must have or whether any of them can be combined; I still don't know if these accounts merely have to exist as regular users in AD because they'll be used internally by Workplace, or if they need more access to Active Directory. I guess I'll find out as I go forward and break stuff. And it's not like they're picking on Microsoft users; the entire chapter on LDAP integration is written this way in a truly platform-agnostic fashion. At least they're consistent. On the other hand, I want to assure them that creating accounts programmatically is a solved problem these days and that doing so allows application developers to be sure that the right accounts exist, have the right permissions, and are in a supportable configuration. Oddly enough, this speeds up installation and decreases the time and money spent on pursuing asinine support issues. Also oddly, customers seem to appreciate these benefits, the ungrateful wretches.
Your next step: make a copy of a text file (the Active Directory version weighs in at a svelte 290 lines -- 78 of which are blank and 161 are comments, leaving a mere 51 parameters to configure by hand. Not a problem, right? Well, it's easier if you realize that many of them have already been configured appropriately for Active Directory, and even more could have been easily taken care of through a simple search and replace of common parameters (like the dc=domain,dc=tld root of the Active Directory domain, or the DN of the host running Workplace; even if they're not correct, they'd have been correct far more often than the generic entries provided). What makes it even more infuriating is that the next step is to use this text file as input to the provided Configuration Wizard, which takes the file as input and uses it to make the necessary changes to Workplace. There are a few parameters that are not included in the file (like passwords), so there's an actual UI to enter them. Again, this is the process used to configure Workplace to use any external service. Why couldn't IBM have included the necessary smarts to do this within the wizard and avoid the need to mess with the text file -- or at the very least, allow the wizard to generate the text file as a template for multiple-machine installation scenarios, with the appropriate machine-specific parameters to applied by the wizard as the template is imported?
If I were evaluating this product for my live enterprise, I'd have stopped at this point. I don't care how well-written the components are when I have to wire them all together myself. I commend IBM for being so diligently platform- and application-agnostic, but they've brought the lowest common denominator so low that they've successfully shifted the burden to their customers -- and when the developers don't take the time to provide necessary components in favor of making their customers sweat the small stuff just to get the product up and running, I have to wonder what else they've missed. I haven't even looked at the steps required to shift from the out-of-the-box Cloudscape database to an external database, but I can only imagine it is more of the same -- and if I were putting it in production, I'd have to move off of Cloudscape, since IBM states it isn't sufficient for production use. The cynic in me would argue that this is all a deliberate strategy to ensure that no customers try to install the product without purchasing consulting time, but I don't think that's the case; I honestly think IBM is still being dominated by the big-iron mentality and they expect their customers to be far more willing to shoulder the burden of installation than I think is commonly the case these days.
As I said, if I've missed documentation or guidance on how to simplify these tasks, I'm happy to be corrected. If there's something I've overlooked, please let me know!