by Hans Bot
Continuous integration - the next step
Since the time Martin Fowler introduced the concept of Continuous Integration the software industry has come a long way. Originally, the concept aimed at the early detection of software integration problems, but soon it grew into one of the pillars of Agile Software Development movement. Development teams experiencing the power of daily builds soon grew accustomed to the practice. Other teams grew anxious to implement the practice too. In short: the software integration problem got solved in many different ways over the recent years.
More: Continuous Integration - Martin Fowler
The most elegant way in which it was solved is undoubtedly with Model Driven Engineering. Working jointly around a shared model banishes the integration problem altogether. In traditional development environments, the compilation of code by it's nature is a batch process. Eliminating the compilation as part of the development cycle therefor is a fundamental solution to the integration problem.
More: Model driven engineering - Johan den Haan
More recently, the thought leaders at ThoughtWorks upped the ante with the concept of Continuous Delivery. This seemingly small step has an important implication - it offers the client the option to be more closely involved into the development cycle. This is no small thing - the sooner mistakes and misinterpretations in the development efforts are caught, the cheaper it is to correct them. Again, with model driven engineering this practice is simple to organize.
More: Continuous delivery - Jez Humble
Now it may be the right time to go the extra mile. After all, Continuous Delivery is no goal in itself, it is a means to an end. In my opinion, at least, delivery is only the start of the dialogue with the client. And it is the outcome of the dialogue that is of the essence: a common understanding about the progress of the development effort. In other words, the objective to strive for should be full transparency into the development process. I propose to name this concept: "Continuous Consent".
How will Continuous Consent enhance the development process?
In my view, Continuous Delivery has already bridged the gap between the development team and their client. But this bridge is designed as a one-way road only. We simply need to add a lane for the traffic from the client to the developers to deliver them the feed-back necessary to further improve the process. Just imagine: delivery of instant feed-back as a standard functionality of the system under development. Report anomalies and requests from within the very system you are reviewing. Why not? What is the advantage of using a separate system? Why shouldn't we integrate that function in order to improve the mutual communication?
This is not the only improvement I envision. If we've got the dialogue running smoothly, it is a small step to use this radically change the way we develop. In my mind, this revolution is long overdue. The software development process is still mimicking the way buildings are constructed: we take a number of months or years to design, engineer and build until everything is ready. Then we "go live" - sometimes in a big bang, sometimes more gradually - after which we morph into the maintenance phase. Among other things, this brings the Continuous Delivery to an abrupt end.
With modern technology like model driven engineering, this need not be anymore. We can - and in my humble opinion should - change the process in a way that will closely align the system development with the way the business itself develops. I propose a mechanism in which an initial operational capability is delivered as early as possible in the development cycle. Ideally within weeks after the start. Simply because there is no better feed-back available than the one from practical usage. It will focus the efforts of the developers to the real needs of the user population and - maybe even more important - it will facilitate the ongoing continuation of the dialogue throughout the entire life cycle of the system. Sure, it will be necessary to rescale the development effort from time to time, but the Continuous Delivery should end no sooner than the end of life.
At Be Informed, we use the term "Grow Live" to pinpoint the phase of the system's life cycle after the Go Live of the initial operational capability. Grow Live together with Continuous Consent will someday revolutionize the system development process. Because we can - and because we should. The sooner, the better.
