How to architect Enterprise Chat for your organisation (Part-2)



Author’s Note:This blog post was a contribution from Ben Osborne, Lead Engineer working on the core collaboration stack, mobile and web products, from our partner MindLink. Ben has over 7 years experience working with enterprise collaboration systems including Microsoft Lync Persistent Chat, and has delivered mobile and collaboration projects to numerous tier-one investment banks.

Visit to learn more about secure and integrated enterprise chat and realize the full potential of your mobile environment.

In our Part 1 blog post (How to architect Enterprise Chat for your organisation (Part 1) – The 5 Types of Chat Rooms) we looked at the importance of a well thought through chat room structure, its benefits and the 5 types of chat rooms that are the basis of all chat room architecture.

This next blog post will look at a real-life example, the principles of centralised vs. decentralised management and maintenance and the creation of naming conventions.

As a reminder here are the 5 types of Chat rooms:

  1. Team-based chat rooms
  2. Project-based chat rooms
  3. Topic-based chat rooms
  4. Auditorium chat rooms
  5. Social chat rooms


Take the above and map them to a real-life make-believe company. This company has:

– 100 employees distributed world-wide

– Small cross-functional teams working on individual projects, plus some non-project based teams

– Projects that relate to one another

– Functional departments from which members work on each project

– Same-function teams working together e.g. HR

– A small collection of products

Now let’s assign the necessary chat rooms:

  1. First, let’s assign a locked-down team-based chat room to each non-project team. The team’s day-to-day collaboration stream can happen in this chat room
  2. Now for the rest of the teams, let’s assign a locked-down project-based chat room to each project team. Day-to-day collaboration on the project can happen in this chat room.
  3. Projects are related to other projects, so we can create chat rooms that can be used to discuss shared information and make decisions that relate to the projects as a whole. The members can be the union of all the sub-teams.
  4. There are employees on each project team that perform the same role. We can create a chat room for all of these across the entire company to discuss the technicalities of their specific role.
  5. The company makes a number of products. It is highly likely that there will be a need to share information between say, those making the product and those supporting or selling the product. This is a good use-case for long-running topic-based chat rooms that can be used as a go-to area to find out about that product, by all involved.
  6. Finally, we should create a general chat room for the whole company to discuss work-related announcements, and a couple of social chat rooms to encourage adoption and keep social collaboration separate from the main chat room content.

Have a look at our previous blog for a visual of an example chat room structure.

Lync Persistent Chat has an elegant but powerful category and permission based system to assign visibility and membership access to each chat room. We’re not going to go into the technical details of how to configure this here – there are plenty of blogs and articles on Technet – but suffice to say that the crux of implementing your chat room architecture is mapping your design to the right categories and right visibility modes and permissions.


All companies evolve, however, and despite your best planning as part of your Persistent Chat roll-out, there will be a time when new chat rooms need to be created. By now you should have gathered that letting users create chat rooms themselves is something we would not recommend.

Doing this will pollute, dilute, and fragment your carefully architected chat room structure, and ultimately end in chaos. In fact, we recommend you assign as few people as possible the rights to create and manage rooms and hold regular triages to clean-up and consolidate the rooms that are available.

If you have made this mistake already, MindLink can provide the tools and expertise to help you realign your chat room architecture – we recently undertook a discovery and documentation process for a Persistent Chat deployment of chat rooms at a major investment bank.


MindLink can provide the correct tooling to define a chat room creation request and approval process through which end users can notify the administration team of the need for a new chat room, and with which the administration team can automatically approve or deny the request – including creating the chat room automatically.

We recommend from the start that you establish a consistent and obvious naming convention for your chat rooms. Doing so makes it easier for users to understand the purpose of each chat room just by looking at the name, helps to avoid accidental creation of chat rooms with a similar or duplicate purpose, and in general helps to focus the collaboration flow in each room. We can help you define a suitable naming convention, and our chat room creation tooling can help enforce such conventions also.

  1. Carefully architect the chat rooms and membership permissions from the start
  2. Lock down chat room creation, and chat room membership modification permissions to the administration team only
  3. For team-based chat rooms, make sure only those who need to be in a room have access – this encourages team members to use the chat room rather than email for their internal communication
  4. Use a naming convention to help to give each room an obvious purpose and to shape the chat room architecture

In this blog we’ve talked about how to optimise your implementation and day-to-day usage of Persistent Chat through planning and administration of the chat room permissions system.

In the next part in this series, we’ll talk about how to drive critical collaboration through mobility and how to conduct rich contextual collaboration through integration with your enterprise’s systems.


About Maria Stockham

Maria Stockham is a Senior Enterprise Product Marketing Manager at BlackBerry focused on unified communications and collaboration and responsible for marketing enterprise applications (corporate and 3rd party including iOS and Android apps securely wrapped for deployment in Secure Work Space). Maria is a full time telecommuter based in Minneapolis, Minn. She understands how technology can enable the successful proliferation of virtual, global teams as well as the productivity and collaboration benefits it can provide. Her software industry experience spans over 10 years in digital imaging and telecommunications verticals. With a degree from the Carlson School of Management at the University of Minnesota, Maria has held various positions in Product Management as well as Product, Program and Channel Marketing.

Join the conversation

Show comments Hide comments
+ -
blog comments powered by Disqus