Bij het uitwerken van de service register functionaliteit wordt gezocht naar een indeling die de toekomstige gebruikers ondersteunt en die een logische indeling heeft voor de diverse applicatie functies.

Canonieke modellen zijn reletief abstract ten opzichte van bijvoorbeeld webservice implementaties en fysieke database implementaties. Er is ook niet een fysieke (en primaire) implementatie van het canonieke model. Dat wordt concreet binnen de service en applicatie implementatie.

Toch neemt dit canonieke model een centrale plaats in binnen data architecturen, met name bij grote organisaties heeft een dergelijk data of domeininformatiemodel toegevoegde waarde. Tijdens diverse discussies en presentaties is een beeld ontstaan om een drie laags modelleermodel op te zetten. In onderstaande afbeelding een uitwerking

Het drielaagsmodel bestaat uit de volgende onderdelen:

• Dienstenmodel, modellering van de ontsluiting van het canonieke model op basis van diensten of services. Houdt er rekening mee dat dit webservices kunnen zijn maar dat is niet noodzakelijk
• Domeininformatiemodel, modellering van de gegevens entiteiten en hun onderlinge relaties binnen een bepaald domein of keten. Er kunnen dus afhankelijk van de situatie meerdere domeininformatiemodellen naast elkaar bestaan
• Fysiek datamodel, implementatie van het domeininformatiemodel binnen de applicaties. Dit hoeft geen een op een implementatie zijn. het domeinmodel kan binnen meerdere applicaties geimplementeerd worden en indien gewenst kan er getransformeerd worden van het generieke naar het applicatiespecifieke model

Deze drielaagsindeling wordt verder gebruikt bij de uitwerking van het service register. Er komt eventueel nog een vierde laag bij en dat betreft dan de documentatielaag of -kolom