Why Semantics Matter

It is all too easy for IAM practitioners to fall into the trap of thinking about identity management in terms of products, connectors, workflows, accounts, entitlements and correlation rules. But to your average business stakeholder—you know, the folks who ultimately determine whether an IAM project will succeed or fail—such terms are meaningless.

Years ago, before I switched careers and became an I.T. professional, I worked for an investment bank. Even though my official job title was “portfolio officer”, I was what we technologists commonly refer to as a “business customer”, using systems that provided highly sophisticated trade execution and settlement functions. Even though I had a conceptual understanding of how these systems worked, I was too busy doing my real job to know or care that when I received an error after executing a spot FX transaction, it was because a pointer to an object in our transaction database had miscast as an unsigned integer. I just expected the problem to be fixed, pronto. And when it wasn’t, I assumed that was because our I.T. folks were overpaid layabouts whose job security depended on them being able to confuse normal people like me with acronyms and technical gibberish.

Of course, after more than a decade on the other side of the fence, I know better. Yet even though the line between I.T. and the business is far less distinct than it was in the early 1990s, the semantic disconnects are the same as they ever were. The only difference these days is that now I'm one of those overpaid layabouts I used to disdain. So whenever I’m in a conference room, listening to I.T. staff discuss the concepts of identity management with “business customers”, I’m often reminded of those days, and can determine from the expressions on the faces of the business folks exactly what they are thinking.

Identity management is a veritable minefield of semantic misunderstandings, and failure to address them at an early stage of an IAM project can be fatal. Not only because it can exacerbate tensions between I.T. and the business, but because it can cause critical requirements to be misinterpreted. To preempt such issues, I always recommend creation of a glossary as part of the “Define” phase of an IAM project. That suggestion often elicits rolled eyes (mostly from other technologists, who are dismayed at the prospect that not everybody is as familiar with technical concepts as they are). My rule of thumb is this. If my mother-in-law cannot grasp the conceptual design of a solution, then I have no right expecting a business customer to understand it either. Not that I run every design past my mother-in-law, of course, but I’m sure you get my meaning.

The failure to appreciate the importance of semantics when deploying an identity management solution doesn’t just apply to implementers. In many cases, it also extends to product vendors. The business doesn’t think of identity management in terms of “Create User”, “Delete User”, “Modify User”, “Enable User” and so on. They are more likely to think of it in terms of lifecycle events (i.e. “New Hire”, “Change in Job Function”, “Name Change”, “Staff Augmentation”, “Contractor-to-FTE”, “Leave of Absence” and “Termination”). Yet very few products ship with configurable workflows that directly address these basic use cases without extensive customization.

An even greater semantic disconnect applies to entitlements management. When not even I.T. professionals can agree on the true definition of an entitlement (never mind a role), how can we reasonably expect to find common ground with business stakeholders? To some people, a role is synonymous with an LDAP, AD or RACF group (this couldn’t be more incorrect, by the way, but that’s a topic for another post). To others, it means a specific capability within a system, a job function or the ability to access a file share (technically the same thing as an entitlement, which opens a whole different can of semantic worms). As for the difference between fine-grained and coarse-grained entitlements, prepare to be met with glazed eyes if you choose to go down that particular rabbit hole.

While an IAM practitioner may view users as abstract blocks of data to be managed, business stakeholders view them as individuals who have job functions that cannot always be clearly expressed in terms of neatly labeled entitlements and permissions. An IAM architect may understand the difference between a user and an account, but such distinctions are not always intuitive for those who haven’t spent their careers thinking about identity governance. I recall one meeting several years ago where a security architect described users as “subjects”, a term familiar to any of us who have worked with access management solutions. He used this word several times while describing his solution. Eventually, a business analyst bravely raised her hand and asked him what the heck he was talking about. That opened a can of worms, from which it became apparent that the entire context of his briefing had been lost on the non-technical folks in the room. All because of one misunderstood word.

The truth of the matter is that to business customers, identity management is simple. As well it should be if we all speak the same language. On the I.T. side of the house, we may be wrestling with architectural nuances and product constraints, but those are not the reasons why most identity projects are unsuccessful. Failure to engage and communicate effectively with business stakeholders is a far more common factor. Our mission as IAM practitioners is to abstract the business from technical complexity, and that isn't always possible if we aren't speaking the same language.

Of course, this is an important consideration for any enterprise I.T. project, but in a discipline such as IAM, which is so heavily dependent upon well-defined business processes, the importance of defining and obtaining sign-off on a common glossary cannot be overstated enough. This is just one of the many reasons why it is critical to engage an experienced business analyst for any identity management project.

And one last piece of advice to my fellow geeks. Please don’t look at your business customers with disdain when you use jargon that causes their eyes to glaze over. After all, you probably couldn’t do their jobs any more than they could do yours. Besides which, they probably think that you’re an overpaid layabout whose job security depends on your ability to confuse them with gibberish.

My mother-in-law would probably agree with them.