Our Senior Technical Consultant Ian Williamson discusses deployment of IBM Connections 3.0.
With v3 of IBM Connections, the product suite has been enhanced and refined, with better integration of the different collaboration tools and providing many additional features compared to the previous v2 releases (such as Ideation Blogs, Media Galleries, nested Sub-Communities, additional content moderation capabilities, Social Graph improvements and suggestions) .
At Digirati we have deployed IBM Connections 3.0 a number of times (both for our own use and for clients), and it is clear that for anything more than a simple demo/Proof Of Concept system a successful implementation relies on detailed planning of not only the core Connections applications installation and customisations, but also the hardware and software infrastructure which supports it, and necessary integrations with other existing systems.
IBM Connections has been designed to be a robust and scalable enterprise quality collaboration platform – able to scale to support hundreds of thousands of users. Deployment of the Connections applications can be relatively straightforward, but does require some experience working with the supporting system components, such as database servers, LDAP directory servers, the IBM Websphere Enterprise Application Server platform, and integration tools including the IBM Tivoli Directory Integrator.
It is possible to deploy IBM Connections on a single server – and if suitably configured, even support loads up to 10,000 users – but for anything other than an initial small prototype is that really going to be desirable? Enterprise applications need to be available constantly, often with ’99.9% availability’ SLAs or better. With Enterprise Collaboration platforms, the usual aim is for them to become a core system used by all employees; critical tools much like email and file servers.
Even when starting with a small-scale trial or prototype, once the system is being used for real day-to-day work tasks, downtime or loss of data can severely hinder productivity – so it is imperative that there is a reliable backup process in place from the start. As for any Enterprise system, make sure backups AND restores have been fully tested before going live, and monitor to ensure that backups continue to run, and are archived securely.
Infrastructure choices should be made early and planned in detail - bearing in mind not just the initial rollout (often to a single small group of users) but subsequent potential rollouts to larger groups and eventually an entire organisation of tens or hundreds of thousands of users.
From v3, IBM Connections requires the use of Websphere’s Network Deployment configuration, allowing clustering of services across multiple managed server nodes for both scalability and redundancy. How the various connections applications are mapped to nodes and application servers should be included in the planning process. Server hardware and software can also influence this decision – For example, 32-bit Windows servers have limitations on per process memory that require multiple Websphere server instances to be created even on a single physical host, in order to spread the application load across multiple JVMs (and so across multiple processes, each with their own allocated memory). Where possible we prefer using 64-bit servers and Operating Systems to simplify the deployment architecture, and remove these legacy systems limitations.
Other basic infrastructure choices must also be made, such as Operating System preference (Windows, Linux) and database (DB2, Oracle, SQL server) – these generally will be determined by the existing organisational infrastructure and the experience of the available system administrators and DBAs.
In more complex scenarios, with multiple application server nodes there is also a need for load balancing across the nodes, and often local or globally distributed reverse caching proxy servers, which improve application response times for users in different locations.
One key area which requires very careful planning is in the area of Directory Server integration.
IBM Connections uses LDAP directories, configured via Websphere’s Federated Identity services, to authenticate users, and also data from the LDAP directories are regularly synchronised with the IBM Connections User Profiles database.
The first step in planning the LDAP integration is to determine what systems the organisation already has in place. IBM Connections supports a number of different directory services, including Microsoft Active Directory, IBM Tivoli Directory Server, IBM Lotus Domino LDAP and others. Often organisations have several LDAP directories, either serving different purposes (e.g. Active Directory for Windows logins, Lotus Domino for Notes access), or due to organisational structure (different business units or acquired companies may have their own separate legacy infrastructure).
There may be a number of choices of LDAP server to use with IBM Connections. Which ones are most appropriate, will be determined by factors such as:
- Distribution of the users across the directories
- What user data is available in the different directories
- Which credentials are considered most appropriate or familiar for the users to use with IBM Connections
- What other applications need to integrate with IBM Connections.
- Whether single sign-on is required between connections and other systems.
Once the LDAP directories are selected, the mappings between the data attributes in the directories and the IBM Connections user profiles must be defined. This will determine which fields in the user profiles are automatically populated from the directory data, and which should be edited by the users within their IBM Connections profile. It is also possible to synchronise data that has updated in IBM Connections back into the LDAP directory, if desired.
As well as which data to synchronise between the directory and IBM Connections profiles, it is also necessary to define which users are able to use IBM Connections. This may start with a small subset of the users in an organisation (for a trial or departmental rollout), and then extend in phases to include other sets of users. The users might be grouped via Organisational Units in the directory, or may be explicitly added to an ‘IBM Connections’ user group – or may need to be determined via other criteria. The synchronisations of users and data between the LDAP directories and IBM Connections profiles is generally managed using the IBM Tivoli Directory Integrator (TDI). This comes with pre-built ‘Assembly Lines’ and scripts which can perform the most common synchronisations with users being selected via LDAP filters. Often, selection of users can be controlled by updating the LDAP filter in a simple configuration file, but in more complex cases custom TDI Assembly Lines and business logic may need to be built.
It is therefore essential that careful planning is performed, before embarking on an IBM Connections deployment, to ensure a successful roll-out and satisfactory end-user experience is achieved. IBM Connections 3.0 brings very powerful collaboration tools to an enterprise, but as with all new initiatives must be implemented in a way that best serves the individual organisation and reduces potential barriers to adoption.
