We’re pretty lucky these days to work and play with lots of cool stuff. In a consumer world of HD TVs, Mac books, iPhones, Droids, Angry Birds, Face books and tweets, life is rarely boring. Working in IT is the same. We’ve got clouds, NoSQL, agile, SOA, ria, pythons, scalas, rubies, and lots of ideas and technologies to play with every week. If only our friends and relatives outside of IT could figure out what the hell we’re all excited about, and the simple fact that most of us aren’t millionaires.
A few weeks back, I had a good discussion at Velocity Conf with a chap called John Willis. You might know him as “The DevOps” guy or the American version of “Patrick Debois” ;-). He’s basically a passionate IT thought leader whose mission is to bridge the divide between current Development and Operations teams (DevOps) so that IT collaborates as a team and delivers. The chat with John was no more than 15 minutes, but I came away with a completely different opinion of what DevOps stands for.
It’s very easy at the moment to talk about Agile Development and Cloud Computing in the same sentence. Doing so is what’s prompting the rumors that Dev will simply take over Ops as they automate and deploy their agile releases to the Cloud. In IT we all want to do things faster and cheaper, and there is a strong argument that Agile and Cloud computing lets you do that. However, when I asked John to define DevOps, his response was rather different to what I was expecting: “DevOps is about making your business more agile — it’s about going from ‘Ah-Ha’ to ‘Cha-Ching’ as fast as possible.”
His response was nothing to do with clouds, technology, deployment scripts, packaging, chefs, or puppets. It was simply about making the business more agile. So what does that mean exactly? Well, businesses exist to make money, and to make money you need to innovate and deliver ideas faster than your competition, so people will pay you instead of going to someone else. Moving from “Ah-Ha” (the idea) to “Cha-Ching” (cash in the till) in the least amount of time possible is what it’s all about. The business can come up with ideas, which IT will deliver using technology and agile methodology, but what happens after IT delivers? How do you measure the success of IT (DevOps) and the “Cha-Ching” factor? 101 Agile releases a week doesn’t automatically translate to $. You may write the sexiest code and the sexiest deployment automation — but if the business isn’t impacted in a positive way, your app is about as useless as a chocolate teapot.
IT collects metrics all day long on how well servers stay up or how many Sev 1 outages were reported and fixed. What IT needs is business metrics and context, so they know whether they have a positive or negative impact on the activity of the business with every deployment or change they make. Success, from a business standpoint, is about beating the competition to increase revenue and profitability; it’s not about Clouds, Agile, NoSQL or SOA. These things are simply enablers that allow IT to deliver value. If IT can report they are increasing the throughput and efficiency of key business transactions, that means they can directly tie their code, deployments and effort to business results. For example, if a new feature, service or code re-write in the app caused order volumes to spike upwards because it was easier or faster for users to submit orders, then IT needs to be congratulated.
Monitoring the business impact of deployments and change is key to IT understanding whether their agility is helping the business become more agile. To do this, IT needs to start monitoring the business activity (transactions) that flow across their infrastructure rather than the infrastructure itself. If the business knew that things like Clouds, NoSQL and sexy code directly impacted their bottom line, they might one day realize just how cool IT and our stuff is beneath the covers. Next time you write a line of code or deploy a release to production, think: “What impact will this have on the business?” You might be a deployment away from significantly improving your business might not even know it. At LinkedIn developers are encouraged to instrument their code in production to find out the impact they’re having on the business; this is just an example of one small step IT can take to understanding their impact on the business.
At AppDynamics business transactions are core to what we monitor. We’re seeing a growing trend of customers moving away from legacy systems and application management so they can directly tie the performance of their code and deployments in production with the activity of the business. If you change a package, class, method or configuration file, you can see in seconds what impact this had on the business in production. Be aware, though, that this visibility works both ways; while positive impact makes you a rock star, negative impact means there is nowhere to hide.