#Social software lessons from the field: Part 2
Colleen Burns 120000C4RP firstname.lastname@example.org | | Tags:  paul_band profiles ibm_redbooks connections tags bm_connections social_software ibm_redbooks_thought_lead...
4 Comments | 5,169 Visits
Social software lessons from the field: Part 2
In part 1 of this two-part series, we discussed some of the IBM Connections architectural options and how to get the most from profiles. Now we'll focus on some more tips that will help your IBM Connections deployment stand out from the crowd.
Measuring engagement and contribution will be an important part of your business adoption strategy. Community owners therefore need the ability to monitor the adoption of their communities. The Community Metrics component of IBM Connections allows community owners to see what’s the most valuable content, the most likable content and the most active content of the community, as well as the number of visits.
In order to expose and perform analysis on community metrics you must deploy the (optional) IBM Cognos Business Intelligence server component as part of the Connections infrastructure. Although this can be deployed at any time, building it into the overall deployment plan will make the roll out of Connections simpler and faster.
The Connections UI: Organizational branding
Many customers want to customize the Connections site to align with their corporate branding or intranet theme. Thankfully the Connections developers have made implementing changes to the user interface (UI) fairly straightforward. You will need some experience with web design (including CSS and JSP) and graphical design skills for manipulating images, such as logos.
From my experience you should engage your organization's graphics team to produce logos and other images, because they either have a library of images already or can create them very quickly. They can also advise on color scheme standards and provide color HEX values necessary for customizing the color scheme.
Common UI changes include:
The daily, weekly and update notifications are often overlooked and can also be customized to incorporate the same branding and UI scheme as in the main Connections site. One tip would be to test notifications in all the different email client types you have, as some things can render differently, depending on the implementation.
If you followed the architectural advice thus far, the Connections system will be receptive to tuning to your specific usage and environment. Tuning and the resulting system capacity is affected by many factors including the type of usage and the hardware used (including servers, disk subsystems and network topology). You should aim to tune the system once it is fully in production and a typical type of usage is established.
There is a very good guide to IBM Connections performance tuning produced by the IBM Collaboration Solutions Performance Team that is available here. Although the guide was produced for version 4.0, many of the principles and techniques can be applied to future versions. It covers a number of deployment scenarios, so it should yield some useful insights regardless of your situation.
It's also worth pointing out that any performance tuning guide shouldn't be applied verbatim without first establishing a baseline performance that any subsequent tweaks can be measured against to determine the effect. Most tuning involves some form of trade-off. That is, you increase throughput or capacity of one subsystem at the cost of another. Having said that, I usually always apply the database tuning recommendations cited in the above guide.
Connections database scripts
On the subject of databases, IBM Connections ships with scripts used by the Create Database wizard to create all the necessary databases but with one-size-fits-all settings. These will work fine and get you started. However, it is likely that your backup and recovery strategy will be to perform online backups overnight without having to take the system down. To facilitate this, ask your DB2 database administrators to review the scripts prior to running them to ensure that Archive Transaction logging is enabled (this is a requirement of online backups in DB2). Also, maintenance tasks (such as performing a backup or a reorganization) and the requisite maintenance window will need to be defined at the database level.
Where a database administrator isn't available, or the scripts are run unmodified, I have written DB2 scripts to make the necessary modifications, although this does require the Connections environment to be down while the one-time maintenance is performed.
I hope you find the experience documented in this two-part blog post useful. There will undoubtedly be more lessons learned along the way, and I look forward to hearing from you if you have any other tips you would like to share. Please leave your comments below or find me on Twitter @therealpaulband.
Paul Band is a technical consultant for IBM Software Services for Collaboration in the UK. Paul specializes in the implementation and administration of collaboration systems. Paul is especially passionate about using social networking to find expertise and widen his network. Paul co-authored a Redbooks wiki publication on Domino administration best practices and enjoys cycling and crazy golf.
Paul is an IBM Redbooks thought leader