Is Your Software Stuck in Transit? Electric Cloud Aims to Fast-Track Release Cycles
Categories: R&D and Quality
Electric Cloud is a software developer in the DevOps space -- meaning, the company's technology automates and accelerates software application development and delivery.
Customers (build-test-release-deploy) process, enabling organizations to deliver their business-critical applications to market faster, with higher quality and improved infrastructure utilization.
Founded in 2002, Electric Cloud has 120 employees, and is based in Sunnyvale, Calif., with a development center in Fort Collins, Colo., and sales and marketing offices worldwide.
Venture funding has come from Mayfield, Rembrandt, and US Venture Partners. "We have chosen not to be profitable at this point," says marketing VP Kalyan Ramanathan. "We're investing in our business, and have not taken any additional investment money in the last four years."
The focus on growth over profit appears to be paying off: Recognized last year as a Deloitte Technology Fast 500 company and named to the Inc. 500 list, Electric Cloud has real momentum: Their growth rate nearly tripled during the period from 2006 to 2010.
We spoke with Ramanathan recently to get his advice for growing your software startup.
Tip #1: Software is what defines all companies, not just developers.
"The fundamental thing that we see in most enterprises is the realization is that software is what drives the enterprise," Ramanathan says. "It is the differentiator behind everything.
"We have customers like GE -- traditional companies -- that are realizing that software is what differentiates them in the marketplace. So, they're trying to find ways to deliver software in faster time frames and with higher quality.
"Instead of waiting for six months to get something out, many have adopted new development methodologies -- especially agile and scrum. It's all about getting something out there quickly, getting feedback, and improving on it.
"The rule of thumb right now is 40 percent of the projects that are out there today are built using agile methodologies. There's no new project that will be initiated today that doesn't follow agile. It is catching on very very rapidly on the development side."
Tip #2: Development is one thing; delivery is something else.
"But what these companies are fast realizing," says Ram, "is that I can write software faster, but the process of delivering that software is still a very arduous task.
"I have to do a set of things to make that software ready for the customer so that he can provide feedback. Build, test, release, deploy. The front end of their organization has gone to agile, and they have brought in various tools to improve that process, but the back end is still very cumbersome, is still very slow, and is still mostly manual.
"That is the bottleneck. Electric Cloud helps remove that bottleneck. We accelerate and automate that back-end process. Lastly, we provide visibility into the process: You can see where the applications are in the delivery process."
Tip #3: A small change in your code should not take months to deploy.
"We did a survey of our large marketing base, which includes tens of thousands of people," Ramanathan says. "and we got 730 responses.
"We asked about their development process. If you were to make a single line change in your software, how long would it take you to get the software to a customer? More than 75 percent said it would take from days to weeks. We're not talking about large chunks of code here; even a small change takes time.
"Another survey question asked, 'What portion of your software release slippages have to do with delivery?' The answer we got was that 50 percent of release slippages are driven by deployment and delivery challenges.
"The reason for this, the reason this is so hard to do, is that 60 percent of application deployments are very complex. There are many different environments, the applications are complex, and so on. In our survey, 65 percent told us they have little to no automation or optimization in their deployment."
Tip #4: What's getting you by today will get you swamped in the future.
"Sure, the software still gets released, but the way most companies do things is ad hoc and manual," says Ram. "They're throwing people at the problem, they're using unstructured bits of code, and gluing bits together.
"It may work OK for what they are doing today, but it's not going to work OK when 80 percent of the world's software is done in agile. We are looking at this tsunami of agile, and at a certain point, that's going to swamp companies that haven't automated their delivery processes."
Tip #5: Deployment automation is best left to specialists.
"Leave the automation to people who specialize in automation," Ramanathan says. "That is what many of our customers have discovered.
"They say, 'We cannot afford to throw people at this problem, and I would be better off having my people focus on what they know, and on building software that our customers want.
"In the same vein, why would you designate four of your people to create a license management system, when you could have those four people creating new software?
"One of our customers said, I had eight people managing the back end of our software delivery, but since I hired you guys, we've deployed seven of them to writing new code.'
"The ROI is pretty staggering. Equinix, one of our customers, has been able to significantly reduce the number of errors in their software. It used to be about 10 per release, but with automation, they've eliminated those errors.
"Another example is FamilySearch: In the past, when they went through build-test-deploy, it took them 30 days or more. Now they are able to go through the whole process in a few minutes.
"We have a large government contractor that does a lot work for the military, and they need visibility into the who-what-where-how-when of a software release. They used to spend weeks trying to collect this data, manually, going through various systems; now they know this in a matter of minutes.
"We can provide lower-end versions of the product, priced for workgroup environments. ElectricAccelerator is $100 per user per year. It's downloadable, and you can instantly see a five to 10X improvement in your build speed."
Tip #6: Figure out your tipping point.
OK, so why would a software company choose to not automate the build-test-deploy process?
"The predominant reason for refusal usually has to do with the maturity of the software organization," says Ram. "If they are not to the point that the complexities of the build-test-deploy process are holding back the company, they won't buy.
"Look, companies released software successfully long before Electric Cloud came into being. But at a certain point -- a tipping point -- the cost of inefficiencies start to cut into profits. The trick for us is to identify that tipping point.
"I will wager that with the rapid adoption of agile, every company under the sun needs to have some automation in place, whether it's from Electric Cloud or any of our competitors out there."
Tip #7: If you're shopping, use this checklist.
Assuming we're sold on the idea of automation, what should we look for among providers?
"First, I'd look at table stake capabilities," Ramanathan says, "In other words, the automation system should not come with an expectation that you're going to have to throw out everything you've done up to today. You want to bring in a system that lets you baseline the process, and iteratively improve from there.
"Second, you want a system that will work not only for today, but where you want to be tomorrow. It has to be able to scale with your future plans, even if you don't have those plans firmly in mind.
"Third, look for a system that doesn't preclude you from taking advantage of new emerging technologies. For example, the cloud. You want a solution that doesn't build fences around you. That flexibility in terms of supporting where you need to go is very important.
"Finally, work with a company that is interested in working with you. You want a company with a core skill set, some DNA, that will create a partnership, not just a vendor relationship. We were not a slam-dunk fit when we started working with some people -- FamilySearch is a good example. They wanted to take us in a different direction, and they pushed us. It really worked in our favor."
You must login to discuss this item.