Not too long ago I wrote a blog post (I.T. 2.0 – The Death of Design>Build>Run) that discussed the value to business of moving away from operational IT mindsets and towards a newer IT Paradigm. Although generally well received, I was not surprised to find that there were some who recoiled at the idea of shifting away from the traditional stability of operating under what has been an institution of IT Methodology.
As much as we may wish to avoid change, evolution refuses to give in. Even more difficult…the rapidly changing IT landscape drives the need for constant reexamination and does not afford the luxury of passivity. Embracing change is key to the IT supply framework’s potential for delivering value.
Cloud computing has driven an upheaval in the strategic IT landscape. Where IT once was considered a necessary cost of doing business now is positioned to take its place as more of a value center.
Transformation is a forward moving effort. Evolving the way IT is supplied to the business is not well served by framing change in based on past delivery styles. Agility will struggle if constrained by compartmentalizing efforts into phases like Design, Build and Run.
A major component of cloud methodology is achieving a level of automation that will free the development life cycle for applications from being hindered by provisioning and deployment operations. This is DevOps.
There are a number of incorrect opinions around exactly what DevOps is.
DevOps is not:
- A set of automation tools
- DEVelopment taking on the OPerational function
- OPerations taking responsibility for DEVeloping code
- Architects taking responsibility for code migration
DevOps is merely a culture shift that reduces cycle time by automating redundant orchestration activity.
- Architects still drive the blueprint for IT
- Developers still code
- Operations still execute and monitor
What was before considered “Design” now is focused on the blueprinting efforts of enterprise architects and conceptual efforts of application design teams.
“Build” becomes a development effort to code both their application functionality as well as the commands to provision their infrastructures, plus maintain repositories of reusable code reducing cycle times.
“Run” becomes the operational component that consumes the code by executing it and monitoring its level of successful operation.
IT shapes itself to promote an “Assemble-to-order” structure leveraging services and micro-services.
Another aspect of IT Transformation involves embracing a “Start-up” mentality. Over time, organizations tend to create monolithic icons of IT projects that are cumbersome to evolve as needed. Replacing large development efforts with smaller ones that can be combined to deliver more comprehensive functionality not only builds components that can be made available for reuse, but more importantly provides the ability to shift or pivot if priorities or business climate warrants. Additionally, it allows faster recovery from failure.
A “start-up” mentality takes the position that you only know what you know right now and need to ensure that you retain value when the unknowns of tomorrow present themselves.
Commitment to IT transformation is by nature diametrically opposed to traditional IT. Transformation cannot succeed by simply re-forming existing methodologies. With transformation comes risk of failure. Small failures lead to organic growth. Effectively managing scope during transformation will bring longer-term viability and success.