How to architect enterprise communications for chat

Not having a defined communications architecture can create a lot of confusion for a team. I've seen this firsthand as an architect and a senior technical support engineer in the Red Hat Product Demo System (RHPDS) team.

One major issue is "channel sprawl." This happens when you create new communications channels that overlap with existing ones. Instead of one clear channel, you have six channels that cover the same topic. No one is sure which channel to use, so everyone picks whichever one feels right at the time.

This makes it hard to find something in history. With a single channel per topic, it's relatively easy to search history. But when you have many channels, you have to search each individually, which adds time and confusion. Then, because topics are split between channels, you have to stitch together different channels into a single, coherent story for any topic.

These compile into severe frustration and even burnout, even with a tool as simple and flexible as chat!

Avoid channel sprawl

So how do you avoid this? The answer is to make sure you have a clear definition and structure for chat communications. The next step is to agree on how to use and–potentially more important–how not to use those tools to avoid confusion.

This makes it easy for someone to figure out where to send a message, even though you'll need to change definitions and add and remove channels as the team evolves.

[ Download the IT leader's essential guide to technical debt. ]

Recently, my team asked me to create a communications architecture to streamline our communications. In my first article in this series, I described how my team created a list of attributes (or metadata) that apply to communication types. In my second article, I showed what tools we use for what types of communication.

In this third and final article, I'll share a real-world example of how we use our communications architecture for one of our channels: chat.

Our chat channel structure

We started with chat design because that seems to be the most flexible and misused tool and the easiest to change. Our team came up with the following channel structure. You can also view more in-depth information in the appendices to this article.

Customer-facing chat channels

• Customer channels
  • These are a place where we can chat with customers where it makes sense.
  • These do not replace ticketing, and anything that requires a ticket must be redirected to the ticketing system.
• Standard events (large corporate events) channels
  • These happen regularly and have a standard format.
  • They help remind us how the event ran previously and contain documentation and areas for improvements for the next event.
• Ad-hoc event channels
  • These are created for smaller events and deleted afterward. They are used for operations communications with event organizers.
  • These smaller ad-hoc channels avoid polluting the other channels with useless information that clogs history and makes searching more difficult.

Internal channels

• Infrastructure changes
  • These are changes our internal team needs to know about. We place status updates here in a thread for each change. If there is a question during the run, anyone can log in and interact with the change team here.
• Catalog item changes
  • Changes here aren't infrastructure changes, but they impact customers.
  • It makes sense in our environment to separate this from infrastructure to prevent confusion about domains.
• Ops and infrastructure chatter channels
• Robot and tool webhook communication
  • Automated reports of runs; chat can make a lot more sense for this than traditional email broadcasts from tooling.
• Daily "changing of the guard"
  • We have round-the-clock ops and development teams, so we keep a separate channel for handover items. Because these threads are sorted historically, it's easy to see the quick handover statistics and chatter.
  • We also use a webhook to allow scripts to gather and place statistics for an operator to provide commentary instead of having to tediously copy and paste from multiple tools by hand. This has dramatically decreased effort and stress and created more productive communications for our operations team. It also gives management an easy and quick take on operations at handover time.

Each tool and team combination has its own needs; this is our example. Now that we have structure around our chat channels, we are working on designs for other tooling choices, including obtaining feedback according to our open model and gaining acceptance in our team for the right way to implement the structure.

[ A free guide from Red Hat: The automation architect's handbook. ]