DataVault, DevOps and the Minimum Viable Product

One of the practices of DevOps is the Minimum Viable Product (MVP), a product with just enough features to create value for the business. This MVP is then improved in subsequent rapid releases,  delivering more value with every release.

So, in DataVault, what would be a Minimum Viable Product? Well, as you may know, DataVault uses three different types of artefacts: Hubs, Links and Satellites. A Hub contains a list of unique business keys, a Link contains the relations between Hubs and a Satellite stores detailed information about a business key (Hub Satellite) or a constellation of hubs (Link Satellite). A Link Satellite also stores measures.

So, let’s say we have a Date Hub (January, February etc), an Employee Hub (John, Peter),  a Link that stores the relation between the two Hubs, and a Link Satellite that stores the hours worked. With these artefacts we would be able to create the following report:

[table id=2 /]

A Minimum Viable DataVault is a Link and Link Satellite plus it’s surrounding Hubs and Satellites. This is enough to create a product (a report, in this case) that creates value for the business.

To improve the product we would then create subsequent releases, each with one more Link with its Link Satellite plus it’s surrounding Hubs and Satellites. This would allow the business users to create more – or more elaborate – reports with every release.

After a few releases there will be less need to add Hubs and Hub Satellites, because they were already added in an earlier release. So, the releases get smaller (eventually consisting of just a Link plus Link Satellite), giving the business user added value, while at the same time giving the developer more time to enhance the product wth BusinessVault artefacts or SuperNova views and perspectives.