I’ve been busy recently moving myself and family back to our native Australia (though “native” there is a dubious term for my kids who have both lived their entire lives in Europe). We’re in “the Nation’s capital” Canberra now, and very cold it is too (for those northern hemispherarians who seem to think July is summer universally, and there’s always snow at Christmas: not down here matey!)
In this post I want to announce that I’ve taken a position as FIM consultant with Unify Solutions, and also to link to a new article on the technet wiki written by my now-colleague Bob Bradley (aka UnifyBob): FIM data modelling and sync design: reference attributes vs. string attributes.
The basic message of this article is that it’s very often better to create a new object type, even though that’s not the immediately obvious thing. Bob uses the example of a person’s “Position” (or job), of which there may be more than one. I raised this point using another specific example in my post Why create a Delegation resource type in the FIM Portal. You could equally apply the notion to anything a person may have more than one of: think roles, applications, equipment… Or a potentially changeable thing that applies to multiple people: think office, cost center, manager.
The other thing that Bob demonstrates in his article is how you should work through your architecture choices before committing, looking particularly at how it will scale. I mentioned the importance of this just the other day, but it’s always helpful to see an example spelled out the way Bob has done.
The final point is that this approach will require extra data manipulation. Bob mentions Unify products which I’ll post about when I’ve learnt them properly. My usual approach would be to manipulate the data in SQL, generating the new object types and the references there. Extra upfront effort yes, but well worth it for the simpler and more scalable system you’ll get.
