Time-to-value is often mentioned with great emphasis in marketing brochures, but rarely explained in detail. Perhaps the marketing mavens believe that the idea explains itself. After all, buying a product or service and being able to use it immediately – a time-to-value of zero – is instant gratification.
However, time to value is usually somewhat greater than zero. Here’s a simple example. You buy a cabinet from IKEA to put your china in. You need to get it home and assemble it. Perhaps it will take half a day to complete that and dispose of the packaging. Or perhaps you’ll get the assembly wrong (it happens) and you’ll have to hire some help to sort it out. So the time to value could be a day or more, but that’s still fairly fast.
There are other kinds of purchases. Think now of buying seeds to grow some herbs in your herb garden. You can plant the seeds in soil and water them very quickly, but if the your value is only realized in the fully grown parsley and sage plants and the time to value will be measured in months.
With software you have a similar range of possibilities. If you sign up for a SaaS application you are expecting swift gratification. There will be some configuration effort and data loading required before the application is happily plodding along and providing value. It will be reasonably fast. If, in contrast, you buy development software and database technology to build an application, then it may be many months before any application is ready to run. Development software is more akin to buying seeds than buying IKEA furniture.
A sensible question is this: What is the value of achieving faster time to value?
There are financial formulae that can be applied. In simple terms, if an application saves the business $10,000 per month and you can implement it a month earlier, the business gains $10,000. It is likely to be more complicated to calculate than that, of course, because the savings may escalate or tail off and there’s also the cost of money (interest) to take into account. Nevertheless if you can accurately estimate the value of an application and when it will be realized, you can use discounted cash flow formulae to get a precise estimate. The important point is that when savings (or profits) from implementing an application arrive sooner, there is a significant financial win.
It is rare for any business to buy development or database software for the sake of building a single application. More likely the business will build a series of applications over many years. If the fastest software is chosen, there will be multiple occurrences of reduced development time. That choice will translate directly into financial gain and the cost of the software will be repaid many times over. But that isn’t the full picture. Time to value isn’t just a factor in delivering new applications, it’s also a factor in any changes that are made to a system.
Database and Time To Value
So to expand our discussion, let us consider time to value in respect of database. Databases are ready-to-run software, so, given a little bit of configuration and data loading work, the time to value is fairly swift. All databases can claim to be that way. However, those that offer greater functionality can claim some superiority in this, if the functionality they offer saves development and deployment time.
Some database features, such as ACID compliance, support for SQL and replication in some form were once a given, but the NoSQL database movement drove a stake through that. There are some use cases where the compromises they made didn’t matter and in the main users of these database products tended to be chosen for those. Such products can delay time to value simply because of the developer’s learning curve. The NoSQL database’s approach to data access may take a while to adjust to and learn. Love it or loathe it, SQL is well understood by almost all developers.
Among databases there is considerable feature variance, even between relational databases and this may impact time to value. Some databases have a significant overhead in respect of database administration, usually because of the need for performance tuning – partitioning, adding indexes and so on. Products that are largely self-tuning have a cost advantage here, and it can be argued, improve time to value by that alone, although the more significant cost involved is likely to be the cost of the DBA or, alternatively, the business cost of poor database performance.
Some practically useful database features improve time to value simply because you do not have to spend time building the capability that is missing or designing around it. A particular case in point here is distributed capability. When a database is particularly proficient at replication, it is usually easy to configure for high availability and disaster recovery. Distributed capabilities vary considerably between products.
Ideally a database will be able to replicate wholly or partially between instances, and do so reliably. This is a particular area where quality matters and product weakness is costly both in development and in production. Extremely good replication capabilities translate into true database migration capabilities, particularly when migrating applications into the cloud, which is usually done to reduce cost. More importantly, in my view, is where databases need to be kept in step across multiple locations – as often happens with organizations that are themselves geographically distributed, such as international banks of large retail operations.
Where such capability is a requirement and the database has not been built for such deployments, it will inevitably take longer to build the applications and, worse than that they are likely to involve awkward compromises in how they can be used.
When we consider time to value, we most likely think of agile development and productive development environments, and so we should, but the choice of which database to use is definitely part of the mix.