by Jerry Parker, MusicMaster Director of Operations

As a MusicMaster Client-Server (CS) installation grows, one of the administrative challenges that can sneak up on you is user security.

With a handful of stations and a small programming staff, almost any reasonable role structure will work. You may have a Program Director role, an Assistant Program Director role, an Administrator role, and perhaps a few special-purpose roles created as the need arises.

Expand that environment to 10, 20, or 30 stations, however, and those simple decisions can become surprisingly difficult to manage.

The solution isn’t necessarily more roles. In many cases, it is fewer, better-designed ones.

Understanding the Model

A USER is typically assigned one or more ROLES, and then the result is applied to one or more STATIONS.

Each role contains a collection of rights, privileges, and activities available within the platform. When multiple roles are assigned, their privileges are combined. Once that combined set of capabilities is applied, the result is then applied to one or more stations. The User can then perform the activities or workflows defined by their combination of roles, within those stations.

Conceptually, the model looks like this:

USER => Role A + Role B + Role C => Sum of privileges => Station 1 + Station 2 + Station 3

This distinction becomes extremely important as an organization grows.

Don’t Build Roles Around People

One of the easiest traps in a large installation is creating roles that mirror job titles or individual employees.

You might begin with:

• Program Director
• Assistant PD
• Music Director
• Production Manager
• Market Manager

Then someone needs slightly different access. You then create a new role, assign it to the person, and now you have:

• Program Director
• Program Director Limited
• Assistant PD
• Assistant Program Director Plus
• Music Director
• Production Manager
• Market Manager
• And so on

At some point, the role structure stops describing the operation and starts describing individual employees. That’s difficult to maintain, difficult to audit, and even harder for the next administrator to understand.

A useful warning sign is a role occupied by only one person. That isn’t necessarily wrong, but it is worth asking why that role exists.

If most users eventually require their own customized role, the role architecture probably needs another look.

Think in Capabilities Instead

For a larger MusicMaster CS installation, it can be more effective to think of roles as collections of related capabilities.

For example, an organization might establish roles along the lines of:

• Scheduling: The activities normally required to create, edit, review, and work with schedules.
• Library Maintenance: The privileges associated with maintaining songs, categories, attributes, and other library information.
• Clock / Grid Maintenance: The ability to create and modify clocks.
• Scheduling Rules: Access to the tools used to establish and maintain scheduling rules.
• Audio and Metadata: Activities associated with audio and related metadata.
• Reporting and Analysis: The reporting, analysis, and export capabilities appropriate to users who need them.
• Administration: The relatively small collection of activities that truly require administrative authority.

Of course, these are only examples rather than a prescribed MusicMaster configuration. Every organization operates differently.

The important idea is that each role represents a coherent body of work.

Roles Add Up

This is where the MusicMaster CS model becomes particularly useful.

Suppose UserA is responsible for scheduling and library maintenance and also needs reporting capabilities. Rather than creating a special role for them, or even a role called Senior Music Director, you might simply assign:

• Scheduling + Library Maintenance + Reporting, and let MusicMaster CS combine the privileges contained in those roles.

Now suppose UserB schedules one station but isn’t responsible for maintaining its music library. The assignment might be:

• Scheduling + Reporting. The same roles are being reused. The combination describes the person’s responsibilities.

A role should represent a recognizable body of work. A combination of roles should represent a person’s responsibilities.

Stations Define the Scope

The remaining piece is station assignment.

• User A may have: Scheduling + Library Maintenance + Reporting, applied to WAAA-FM, WBBB-FM and WCCC-FM
• User B may have: Scheduling + Reporting applied only to WDDD-FM

This is an important reason to avoid building station identity into the role structure unless there is a specific operational reason to do so. You generally shouldn’t need WAAA Music Director, WBBB Music Director, and WCCC Music Director if the underlying privileges are identical.

The roles describe the capabilities. The station assignments establish their scope.

Keeping those two concepts separate can dramatically simplify an enterprise configuration.

Consider the Many-Station Problem

Imagine an organization operating 25 stations across several markets.

Over time, it decides that everyone responsible for music-library maintenance should have access to an additional MusicMaster CS capability.

In an environment built around job-title roles, the administrator may have to determine whether that privilege belongs in Program Director, Assistant Program Director, Music Director, Corporate Program Director, Market Program Director, Programming Assistant, and several locally created variations.

Worse, those roles may have accumulated slightly different permissions over the years. In a capability-oriented model, the question can become much simpler:

Does this capability belong to Library Maintenance? If the answer is yes, update that role.

Everyone who has been assigned Library Maintenance receives the appropriate capability within the scope of their station assignments.

That is much easier to understand and maintain.

Don’t Go Too Far the Other Direction

There is another trap here.

If combining roles is powerful, why not create a separate role for every individual privilege?

Because then you have simply traded one management problem for another. An administrator shouldn’t need to assign 37 roles to give someone the capabilities normally associated with scheduling a radio station.

Roles should be large enough to represent meaningful activities, but small enough to be reusable.

Think in terms of bodies of work, not individual checkboxes. If several privileges almost always travel together operationally, they probably belong together.

Exceptions Should Be Exceptions

Every organization has unusual situations.

Someone temporarily covers another station. A corporate programmer needs access to several markets. A production employee needs one capability normally associated with programming. Someone is being trained for a new responsibility. Those situations don’t necessarily justify redesigning the entire role structure.

Before creating another role, ask:

• Can the requirement be satisfied by combining existing roles?

Then ask:

• Can the scope be handled through the station assignment?

Only after those possibilities have been considered should you create another permanent role.

This helps prevent an installation from accumulating years of roles created to solve one person’s temporary requirement.

Privilege versus Paralysis

Security design frequently invokes the principle of least privilege: users should receive only the access necessary to perform their responsibilities. That’s a good principle. However, when taken too literally, it can produce a system in which every ordinary task requires another permission request.

The objective should be to create sensible operational boundaries.

Someone responsible for scheduling should have the capabilities normally required to schedule effectively. Someone maintaining the library should have the tools necessary to maintain it. Truly administrative or potentially disruptive capabilities can be reserved for the people responsible for them.

The goal isn’t to see how few privileges can be granted. The goal is to give people the authority required to do their jobs while maintaining clear and intentional boundaries.

Periodically Audit the Structure

A MusicMaster CS installation should occasionally review its roles rather than simply continuing to add new ones: Look for roles that have no users, have only one user, duplicate another role, differ from another role by only one or two privileges, contain privileges that no longer match their name, or were created for a temporary situation that no longer exists.

Don’t forget to review station assignments as well. People change jobs. Stations change programming responsibility. Markets are reorganized. Employees leave.

A clean role architecture makes those changes easier to identify and much easier to implement.

Final Thought: Design for the Organization You Are Becoming

A five-station MusicMaster CS installation and a 30-station enterprise don’t necessarily need different security features. They need different ways of thinking about the same features.

At larger scale, try to resist the temptation to create a role for every title, market, station, or exception.

Instead, separate the questions:

• Who is this person?
• What activities are they responsible for?
• Where are they responsible for them?

MusicMaster CS already provides the pieces necessary to answer those questions independently.

• Use roles to describe capabilities.
• Combine roles to describe responsibilities.
• Use station assignments to define scope.

The result is a security model that is easier to understand, easier to audit, and perhaps most importantly, much easier to change as the organization grows.

A good MusicMaster CS role structure shouldn’t describe every employee in the company. It should describe how the company works.