Traditionally IT departments have had two primary purposes, the first was to ‘keep the lights on’ and the second was to provide capability to deliver technology changes. In this new era however these two purposes are morphing together where ‘keeping the lights on’ teams are needing to closely integrate with the teams managing the technology changes.
Cloud is deemed the agent of this new way and as such new delivery frameworks such as DevOps are quickly evolving to promote faster change through revolutionising the end to end delivery cycle.
A DevOps framework
The DevOps delivery framework is designed to assist organisations increase the cadence of IT change within the environment, firstly by identifying and reducing bottlenecks as well as reducing the size of deployments into smaller chunks. Adapting your delivery approach streamlines the processes and increases the flow of code travelling through the end-to-end delivery lifecycle. These improvements are achieved through the combination of; collaboration of people, convergence of processes and exploitation of tools all under pinned by the belief in trust.
Lee Raid’s blog The Simple Maths of DevOps, has defined a simple formula to suggest achievable time savings by adopting a DevOps approach. Conceptually, I think this is a great way of thinking about the potential benefits that can be achieved and well worth a read.
While DevOps is designed to improve flow over the end-to-end delivery process, this blog will isolate and discuss how ViFX approaches the Design and Build phases of the Software Delivery Life Cycle (SDLC) and explore how adopting DevOps thinking can reduce time to complete these phases, and therefore the entire project, while improving the quality of output.
Typically, successful IT projects require the understanding of the project’s business requirements, which are then used as inputs to the creation of the high level design (HLD). Once the HLD this has been reviewed, updated, reviewed again and approved a detailed design (DD) will be created that also needs to go through the review and sign off process before any development can start – only then can development start. The two identified bottle necks in this approach are firstly that it generally takes longer than planned to complete the HLD and DD stages, secondly the business requirements tend to get watered down to a point that the DD may not fully reflect the initial business intent. There has been a lot of talk about benefit realisation to help limit the second issue, but mapping the final business requirements to the detail design tends to add more time delays and costs to a project.
Once the design has been agreed the developers then crack on and cut the desired code for the full solution while unit testing components along the way. When the developer is satisfied with the results, they package the code and transport it over the fence to the next environment for further testing and validation. This is generally done in isolation without business review or feedback.
The new way
The DevOps approach looks to resolve identified bottlenecks by creating workable solutions to remove the constraints from the process. In our case the bottlenecks are identified as the protracted time spent creating the design and ensuring the solution is compliant to business requirements. The additional downstream bottleneck is that the business only gets to validate the design via the User Acceptance Testing phase near the end of the project.
An iterative approach of delivering projects is to containerise the Design and Build stages into a simplified process where the design is split into logical functions then designed and built by these groupings. The project team includes both business subject matter experts and IT solution designers working closely to create the desired outcomes. This collaborative approach allows the project team to design, build, and fully test the solution so it meets the agreed requirements within the development environment.
Key success criteria
The key inputs to this approach is having clearly defined business requirements, a collaborative project team and an agile mindset to deliver (this does not need to be pure Agile Project Methodology but the ability to work closely together to meet shared outcomes) and a tool that allows easy configuration. The output is a business solution that has been successfully tested against requirements and is ready to be moved through the remaining SDLC phases.
At ViFX Service Management, we support this approach as it aligns perfectly with the highly configurable Cherwell Service Management delivery model and allows the full benefits of a highly configurable tool to be realised. This approach dramatically decreases the time to value and in our experience enables a better outcome by empowering teams and delivering a better solution.
This streamlined approach takes away inefficiencies of the traditional model and improves the quality of the desired outcomes by validating business requirements sooner in the development lifecycle, allowing issues to be resolved sooner.
In what ways is your business adopting new, more agile approaches to project delivery? Let us know your thoughts in the comments section below.