How to architect enterprise communications: Defining metadata

Recently, a fellow member on the Red Hat Product Demo System (RHPDS) team said to me, "John, we're having issues with communications. Can you work out a design for it?"

I'm an IT architect and senior technical support engineer, but I also have an MBA. I've been a manager, so I'm somewhat familiar with the knowledge domain. I felt confident addressing this request, but I knew I needed to do a bit of research first.

I spent several weeks combing the web and academic websites and asking colleagues, friends, and acquaintances for information. I couldn't find what I was looking for, so I decided to do a full investigation and design a brand-new communications architecture with my team. Here is how we did it.

Define a communication flow

I started by defining "communication." Have you ever deeply considered this topic? It can mess with your mind a bit. Here's where I landed:

Communication is information that is conveyed.

I believe the flow goes something like this:

1. Measurements and experience lead to data.
2. When you add processing and context to sift that data, it leads to information.
3. Information made available (and potentially sent to the right places and people) is communication.
4. We place communication in specific tools so that it will be available to the right people, now and later, by someone who needs it.

Here's an example in an IT context: Think of data as what a Prometheus system provides. There are thousands and thousands of data points organized over time (which makes it information). You might choose to use Grafana to organize the data into information in graphs using queries. Dashboards are the method of communicating information to stakeholders. The tool used for these communications is Grafana. Any stakeholder can access that tool to find the information.

I struggle to keep "communication" and "information" separated in my head, even though academically, they seem distinct. So I use "communication" and "information" interchangeably in this article.

Understand communication attributes

Next, I had to determine what attributes of a particular type of communication or information are inherent to the communication. What "metadata" of a piece of information defines a type of communication and makes it unique from other types?

For example, what separates a "team policy" from a "corporate policy"? Or what distinguishes a "dashboard" from an "alarm"? Determining these attributes is important for delivering communications in ways that all parties involved (from the communication's conception to delivery) agree to, including how to structure specific information types and where to store each type of information.

For example, should operational processes be found in mailing-list archives or a wiki? Or should daily updates be found in a newsletter or a chat room?

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

Each team and function might have slight variations in how this plays out. A marketing team might use a mailing list and whiteboarding software for procedures, while an IT development or operations team could prefer a wiki. The information still needs to be communicated consistently so that each team member can quickly and efficiently find it when they need it.

Define team communication metadata

Third, we brainstormed what metadata defines the characteristics of each type of communication. Usually, our brains automatically group different types of communications into larger categories without thinking about it, but each type is a distinct item with characteristics that distinguish it from others. Knowing these distinctions allows us to separate communication types for analysis.

Attributes are the metadata that define a type of information or communication. They allow us to distinguish and group different types of information. In two months of work, my team defined eight attributes:

• Content type
• Target audience
• Source
• Frequency
• Rate of decay
• Urgency
• Structure
• Purpose 

I'll describe these attributes below; you may identify other attributes or definitions that apply to your team's work. You can also view more in-depth information in the appendices to this article.

Content type

Content types describe what specific categories of information are communicated.

For example, a schedule would be a content type. A change-management schedule and a team leave calendar both communicate schedules but are fundamentally different types of information. Therefore, mixing them on the same calendar (a tool) doesn't make sense.

Content types include:

• Schedules or availability
• Regulations or laws
• Team structure
• Images
• Diagrams
• Requirements
• Checklists
• Prose (usually free-form text from customer requests)
• Tasks
• Alarms or notifications
• Graphs
• Tables

Target audience

This attribute defines a communication's expected target audience when the information is created. A specific communication type can have multiple, distinct target audiences, and there can be exceptions to the target audience initially defined.

Target audiences include:

• Management
• Developers
• Operations
• Architects
• Organizational unit members
• Customers
• Executives
• Help desk
• Regulators

Source

This attribute defines the source of the information, such as a machine, team, or role.

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

Frequency of creation or revision

This attribute considers the likely frequency that the information will be created or updated.

Words describing this would include:

• Continuously
• Ad hoc
• Less than hourly
• Hourly
• Daily
• Weekly
• Every other week
• Monthly
• Quarterly
• Annually or yearly

For example, a company policy's frequency would probably be ad hoc or yearly, as they are not updated very often (such as due to a regulatory change that affects the company). However, they are usually communicated yearly during annual compliance training.

Rate of decay

This attribute considers how quickly information decays and becomes useless or obsolete.

Words describing this would include:

• Continuously
• Ad hoc
• Less than hourly
• Hourly
• Daily
• Weekly
• Every other week
• Monthly
• Quarterly
• Annually or yearly
• Historical records
• Does not decay

For example, monitoring alerts are continuous, and historical alert information is occasionally useful. It is not useful to have old (and now resolved) alerts sitting in the dashboard, as it wastes the operations team's time hunting down the alerts and adds monitoring fatigue. So monitoring needs immediate and continuous freshness, but historical alarms have limited usefulness, except during problem resolution, when knowing the historical occurrences of an alarm can be helpful.

On the other hand, daily status reports are not looked at beyond the first day or two, so they are daily occurrences with almost no historical value.

Examples of information that does not decay include the company, team, or division name. These change rarely (if ever).

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

Urgency

Urgency is the relative need to act on information once it is received. Operations alarms are urgent. Company policy updates related to regulatory changes are less urgent because you usually know about them well in advance of the implementation deadline. Team meeting recordings are generally less urgent, as they communicate immediate information.

Words describing this are:

• Critical
• High
• Medium
• Low

Structure

Structure defines whether the information is easily machine-parseable.

Words describing this are:

• Structured
• Semi-structured (mixed)
• Unstructured

For example:

• A structured type could be a CSV file generated from a report, as a machine can parse this data easily.
• An unstructured type would be a free-text customer complaint form. These are usually unstructured and require a highly complex artificial intelligence (AI) to understand them (and even that will be incomplete).
• A semi-structured type might be a resume or CV. They have simple, basic structures, but most of the information in each field is beyond a machine's ability except for role title and begin and end dates. Recruiters use machines to simplify resume reviews, but a human still needs to check the data once the machine is finished with it.

Purpose

This defines the purpose of the information. Some examples include:

• Historical
• Notification or alarm
• Process
• New policies

Comprehensive communication

Communication is comprehensive, and it doesn't stop with defining attributes. In my next article, I'll explore the distinct communications tools my team discovered on this project. My third and final article will show you our tool-specific design for chat channels.

Being comfortable knowing these terms, applying them to your communications, and ensuring they're put into practice is the best way to mitigate the usual causes of communications failure: The lack of a shared, mutual agreement on how and where each type of information sharing takes place.