You re going to be a software company. You re going to need DevOps. by John Michelsen, Chief Technology Officer, CA Technologies

Transcription

1 About the author John Michelsen is the chief technology officer of CA Technologies, responsible for technical leadership and innovation, further developing the company s technical community, and aligning its software strategy, architecture and partner relationships to deliver customer value. In 1999, John founded ITKO, and built LISA from the ground up to optimize today s heterogeneous, distributed application environments. The company was acquired by CA Technologies in Prior to ITKO, John led SaaS and E-commerce transformations for global enterprises at Trilogy and Agency.com. He also founded a boutique custom software firm that focused on distributed, mission-critical application development projects for customers like American Airlines, Citibank and Xerox. John earned degrees in business and computer science from Trinity University and Columbus University. He has authored a best practices book, Service Virtualization: Reality is Overrated. He has multiple patents and contributed to dozens of leading technical journals and publications on topics ranging from hierarchical database techniques and agile development to virtualization. You re going to be a software company. You re going to need DevOps. by John Michelsen, Chief Technology Officer, CA Technologies All of our customers face the challenge that they re becoming software companies. Citi s CEO, Michael Corbat, told 2014 s Mobile World Congress that his company 1 wasn t a bank anymore: we re a technology firm that has a banking license. That s what all our customers are going through. They know that their competitive edge depends on developing high quality software quickly and getting it to their customers in the form factor they want. If you re a bank, it doesn t matter how old your bank is, what your assets are, what your history is, how many tellers you have, or what your community of customers used to be like. The younger customers don t consider any of that. They want instant services and products on their phone or tablet, or they won t look at you. Banks are where that consumer action has hit hardest, but it s true everywhere. The next generation of automotive competition won t be on color or speed, but connectivity: how well you can do in your car, what you do in Starbucks or at home. Google doesn t want to build driverless cars because it likes cars. It wants you to use Gmail while you commute. Every company must think of itself as a software company, competing with other software companies, because it s true for your competitors, too. That means making software faster, better and more cheaply. You can t put users through the experience of buggy software. You can t take too long to fix stuff. You can t let it cost too much to deliver. All of these things will put you at a competitive disadvantage. It doesn t matter what you re selling. The challenge for everyone is this: to be a world-class software company. I ve learned something very interesting, which is common for all companies: no matter what their job is, they have to treat software delivery just like every other supply chain, refining and combining raw goods and services until they re suitable for consumption. Everything has to be integrated, and all the functions in a company have to work within that delivery system. That s as true for aviation or consumer goods as it is for companies that have always been software companies. Supply chain optimization is how modern industry works when it makes physical stuff. But before that became the norm, companies tried to optimize each component in the supply chain individually. They ended up with warehouses full of spare parts but no widgets to sell in shops. What had to happen was to integrate everything in the chain, taking each stage and plugging it into the next.

2 If you re making shoes, the buyers of the raw leather had to talk to the leather treatment works, who had to talk to the packers, who had to talk to the shippers. They had to get closer together. The way companies make software hasn t been like that. It s been largely suboptimal. Design development, testing, delivery-- they ve all been separate parts of the supply chain, all working in silos. You can make them work really well by themselves, but that s not good enough. They have to be brought closer together, integrated horizontally. Many IT organizations have been very focused on Agile software development, helping developers to create more code more quickly. But if the rest of the supply chain isn t optimized, software still won t be delivered faster. It ll be that warehouse of spare parts waiting for assembly, waiting for the delivery truck while the shelves in the shops stay bare. We have to force these parts to work together. That s what DevOps means, to any company. You can t buy DevOps. CA Technologies can t sell you DevOps. It s a concept. It doesn t come in a box. What we can do for you, and for the industry, is to be thought leaders on how to get DevOps right. We can deliver the capabilities that let our customers reach their goal of becoming world-class at software. What does it mean to have those capabilities? What capabilities we can deliver? Practitioners in each of the disciplines in software delivery -- the designers, developers, testers and administrators -- must start to think quite differently. Even if they have thought about optimizing their own silo, being better at developing or better at testing, they must think more. DevOps means thinking about the others. Let s take something that was once thought as good and now is bad. Take the tradition of the heroic ops guy. When the ops guy is really proud of himself for finding an issue at the eleventh hour - I protected the business by stopping this from going out - he s probably expecting a medal. Instead, he should be fired. If you stop a release, you re not doing your job. You ve failed. Your job is ensuring that stuff gets delivered. In order to encompass that goal, operations has to get closer to development, to prevent critical issues long before the eleventh hour. Validation for production has to take place during development, during coding. The ops guy used to shoot releases for not working. Now, he has to make sure it never happens. The challenge of DevOps is most obvious for the operations side, but there are challenges on the development side too. It used to be okay that developers furiously created a bunch of code and gave it to someone else to test. They threw it

3 over a wall and went home. However, today s code is built from many components, and without end-to-end visibility, you will be building disaster. Such blind development results in poor quality components that are only fully tested once the final product is assembled. Only then do you realize the components don t work. You identify bugs far too late, and the shelves stay empty while your code goes back over the wall to repeat the cycle. You can t run that way. Would Intel blame Dell for the poor quality of component manufacture? Would they ever give Dell a chip and ask if it works? Never in a million years. Intel makes sure their chips work before they re ever taken to a factory and plugged into a motherboard. Developers have to build effective components that work before they re assembled. Service virtualization is how you do this. You take your end environment, the place where your stuff has to work, and you virtualize it. You give virtual copies to everyone and say Test in there. If you have a test lab where the final assembled product is tested, virtualize that. Let everyone work in parallel, test in parallel, then you will have no surprises when you get to the real world. That takes us to the next area where DevOps changes the game: testing. The classic approach - and CA Technologies knows this, because we make software - is that most of the testing is done by people. That s wrong. It doesn t work that way in other industries. One way to make high quality cars would be to build them first without testing anything, and get all the bugs out on a 10,000 mile test drive. but no cars would ever get into the showroom. Each component in a car is known to work before it gets bolted in, because it s been tested when it was made. So we have to make engineering do the validation, and that testing has to be automated. When our quality engineers put their hands on keyboards, it s to build the automation that proves the system works. It s not to do the testing itself. We hear from our customers, and know from our own experience, that most development cycles are 70 percent testing. It doesn t matter if you completely optimize code creation, you re only going to see 30 percent improvement overall. You can t move the needle through DevOps without removing manual testing, without directly addressing that 70 percent. That means automation. You get more bang per buck by fixing the testing, especially if that testing is highly repetitive, which it often is. Generally, development is different every time you do it; testing is much the same. Automate where it matters. Such an approach to automation is fundamental to continuous delivery, which underpins DevOps. This automation has to work if you re going to be that worldclass software company. Continuous delivery means building the environment that supports your application code, and promoting changes across that environment as they re demanded. That needs all of the management technology that CA Technologies is already known for.

4 While application delivery is the center of the DevOps target, everything has to be a part of the philosophy. Security is terribly important. If you don t fully integrate security, you re being irresponsible. You can t automate your process, leave security to one side and think you won t increase your exposure. If you think: Hey, we have a security team over there. We ll hand them the complete product to test, will you get a safe product delivered on time? Of course not. Either you won t hit your cadence, or you ll ship unsafe code. Neither is good. Security has to be written in at development, and it has to be tested alongside everything else during development. Components must be secure. What can you leave out? Nothing. Mobile, cloud, mainframe, business management - our security and IT business management portfolio are essential to make DevOps happen. DevOps as a term is too limiting a factor. The idea has to extend to everything you do that involves software. Which is everything. Exclude nothing. That s why CA Technologies belongs in the center when customers start thinking about DevOps. It s a new philosophy that needs good tools. We have those tools and know how they can work for people. That s why CA Technologies belongs in the center when customers start thinking about DevOps. In part, we know because we ve been using them in new ways ourselves. Our internal IT group has been using DevOps principles with our own tools, and the results have been astonishing. We took one 12-hour deployment task and cut it down to nine minutes. We ve seen test times go from weeks to days, or even hours. None of this would be any good if it made bad products. However, in the vast majority of cases - over 90%, according to research sponsored by CA quality shoots up when you use these technologies. 2 The problem isn t that people won t test. It s that they can t test enough. There are always environmental and resource constraints. Take away the challenge of having to do repetitive testing, and a lot more testing gets done. Doing things the old way, if we make a big change to a product, it takes thousands of hours to rebuild, retest and redeploy. That s a huge drag on agility. None of that time is getting new ideas into action. It s stopping new ideas from getting out there. But we know from our customers that DevOps can take those thousands of hours down to a couple of days. One of my favorite customer stories illustrates how this works -- not just technically, but how it fits in with partnerships between different companies in this business. It showed us that we were on the right track. It s something we did for a major US telco backbone provider, who went to their main systems integrators, and said: Hey, we ve gone Agile but it s not working well. Our quarterly releases are coming out every five months, and with so few new features, the business won t take them. We can t move the needle. Fix it. When you ve got lots of development worked outsourced, the integrator tends to get the blame when things aren t working well. The SI needed a dramatic result,

5 knew we had had some success elsewhere with this sort of issue, and asked us to help. We can t sell by having massive account teams for each customer, so our MSPs (Managed Service Providers) are really important to us. They know when we ve got a good fit for someone. The customer had a component problem. Every one of their component builders was dependent on other component builders. Everyone was waiting on everyone else. Development was taking way too long and there was no reliable way to test until assembly. When the product was built, it was of poor quality. So, we put in the tools and the thinking to test during development, to automate, to remove all that interdependence. When we were through, the same teams working just as hard as before delivered releases 40 percent faster. Seventy percent of test time was reduced. Fifty percent more stories, new things the user could do that they couldn t before, were delivered. And it was all high quality. Component-based testing and automating the test function really delivered. The result was that the quarterly cadence was fulfilled, and then some. Planning got better. Goals got hit. Promises were kept, and the business learned it could rely on its software team to deliver. This is one of the reasons I m so excited to be here and working on this, working with everyone else in CA Technologies. It s not often you get to be a part of a huge transformation of an industry, becoming a part of a team making an enormous impact. It ll be felt throughout the entire world of software, and through that to the whole world of industry and enterprise. Software is rewriting business, and we re writing the software to do it. References 1 Keynote Speech, 2 TechInsights Research: What Smart Businesses Know About DevOps, conducted for CA Technologies by Vanson Bourne, 2013

6 Connect with CA Technologies at ca.com CA Technologies (NASDAQ: CA) helps customers succeed in a future where every business from apparel to energy is being rewritten by software. From planning to development to management to security, at CA we create software that fuels transformation for companies in the application economy. With CA software at the center of their IT strategy, organizations can leverage the technology that changes the way we live from the data center to the mobile device. Learn more about CA Technologies at CA. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. ITIL is a Registered Trade Mark of AXELOS Limited. The statements and opinions expressed in this document are those of the author(s) and are not necessarily those of CA. CA and the authors assume no responsibility for consequences resulting from the publication of or use of this document, and are not responsible for, and expressly disclaim liability for, damages of any kind.