How do you feel when you contemplate the idea of changing the way your organization operates? Scared? Jaded? Excited? Your answer—and the answers your employees give—to this question reveals how difficult it will be for you to pursue Digital Transformation and DevOps. This photo, ‘change machine,’ is copyright © 2009 tracyshaun and made available under a Creative Commons Attribution-ShareAlike 2.0 Generic License. ...
Your organization delivers software, so it should be obvious that improving your software delivery means improving your organization. But how to improve your software delivery organization? I’m going to tell you how, and you’ll be amazed at its simplicity: To improve an organization’s performance you need to improve all the components of the organization. And, you need to know how to improve each component. An organization is made of… An organization is composed of people, process, and artifacts. ...
Or, The Seven Habits of Highly Effective DevOps. You may have heard that the goal of DevOps is to rapidly deliver and reliably operate high quality software-based services. But that is only partially true. True, that is the desired result. But fostering the habits that produce that result consistently is integral to the goal. Habits foster results. The goal is both. In my work with clients I have found several cornerstone habits essential to creating DevOps results, and I have helped software organizations embrace these habits and earn the payoffs. Let’s explore the cornerstone DevOps habits and why these habits are as much a goal as the results they promote. ...
Like companies producing any kind of offering, software companies require three elements in order to successfully deliver: knowing what to build, knowing how to build it, and knowing how to deliver it to the customer. When each of these three functions - research, engineering, and delivery - does its job independently, you get slow progress and uninspired, sub-par products. But when all three functions work together in a customer-centric fashion, you get excellence - in implementation, innovation - in concept, and world-class results - by delivering those two to the customer. ...
Adrian Cole, author of the jClouds library, has an excellent writeup of the trajectory the library’s development followed as it added support for more cloud providers’ APIs. [Update August 2011: Blogger.com has removed Adrian’s blog so that link no longer works.] Some important takeaways for application developers: Your unit tests are as valuable as your code. The tests ensure the code works to spec, and they should be used as frequently as possible during development. Make your code easy to test, with sensible defaults that require no external dependencies: e.g. don’t require internet connectivity. Cloud limitations, both general (such as eventual consistency) and cloud-specific (such as a limit on the number of buckets per S3 account), will require careful consideration in your code (and tests). Some things can only really be tested against a live cloud service. As Adrian points out, the only way to test that an instance launched with the desired customizations is to ssh in to that instance and explore it from the inside. This is not testable using an offline stub emulator. But the key lesson developers can learn is: Whenever possible, use an existing library to interface with your clouds. As Adrian’s post makes patently clear, a lot of effort goes into ensuring the library works properly with the various supported APIs, and you can only benefit by leveraging those accomplishments. ...