DigiTech Magazine - UK CIO2020 - Spring 2015 | Page 13

...................................................................................................................................................................................... TRAVELSPORTGAMES DEVELOPMENT RISKS REMOVED: 1. Less risk from incorrectly specified requirements In summary, we believe that: 2. Changing requirements are absorbed throughout the lifecycle By default IT should be ‘built to change’ not ‘built to last’. IT change needs to be delivered in small frequent increments and Professionalising IT in this way means we reduces business risk. 3. Design issues are uncovered early 4. Business engagement is far easier 5. Simple deployments as often as possible 6. Functionality released as business change demands The sourcing/contracting of development and operations needs to change. We are seeing lots of different models emerging. The thing I think most people are agreeing on is that the in-house capability needs to improve and where we do contract for services we need to stop trying outsource risk, it has to be shared. OPERATIONAL RISKS REMOVED: 1. Everything is automated and recorded 2. Nothing is built by hand during deployment 3. Everyone does the process every week, they know it well 4. Simple changes create smaller failures and take less time to undo Perception The fastest approach to find the ‘faster gear’ required is create a digital function and master this in one 20% Business ‘end-to-end’ value stream first. Business, operations and development have to be one team and we need IT to address the whole lifecycle from Procurement to Deployment. of change The biggest challenge however is the culture and silos 80% down the between teams. The Agile movement is breaking wall between the Business and Development areas, DevOps is breaking down the wall between Dev and Ops. Now we are seeing DevOps becoming DevOpsSec as organisations Change to keep Change to meet the add Security people to the product teams. We are seeing the lights on business need quite a few organisations insourcing Dev and Ops function at this point to remove Keeping the organisational boundaries Change and to keep pace with the basics contracts from lights the on product development teams. For more information speak to Ben: At North Highland we’ve run some really successful [email protected] collaboration workshops to break down theses barriers 30% a 20% 20% 30% thing is to create IT Effort and overall we’ve found the critical culture of trust across these areas of expertise. THE DIGITAL AGENDA Traditional If we take a look at the below diagram and reflect on the Iterative then sweat fact that we’ve Iterative had twenty years of a ‘refresh as long as possible’ culture with our IT. We need to think that if we are going to switch from ‘Build to last’ to ‘Build to change’ then transformational change is required at each Traditional vertex. If its not done in unison, the leading vertex is held Traditional TIME back by the trailing one. TIME Iterative TIME Brains of IT in-house Agile development Build to change IT FUNCTION Professional Dev Ops Ongoing management Continuous change Tolerate risk Simpler & shorter Low entry cost Build to change Speed Co-operation PROCUREMENT SUPPLIERS Agile development Continuous competition Open technologies CIO Magazine Spring 2015 Issue 13