\u201cMove fast and break things\u201d with DevOps has become a popular Silicon Valley mantra during the past few years. DevOps empowers developers to quickly ship code and holds them accountable for operating their software. As DevOps becomes the new norm within Silicon Valley, enterprises outside the Valley have begun to look on with a mix of intrigue and terror.\nSome organizations have held to enforcing the ITIL (Information Technology Infrastructure Library) method of ITSM (IT service management) and shied away from using DevOps. These organizations maintain that the segregation of duties is a non-negotiable requirement for compliance, and developers should never be allowed to ship code directly to production.\nOther enterprises, such as Intuit, CSAA, NBCUniversal, Rally Software, and Family Search, have wholeheartedly embraced DevOps. These organizations found ways to smartly navigate compliance issues, and in the process, accelerated their development velocity, shortening the time needed to take ideas from whiteboard to customer implementation. These enterprises are now well on their way to becoming \u201cprogrammable enterprises.\u201d\u00a0\nThe programmable enterprise\nThe programmable enterprise deconstructs its systems into APIs and microservices. Once deconstructed, those APIs and micro-services can be quickly assembled into new business capabilities, such as a new web store that reuses internal services like customer lookup, billing; and leverages external services like card processing or shipping.\nWhen programmable organizations combine these with a culture of commercial intensity, they innovate faster, and more importantly, accelerate delivery of new value to their customers. The result is sustainable business differentiation when compared to enterprises holding to traditional IT service management.\nContinuous delivery\nBecoming a programmable enterprise allows organizations to continuously deliver new capabilities to the market. To the torch bearers of traditional IT service management, this sounds dangerous. It isn\u2019t. With continuous delivery, enterprises release code when it has passed all the checks rather than on an arbitrary date. Those checks ensure that there are no security exposures, that the services are resilient and that there is no risk to revenue or the brand.\nA continuous delivery process typically conducts the following:\n\nWhite box analysis\u00a0focuses on analyzing the source code for issues. Steps include:\n\nAdherence to coding standards, using tools like SonarCube to ensure there are no \u201cblocker\u201d defects. \u00a0In other words, scanning the source-code to ensure that developers aren\u2019t doing things that are obviously bad, like executing System.exit(0) in server-side code. The scan also ensures structural correctness, like appropriate level of comments and minimal cyclical complexity.\nStatic application security analysis that examines the source code for vulnerabilities, like SQL injection and cross-site scripting.\nAppropriate unit-test coverage and successful execution of those unit tests.\nDependency analysis, detecting and mapping upstream and downstream services. This can be used for both impact analysis as well as fine-tuned automated testing services that only run tests on components effected by a change.\u00a0\n\n\n\nBlack box analysis\u00a0focuses on running a service and testing it through external interfaces. Steps include:\n\nDynamic security testing that essentially auto-hacks the service.\nPerformance regression testing that can identify degradations in performance and scalability.\nInjecting failures for resilience testing, also known as \u201cChaos Monkey.\u201d\nAutomated user-acceptance testing that can identify regressions in business function.\nPortability analysis, essentially running and testing the service with alternative run-times to ensure there is no vendor lock-in.\n\n\n\nTriggered code-reviews\u00a0could be the last step in the process. In this step, the automation has filtered out most of the problems, but there is still a need for peer-review of the code. Some triggers include whether there are changes to a critical-path component or whether a developer checked in more code than expected.\n\n\nOperational readiness\u00a0becomes an inherent part of the process. IT and Security Operations teams monitor and react to the black box tests, including dynamic, application security and resiliency tests, to exercise the incident response and triage processes.\n\nContinuous delivery and architecture as code\nContinuous Delivery also enables organizations to \u201cshift left\u201d \u2013 to catch and remediate problems earlier in the software development life cycle, rather than waiting until the end of the release, or worse, in production. The more robust the continuous delivery process, the more trust the organization have in the quality of the code as it goes live. When combined with\u00a0\u201carchitecture as code\u201d\u00a0principles,\u00a0organizations trust in both the software and the underlying systems. As a result, those organizations can quickly and responsibly deliver new capabilities to market.\nFrom an application developer\u2019s perspective, this process must be frictionless. False positives, where the process identifies defects that are not issues, erode credibility and lead to organizational disillusionment.\nUltimately, the wing-to-wing experience from an application developer\u2019s perspective should be:\n\nThe app developer checks in code.\nThe code is automatically deployed into the build cloud, leveraging the development pattern within the Architecture-as-Code library, and run through a series of automated white box checks.\nIf the code fails the white box checks, the build fails, and the application developer is notified with details on what failed, and possible recommendations for how to remediate.\nIf the code passes the white box checks, it is automatically deployed into the test cloud, leveraging the QA \/ production pattern within the architecture-as-code library, where black box tests are executed.\nIf the code passes the black box checks, it is marked as ready for production, and in certain cases the code is automatically deployed into production. In other instances, the production deploy will require additional approvals.\nThroughout this entire process, data is collected and conveyed to the development managers via an analytics dashboard. This allows managers to have a better idea of developer performance and leads to better, more informed management. \u2028\nWhen combined with Architecture-as-Code principles, the only difference between test and production should be the user IDs, passwords, resource connections, and IP addresses.\n\nContinuous Delivery allows an organization to become a programmable enterprise, putting data at the fingertips of developers and decision makers, providing greater transparency into the development process and ensuring that IT teams can responsibly deliver new capabilities, at a high velocity, to the business. At this point, foregoing DevOps and continuous delivery for traditional IT service management, like ITIL, is more than a difference in philosophy -- it\u2019s a disservice to your business.