The Product Delivery Balancing Act

MVP vs Production 

Summary

Over the years – our engineers have seen the good, the bad and the ugly with previous employers when it comes to project delivery. One key factor in determining a ‘good’ outcome for projects, is the degree to which a solution is either under or over-engineered.

On the face of it, one might ask why not over-engineer everything as a belt and braces approach? This approach is typically taken by large Tier 1 firms for mission critical applications. Systems that need this approach typically include Payment and Settlement platforms, Risk Systems or Trading applications.

 

Examples of Software Resilience

Classically a database will need to be highly resilient and available in a mission critical application. In order to achieve this, the database team will use built-in database replication to maintain parallel systems in case one fails. Backups will be taken daily or weekly and incremental backups will also be performed. Companies such as Oracle provide an arsenal of tools and techniques in order to help you build a ‘Maximum Availability Architecture’. To provide scale out, some database vendors will facilitate clustering of servers to allow more users to be added over time.

 

Belt and Braces

At the same time, it is quite common to see the ‘Sysadmin’ teams undertaking a similar approach at the storage level. Many storage vendors offer similar levels of replication of data to standby systems should the primary fail. It can be described as ‘belt and braces’ and also ‘expensive’!

 

Cloud

Parallels can be drawn when deploying Cloud solutions to major cloud vendors such as Amazon, Google, Microsoft and Oracle.  All these platforms offer replication of data and ability to scale out compute and disc capacity. Software frameworks will need to know about these environments in order to gracefully ‘fail-over’ when required which will also require development and test cycles.

 

Future Proofing Applications

This approach then often extends into the fundamental application software design. Application frameworks are often developed by application developers to be highly extensible in order to ‘future proof’ for later project phases. Facilities are often introduced into the code base to allow scale out and resilience in the future. This future proofing often figures highly into the overall solution architecture. So why not do this all the time?

 

Burn Rate

The classic problem firms often face is the ‘burn rate’ in order to put all of the above in place. If it is a truly global production trading platform then there really is no choice. However if the real requirement is to be able to demonstrate to a VC who is considering funding Series A, then it can be beneficial to think further. It is interesting to note that many projects do not get past the first gate and never get to the stage where the upfront cost of re-use of earlier engineering, resilience and scale-out is utlisied.

Minimum Viable Product (MVP), Prototype or Full Scale Rollout?

Our guidance is to spend time in the project initiation phase thinking hard around a MoSCoW list ( Must have, Should Have, Could Have, Won’t Have – this time ). Most MVPs do not need to scale out to millions of users on day one, hence scale-out will fall into the ‘Won’t have – this time’ category. Client Origination, Client Onboarding, Transactional Capability, Mobile Client, Admin Screens probably all fall into the ‘Must Have’ capability.

Experience will tell which functional and non-functional requirements fall into which category in our MoSCoW list. At LDN Labs we place great focus on understanding the critical success factors, the business requirements and formulation of a MosCoW list. By judicial consideration of the MosCoW list, the ‘burn rate’ for developing an MVP can be optimised to deliver optimal business functionality

In some scenarios, rather than trying to build an MVP that can be scaled up to production, we have found it can be beneficial to re-engineer certain components for production.

Production Systems

Having said one should consider the cost of potential over-engineering, we have also worked with firms who have under-engineered production systems. More often than not this has been due to lack of experience rather than deliberate cutting of corners. Critically, the software design and development process becomes key. Quality Assurance, Peer Review of Code and signoff, multilevel authority for process and change control all take on greater importance. No matter how resilient or scalable an underlying architecture is, ultimately buggy and unmaintainable code is often the barrier to highly successful production deployment.

 

How LDN Labs Addresses Code Quality

At LDN Labs we maintain a mentor approach from day one for new hires. All staff are required to operate in a framework that supports development of small modules of easily testable code. Their code is peer reviewed and only deployed once it has passed all Q/A processes. Our test environment has been honed over several years using automated tests to ensure the highest possible quality of production code. Automation plays a big part of our test methodology and it has been an investment that has paid back many times.

 

In Summary

It can prove beneficial to invest time up front making conscious decisions regarding levels of engineering. Establishing a MosCow list early in the cycle helps to decide on a level of engineering appropriate to business needs. We have found the key for many MVPs or prototypes projects has been demonstration of transactional process flows. Users are able to register for a service, can be onboarded and perform real world transactions in ‘limited deployment’ Once this stage has been successfully achieved, focus can be moved to future proofing and adding addtional resilience.