My Top 5 Likes/Dislikes about being an IAM Professional

Recently, a fellow I.T. industry friend of mine was asking me why I chose IAM as a specialty. It got me thinking about how I got into this field, and why I decided to make a career out of it. I'd be lying if I said it was a conscious decision, although at this point in my life, it's difficult to imagine another I.T. discipline that I would find quite as rewarding, or as challenging.

The "getting in" part is easy to explain. IAM found me back in the late 90s when I was working as an enterprise architect for Travelers Insurance. Having worked there for less than a month, I was given an assignment to create a custom Web SSO and directory framework for all of the legacy host applications that were being web-enabled at the time. Back then, there were no serious vendor offerings for Web SSO (at least none that weren't extortionately priced). Even if there were any vendor offerings worthy of consideration, we had a "build, don't buy" I.T. culture in those days. Besides, there were only about a dozen applications and a few thousand external users that would be using it, and nobody was using the term identity management yet.

Immediately, I was hooked. Within two years, what started out as a tactical framework evolved into an enterprise SSO, federated identity, user provisioning, role management and directory virtualization suite (all of which was developed in-house). A dozen applications turned into several hundred, and a few thousand users turned into a couple of million. Before I knew it, I was no longer an individual contributor but was leading a large and extremely talented group dedicated solely to identity and access management. I never anticipated my career panning out the way it did, but I'm pleased it happened, mainly because of all the wonderful experiences I've had working in IAM over the years. Not to mention that I'm still extremely proud of what we accomplished there (it wasn't until several years later that we finally began to start replacing our homegrown suite with vendor solutions).

Anyway, I've decided to put together a short list of the things I love and hate about IAM, and would be interested in hearing from fellow IAM professionals about their own lists...

Likes

1. Working with customers. Although I was always enthusiastic about IAM, I only discovered how passionate I was about it when I moved over to the consulting side of the industry and began working with customers to solve their business problems. Having spent so many years as a customer myself, I can empathize with the internal challenges each of them face, having been there and done that. While at Qubera, I've had the privilege of working with some wonderful and highly talented professionals at customers all over the world. That's an experience I wouldn't swap for anything.
2. Technological diversity. I can't think of another I.T. discipline that provides one with exposure to such a vast range of technologies and platforms. An IAM project can touch every element of an organization's technology infrastructure, so in order to be successful, you need to demonstrate extraordinary technical breadth. In any given week, for example, I might be working on projects that involve integrating an IAM system with everything from vanilla LDAP directories to healthcare systems to mainframe applications to homegrown web portals to custom client-server apps to mobile devices.
3. Solving business problems. One of the pillars of our philosophy at Qubera is that IAM is a business enabler rather than just a technology. This is one of the first things we try to impress upon our customers. The sense of accomplishment one gains from solving a complex business problem for a customer and delivering quantifiable business value is an addictive feeling. IAM is one of the few I.T. disciplines where you have the opportunity to have a demonstrably positive impact on an organization's business culture.
4. Constant change. Although IAM technologies and best practices have matured dramatically over the past few years, IAM itself is still very much in its infancy (or at least in its adolescence, which makes me wonder when it will begin asking for a car). Just staying abreast of all the constantly evolving IAM standards, tools and technologies out there can be a full-time job in itself. As somebody who thrives on change, I think that the day IAM stops evolving will be the day that I get tired with it. Fortunately, there is no prospect of that happening for the foreseeable future; in fact, I believe today is the best time ever to get involved in IAM.
5. No two projects are the same. Every customer likes to think that their IAM challenges are unique. At a high level, I've never found this to be the case, as the general issues faced by most organizations tend to be extremely common. However, at a more granular level, the characteristics of every IAM project are very unique indeed. Sometimes this is because of the technical landscape or some unusual business processes, and sometimes it's purely because of the personalities involved in the project. Whenever I engage with a new customer, I know for certain that I am going to be faced with new challenges and have new experiences. That keeps things exciting and ensures I stay sharp.

Dislikes

1. Politics. IAM projects are notorious for being politically contentious, and at some point in every IAM project, politics will rear its ugly head. This is sometimes because of data stewardship or process ownership issues, sometimes because of turf wars, sometimes because project participants fear change, and sometimes because of internal disagreements over strategy and direction. No matter how careful you are to avoid it, political contention on an IAM project is as inevitable as the sunrise.
2. IAM is unglamorous. If you're looking to make a big name for yourself in I.T., then IAM is probably the wrong field for you. It is extremely unfashionable, and because ROIs often tend to be squishy, it isn't a top budget priority for most organizations. Generally, the only time anybody will care who you are is if you fail, and then everybody will know your name. To some extent, your proficiency in IAM can be measured by your level of anonymity. Fortunately for me, I never wanted to be famous, otherwise I would have chosen to become a movie star instead (/snark).
3. Delivering bad news. Just like doctors have to learn how to deliver bad news to patients, IAM professionals are constantly having to deliver bad news to executives. Usually, this is because a customer's security exposures turn out to be far more significant and costly than they had believed. Sometimes, it's because their project objectives and timelines are horribly unrealistic. And occasionally, it's because they lack the internal staffing to support an enterprise IAM solution, never mind implement it to begin with. Worst of all is when a customer engages you for a clean-up project after another consulting company has messed up an IAM implementation, and you have to deliver the bad news that the implementation is so bad that you need to rip down everything that your predecessor has done and start again.
4. Nobody takes IAM seriously until they suffer a serious breach. This one speaks for itself. We've all been there.
5. All the misunderstandings surrounding what IAM "is" and "isn't". No, it isn't a "product" that simply needs to be installed. No, it isn't just about provisioning users, standing up an LDAP directory or synchronizing passwords. No, it isn't an operational back-office function. And.... well, I'm sure you get my meaning.

If you work in IAM, what are your top likes and gripes?