Hi Dev,
Here is what we have done:
1. First prerequisite: Come up with the "<b>sample</b>" business data model that you want to prototype. I used the word sample because the model does not have to be your organization's complete business model. But it should contain all representative objects so that you can build look up tables, main table with fields of all "<u>field types</u>", taxonomy, qualified look up tables etc.
2. Second prerequisite: Come up the sample data that you want to load for all the objects that you have in mind.
3. Third execute in a logical flow:
a) Build the repository- manual if your model is a custom model.
If not you can use the out of the box, and customize as needed.
Assign display fields, unique fields, writable once, search tab, calculated expressions, etc.
b) Try out <b>centra data management scenarios</b>- data entry through data manager, write validation expressions to validate the data; assignment expressions; add workflow, and approvals; search and sort of the data; test unique fields, writable once, calculation expressions, required fields, etc;
c) Then, ETL: use different types of source files; import using import manager into all table types; then try out import server; workflow job activation on import. If your repository is out of the box, you will probably start with out of the box maps.
d) Syndicator: extract data into all types of output files; use syndications that use merge feature, delta syndications, syndications with filter on qualified links; syndication of expressions, and finally syndication server.
e) You can go back to data manager, and try out match, and merge strategies & rules; savable searches; free form search and simple search combinations, etc.
f) If you are interested in iviews, build some, one on each table type. If you have 2 repositories that have related information (such as one for master data, and one for exceptions), try cross repository iviews;
g) Now is the time to learn the console admin ops such as archive (manual and scheduled), unarchive, check, repair, master-slave, duplicate, schema transport, delete, update, etc.
h) Define security using the Admin section of your repository in the console, and use data manager to test the security. Establish change tracking, and see how it works.
At this point you have a got a very good idea of how MDM nuts and bolts work.
Hope this helps. This is what I have done in April 2005, and by end of a good 4-6 weeks, I felt extremely comfortable speaking about the technology. You can do it in half the duration if you are focussed on just the prototype.
Savi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.