Data In Action

Service components in this zone are simply tasked with acting on data that exists within the Data at Rest repository to implement federated workflow and other processing.

Data presentation

Data in Action components expose a Web API so that they can be called by internal or external applications or services.

The API requires the InstanceGUID of the record that will be the target of the action.

The API also requires security tokens for each request to authenticate the requesting user.

Note that internal or external applications or services are never granted direct access to the Data at Rest components.

Typically, the Data in Action components are implemented as micro-services and may be constructed using many of the standard Domain Driven Design (DDD) principles.

Consider again our Insurance Policy example: we might want to provide a micro-service that enables “Policy Rating”. Our standard DDD approach is to define a Policy concept strictly in terms of the requirements for Policy Rating. Our business may need to use Policy data in other micro-services such as: Claims Management, Renewal, Accounts, Risk Assessment, etc. In each of these cases the definition of Policy would be slightly different, and each micro-service would store its own representation of Policy. Each micro-service would have to implement its own security model to protect its internal data and synchronise its Policy store with the other micro-services. There are several approaches to data synchronisation, but they can negatively impact performance, increase solution complexity and fragility.

A simpler solution is to adopt the DaaS approach where the Policy records would be converted to XML and stored in the Data at Rest service instead of the Policy Rating service. Each micro-service could add the XML fields it needs to the Policy record, they could also share the “common” fields that would be required by most (if not all) services – for example: Policy Number, Effective Start and End Dates, Policy Type, etc.

The advantages of storing the Policy data once in a centralised System of Record include:

  • There is only one copy of the Policy data with CRUD+ functionality
  • The latest version of the Policy data is always available to all micro-services in real-time
  • Policy data does not have to be copied and cached across multiple micro-services creating consistency issues and service dependencies
  • Policy data can be secured with a single authorisation/authentication model
  • We can still use DDD, the micro-service just maps the XML it retrieves from the DaaS into its own representation of a Policy and leaves the fields it doesn’t know/care about unchanged


The ability to add Data in Action components as micro-services using a hub and spoke model over the Data at Rest service enables us to take maximum advantage of both Domain Driven Design and the latest DevOps techniques.

We can create multiple smaller Data in Action micros-services than we might normally consider. Services that encompass a single (or small group of related) function(s) without creating multiple interdependencies and data synchronization issues. This significantly reduces the chances of cascading failure and creating performance bottlenecks - which improves solution resilience. Each Data in Action micro-service can be independently versioned, deployed and scaled. It is also easy to onboard a new resource – they don’t have to understand how all possible services work – they simply focus on the functionality they are developing.

What is Data as a Service?

at Rest

At rest within a persistent data storage medium

in Motion

When being shared with third parties or other internal solutions

in Action

In action when we want to perform some business logic on it


Presented as part of an omni-channel user experience