‘We’re not flying, it may take a while…’
Recently a lot of flights were cancelled in the United States due to bad wheather. And once the wheather improved the flights continued again. However, not all of them. For SouthWest Airlines the flights didn’t pick up, they kept cancelling large numbers of flights. What had happened? Their software and systems were so much behind in upgrades and updates that they couldn’t get them to pick up the schedules. They were suffering from ‘technical debt’.
What does this have to do with IAM? IAM can also suffer from technical debt. Actually we’ve seen this in numerous occasions. One way to tackle this is: recognize this challenge and create a masterplan.
Where does ‘technical debt’ come from?
IAM can facilitate and support critical business functions by overseeing who has access to what data. But also IAM is susceptible to ‘technical debt’, especially in larger corporations who have software for IAM that has been bought over the past decades. SouthWest provides the case what happens if you do not address this backlog of work (see this NYT article The Shameful Open Secret Behind Southwest’s Failure), and I’ve seen it happen quite a few times. Focus on the shiny new developments, the new features, the improvements, adding pressure by complex business changes (that impact who needs access where). This all can be carried by IAM. And yes, we can postpone a change or an update, because it does not immediately lead to issues. This is aggravated when a lot of requests have been responded to with scripting. Numerous scripts within IAM solutions result in complexity and a lot of (inter) dependencies within the solution. A scripts solves a question quite quickly, but a 100 scripts become a dragging anchor to agile responses to change.
In an illustration, it is a bit like: yes, I can eat another cake (business feature), although my tooth hurts a little bit (IAM). And it hurt a little bit yesterday already, and it will probably be hurting tomorrow as well, but I can postpone a visit to the dentist (upgrades/maintenance). Because that takes time out of my (business feature) schedule and obviously it is not fun to visit a dentist. But if you wait long enough, the dentist might see you and forward you to the hospitals’ dental surgeon, because you waited too long. And then you’re in trouble…
A masterplan, a master-team, and a bell that is heard
There needs to be a masterplan that keeps track of the legacy being build, the upgrades needed for IAM itself to remain sustainable and responsive. And that masterplan needs a master-team that rings the bell when the balance is tipping too much towards ‘new functionality’ and pushes the IAM technology beyond the point of ‘sustainable’ (meaning: upgradeable, in line with standards and architecture, and ultimately operable). And as a last attention point: make sure that bell is being heard and acknowledged. Sometimes senior leadership already has challenges understanding IT and technology, and I can’t blame them, try to explain to complexities of middleware and infrastructure to someone who only has had ‘the iPhone experience’, it is a black box to them. But it is leaderships’ responsibility to have insight in what drives their business, and which functions are providing the stability for business to run on, and what these functions need. In the case of SouthWest, the ‘technical debt’ was known, reported and not a surprise. It just wasn’t picked up by leadership, nor was it given the proper priority. Because, according to the NYT author, the incentives of leadership were tied to quarterly results of stock prices and earnings statements. So you duct tape the technology in favor of short term results. Short term gain leading to long term pain.
Balancing business, control and technology
A masterplan includes the functions of IAM that describe what business benefits and impact it delivers. A masterplan creates the space to deliver new features and functions for the business, and to support large change programs of the business. Because with each of those the key questions usually are: when I log in tomorrow, can I still access my applications and data? (that is like eating cake, a lot of it and really fast) A masterplan also creates the overview to position risk and control measures, the so-called ‘guardrails’ in which the business can lean and will know that they’re not spinning off the road. (that is like brushing your teeth and responding to tooth aches in a proper way) And lastly, the point of this blog, a masterplan keeps track of the status of IAM technology, when major upgrades are required (with COTS that is running onprem this might be every two years, taking the backlogs of IAM devops teams for a couple of weeks if you’re lucky, months if the impact is significant). (that is like the periodic visit to the dentist) And these three need to be balanced. Sometimes you need to do large maintenance, but not that often. Guardrails might slow you down, but they prevent you from ending in a ditch. And a lot of focus should be given to business enablement. Including the proper incentives with business and leadership to balance short term gain and long term gain. A masterplan works together with a vision and it informs the strategy, the choices you make.
That plays out on high level of leadership that directs the entire business. But it also plays out at low level in the teams in the organization. When I was working with these teams, we found an illustration (through a LinkedIn post by John Cutler) that helped us visualize the issue of ‘technical debt’. It’s called ‘Care for the garden’:
Business and IT alignment for IAM
This topic relates strongly to the article on Business and IT alignment, by Andre Koot. Where the article emphasizes the importance of business and IT alignment for IAM and the role of access governance. The case of technical debt that triggered this blog can be read from the perspective of business and IT alignment as well, but that would be another blog.