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.