“The more restrictions you have, the easier anything is to write.”
In an earlier post, we discussed the importance placed on permissions in an OSS. We talked of the slice and dice analogy of being able to segregate data by function and operational group and how difficult this can be for many OSS, especially ones with complex referential integrity constructs.
But I sometimes wonder whether organisations put too much emphasis on being able to slice and dice. If your OSS can only segregate based on function (eg adding devices to the database), then is it essential that you also then segregate by operational groups (eg transmission, mobility) as well?
Let’s look at some of the pros and cons.
My OSS can only slice (ie segregate based on function):
Operators from one domain can view configurations of other domains, which is particularly helpful for cross-domain network designs or fault finding.
You don’t have to create and maintain different group privileges for each domain.
Operators make changes to devices that are outside their jurisdiction (either on purpose or accidentally). The reality is that most operators clearly understand their areas of responsibility and most OSS log the actions of operators so a misdemeanour can quickly be traced back to the culprit
My OSS can slice and dice (ie function and group segregation):
This makes intra-domain management faster and easier because external domains don’t distract the operator’s attention
It is usually harder to customise, configure and maintain the data sets to have multiple levels of segregation
It makes fault-finding more difficult if you can only see part of a cross-domain issue. You might as well just work from your element management tool.
The OSS integrator invariably creates an account for themselves that has super-user status and isn’t limited to sub-sets of data so sometimes they don’t test the experience of