Getting Started With A Collaboration ArchitectureGetting Started With A Collaboration Architecture

So it’s January 2008 and like all good collaboration managers, you’ve vowed that this will be the year your organization crafts a comprehensive “Collaboration Architecture” covering tools, processes, and policies for collaboration in your organization.  Easy right?  Well………

Perhaps the main problem is that creation of a collaboration architecture isn’t a “one-size-fits-all” process.  In the last six months I’ve had the opportunity to work with a number of organizations to help with strategy and architecture development and I can tell you that they were all different, each with a different set of challenges and requirements.  But there are a few constants that we can address to provide a starting point.

First, decide the goal of the architecture.  Are you trying to create a single enterprise-wide platform for collaboration? Or, are you trying to develop guidelines to enable integration of various applications and/or services?  What are the constraints?  Is there a single strategic vendor for key components such as shared-workspaces or voice?  Or, is the organization following a best-of-breed model?  Often the scope will be driven by the nature of the organization.  E.g. a highly centralized entity may be able to implement a strategic-vendor approach, whereas a distributed organization may just want to ensure that various applications can be integrated.  Defining a set of ground-rules (or principles) is the key starting point for architecture development.

Next, look at the requirements.  What is it that you need your collaboration architecture to support?  What are the end-user requirements?  Compliance requirements? System/platform requirements? Mobility requirements?  Governance requirements? And so on….  Pay careful attention to current processes and legacy systems that you will need to integrate into your architecture plans.

At this point you are ready to define the scope of the architecture.  Typically this will include areas such as voice, video, messaging (including e-mail, IM, and unified messaging), and shared-workspaces.  Beyond those core elements many organizations look at integrating portals, search, project management, content management, and Web 2.0 components including blogs, wikis, RSS, etc.  For each of these areas the organization should define standards such as web service support, protocol support, or even vendor platforms if the enterprise architecture is based on a small set (or even one) strategic vendor(s).

Beyond the definition of the architecture is the real hard work – determining an implementation plan.  This involves looking at the current picture, comparing it with the desired end-state, and figuring out the strategy for getting from here to there.  This will typically involve identifying the “low hanging fruit”, and then moving to more difficult tasks.  In this case we’re looking at putting together project plans and perhaps most importantly, assigning responsibility so that you can at least have a reasonable expectation of success (or someone to pin the blame on if things go awry).

Finally, make sure to remember that no architecture is successful without buy-in from impacted parties.  Be sure to make architecture development an on-going process that involves feedback mechanisms, regular revisits of the assumptions and decisions made during the process, and the communication of architectural issues both to the organization, as well as to the architectural planning team.