Creating a Collaboration Architecture: Step-by-Step Instructions

Several weeks ago I attended Gartner’s conference on portals, collaboration, and content management.  There I had a chance to speak with over 50 different customers who were looking to solve problems that included collaboration.  Many of them were just starting their efforts and were very happy to receive guidance from Gartner on how to start their enterprise projects.  But several customers needed more assistance in understanding how to start a collaboration architecture project that would lead to a deployment roadmap. So I thought I would provide a step-by-step process you can follow to create your own collaboration architecture and deployment strategy.  

1. Create an advisory board to help with the effort. Unless you have been in the company for a long time or have been exposed to all the business units in the business, I think it is a good idea to form an advisory board for the project.  Call it a cross-functional advisory board and invite different business process owners to participate.  Use the board to measure interest and to help navigate the organization to find groups in the company that are most needy and executives who would be willing to support the project. 

2.  Gather and document user requirements. With your board’s help, get in touch with different business process owners and participants so that you can gather the businesses requirements.  I would suggest for you to focus on the core business processes in your company and interview a wide range of individuals within those processes.  It is important that you interview the knowledge workers in the trenches and the executives.  As you start your interview process, you will learn a lot about the business and start identifying which business units are in the most pain and have the most passion.  Also, you will find out what executive is most willing to support your effort.  I recommend recording these interviews and making them available to the whole company. 

3. Create the business requirements document. After completing your interviews, it is wise to summarize the business requirements in the form of use cases, and then requirements.  Compare the use cases to your company's goals and objectives and categorize them in such a way that they align.  This way you will be able to use your requirements to describe the return on value that a collaboration system would provide the company.  Most importantly, you will start to understand and select priority processes where collaboration technologies could make the greatest visible impact. 

Once you have your use cases documented, you will find that many of the use cases are similar in their process, but not their context.  For example, you may have a business need for a resume repository in the consulting business unit and a request-for-proposal repository in the sales group.  Both have different results but the core use case is similar. Take these similar use cases and aggregate them into a high-level set of business requirements. This will give you the basis for the next step: a deep dive into the technical requirements. Unfortunately, most people start documenting the technical requirements first and forget all about the business need.   

4. Take your business requirements and transform them into technical requirements. This is where the true architecture work begins.  Now that you have your business requirements, you should take those and start dividing them into two categories: What and How. "What" represents the business requirements we are trying to solve and the "How" represents the technical requirements we need to implement to solve the "What". As you start doing this, you will quickly see that you mixed some business with technical requirements throughout your requirements gathering exercise.  You will also fill in the technical requirements missing for all the business requirements.  This exercise is time consuming, but it will help you come up with the architecture and understand what applications will need to be integrated to solve your business need. If you get really detailed, you will also understand how applications need to be integrated. Having this detailed understanding will save you a lot of time and money in the actual implementation.    

5. Categorize the technology requirements. Once you have finished documenting all of your technology requirements, you will end up with a large list.  Take that list and map the requirements to your standard IT architecture.  An example would be the standard N-tier architecture.  Using a standard architecture will allow you to map your requirements into categories that will prepare you for creating a logical architecture. You should also use this process to eliminate duplicate requirements and to consolidate similar requirements. 

6. Draft architecture diagrams. Using the categorized requirements will allow you to create a logical architecture diagram. That diagram will include all the components needed to resolve your business requirements and fulfill your business use cases. The logical architecture will undoubtedly include the following components: portal, collaboration, content management, business process tools, and development tools. Several vendors have architectures that you can use to give you some ideas.  Once you have created a high-level logical architecture, I recommend drilling down into each component, such as content management or document management, and create an architecture for each component. Once you have completed this exercise, you will know what solutions and products are required to solve your business needs. These architecture diagrams will be your most utilized tool. They will guide you throughout the rest of the project and allow other groups to understand the required components.

7. Conduct a gap analysis. By this stage in your project you will be very familiar with your business requirements.  Also, from your different interviews and advisory board interaction, you will know what solutions your company already has in place and what tools various departments in your company have deployed. Now you can take your knowledge of what is available and compare it to your collaboration architecture.  This will give you a gap analysis that will probably be very revealing.  For example, you may find a large overlap of products solving a specific need such a team collaboration.  These results will help you build a business case for consolidation or standardization.   

8. Create your roadmap. With these seven steps completed, you will know the business needs of your organization. Your knowledge of what tools are in place, missing, redundant, and most important, will let you create a road map describing what should be implemented, and in what sequence.  Knowing your resource availability will allow you to put together a proposed timeline for deployment.  Your roadmap may take several years to achieve, but you will now have a direction.  Your gap analysis and business use cases can be used as a business case for each project, and for the whole project.   

9. Execute. The last step in the process is to use your roadmap to get executive sponsorship and resources. Then you execute.  By this stage in the project, you will have a lot of information to backup your recommendations and you will have some detailed business cases for each of your proposals.  Your effort will also reduce the risks for project failure while increasing the chances of immediate results.  Good luck.