In any IT project we start with a requirements list. With IAM it can be hard to define just what a single “requirement” is – when a person creates an account, or adds a member to a group they think of that as “one action”. However when automating you need to break the action down into all its constituent parts, and you need specifics.
How often have we heard it: “We’d like to synchronise HR to AD” followed by an expectant air of “OK so now you know the requirement, off you go and do it”.
But what it really involved? For example just for provisioning we may have to:
- Import people’s details from a number of HR tables,
- Provision user accounts to variable OUs based on department or location,
- Create a mailbox in variable locations,
- Create home and profile folders in variable locations,
- Set up terminal services profile,
- Add a bunch of default groups,
- Send a notification email,
- …
And we haven’t even got to moves, changes and deprovisioning yet!
So you see how “one” requirement may actually be 20, 30 or more once you get down to the details. Without this level of detail you can neither estimate the workload nor have a hope of implementing what is actually required.
Oooh, oh, oh, don’t forget cleaning up existing data in systems and initial linking/joining. Huge task typically and you someone with knowledge of the infrastructure and organizational experience to help you sort out the discrepancies.
All of this – always a biggie in my projects…
I haven’t forgotten – just getting started here. Data cleaning is BP number 8, coming in a couple of weeks.