improvements ( or they may not ), but they will not likely become high-performing IT shops . In many cases , I have seen companies form a DevOps team that becomes a new silo , just acting as a bridge between dev and ops instead of creating an environment of better collaboration between dev and ops . This is a classic anti-pattern that often results in lessthan-stellar outcomes .
Think Bigger than Software
I recently spent time studying 3D printing and digital manufacturing . What I discovered is that the agility and speed that I see the cloud and the DevOps approach bringing to the large enterprise and its software generation process is very similar to what 3D printing is bringing to product engineers . The parallels between what product engineering is trying to accomplish and what we are trying to accomplish in IT are amazingly similar .
In the old days , a person would design a CAD / CAM model that would be sent off to another group ( often outside of the company ) to produce a working prototype . In two to three weeks , the prototype team would send the first version of the prototype back for review . The reviewers would provide feedback and request additional changes . The prototype and the CAD / CAM design would be sent back for the next iteration . This process would repeat for months , until the product owner finally was finally satisfied that the prototype was in a state to move to the next phase of production .
With 3D printing , the goal is to get feedback faster in the product lifecycle and allow for more iterations in shorter time frames . That sounds very similar to what DevOps preaches . Faster feedback loops , incremental changes , smaller changesets .
The new process works like this : A designer creates a CAD / CAM design , which is fed directly to a 3D printer . The 3D printer creates a working prototype in a few hours , as opposed to weeks . The team can immediately review the prototype and continue iterating through this process until an acceptable prototype has been built . This entire process can be completed in days instead of months , and the total cost of the process is substantially lower .
This is exactly what we are trying to achieve with DevOps within IT . Increased agility , better collaboration , faster feedback , and better results .
Focus on Business Outcomes
In the 3D printing example , the business outcomes are many :
• Faster to market
• Better-quality product ( due to more iterations , more accurate models , faster feedback )
• Competitive advantage : better quality , lower price , new products get to market faster
• Improved customer satisfaction : ability to customize , better quality , shorter cycle times to deliver new products the client desires
Many of these business outcomes are exactly what a well executed DevOps strategy can yield . If we are able to iterate quickly with more “ working models ” in front of our customers , we can produce software that better meets the needs of our customers . Getting faster feedback earlier in the lifecycle should also improve the overall quality and improve speed to market . Automating infrastructure and pipelines plays a huge role in enabling this , but only if the automation is designed after understanding the optimal process .
DevOps should focus on driving improved business outcomes , not on technology . Technology is an enabler and automation is a key contributor to that enablement , but automation is not DevOps .
In fact , everything we do in IT should be based on delivering better business outcomes . When we lose sight of that , IT becomes nothing more than a cost center that is a necessary evil on the balance sheet . And when that happens , management looks at ways to outsource IT to lower the cost . When IT is a business enabler and a partner in the overall company ’ s success , IT becomes a revenue generator and a source of competitive advantage .
SUMMER 2016 | THE DOPPLER | 29