The title of this post is in tribute to LANexpert, where I have been a consultant for the last four years. It’s been a great time but today I bid my LANexpert collegues a fond farewell before moving back home to Australia.
“Simplify Complexity” is LANexpert’s motto and I’ve always loved it. Overly-complex IT systems will not perform well on cost, stability or maintainability, so as IT professionals our mandate has been to architect systems that are clearly designed, follow best practises, and can be managed by the customer after we walk out the door.
It’s also a great motto to keep in mind when working with FIM, and here’s some reasons why.
It doesn’t work like you think it does
People come to FIM with all sorts of pre-conceived notions, the worst being “this should be pretty easy”. It’s hardly surprising really, considering that’s what the marketing says. But when you think about the number and variety of tasks FIM is called on to do, and all the site-specific peculiarities involved, it should be clear that the marketing is being distinctly optimistic.
The next thing to userstand is that the Sync Service and the Portal  operate in quite different ways:
- The Sync service is a “Steady state system”, which means that you should be able to synchronize the data in any order and it will end up the same, with no further changes until the source data changes.
- The Portal is object-oriented to it’s very core, meaning you’re often better off defining a new resource type than trying to bend existing ones. It’s also sequential and workflow based, meaning you have to think more about the process of making a change, and who requested it.
I’ve come across a lot of frustration from people starting to work with FIM, and also people who have an existing MIIS/ILM system, which lead me to believe that these basic concepts are often misunderstood.
The most obvious approach isn’t always be the right one
FIM is essentially a framework on which you build your own IdM solution. It is inherently flexible and extensible, and you’ll usually find there is more that one way to skin the proverbial cat. And it’s often the case that the immediately obvious way is just what you shouldn’t do.
I try to think through how my ideas will scale. Say I want to assign application licenses to users through the FIM Portal – what will happen when there are hundreds of applications to choose from? How will the data be kept up to date? How will it look to the users? The immediately obvious idea of adding extra checkboxes to the Person form might start to look a bit less workable.
An early redesign can save you a lot of trouble later on
There are two things you need to build a great FIM system:
- a lot of FIM knowledge, and
- a lot of site knowledge.
Clearly it’s nigh on impossible to find one person with both at the beginning of a project. But even when you partner a consultant with an internal IT person it can take some time for comprehension to filter through on both sides.
Every major MIIS/ILM/FIM project I’ve worked on has gone through a redesign after having gone into production, once real-world data starts flowing through, and it becomes clear that certain key decisions have become constraints. And it’s always been the right thing to do.
Play to the product’s strengths
There’s a great phrase: “if all you have is a hammer, every problem starts to look like a nail”. FIM is so extensible that I think some people get a little giddy with the power of it all. But just because you can do something with extension code, does that mean you should?
I’m a big fan of letting FIM do what it’s good at, and using other tools, like scripting and SSIS, where it’s not so great.
Let’s take the Sync Service. It’s really good at creating, updating and deleting individual objects. What it’s not good at is anything that involves looking at a bunch of objects at once – such as generating a group membership. So we do that bit outside the Sync Service – like in the Portal, or in a SQL table, or an LDAP – and then we just let the Sync Service do it’s fabulous sync’ing thing.
Business logic should be accessible
A common situation with MIIS/ILM is extension code that includes a great long list of if statements that looks at departments and job titles and countries and goodness knows what else to determine actions. I’ve never felt this to be a good idea and I try to stick to this ideal: If it’s liable to change, don’t put it in compiled code! Instead I’ll use SQL queries and XML lookup tables to bring all that logic and variable data out into a place where it can be modified.
With the FIM Portal we can now manage some of this in a graphical way. So if you have a Set of users who should be able to access a certain application, you can now change the definition of that Set and your rules should be applied. This is a great improvement but may not be right for all cases. Somehow I don’t think we’re quite done with XML and SSIS just yet…
Some other posts
I have blogged on this sort of topic before, and yes it was about MIIS, but if you’re working with FIM Sync then it all still applies:
Very nice article. I like the way you talk about playing to the product’s strength’s and trying to make things scale I couldn’t agree more. Good luck back home in Australia!