“Then Goldenlocks sat down in the chair of the Great, Huge Bear, and that was too hard for her. And then she sat down in the chair of the Middle Bear, and that was too soft for her. And then she sat down in the chair of the Little, Small, Wee Bear, and that was neither too hard nor too soft, but just right. So she seated herself in it, and there she sat till the bottom of the chair came out, and down she came plump upon the ground.”[i]
I’ve been making this observation formally ever since I
started in the software field at a company called Magic Solutions back in the
late 90s and probably informally before then. You see, it’s been my experience
that when organizations roll out new enterprise concepts, particularly in IT
and more specifically in IT Security and Governance, it goes through at least three
revisions. I’ve seen this happen in several models whenever there is some sort
of organizational hierarchy. In my Help Desk days, it was about Ticket Subject
Organization, in Identity it’s usually the organization of the Directory
Service (Security Groups and Organization Unit structures) or role/entitlement
hierarchies.
For the record, I’ve been involved in all of the scenarios
listed below, and I’ve been confident I nailed it nearly every time. As I’ve
become more experienced, I mention that these structures will most likely change over time
and that the first time is seldom the charm.
The first one is usually pretty much what the organization
thinks they need. This might be in consultation with experts either during the
sales process or when working with the implementation specialists. This frequently
suffers from a lack of flexibility, in that not all use cases have been
properly considered and weighted. It’s good enough for now, and the project to
review how things are configured is pushed to the next version of the
application / architecture review.
The second time around, the organization is looking to be
flexible, so that any potential scenario can be handled. Now we have the opposite
problem, where different parts of the organization have too much control and
the solution becomes too cumbersome and there is little to no organization. It’s
complete anarchy, audit logs become so incomprehensive that they border on
being meaningless, and nobody is happy.
At the third time through the process, I believe that we are
starting to maybe see a proper solution that has structure, and is somewhat
flexible to new scenarios. In terms of our introduction quote, it’s not too
rigid, and it’s not too open, but just flexible enough.
Sometimes this is
because the structure is more open, or because there’s a stronger change
control process in place. Sometimes it is because the organization itself has
changed, changing in size, complexity, governance needs, or just a plain old
change in culture. Change will still occur, but with the lessons learned the
process should be more manageable.
[i] https://en.wikisource.org/wiki/The_Story_of_the_Three_Bears_(Brooke)
That’s how this version spelled it. Emphasis is mine.
