IBM's IICE heats up content federation

WebSphere IICE not only locates content but can add, modify, delete and manage data items through a uniform interface

It's an undeniable problem. Many IT sites lack uniform access to unstructured data locked away in ECMSes (enterprise content management systems), workflow software, and other repositories. Data in these systems is frequently accessible only through the vendors' proprietary interfaces, and so federating it is difficult.

Search engines do a terrific job of federating search access, but they merely provide read access. For plenary access, sites need a product that not only locates content but can add, modify, delete, and manage data items through a uniform interface.

IBM's WebSphere IICE (Information Integrator Content Edition) v. 8.3 provides just this capability for ECMSes from IBM itself (DB2 Content Manager, WebSphere Portal Document Manager, and Lotus Notes), IBM's recently acquired FileNet (P8), Documentum Content Server, Open Text Livelink, Stellent Content Server, and Interwoven Team Suite, among others. IICE also provides read-only access to IBM DB2 and Oracle databases, as well as DBMSes that can connect through other IBM products.

Because of the complexity of setting up substantial content repositories on multiple platforms for testing purposes, I reviewed IICE at IBM's site --so this review isn't hands-on in the traditional sense. Nonetheless, I got a good sense of the features and benefits, and it is clear that IICE is a robust and expansive solution. I was impressed with IICE's capabilities, but was taken aback by its hefty price tag and disappointed that it doesn't integrate with more systems.

IICE is generally deployed in conjunction with IBM's other information and data management solutions. However, it is just as comfortable being a stand-alone package. In the former configurations, IICE serves either as a front end to an ECMS or as a middle layer between users and back-end systems containing unstructured data.

IICE works with content repositories by relying on their own proprietary APIs to do the work. For example, to search ECMSes, a user will enter the search terms on an IICE console. The package then runs the search against all the content management systems using their interfaces, normalizes the returned results, and displays them in a Google-like interface. IICE transparently handles single sign-on --with integration with LDAP and Active Directory --for authorization, and it relies on the respective back ends to enforce access control.

IICE does not display search data until all searches are complete, which unfortunately puts performance at the mercy of the slowest back-end system. You may remove a given system from a search, but there is no option for displaying partial search results in the name of speed. In a simple demo across four back-end systems, we waited several minutes for a search to complete, because one repository was hosted on a severely underpowered platform.

Contributing to this slowness is the fact that IICE does not maintain an index of items found on the back ends, nor does it cache searches or results. IBM attributes this design to IICE's focus on completeness of search results, rather than speed. If fast searches are important, IBM recommends its

OmniFind edition, but I don't buy this either/or paradigm. Users would be well served by options that allows them to tune activities between performance and completeness.

After the results have been displayed on the console, users can modify the data. For example, highlighting an item in IICE can be saved to the CMS via IICE. The product also exposes administrative options to these repositories --most data manipulation capabilities that the system provides are passed through to the user in an integrated UI.

More about BEACMSDocumentumGoogleIBMInterwovenOpenTextOracleParadigmSpeedStellentVIA


Comments are now closed

OS X Yosemite public beta nears release