Ambit Energy\nAmbit Energy, which provides gas and electricity to deregulated markets, was founded in 2006.\u00a0 At the time, John Burke, CIO and co-founder scoured the market for packaged software to run the business, but he didn\u2019t find what he was looking for, so he and his small team built their own.\n\u00a0\nThe 'Big Application'\nWhen the business started to take off, growing from zero to $325M in three years (today they are $1.5B), Burke saw that they were running almost all of the business \u2013 including billing, rating, customer care, and transaction management \u2013 on one huge, monolithic system.\n\u201cWe were growing and expanding into new markets and running the business on one centralized system,\u201d says Burke. \u201cBy 2009, it was painful to do deployments.\u201d As such, Burke and his team would plan one day a month for deployments. \u201cThe night team would start at midnight and go all night, and then the morning team would come in and repair what was wrong,\u201d he says. \u201cIt was hard to replicate a production environment in our test environment because the application was so big and complex.\u00a0 The process burned out the IT team and frustrated the business.\u201d\n\u00a0\nTime to Replace Waterfall Application Development\nBurke recognized that he had to replace the Waterfall development model his team had been using with something more agile. \u201cWaterfall was such a long pole,\u201d he says. \u201cWe would define some new functionality but by the time we deployed it, the business was no longer interested and had already moved on to the next thing.\u201d\nIt took a little convincing of both his development team and his business partners, but over the next eight months, Burke moved Ambit Energy to an Agile development model. In another major move, he reorganized his department to have nine dedicated software teams to align to the company\u2019s nine business units.\n\u201cAt first, everyone was very excited about what, to us, was a pretty radical organizational change,\u201d Burke says. \u201cThey said, \u2018This is great. The business line managers can go directly to their dedicated development teams and tell them what they want.\u2019 It was very empowering to them and they were motivated to make a lot of change.\u201d\nBut that excitement was short lived when the development teams realized that they had not solved the primary obstacle to driving rapid change. \u201cThe development teams were broken into business units, but we still had one large central system, so we were still doing late night pushes,\u201d Burke says. \u201cWe had a brief moment of excitement and empowerment, but then we realized that nothing changed. When it came to making system changes, we were in the same boat.\u201d\n\u00a0\nTaking a Page from Amazon\nAround that time, Burke\u2019s senior developers and architects were all talking about Silicon Valley and how Amazon, Netflix and Google were changing their development processes.\u00a0 \u201cPeople were talking about an edict that Jeff Bezos gave to his development team at Amazon when they hit their own \u2018big application\u2019 problem,\u201d Burke says. \u201cBezos told them, \u2018You need to take your own piece of the large application and rip it out from the rest.\u00a0 As long as you provide APIs to the large application, you can write your own piece in any language. But your little interfaces have to always be working.\u201d\nDespite the fact that Ambit Energy is in a century-old industry, Burke took notice of the Bezos edict.\u00a0 \u201cI held an open discussion with our development team about whether we could rip our application into smaller pieces,\u201d he says. \u201cThere was a small minority of sharp developers who thought it was possible, so we decided to give it a shot.\u201d\n\u00a0\nIntroducing Dev-Ops\nBurke and his team renamed the \u201cSoftware Configuration\u201d team \u201cDevOps\u201d, in part, to herald the directional change for the organization. \u00a0\u201cSoftware Configuration\u201d connoted a hurdle to get code into production, while \u201cDevOps\u201d meant automating and pushing quality code faster. \u201cOur DevOps people were not really DevOps people when we first renamed the team,\u201d says Burke. \u201cBut we had to move their mind-set from gatekeeping to facilitating. That was one of the hardest changes we had to make, to get them to see their role as facilitating rapid deployment in pushing code.\u201d\nThis meant that rather than write the code themselves, the developers now had to configure deployments that were so mathematically correct that they could be all done by scripts and automated software. \u201cThat kind of process really makes you think through all of the configurations on your system,\u201d says Burke.\nBurke identified a few key architects who believed in the automated continuous delivery model and coached them to bring the vision to the rest of the team.\u00a0 \u201cThrough the influence of these leaders, the people who had been terrified to automate development were starting to get excited about it.\u201d\nWhile Burke was reorganizing and appointing leadership, he still had this large application he had to split up, while the company was growing fast. \u201cWe didn\u2019t have an R&D department to figure this out while we performed our day jobs,\u201d Burke says. \u201cWe were all working on things that matter to the business, and at the same time, we had to figure out how to break one large system into nine smaller business-aligned systems.\u201d\nTo break down the application, the IT team had to figure out which automation toolsets to buy and how many extra servers they would need, but to Burke, that was the easy part.\u00a0 In addition to changing the mindset of the team, the other real challenge was getting buy-in from the business. \u201cIt was now 2011, and while the business had gotten excited about the nine dedicated development teams, they started to lose faith when we couldn\u2019t get any deployments out the door. We had to convince our business partners to take the chance and allow us to rip apart the application.\u201d\nIn the end, after a two-year initiative, Burke and his team did rip apart the application and are now in automated continuous delivery heaven.\u00a0 \u201cToday, we\u2019re doing roughly 34 deployments a day and we never see a hiccup. Our business teams are on fire because they come to work with a purpose and get things done.\u201d\n\u00a0\nBurke\u2019s Advice on the Conversion to Automated Continuous Delivery\n1. Prepare for heavier network volume: \u00a0\u201cYour path to segmented systems will most likely involve a service oriented architecture,\u201d Burke says. \u201cYour network traffic will quadruple because you are moving from strict database calls to multiple network calls. Especially if you manage your own infrastructure, you\u2019ll need to be prepared for some pretty serious volume.\u201d\n2. Identify and coach your leaders: \u00a0Burke identified a technical evangelist who was so obsessed with continuous delivery that he read about it all the time and practiced on the weekends. Burke gave him the leadership coaching he needed to bring the vision to the rest of the team. \u201cYou have to bring your developers and QA people into the discussion; you have to hear from the infrastructure people. If they are gatekeepers who don\u2019t like change, you\u2019ll have trouble getting them into the right mindset. You need an evangelist you can trust who can start demoing the model through prototypes and bring everyone along.\u201d\n3. Publically praise your MVPs: \u00a0\u201cThe magic happened when two teams \u201cgot it,\u201d says Burke. They were the first to start using the continuous deployment model and became our Most Valuable Players.\u00a0 Other developers saw what they are doing and said, \u201cLook at those guys; they are deploying during the day and nothing is disrupted! They are Amazon!\u201d\u00a0 Burke took that success and broadcasted it with congratulatory emails and public praise. \u00a0\u201cYou need to come really quickly with one or two wins. Then you market their successes and other teams will take notice. They\u2019ll realize how cool automated continuous delivery is and that they are a part of the next big thing.\u201d\n\u00a0\nAbout John Burke\nJohn is the CIO of Ambit Energy, and joined the company in May 2006. He has more than 15 years of leadership and consulting experience in the electric utilities, telecommunications, financial services, venture capital and software development industries. John earned an MBA in Information Systems from The University of Texas at Austin and a Bachelor of Arts in Economics from Rutgers University. He is a member of Phi Beta Kappa and has served as a representative on The University of Texas at Austin Graduate School\u2019s Information Management Steering Committee.\n\u00a0\nAbout Ambit Energy\nAmbit Energy was founded in 2006 by Jere Thompson, Jr. and Chris Chambless with the goal of providing cost-effective electricity and natural gas services in deregulated markets across the U.S. The services are primarily marketed by more than 250,000 independent consultants via a direct sales channel. Ambit Energy is continually recognized as one of the fastest-growing companies in the retail energy sector, exceeding more than 1 million active customers in 2012. The company is headquartered in Dallas, Texas.