Blogger: Kevin Kampman
In my speaking engagements, I've learned that I sometimes refer to experiences that make no sense to younger folks in the audience. For example, I once spoke about a military data breach where physical, paper records about veterans were removed from an archive facility. I teasingly referred to the "green bar" records as the media that was stolen. I learned later from a participant in the audience that about half of the people there had never seen a report printed on paper with those printed green bars (a feature designed to improve readability). A dinosaur, it seems.
I've learned to keep this in mind when I address an audience, and in fact, use it as a way to gauge their experience. A term I used last week to refer to a security threat was "death deck", a term that hearkens back to the days when computers read programming instructions from something known as a "tab card". It seems that a programmer about to lose his job left a script in place that would destroy data on the computers at a lending institution, delete the OS, and shut the serves down. Fortunately his script was discovered beforehand, and he is now being prosecuted. In olden days, this sort of script was referred to as a death deck. The only difference between then and now is the media employed. Only two people out of 50 had heard the term, or would admit to it.
Subsequent to my speech, I met with a company who had been trying for a number of years to get an identity management initiative off the ground. There were many people in the room; all there looking for magic insights about how to achieve efficiency, demonstrate return on investment, and achieve compliance. A basic issue they cited is that it takes three weeks for new hires to get assigned to resources; in the meantime the new hires sweep floors. While this may seem like a provisioning problem, we've also come to understand that there may be something more fundamental at work here: Poor business processes.
When I started in the IT industry, one of my first jobs was designing business forms. You might not know what that is, but essentially forms were (and are) a way to design and implement a business process. A good forms design demonstrated the process essentials, demonstrated workflows, and captured the associated attributes and decision artifacts. Designing a form required a good understanding of its application. During the analysis effort, more efficient alternatives often became apparent. As with any automation effort, a good form could not make up for a bad process. It could, however, help to point one out.
In the organization with apparent IdM challenges, the audience was mostly IT folks. No one from the business or human resources community was present for our meeting. Given their difficulty in justifying their initiative, or even finding the right problem to solve, I think it is important to point out that IdM doesn't operate in a vacuum. It is integrally related to business processes and procedures, and this alignment can't be discounted. The point of this is that IdM efforts must always demonstrate business alignment. On the other hand, if the organization has process challenges, they shouldn't look to IdM to solve them. Proper process design and flow are essential to the success of any initiative, regardless of the technology we employ to implement it.
Comments