In the world of TIBCO BusinessWorks™ (BW) development, the concept of automation through integrating disparate systems is very familiar, with mature and advanced approaches such as EAI Patterns and SOA. Yet when it comes to the development processes for the integrations that we build, the typical level of automation is extremely low – or even non-existent – costing the business far more than most people recognise.
The goal of development automation (also known as ‘continuous delivery’) is to apply rigorous automation to the development process. This concept is well recognised for software development outside the BW world. Continuous Delivery – a book detailing techniques that are proven as successful in automating different aspects of the development process – won the 2011 Jolt award for ‘jolting’ the software industry with its significance.
It is widely acknowledged that development automation results in cost benefits; however, the true value to the business is often severely underestimated. Likewise, the true cost of poor development automation is seldom fully recognised.
In the typical BW development process, developers get the code from source control; set up their file aliases and anything else needed for that specific project; do the actual development; perform a little ad-hoc testing; and then send the changes back into source control
The progression of the BW code through the various environments typically involves creating the EAR file; drawing up the configuration for the environment and the deployment guide; waiting for a deployment window; doing the actual deployment; and then waiting for the testers to do the testing and provide the results.
Mapping these activities to a value stream provides an insight into where the process can be optimised.
With the length of the horizontal lines representing the elapsed time for each activity, we often find long periods of non-value-adding activities. The objective of development automation is to eliminate the non-value-adding activities and to reduce the duration of the value-adding activities.
This is how the value of development automation is typically calculated; however, there is further potential for optimisation and significant value that is not factored into this equation.
Activities with a high cost, such as manual testing, tend to be done in large batches. This is because the transaction cost of the activity (i.e. the cost of running a test cycle) dwarfs the holding cost (i.e. the cost of doing development on untested code). The combination of the transaction cost and the holding cost provides a total cost for a particular batch size and allows us to calculate an optimal batch size.
While the transaction cost of running a test cycle is often well recognised within an organisation, the holding cost – in terms of the benefits of smaller batch sizes (and, conversely, the cost of larger batch sizes) – is poorly understood. When a piece of code is developed that has a defect and it is tested straight away, the cost of fixing that defect is relatively small. If the code is instead held for a long period of time before being tested, the cost of fixing the defect is much higher. The developer has moved on to other tasks; if they are even available, the code is no longer fresh in their mind, resulting in the effort of re-familiarising themselves with the code before the defect can be fixed. Additionally, the developer has the work not only of fixing the original defect, but also of fixing all the code that has been built upon that defect. Indeed, it is not uncommon for long-held defects to require large sections of code to be rewritten.
When we reduce the transaction cost (e.g. reducing the cost of a test cycle through test automation), not only does the total cost come down, but also the bottom of the total cost curve shifts to the left, which allows further cost reductions through batch-size reduction.
Effective test automation has been successfully used to reduce the transaction cost of testing to almost zero, resulting in cost savings through batch-size reduction that are significantly more than the costs saved by the reduced transaction cost.
An optimised delivery process, along with reduced batch sizes, can significantly reduce the length of projects, which has the additional benefit of reducing the cost-of-delay. To understand cost-of-delay, we start with the value that the business expects to gain over the full lifetime of what the project will deliver. The value gained might be cost reduction, revenue generation or something else, but it is the basis of – and the justification for – the business case.
When the project is delayed, the value that will be realised is reduced and – because the reduced value is calculated over the full lifetime of what is being delivered – the cost-of-delay is usually significantly larger than appreciated.
Similarly, when a project is delivered early, the extra value gained is calculated over a full lifetime; the value of early delivery can be very significant. For instance, suppose that the cost-of-delay for a project is $200K/month and that development automation will reduce the project length by 25%. It follows that on a 12-month project, spending $100K on development automation will save the business $600K (netting $500K) on that project alone. Conversely, foregoing development automation for the project would cost the business $600K in missed value.
The benefits realised through reduced transaction costs, reduced batch sizes and reduced cost-of-delay compound – to provide massive value to the business. For teams that have no development automation, the benefits are too big to ignore.
For TIBCO BW teams, BWUnit provides a unique platform for development automation, which addresses the end-to-end value stream.
BWUnit moves development PC configuration into source control, allowing file aliases and TIBCO product paths to vary from project to project, but to remain consistent across developers. It automates the building of EAR and environment configuration files, and their deployment, which – when combined with advanced continuous-delivery, no-outage deployment techniques, such as blue-green deployments – eliminates the need to wait for deployment windows.
From a test-automation perspective, BWUnit covers the full testing strategy (not just end-to-end integration testing), including automation of unit tests, system tests, integration tests, Behaviour Driven Development (BDD)-style acceptance tests and load tests. BWUnit has also been designed to integrate with Continuous Integration servers such as Jenkins, so that test runs can be triggered automatically and notifications of test results sent as soon as they are available, removing the delays caused by waiting for these stages.
No other platform provides such a holistic approach to automating your BW development. Find out today how BWUnit can help you realise the value of development automation within your BW development team.