I just finished reading Corbin Links' IAM Success Tips, Volume 1 and really think it would be a great resource for any new IdM initiative your organization might be starting. I know that I will try to implement many of the suggestions in the book as we move forward with our project. Many of the "bad" examples in the book -- the things not to do -- brought back some memories for me... I hope that this project at the U of R can avoid many of those common pitfalls. Things like not understanding your current environment, and expecting a vendor's software package to solve all the IdM problems that have grown out of bad business processes.
I look forward to the imminent release of Volume 2 (which, according to this post, is slated for tomorrow!)
Sunday, November 30, 2008
Wednesday, November 26, 2008
Identity management at a university
There are a few unique aspects to doing an identity management project at a university. Well, if not unique, then certainly more pronounced or common than in a typical enterprise...
One challenge is the decentralized nature of the university. The number of individual organizations -- departments, schools, libraries, etc. -- is higher than that of a typical corporate environment. And more importantly, each group has traditionally created its own processes and support mechanisms for their own end-users. It will be important, as the project progresses, to build the identity framework in a flexible way that allows different organizations to feel like they are still in control of their data, but in turn, make that data (or subsets of that data) available to the University community at large. Corporate deployments would usually have the luxury of having complete control of the environment, and typically has a central IT department. This isn't always the situation, such as in the case of acquisitions, but usually IdM projects have the ability to set policy for the corporate-wide computing resources.
The other aspect that makes an IdM project at a university different than within a corporate environment is the number of different relationships people may have to the organization. First, identify the various relationships a person can have with the university and medical center (undergrad, grad student, alumnus/alumna, faculty, staff, contractor, patient). And what commonly occurs is that a person has more than one relationship with the University (employees are also graduate students, students are doing work-study programs, etc). Understanding these relationships, and documenting the process by which all the different types of users get added into the system(s) will be job number one for the project.
One challenge is the decentralized nature of the university. The number of individual organizations -- departments, schools, libraries, etc. -- is higher than that of a typical corporate environment. And more importantly, each group has traditionally created its own processes and support mechanisms for their own end-users. It will be important, as the project progresses, to build the identity framework in a flexible way that allows different organizations to feel like they are still in control of their data, but in turn, make that data (or subsets of that data) available to the University community at large. Corporate deployments would usually have the luxury of having complete control of the environment, and typically has a central IT department. This isn't always the situation, such as in the case of acquisitions, but usually IdM projects have the ability to set policy for the corporate-wide computing resources.
The other aspect that makes an IdM project at a university different than within a corporate environment is the number of different relationships people may have to the organization. First, identify the various relationships a person can have with the university and medical center (undergrad, grad student, alumnus/alumna, faculty, staff, contractor, patient). And what commonly occurs is that a person has more than one relationship with the University (employees are also graduate students, students are doing work-study programs, etc). Understanding these relationships, and documenting the process by which all the different types of users get added into the system(s) will be job number one for the project.
Friday, November 21, 2008
A few more random identity managment thoughts
Just wanted to say a quick thank you to Ash for the workshop on Monday... And add a few other thoughts:
Ash's Identity Management Rantings: It's About the Business...
Ash's Identity Management Rantings: It's About the Business...
- "Identity management" as a goal in and of itself doesn't mean a lot. Concrete business requirements are necessary in order to have a project succeed.
- It doesn't matter what you do on the back-end -- if the end users (and project sponsors) can't see tangible results that affect their day-to-day activities, all the process re-engineering and data clean-up in the world is going to go unnoticed and unappreciated.
- For whatever reason, hearing the exact same thing come from an outside consultant actually sinks in with management, but this never seems to happen for internal people :)
Thursday, November 20, 2008
The beginning
Hi! Glad you stopped by...
A little about me: I have been designing and supporting identity management infrastructures long before there was a fancy name for them (like "identity management infrastructures"...) This includes directory servers, Web access management systems, as well as the rest of the software stack that goes along with that (web servers, Java app servers, etc). Currently, I work at the University of Rochester, where I am part of the team that will be developing the identity management strategy here, and implementing all the supporting technology.
"Identity Management Lessons" seemed like an appropriate title for the site, seeing as this current project will be taking place at a university. The articles will be focused on the overall process we're undertaking, the problems encountered (and hopefully some solutions to go along with them), unique concerns of rolling out identity management at a university and medical center, and general thoughts about the various technologies involved.
A little about me: I have been designing and supporting identity management infrastructures long before there was a fancy name for them (like "identity management infrastructures"...) This includes directory servers, Web access management systems, as well as the rest of the software stack that goes along with that (web servers, Java app servers, etc). Currently, I work at the University of Rochester, where I am part of the team that will be developing the identity management strategy here, and implementing all the supporting technology.
"Identity Management Lessons" seemed like an appropriate title for the site, seeing as this current project will be taking place at a university. The articles will be focused on the overall process we're undertaking, the problems encountered (and hopefully some solutions to go along with them), unique concerns of rolling out identity management at a university and medical center, and general thoughts about the various technologies involved.
Subscribe to:
Posts (Atom)