Core Services Core Services is basically data services. Typically they evolve to become the master repository for the most important business objects in the enterprise. Typical examples are Customer and Product. You will also find that it often makes sense to split a service for a domain object into a CRUD (master) service and a accompanying Query Service to keep the complexity to a manageable level, and to allow a more feature rich query interface.
Data access services
Domain object repositories
SOA as an integration strategy
Single repository of domain objects
Decoupling the client from persistence technology and strategy
Focused on getting an agile architecture to support both the complexity in today's deliverance and infrastructure, and also to build a platform that will give faster time-to-market than the competitors. Central in this architecture lays the concept of Master strategy. Per today the following central domain objects have been planned implemented using the master-service-strategy:
CustomerMaster (including customer relation an contact persons)
ProductMaster (including mastering of instantiated products/services towards ordering and delivery track)
ServiceMaster (both CustomerFacing and ResourceFacing - technical building blocks that connects product to resource/provisioning)
ResourceMaster (management and control on all components in the infrastructure that there will be an shortage off/expense to scale further)
The Master strategy works like this: A Master-Service is established and made available for all systems in our enterprise
The Master-Service has the responsibility to collect and aggregate master-domain-objects across the under laying systems
The Master-Service will master merging of elements in e.g. customer objects on the field level, based on a rule set of which changes are allowed in the different systems (a contact person with invoicing responsibility is 'owned' by the order system, and will not be updated by a mistake by the portal or the CRM system).
The Master-Service can be expanded with its own persistence/storing to make sure of optimal uptime, so SLA will not be impaired if one or several of the systems falls out.
The Master-Service will establish triggers in the different systems, and will there for detect by them self out-of-bounds updates and merge this by applying the same rule set as described above.
See EDR and EDR-MDS for more in-depth of the mastering strategies.