This is the second part in a series on Job Role Security. Bob is a builder, working for Mr. Vila on the builder team, and bob is our example of Role based security in a real company. Take a look at Part 1 to get an understanding of the basics.
The Certificate Case:
OK, so Bob has been on the job about 6 months, and he’s just passed his hazardous materials handling course, and he’s now allowed access to the insulation shed. This access isn’t part of the builder role; we can’t just give access to every builder since only a few builders are trained to handle the insulation. So how do we model this? We can’t define this organizationally, because the insulation shed isn’t tied to managers or organizations.
We could just handle this as a one-off exception. Any large number of objects can be managed as a small number of groups and a small number of exceptions. Exceptions always occur and you NEED to have a plan for exceptions that can’t be pushed back into one of the support cases. The idea is to minimize exceptions. Managing similar issues as a unit will always improve service time.
Instead, we’re going to create a new job role. Insulation work can be treated as a separate job task, assigned only to certain people. We can easily tell who should be in this group since we can compare members to certificate holders, and we can easily tell why this group is granted access to a certain area (Asbestos is hazardous, m’kay).
This is very similar to a traditional UGLR/AGDLR model, but with one major distinction: we define the new role as “people who currently hold a hazardous materials handling cert”. We can also make the safety team responsible for access and membership this group provides. They are much better positioned to know who’s certified, and what that certificate entitles people to. Bob’s supervisor may not know what that exam covers, what that certificate requires or grants, just that about half his staff needs to have it so his team can deliver. Moving “Ownership” of this role over to the health and safety team means that the team responsible for enforcing this is telling us what to enforce.
The Project Case:
So Bob has been assigned to the renovation of the city museum. The museum has a LOT of valuable art, and they don’t want any of it wandering off during renovations, but the construction group is going to need to measure, fit, frame, and eventually re-install all of that art. In order to square this circle, the museum has granted the renovators access to the backroom vault, where pieces not currently showing are stored.
Obviously, we can’t tie this right to any of the existing rights, because it’s not based on a job role (lots of work is are being done for this project), and we really don’t want anyone not involved in the project near this vault. Similar to the certificate case, we can create a new security role based on the project, make the PMO the owner of this group, and make it his responsibility to ensure people get added and removed correctly. This charges the person who is actually responsible for who has access with the job of deciding who has access.
In Other News:
So probably the first question your asking is why this is any different from UGLR model (yes, a NT 4.0 reference). The main difference is one of management, not implementation. A traditional group model doesn’t specify any method for managing, checking and maintaining memberships. This is the major point of failure for a lot of organizations; no one knows how the groups are defined, or what they mean, so everyone creates their own groups that they define to themselves, and the cycle continues.
If, on the other hand, the purpose meaning and membership of groups is tied to some external factor, such as job role or project, then those groups can be used to model the real use. I mentioned this in the first part, but role based security doesn’t mesh well with creative or highly dynamic industries. The methods identified here are an excellent way to fill that gap. By mixing and matching job based, project based, and condition based roles, a matrix or project focus organizations can control their security by archetype, rather then each, single instance.