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

Separation of Concerns

In the DaaS model a service is a distinct piece of functionality that acts on data. We enforce a strict separation of concerns between the services we create. Each service exists totally within one of the four DaaS zones shown above.

So, a service in the “Data Presentation” zone strictly controls the user interface. If data needs to be saved 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 services. For example, we could completely replace any of our data storage services without impacting any of our data presentation services that call them.

Because DaaS is data agnostic we can reuse our services in multiple solutions. For example, the service used to save a Car is the same as the service used to save a person, or Insurance Policy since the data is stored in a neutral format.

This reduces the complexity of the overall business solution making it easier to sustain.

Security Boundaries

As data crosses any of the blue lines in the diagram, it is crossing a well-defined security boundary protected by firewalls and other intrusion detection devices. We can also apply technology such as Virus and Anti-malware software 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.

Another advantage to the separation of concerns and security boundaries is that most of the common mistakes in legacy code that allow for things like injection attacks are blocked by DaaS. For example, if a service in the Data Presentation zone allows a user to try to enter an injection attack, it can’t access the data storage directly. It must instead call a Data at Rest service that protects the data storage.

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 and well-defined security boundaries, 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.

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.

Component Library

A key objective of the Data as a Service approach is to break the link between Functionality and Code. Ideally, we want to be able to create and deploy Functionality without writing any Code. To achieve this, we want to make sure that when we are forced to create code to implement some Functionality we maximise its reusability.

The first step is to break down the required Functionality into a set of reusable functions. This doesn’t mean writing functions that are generalised and offer many options through configuration or parameters, which leads to overly complex code. Trying to address future requirements that may never be needed wastes time and effort. We only want to focus attention on the problem that needs to be solved now. We might need to break a bigger problem down into small and reusable functional building blocks. We then code the building blocks from which we can implement the required Functionality with a view to being able to reuse and recompose those blocks later.

For example, consider a simple requirement to send an email to a user. The general problem is outbound communication – we could build a general service that can send emails, SMS, push notifications, etc. This would lead us to the conclusion that a general service should be possible and we could drive some general requirements to build and deploy it. At this point in time that general functionality is not required - we just need to be able to send an email! We don’t need to invest the extra time, effort and complexity to build something that we may never fully utilise.

The most efficient approach is to start by building a very simple function that just sends an email and integrate that into our solution. Job done – minimum cost and time to develop a simple and reusable building block that will allow any of our solution components to send an email.

At some future time, we may need to send an SMS, then we will create a building block that just sends an SMS and integrate that into our code.

Later, we may need to send a message to a person either by email or SMS depending upon preference. We will create a new building block that will check which is the preferred channel for the user and use either the email or SMS building block to send the message.

Small and simple building blocks should be our preferred development approach as it enables us to build the absolute minimum amount of code to implement the required Functionality quickly. Designing for reuse and re-composition means that we can later combine them in new ways to implement more complex Functionality without breaking or needing to re-implement earlier solutions.

For these building blocks to be fully leveraged we need to build a Component Library where developers can easily find them. The Component Library should hold all versions of all building blocks with clearly identified stable and developmental builds. It should be easy to search for existing building blocks that provide Functionality that has already been developed, tested and proven in production. Building blocks should be stored along with their associated documentation to make is easy for developers to understand their purpose, interfaces and implementation. That way they can be reused as is or enhanced to provide additional functionality. At the project management level, it should be a requirement that developers first search for and reuse an existing building block before creating their own.

What is Data as a Service?

at Rest

At rest within a persistent data storage medium


Presented as part of an omni-channel user experience

in Action

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

in Motion

When being shared with third parties or other internal solutions