How to architect enterprise communications: Selecting tools

Recently, a member of my team explained that they were having trouble organizing communications and asked me to help them by developing an architecture to streamline our interactions. In my previous article in this series, I described how my team began this project by creating a list of attributes (or metadata) that apply to communication types. In this second article, I'll show you the tools we use for different types of communication.

This framework should be malleable to your situation. Your information flow and tooling might differ from ours, and we might have some tool categories that you do not have or use in your context. Also, since we are the Red Hat Product Demo System (RHPDS) team, we try to use the products Red Hat offers for a function.

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

First, I'll define the tools we use:

• Wiki: The wiki software where you keep your team's documentation.
• Content delivery network (CDN) FAQ: This is a place where your team can answer customers' frequently asked questions. You can use your wiki tool, but many teams use different tools and spaces (such as the corporate intranet site). The idea is to reduce the number of tickets and help requests you receive for simple items.
• CDN index: This is where you can put more in-depth information and how-to guides for your users for things that don't fit in the FAQ category.
• Status page: If you run an external service, you can display the status of your various systems on a page.
• Ticketing: This is the system where your customers can submit tickets. It could be a GitHub issues page, Bugzilla, or another ticketing system.
• Dashboards: Your internal dashboarding and metrics. We use Prometheus with Grafana for technical metrics like response times, service load, and availability.
• Reporting: The dashboarding and reporting tool for managers and executives. It might be the same tool you use internally but with restrictions on viewing some technical items. The content is focused on business metrics.
• Customer portal: This is a "front-door" or "ordering" page for your customers.
• Video: Video recordings and meetings fit in this category. Most of the time, you'll link your video hosting service to this tool. If it's different, split the tooling types.
• Chat: Chat is ubiquitous and includes IRC, SMS texting, and encrypted chat. Ideally, there will be a single, standard tool for all chat communications, internal and external.
• Email: This is a long-form, asynchronous chat tool, mainly used for more formal unit-to-unit or external business communications.
• Calendar: All scheduling should be done in a single tool. For example, production testing, event schedules, and leave calendars should all be placed into a calendaring tool. For global teams, choose one that handles time-zone conversions.
• Vault: This is a place for automated tooling, application tools, and so forth. If you run CI/CD tooling, you'll want a place where your applications can securely access and store passwords and secrets for use. You don't store them in local text files on each server, right? RIGHT???
• Secrets or passwords: This is a companion to your vault where personal passwords and other human-use passwords are kept.

[ Get essential IT career advice from award-winning IT executives. ]

Beyond defining these items, you must do two more things to make this effective:

1. Your team(s) must accept and agree to follow these tooling selections, so it would be good to involve them in this process.
2. You must have an agreement within your team on how each tool's information will be used.

Think of this in terms of XML or JSON communication in an API. Both the client and the API must use a common set of definitions for the variables, and they must always be put in the same place. And the API must return something with a similar, set definition. Otherwise, the calls made to the API will be misunderstood, or the client won't be able to process the response. This requires mutual agreement and understanding of the forms to be used.

This communications structure is no different, but instead of having a server and client, you have people-to-people (or tool-to-tool) communications. Human communication is far more complicated than any machine.

What tools work for what types of information?

You have many options for how you communicate information throughout your team or organization. The key is creating an architecture that defines the tool or channel you use for each information type.

My team's generic communications structure and information flow are outlined below, and you can view this information as a table.

• Company policy or team policy:
  • Wiki
  • CDN index
• Team structure:
  • CDN FAQ
  • Nontechnical diagram
• Team schedule and availability:
  • Calendar
• Technical diagram:
  • Technical diagram
• Nontechnical diagram:
  • Nontechnical diagram
• Architecture requirements and documentation:
  • Wiki
  • Nontechnical diagram
• Procedures:
  • Wiki
• Internal and external events and schedules:
  • Calendar
• Infrastructure changes and change schedule:
  • Status page
  • Calendar
• Production demos, workshop changes, and change schedules:
  • Status page
  • Calendar
• Feature requests, internal or external:
  • Ticketing
• Task lists
  • Ticketing
• Daily status time-zone handover
  • Video
  • Chat
• Developer-of-continuous integration (CI) communications (break-fix):
  • Ticketing
  • Email
• CI owner (deprecation):
  • Ticketing
  • Email
• Development-to-operations team communications:
  • Video
  • Calendar
• Operations-to-development team communications:
  • Video
  • Calendar
• Non-team communications (features/break-fix):
  • Status page
• External, upper management, and stakeholder notifications:
  • Dashboard
• Lateral internal stakeholder notifications:
  • Dashboard
  • Email
• Dashboards:
  • Dashboard
• Reporting:
  • Reporting
• Monitoring and alarming:
  • Customer portal
  • Email
• Innovation; ideas for improvements, whiteboarding, team brainstorming:
  • CDN FAQ
• Customer-facing problems:
  • Status page
  • Ticketing
• Customer-facing requests for evidence or special requests:
  • Ticketing
• Customer-lab status communications:
  • Customer portal
  • Email
• System maintenance or outage also CI status (internal/external):
  • Ticketing
  • Dashboard
  • Email
• Team relationship and discussion:
  • Video
  • Chat
• Outage resolution:
  • Video
  • Chat
• Documentation and explanations:
  • Wiki
  • CDN FAQ
• Secrets and passwords (user):
  • Secrets passwords
• Secrets and passwords (tool):
  • Vault

Next step: An example

In my third and final article in this series, I'll give a real-life example of how this works by sharing how we apply this structure to our chat channels.

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