Bring order to your group names

I'm not and admin buff, so I try to keep time spending in administration short. Management of groups for security purposes can be a drag on your administrative time. Since Notes basically let you do whatever you want, I find a lot of organic grown group structures. These are hard to maintain and often confusing. So over the years we refined a group structure, that is easy to understand as well as processable through code. The groups consist of three semantic elements connected by a dot:

&domainname dot metagroup dot purpose

Some examples:

&mycorp.sys.accessserver
&mycorp.sys.server01.signagents
&mycorp.sys.denyaccess

&yourcorp.apps.leave.administrator
&mycorp.apps.leave.support
&theircorp.apps.news.users

&domainname stands for your domain name or a sensible abbreviation of it.
metagroup can be either sys for system group (e.g. server access) or apps for applications
purpose can be composed out of one or more sub-elements. In the system metagroup it would be either an access role .createdatabase or a servername with an access role x34za.denyaccess. In the application metagroup it always will be the name of the application and the application function. . leave.hr .po.manager etc. Depending on your organization's size you might want to tweak the structure rules for the best fit (<advertisement>if in doubt ask TAO for consulting services</advertisement>). Keep in mind to stick to the maximum length of 64 characters

The structure has a number of advantages:

1. Using the # in front makes sure the groups are not mixed with user names or mail-group names in the address dialogue
2. Having the domain (or a sensible abbreviation of it) in front eases the maintenance of ACL of databases and templates that get replicated across domains (e.g. from system integrator to customer)
3. The structure allows for easy parsing. E.g. a server document must only contain groups that have .sys. in the second position. A ACL can only contain groups that carry the application name in third position. We typically use a registration database where all databases are configured with their "application name" to a acl scanner can find inconsistencies
4. We typically add a #mycorp.apps.NameOfTheApp.support group with designer rights to every database. The group is empty. When there is a need for troubleshooting a workflow process will add the developer to this group for a specified time frame. This way we avoid the two pitfalls in security: giving developers full admin rights or giving them permanent developer access to production databases
5. Since group names for applications are well defined you can use the application registration database for some kind of self service, where the business owner of a database grants access to a user by filling in a form and a background agent is updating the Domino directory. You can have as much audit trail and workflow as your auditors need to see.
6. ACL structures can be fine granular and well defined at the same time. E.g. you can enforce (and scan) rules like: If it is not a mail file, there must not be a person entry. Every database needs a support group with designer access (the structure would determine the exact name). etc.

Update: IBM recommends not to use #, so I replaced it above with &