Thursday January 18, 2007
Thursday January 18, 2007 Questions keep arising around Sun's Identity Manager's MetaViews. Thought a brief attempt at an explaination might help.
As a workflow engine, IdM's raison d'etre is to collect and manipulate attributes about users and their accounts through the IT infrastructure. FirstName and LastName attributes may be retrieved from the HR system, passed through a rule that manipulates the string to create a userid perhaps (Lastname + First two letters of first name), and then pushes that down a resource adapter as an attribute. Individual forms can then validate and further manipulate it during this process.
In the end of the project, you end up with a intricate tapestry of workflows and manipulations. Any change to the attribute logic/manipulation means you have to figure out where it is being used and what forms, rules and resources work with it. Gets sticky fast.
MetaViews flip this problem inside out to greatly simplify the building and maintenance of provisioning workflow logic. A "Meta View" of the user is logically created within the workflow as an object and each attribute is responsible for expressing itself. The meta view attribute knows where to gather its "inbound" user information (from HR perhaps) and how to manipulate the information (perhaps running the above mentioned rule). Then, every resource adapter that needs that information just maps to the meta view attribute.
This centralizes all of the information within the workflow into one location. Need to make a change? Only modify the metaview and all references to that attribute receive the update. Need to change an authoritative resource? In the old method, you would have to find all references to the resource attributes and logic and update them to reflect the shift in source. But in the meta view approach, all you have to do is repoint the attribute to the new resource. All other references stay the same.
Its a new concept and we realize it will take some time to get use to for designers and developers. In Sun IdM 6.X, the concept was introduced as an option. In IdM 7.X, it is a clear choice and encouraged by the administration screens. Logic would indicate in 8.X, it will continue its move to center stage.
So review the documentation on Meta View and at least get the concepts down. Perhaps buid some simple logic using the approach; it will take some getting use to. If you are just starting out on an IdM development project, give a serious look at perhaps going the meta view route for the project.
As a workflow engine, IdM's raison d'etre is to collect and manipulate attributes about users and their accounts through the IT infrastructure. FirstName and LastName attributes may be retrieved from the HR system, passed through a rule that manipulates the string to create a userid perhaps (Lastname + First two letters of first name), and then pushes that down a resource adapter as an attribute. Individual forms can then validate and further manipulate it during this process.
In the end of the project, you end up with a intricate tapestry of workflows and manipulations. Any change to the attribute logic/manipulation means you have to figure out where it is being used and what forms, rules and resources work with it. Gets sticky fast.
MetaViews flip this problem inside out to greatly simplify the building and maintenance of provisioning workflow logic. A "Meta View" of the user is logically created within the workflow as an object and each attribute is responsible for expressing itself. The meta view attribute knows where to gather its "inbound" user information (from HR perhaps) and how to manipulate the information (perhaps running the above mentioned rule). Then, every resource adapter that needs that information just maps to the meta view attribute.
This centralizes all of the information within the workflow into one location. Need to make a change? Only modify the metaview and all references to that attribute receive the update. Need to change an authoritative resource? In the old method, you would have to find all references to the resource attributes and logic and update them to reflect the shift in source. But in the meta view approach, all you have to do is repoint the attribute to the new resource. All other references stay the same.
Its a new concept and we realize it will take some time to get use to for designers and developers. In Sun IdM 6.X, the concept was introduced as an option. In IdM 7.X, it is a clear choice and encouraged by the administration screens. Logic would indicate in 8.X, it will continue its move to center stage.
So review the documentation on Meta View and at least get the concepts down. Perhaps buid some simple logic using the approach; it will take some getting use to. If you are just starting out on an IdM development project, give a serious look at perhaps going the meta view route for the project.
Wednesday January 10, 2007 Happy New Year. Don't know about you, but its been busy and bloggin had to take a back seat for a while.
Start off the year with a reminder to be sure to balance you Identity Project between ROI type goals and compliance. Again and again we see projects that are started for compliance reasons and are soon in the weeds due to lack of funding.
Remember, compliance projects are expense projects. There is no direct add to the bottom line. Its a cost avoidance. Once the project spends its first wad of funding to get the system up and running, unless there is some ROI to the mix, funding will start to dry up as management tries to lower compliance costs using your system. Could even mean the project dies a slow, cruel death.
So, as a new year's resolution, work some password resets into the mix or user self service. This IdM utility cuts down on the administration support (more than you think; try our free ROI calculator). Even if you put in a simple "demo" version of these functions, it will give management the idea that there is money hidden within all that compliance spend.
Start off the year with a reminder to be sure to balance you Identity Project between ROI type goals and compliance. Again and again we see projects that are started for compliance reasons and are soon in the weeds due to lack of funding.
Remember, compliance projects are expense projects. There is no direct add to the bottom line. Its a cost avoidance. Once the project spends its first wad of funding to get the system up and running, unless there is some ROI to the mix, funding will start to dry up as management tries to lower compliance costs using your system. Could even mean the project dies a slow, cruel death.
So, as a new year's resolution, work some password resets into the mix or user self service. This IdM utility cuts down on the administration support (more than you think; try our free ROI calculator). Even if you put in a simple "demo" version of these functions, it will give management the idea that there is money hidden within all that compliance spend.