Agile software development practices have been transforming AD organizations for more than a decade. With more rapid development cycles has come a bottleneck at the deployment boundary - at the frontier between Development and Operations. The DevOps movement is working to remove this bottleneck, and in the process is transforming both Dev and Ops for the better. In many respects it is a logical evolution of the agile movement, but practices like continuous deployment are deeply transformative of the way that organizations think about customer engagement, business engagement, testing, development and requirements - in fact, nearly every aspect of agile development is subtly but powerfully affected. The implication of a check-in resulting in code being deployed to production gives a whole new emphasis to the word "commit"!
DevOps is a movement for developers and operations professionals that encourages more collaboration and release automation. Why? To keep up with the faster application delivery pace of Agile. In fact, with Agile, as development teams deliver faster and in shorter cycles, IT operations finds itself unprepared to keep up with the new pace. For operations teams, managing a continuous stream of software delivery with traditional manual-based processes is Mission Impossible. Vendors have responded to DevOps requirements with more automation in their release management, delivery, and deployment tools. However, there is a key process that sits between development and operations that seems to have been given little attention: testing.
In fact, some key testing activities, like integration testing and end-to-end performance testing, are caught right in the middle of the handover process between development and operations. In the Agile and Lean playbook, I’ve dedicated my latest research precisely to Agile testing, because I’ve seen testing as the black beast in many transformations to Agile because it was initially ignored.
As many of you know, Forrester conducted a joint research study earlier this year, in conjunction with the US chapter of the IT Service Management Forum (itSMF-USA). The report is finally now available to the deserving. Forrester clients can download it using the normal access methods. Members of itSMF-USA will receive their copy from itSMF-USA. If you contributed, but do not fall into either category, Forrester will be sending you your copy.
You can read a few of the finding in my original post announcing the completion of the study. An example of the findings is the level of satisfaction with service desk solutions. While satisfaction in general is higher than one would think, a SaaS model has proven especially satisfactory:
Please let me know if you are having difficulty obtaining your report. Thank you again for all the participation that led us to these findings! We look forward to next year’s study!
If you've been reading the research I've been writing over the past year, you know that I'm a fan of implementing an application life-cycle management strategy that focuses on increasing development flow and supports high-performance teams. You don't need to religiously implement all 22 CMMI processes or deliver dozens of intermediate development artifacts like some leading processes advocate. Rather, there are certain important processes that you should spend your time on. We wrote about change-aware continuous integration and just-in-time demand management in last year's Agile Development Management Tools Forrester Wave™. They are two of my favorite areas of focus, and they are great areas to invest in, but once you have them working well, there are other areas that will require your focus. In my opinion, the next process where you should focus on flow is everything that happens post build and preproduction. Most folks think about this process as release management or configuration management, but I think there's a better term that focuses on how quickly software changes move through both processes. It's called continuous delivery. When you focus on establishing a process of continuous delivery, you'll find that your capacity to release changes will increase, your null release cycle will shrink, and a larger proportion of the productivity gains you've seen from your Agile development efforts will flow through into production.
Forrester’s survey and inquiry research shows that, when it comes to cloud computing choices, our enterprise customers are more interested in infrastructure-as-a-service (IaaS) than platform-as-a-service (PaaS) despite the fact that PaaS is simpler to use. Well, this line is beginning to blur thanks to new offerings from Amazon Web Services LLC and upstart Standing Cloud.
The concern about PaaS lies around lock-in, as developers and infrastructure and operations professionals fear that by writing to the PaaS layer’s services their application will lose portability (this concern has long been a middleware concern — PaaS or otherwise). As a result, IaaS platforms that let you control the deployment model down to middleware, OS and VM resource choice are more open and portable. The tradeoff though, is that developer autonomy comes with a degree of complexity. As the below figure shows, there is a direct correlation between the degree of abstraction a cloud service provides and the skill set required by the customer. If your development skills are limited to scripting, web page design and form creation, most SaaS platforms provide the right abstraction for you to be productive. If you are a true coder with skills around Java, C# or other languages, PaaS offerings let you build more complex applications and integrations without you having to manage middleware, OS or infrastructure configuration. The PaaS services take care of this. IaaS, however, requires you to know this stuff. As a result, cloud services have an inverse pyramid of potential customers. Despite the fact that IaaS is more appealing to enterprise customers, it is the hardest to use.