|
You can refer to preview on the architecture in metadata overview. This page carries more depth
Pure-form single physically integrated metadata repository
This pure form generally does not exist in real world, but it is useful to mention it. This is similar to having a single enterprise data warehouse without any stand-alone data marts. A single physically integrated repository will be taking the metadata directly from the source systems and not from other stand-along metadata repositories.
Though envisaged as nirvana few decades back, organizations have failed to create this kind of metadata model (just like having an all-inclusive single and enterprise level data warehouse has not seen many successful examples).
Physical integration of stand-alone metadata repositories and source systems
This architecture will be a metadata warehouse, which will draw metadata from – independent metadata repositories as well as from the source systems of metadata. This integrated repository will have the metadata from the feeding sources as well as also will contain the standards, taxonomies, ETL specs etc. which will be used in managing this metadata warehouse.
In this architecture, while the physical warehouse exists, the independent repositories will also continue to function and being used by the relevant interest groups.
Shared data Federated Metadata Architecture
In this architecture, you will only have the metadata of common interest in the central physical Metadata warehouse. The other data will physically exist only in the respective independent metadata repositories. Apart from the shared data, one will also have the standards, taxonomies, ETL specs etc. which will be used in managing this metadata warehouse. If you want to access the non-shared metadata, you will have virtual views, which can transparently fetch the data for you.
TIP- This is for the data which is existing in the source systems (like operational systems, data modeling tools.), and not in the feeding repositories. We would recommend not federating the source data. A better option is to get it physically into the central warehouse. This is assuming that none of your feeding repositories is picking this data. ExecutionMiH.com is cautious around the use of data federation for dynamic information systems environments.
Pure virtual federated Metadata architecture
This is just like the shared data federated architecture, with the difference that there is no shared data existing in the central ware house. There will be no warehouse, but a metadata repository management reference, which will contain the details on virtual views, mapping, taxonomies, standards etc. This is similar to the data federation concept in Business Intelligence.
Two-way metadata architecture
This is a new possibility which has emerged. Your architecture (if enabled by a tool), may have a capability by which a change done in the central metadata repository, will be updated back to the feeding repository. This concept is useful, but fragile and is needed to be handled with care:
TIP- Apply the two-way updation only on select metadata. Contextual and Conceptual level details are first quick-hits.
TIP- Ensure that there are enough audit trails on this two-way updation.
TIP- Give a prompt for choosing the source of precedence. This is similar to when you synchronize your hand-held with laptop. If both sides have done changes, the system prompts you to choose your preference on which change you want to accept.
|
