Have you ever tried explaining how your network or system works?
A few weeks back, a client of mine – we'll call him Paul – struggled to explain to a consultant the identity architecture without a single, accurate picture of the system. He relied on a series of incomplete and out-of-date diagrams to describe how he thought things worked.
The consultant hired to assess the program – we'll call her Sarah – asked more questions. Paul grew more frustrated and flustered, apologizing for a “messy” system patched together over a decade of acquisitions, technology upgrades. Sarah pointed out, “you’re functional, and that’s good.”
The mood shifted. Paul was so focused on everything wrong he overlooked what worked. Sarah offered to help map the identity architecture and processes to ultimately “look for and showcase what works."
Boom.
We focus on what’s wrong and fixate on gaps too often. It might get attention, but it’s always negative. It is time to break the cycle.
The risk management and governance aspects of security mean we’re often the team to uncover the technical and legacy debt across the organization. That leads to some tense conversations where sometimes people lose sight of the reality that all projects force choices based on the technology, situation, and budget. We — and our colleagues — do the best we can with what we have.
In security, we find our firewall rules sprawl out of control and cause a conflict. Or we finally get around to audit our control lists to discover many people have a lot more access than needed.
It’s easy to look back and see the mistakes. But let's imagine showing people what works instead of showcasing all the failures. Here's what would happen: stakeholders would be offered proof of what is possible and suddenly, the uncertainty of change would not be quite so frightening. They'd see what the future could look like.
And they're in.
It took a few months, but eventually Sarah and Paul captured the current state of the identity architecture. It took over a dozen sessions with roughly a dozen different people across the technology organization to figure it all out.
As you might expect, it was messy.
But when they presented what they learned about the identity program to the leadership team, Paul and Sarah also showed some of the cloud-based capabilities the business wanted.
Once the leaders saw what the business wanted was working in the environment, they focused on defining a better state to offer more value. Then they agreed to transition the current identity program to that better state (over the next two to three years) instead of trying to fix and improve the current system that no longer made sense.
So what happened there? The leadership and identity team focused on solving the right problems to deliver value without getting bogged down by fixing the mistakes of the past. This took pressure off Paul and the identity team as they set out to build a new program their colleagues in technology and the business as a whole could get behind.
And they can do that with a strong foundation.
