Two Out of Three Ain't Bad

Around the time that Nick was finishing up with his bank project, I was starting a new engagement with a different bank (I promise we've done this at more than just financial institutions, we'll get there). We were about to test three theories we had regarding our Role Model Analysis capabilities:



The first theory was that we had generalized the mathematics behind Role Model Analysis, that what Nick did to figure out the Role Model for his client would be doable at this bank. I was very confident in this, the math seemed sound at the moment, but there was a lot of pressure to succeed here, which makes sense when you claim to have an answer to a question as valuable as "What roles should we build?"

The second theory was that different companies even in the same industry would have different role models. It was obvious that the names of the elements would at least be different, job titles, divisions, departments etc. would all differ of course, but the underlying structure, their relationships to the access their people would use would also differ. In a perfect world, they wouldn't of course, but we were pretty sure the only place the Platonic ideal of a role structure exists is in the CISA RBAC guidelines. If we were wrong, and some universal ideal structure existed, our analytical method would amount to little more than a novelty and any organization could simply look up the standard for their industry rather than derive it from their data.

The third theory was that we could train very junior personnel to perform this. I was less confident in this, the only professional instruction I've ever given was on soldiering and artillery adjustment. I went into this with a fresh college hire, a fantastic software engineer with a computer science degree and a month's worth of exposure to Identity and Access Management. I already knew that I could teach him how to run the tooling that we had developed (I'd already done this for a previous client), but I was less sure of my ability to explain what we'd be doing with it and why.

Two of these theories were correct and the third was another false positive. We did indeed find the ideal roles structure for the bank, my junior associate was more than capable of absorbing the how and the why of what we were doing despite my lack of teaching experience and the role model for this bank was very different from the previous one. The org structure of the company was more robust and the HR data richer, it allowed for a more nuanced role structure that allowed for a more elegant fit of access to responsibilities using more tiers of roles. To be clear on this last decription, more tiers of roles typically means a smaller number of roles, as higher tiers in a role structuer apply to more people. The process turned out to be so smooth that we ended up taking on additional work and leveraging our tool to optimize a migration between systems in preparation for a merger.

The false positive was in thinking that we had indeed generalized a solution to the question "What roles should we build?". While it worked here for the third time, we came to find it did not work everywhere, after all there's a reason why we're moving past Role Model Analysis and we'll dive into its limitations in our next article.