Ideas are worth nothing, no matter how smart they might sound like. They are just theory (even if they are based on real-world practice). And we all know, that in theory there is no difference between theory and practice. While in practice such difference exists.
The crucial bridge between theory and practice is called execution. Good execution is the key element that can take a simple idea and turn it into profitable and inspiring business. Bad execution can easily ruin a brilliant idea and turn it into a pile of debts and bunch of burned out people.
Ideas expressed in this and following texts could be dangerous or reckless, if considered in isolation, without taking a closer look at the execution.
For instance, let's talk about rapid delivery at Lokad, where multiple releases to cloud per day are not an outstanding exception. For us it is a way to outrun competition, rapidly respond changing market or solve some unexpected problems. It is one of the reasons customers give us testimonials like this one:
Lokad improved the accuracy of our planning process significantly. The immediate impact was a stock reduction of almost 1 million EUR at a monthly cost of 150 EUR.
Thomas Bremont, Head of Supply Chain Bizline
This might sound like an impossible idea for people coming from enterprise background with highly formalized environment, predictable monthly milestones and precise technical specifications. In fact, this approach is barely applicable in their case (which strengthens our competitive advantage even further).
However, while thinking about reliability of these ideas, please consider their execution aspects at Lokad:
- we test complex behavioral code thoroughly with things like specifications that also serve as living documentation;
- even more complex forecasting code has a dedicated multi-machine cloud deployment and benchmarking infrastructure that continuously cross-tests changes in the code against large data library; this tracks performance of forecasting models and allows our brilliant analytics team to push state of the art in forecasting; they even have their own stack for Windows Azure;
- our master branch (in git source control repository) of integration systems is always close to being stable (large changes happen in separate branches); releases are tagged, backed up and deployed according to deployment protocol;
- core data is immutable and append-only (persisted as event sourcing streams for behavior-based entities) and hence it is inherently easy to back up or revert any changes;
- a lot of systems include sanity checks and self-diagnostic routines that help DevOps to detect any potential problems or edge cases; some even have self-recovery logic;
- most frequent changes in customer-facing systems deal with user experience, and UI is simple in DDD/CQRS systems, especially when changes to data structure behind UI are managed automatically by cloud servers;
- all of our new systems inherently support hybrid cloud deployments. Newest designs even support real-time replication of data based on event sourcing, since we must become more reliable and secure than any single cloud.
As you can see, we simply took brilliant ideas from Greg Young and other members of CQRS community and try to diligently execute them by applying lessons from companies like 37Signals, github and Twitter.
In the following articles I will try to address both aspects in parallel: ideas and execution.