In this post I discussed some ways to simplify an MIIS/ILM installation, with a view to making it more efficient and easier to troubleshoot and maintain. I have a few more points for the list.
A Recap
So far on my list I had:
- Use MVRouter to separate provisioning for different MAs.
- A simple, and consistent, outline for the provisioning code.
- Shift data generation away from advanced attribute flows and into SQL.
- Remove complex join rules.
And now some more…
5. Minimise Metaverse Object Types
Organisations will commonly have different types of people – users, perhaps split into internal and external, customers, contractors… It may initially seem to be a good idea to create different metaverse object types for each one. Sometimes there are good and unavoidable reasons for using seperate metaverse object types, but I maintain that in the majority of cases it is better to call them all person, and then use their attributes to differentiate between them.
Newbie clarification: Just because they’re all one object type in the metaverse does not mean they have to be the the same object type in the connected directories. There is no problem with, for example, creating some as users and some as contacts, depending on their attributes.
There are all sorts of advantages to this approach:
- Metaverse searches are simpler (and remember, “simpler” means “easier to explain to other people so they can find what they need themselves and quit bugging you”).
- You can move more quickly when a new application comes along that needs a different combination of person types, perhaps even everyone in the system – one object type means one provisioning instruction and one set of flow rules.
- If there is any possibility of people switching from one type to another it will be very straight forward, with no need to delete and recreate objects.
6. Match Metaverse Attribute Names to CDS Attribute Names
When I first started with MIIS, it took me a while to figure out that it’s ok to delete the default metaverse attributes. Now I will habitually try to name metaverse attributes to match their primary source or primary destination attribute. A flow rule like this: staffnum -> staffnum -> employeeid is easier to remember than staffnum -> uid -> employeeid Once you have hundreds of flows like this you will be glad you went for some level of consistency (and so will the person who has to pick through the system after you’ve moved on).
7. Don’t use the default advanced flow rule names
I hate the default rule names and I always change them. The convention I use is “import_” or “export_” followed by the name of the attribute at the end of that import or export flow. import_displayName export_proxyAddresses These names are much easier to remember and to pick out in your code. It’s also pretty obvious what they’re for, and I like obvious!
8. Be consistent with your Run Profile names
I must admit it kind of bugs me when I see one MA with “Full Import and Full Syncchronization”, while another has “Full Imp/Full sync” and a third has “FIFS”. I don’t care what names you use – just make them the same across all MAs! Again it’s easier for others to understand, easier for you to remember, and much easier when automating your run profiles with scripts or using my ILM Scheduler service.
Always Keep It Simple, Stupid
That should really be my Rule Number One, but I’m still short one here. Once I think of something else I’ll make this list into a proper top ten.
