What is Data as a Service (DaaS)?

The essence of the Data as a Service approach is to see data as a generic quantum of information where the data content is immaterial. That is, we do not care what type of data is being stored. It could be information about a Car, Customer, Person, Insurance Policy, etc. The storage of the data does not depend on the format of the information. We can achieve this by simply storing the information in a neutral format such as XML or JSON.

The next step is to enable the storage of information to be independent of its usage within an application or service. This means that data should be stored in a single System of Record (SOR) within centralised location and not be distributed or duplicated within multiple applications or services. All applications and services access the same data repository which exposes the latest version of the data. This will prevent issues with performance, synchronisation and eventual consistency.

Data as a service

We can then develop a set of services that handle data within four distinct zones:

  • At rest within a persistent data storage medium.
  • In motion between data stores (for example when being shared with third parties or other internal solutions).
  • In action when we want to perform some business logic on it.
  • Presentation as part of an omni-channel user experience.

Separation of Concerns

In the DaaS model we enforce a strict separation of concerns between the services we create. Each service exists totally within one of the zones.

So, a service in the “Data Presentation” zone strictly controls the user interface. If data needs to be persisted it calls a “Data at Rest” service to do that. If data needs to be acted on by some form of workflow it uses a “Data in Action” service to do that.

We never mix functionality within a single service – so there isn’t a case where there is software within a form that is writing data directly to a database or attaching business logic to the code behind a button.

This allows us to produce simpler services with clearly defined interfaces that hide the internal implementation of their functionality. We can modify how each service works independently of all other components. For example, we could completely replace our data storage service without impacting any of our data presentation services. This reduces the complexity of the overall business solution, makes it easier to sustain, and enables services to be reused in multiple solutions.

Security Boundaries

As data crosses any of the red lines in the diagram, it is crossing a well-defined security boundary protected by firewalls and other appropriate intrusion detection devices. We can also apply appropriate technology within each zone to prevent the spread of malware or viruses.

As data crosses a zone boundary we can audit the transfer by timestamping it and tagging it with the credentials of the user to validate their access to the data. This enables us to track trends and isolate suspicious or anomalous activity.

Our security boundaries allow us to create a defense in depth utilizing different technologies to secure different data services. We can add monitoring, threat detection and alerting within each data zone to initiate a rapid response to any security incident so that we can isolate, and shutdown impacted services.

Inherently Sustainable

In an ideal world, we want to leave business solutions better than we found them. We need to focus on creating sustainable software that will be simple for the next set of developers to be able to evolve and extend as business needs change.

To create a sustainable solution, we should be starting with the development of a sustainable architecture. This architecture needs to be well documented, understood, and enforced by all our team members. If we need to go outside the architecture because we absolutely need some new technology, then we should be extending our architecture to include the new technology in a way that complements and enhances our existing solution components.

As we build new components and services we should be considering their full life-cycle which includes how they will ultimately be retired and replaced. We should be making it easy for the next set of developers to understand, maintain, or replace any component within the solution without running the risk of bringing the whole solution down.

The DaaS approach naturally lends itself to the development of sustainable solutions. By maintaining a strong separation of concerns, we are going to be creating small services with well-defined interfaces that hides the inner workings of the service.

By abstracting the Data at Rest into its own services we are minimizing the issues normally associated with the creation of data silos within applications and services. This means that any service can always get immediate access to the latest version of any data it needs - if the user has appropriate permissions.

This means that the services in the other zones (Data in Action, Data in Motion, and Data Presentation) can be smaller in scope since the security and synchronisation is dealt with inside the Data at Rest service. For example, if we need to build to add new functionality to an existing solution we can encapsulate that functionality into it own separately versioned and deployable service. This new service would be totally isolated from existing services and would be compartmentalised within its own security boundary.

What is Data as a Service?

Data
at Rest

At rest within a persistent data storage medium

Data
in Motion

When being shared with third parties or other internal solutions

Data
in Action

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

Data
Presentation

Presented as part of an omni-channel user experience