Interview with Mihir Shukla – CEO Automation Anywhere

In this interview, Mihir talks about how he built a company to bring buisiness
process and IT automation down from the expensive enterprise sphere, and out to
the every-man. Along the way, Mihir shares thoughts on open source and
proprietary development approaches.

Scott Swigart: To start, please take a moment to introduce yourself, your company, and its key products.

Mihir Shukla: I’m the CEO of Automation Anywhere, which is a software automation company. Our flagship product, Automation Anywhere, has been a leader in the space of business and IT process automation. We started about six years ago, with the goal of shaking up the market.

Before we entered the market, products for business and IT process automation were in the cost range of $1 million to $2 million. Even though just about every company needs business and IT process automation, the entry point was too high for most businesses to afford it. Our vision was that we wanted to do business and IT process automation 10 times faster, for one tenth of the cost.

To put that in real-world terms, a project that used to require $1 million should be able to happen with a budget of $100,000. And if it took 10 months to do a business and IT process automation project, it should happen in about a month. That was a pretty lofty goal, so we had to innovate in many areas and change the rules of the game. Today, we have more than 25,000 customers in more than 90 countries.

By shaking up the market in business and IT process automation, we found that thousands of users are using it for test automation purposes. Last year, we decided to more formally enter into that market, and we launched the product Testing Anywhere.

Scott: For a bit of level-setting, how would you define business process automation and IT automation, just to provide a sense of kind of exactly what those two things look like?

Mihir: Every business has many, many business processes, which could include generating reports, or entering patient data into a health care system if you’re a hospital. If you’re a retail company, your business processes would include checking inventory and reordering whatever is in short supply. If you are a dentist, a relevant business process could be to remind people of their upcoming appointments.

And to give an example of an IT process, you may want to install a new operating system patch on various computers. You may want to monitor your data center and find out which hardware is performing below expected levels. You may want to restart various servers routinely.

Those are some examples. We have learned that over 25,000 customers, there are 20,000 unique business processes that businesses rely on.

Scott: And then on the testing automation side, is that automated QA and software testing?

Mihir: Right. That is a very specific example of a process that needs to be automated, but yes, test automation is part of automating a QA process.

Scott: You mentioned that your goal when you set out was to complete implementations for a tenth of the cost, in a tenth of the time. What makes your business process, IT automation, and test automation different?

These are definitely spaces where there’ve been a lot of products in the marketplace for a long time, with really large vendors involved with patch management, systems management, and so on. Talk a little bit about your approach and what makes it different and less expensive and more productive.

Mihir: We decided that if we are to improve it by a factor of ten, we could no longer do what has been done before, or we would be limited to perhaps a 10 or 20 percent improvement. We looked at the space and where the costs involved come from.

We found that the dominant approach to business and IT process automation was very programming centric and involved a lot of consulting requirements. There was not a lot of focus on putting intelligence in the system itself.

Let me give you an example. In business and IT process automation, we created a drag and drop environment and intelligent automation that automatically figures out what it is that you intend to do.

So, for example, consider a business process where I log into my ERP system, type in my dates, generate a report, and email that report to three executives. When I perform that business process, behind the scenes, our software would automatically create the entire automated business process.

It is done in a very intelligent fashion, so it figures out the intent of what you want to do, rather than focusing on your actions themselves. For instance, if you double click on your desktop, we know that you intend to start an application, so we focus on that, rather than the actual fact that you double-clicked.

We developed some technologies that were groundbreaking in terms of how we integrate with various systems for automation. Instead of creating specific adaptors for various systems, we came out with an on-demand integration adaptor for any Windows application. So, suddenly you could integrate with any of the 20 million applications out there.

We also implemented a visualization technology, so the entire automation became visual. At every step of the way, you have a visual picture of what part you are automating.

Scott: How are you extending that to the test automation space?

Mihir: We intend to bring the same spirit of innovation that we did with Automation Anywhere.

Our viewpoint toward the test automation market is that in the last 10 years or so, there hasn’t been any true innovation. Many of the tools out there, even if they have more bells and whistles, more or less work the same way they used to. If anything, it takes longer to learn those tools, and even longer to automate some of the new technologies.

In the test automation space, we brought forward quite a few new innovations. For example, one of the problems we saw in the test automation space is the problem of test portability. You may have a test case that works in your environment, but not elsewhere, such as in a production environment, a partner’s site, or a customer’s site. In cases like that, I cannot take my test and run it on another environment, basically.

We came out with a very intelligent solution, where you can export a test into a standalone executable that has an intelligent Testing Anywhere agent inside it.

Consider a very simple example of a communication between a QA person and a developer. If a QA person finds a problem, they could report it to the developer, and the developer could come back and say, “I cannot reproduce your issue.”

In a situation like that, the conversation could go on back and forth for a while, in a very unproductive fashion.

Scott: That’s certainly a familiar experience to a lot of people in the software industry. How does your approach change that dynamic?

Mihir: With Testing Anywhere, the QA person could take the failing test case, export it as an executable, and attach it along with the bug report to the developer. The developer could run this test case, standalone, without installing Testing Anywhere, and instantly be able to reproduce the problem.

This innovation alone has opened up many possibilities to our customers. We see customers who are using the test to exe capability to do compatibility testing, for example, where you have a test case on one version of the operating system and you want to try it out on a different version to see if the same test case could work.

One of the areas where it’s used significantly is in Agile methodology, where some of our customers have two-week release cycles. That gives you about a week’s time for a feedback loop between a developer and QA to validate the feature, communicate it back to the developer, reproduce it, get it fixed, revalidate it again, and make a release.

They use the test to exe capability for communication between developers and QA. Many of our customers are using it to reproduce problems from a customer’s site or a partner’s site. Problems could be because of user error, or they could be genuine bugs based on certain values.

Issues that were taking an enormous amount of time are being solved now at a fraction of the cost and time.

One of our customers summarized using the test to exe capability well. He said, “15 years ago, when there weren’t mobile phones, life was just fine, but today, if I forget my mobile phone at home, I’ll miss it 15 times during the day.” Once you have it, you cannot imagine going back.

Scott: When I think about the test tools that I’ve used over the last decade or so in software development, many of them seem brittle. Even when you make relatively small changes to an application, you may have to recreate all of the tests, because a button isn’t at the same pixel location, or the output that shows up on the screen isn’t exactly the same, and so it doesn’t key off of it quite right.

Talk a little bit about that notion of making tests more resilient, or the automation more resilient so that the amount of time that you have to go back and recreate them is minimized.

Mihir: The argument for test automation is strongest in Agile methodology, where if you’re going to run through all the tests every two weeks, you’d better automate. The first issue there is that, as you very correctly pointed out, if you change an application, you shouldn’t automatically have to go back and change things. In today’s day and age, you don’t have months and months of product cycles to do that.

Another issue is that even if you have to change it, it shouldn’t take you too long to change it. We know of examples where it takes you 10 minutes to make those changes with Testing Anywhere, and it takes you two days to do it with some of the other software. The difference can be enormous.

The third point is that you want a process that is collaborative, especially in Agile method. Some of the older testing tools are designed for waterfall models or others where you have a year or two to develop and maybe six to eight months to do testing. In that methodology, you are OK, because you’re going through a systematic process. Well, in Agile also there’s a systematic process, but it’s a lot more collaborative.

With Testing Anywhere, collaboration is built in. Whether it’s two QA guys, a QA guy and a developer, a QA guy and a product manager, or a QA guy and outward-facing business users, you can easily collaborate on various aspects.

Scott: What about documentation? How does that fit into the use of Testing Anywhere?

Mihir: You don’t want to make Agile into a cowboy methodology, right? Testing Anywhere creates documentation on the fly that is lightweight but effective, and that helps us create a lot of traction in the market.

I’d like to come back to the issue of what you can do so that if things change you don’t have to come back to it to change your tests again. One of the things that Testing Anywhere does is that, as you create any test case, it doesn’t leave it to the user to figure out and implement what I call the plumbing logic.

The product is intelligent enough to figure out that this is what you intend to do, and it will create an automatic test routine by default. For example, if you double click on a desktop, it automatically figures out that you intend to start an application, and internally, it will just launch that application.

If you take that test case to any other machine, it will continue to work. Whether it’s a Windows application or a web application, it automatically figures out all the controls and it figures out what is the optimal way of matching those controls. It allows you the flexibility to change anything if you like, and the intelligence comes automatically.

Scott: In other words, if you’re double-clicking an application on the desktop, and on a different machine, that icon is in a different location, that doesn’t matter, because the test has figured out the intent. As long as the application is installed, the test is still going to launch the app, even if something’s slightly different from one environment to another.

Mihir: Absolutely. Testing Anywhere does about 100 things like that intelligently and automatically, so when you use the tool, the difference is quite obvious. Relative to using some of the older tools, you would go about 200 percent to 300 percent faster in creating, developing, editing, and managing your test cases. The effect is very measurable.

Scott: To shift the conversation over a bit to the business side, just today, Red Hat said on a community open source site that, with the exception of Apple, all the innovation that’s happening today is in open source.

In reality, though, we come across a lot of proprietary software companies that are doing very interesting things. Talk a little bit about your decision to build intellectual property internally and not develop this as an open source product.

Mihir: As a company, we are founded on the principle of innovation. We believe that innovation is not a property of any particular model, but a result of what you believe in. We’ve seen innovation across all kind of models.

Our goal was to provide a very reliable but at the same time breakthrough technology that has never been seen before, and based on our experience in the industry for the last 15 or 20 years using many tools and technologies, we knew we had ideas that would shake the market up.

It made sense for us to come out with these technologies using a very fast-paced model. We internally use Agile methodology ourselves, and we incorporate many of these new breakthrough features. This made more sense for us than open source.

We also have a Team Anywhere program, which is a program where we invite an elite group of our customers to influence our product direction and provide feedback. In a sense, that creates a collaborative effort that has some things in common with open source.

The collective experience of our 25,000 customers is enormous. These are the people who live the day-to-day life of business process automation or test automation, and they have become a driving force for our innovation as well.

Scott: In other words, whether your software’s being built by the community or the community’s just providing feedback, collecting that input from the actual users of the product is really important. I would imagine, too, that you’ve probably got some stories about people starting to use your products in ways that you never really imagined.

Mihir: Absolutely.

Scott: Talk a little bit about some of those cases.

Mihir: We believe in innovation with the customer, and we have about six or seven different channels through which customers can talk to us. If a customer wants to tell us of a problem, something good, something that could be improved, or something that’s awesome, we always want to hear from them.

Within the product, we have various ways customers can provide us feedback. On our website, we offer a free service where we have a team of experts who can provide customers with assistance. We have learned so much from our users, across the board, in business and IT automation as well as test automation.

Let’s take an example. When we created the test to exe feature, we understood that test portability could open up many avenues, and we had ideas about a few. We saw enormous breadth in the ways customers incorporated it into their communication between QA and development.

At the site of one of the customers we visited recently, when a bug is identified, it’s back with the developer within about five minutes, and in the next five or ten minutes after that, the developer has reproduced it. That was amazing, and it’s just one example.

Scott: When you launched the company six years ago, the global economy was growing rather nicely. A year and a half or two years ago, the global economy pointed its nose at the ground and started to descend pretty rapidly.

What’s your advice to somebody who’s thinking about being a software entrepreneur, in terms of navigating the inevitable economic ups and downs?

Mihir: I think one silver bullet, even if it’s not necessarily a novel thought, is that if you are very close to your customers, you can navigate through any economic ups and downs. Trouble happens when you are too far from the customer and you cannot adjust fast enough to the changing times.

For us, 2009 was pretty good; we had about 50 percent growth. We faced issues just like most people did, but you want to stay close to the customer, understand their pain points, listen to them, and use that as your inspiration for innovation.

When you do that, success is inevitable. When we launched the product Automation Anywhere, I wanted to be the first one to buy the software, just as a matter of pride. The whole company got together, we launched the product, took a coffee break, and gathered around a table. A customer in Australia beat us to it. That’s the story.

Scott: You were doing something in the marketplace that you planned from the beginning was going to be disruptive. You were going not for incremental improvement, but really for an order of magnitude improvement.

Maybe during good times, a lot of companies might have said, “Well, we have testing tools and automation tools. We know them, we’ve bought them, they’re expensive, and it’s not necessarily strategic for us to look at replacing or augmenting those.”

In times of crisis, companies go out and really look at how maybe they could do things differently, and they’re motivated to go look for savings under every rock. Did you find that the cost and time savings of your product positioned you well for the downturn in terms of the interest customers may have shown?

Mihir: You’re absolutely right; disruptive technologies have a huge upside in tough economic times, across all segments, including small businesses, medium businesses, and especially Fortune 500 customers.

Typically Fortune 500 customers have more budget at their disposal. Of the top Fortune 100 customers, 70-plus are our customers. Many of them just came to us and said, “We heard you do things differently.”

We heard that in tough economic times, it was hard to sell the old test automation tools, not just because they’re expensive, but because of the high cost of ownership and how long they take to ramp up, learn, modify, and manage.

It was taking so long that revenues of these companies were affected. I was very surprised at how open they were to accepting a new, disruptive tool in this space.

Scott: We’re not very far into 2010, but I know that some software and IT companies are starting to feel like things are improving. As you look forward to 2010 and beyond, how are you feeling about growth potential?

Mihir: 2010 definitely looks much better than 2009, that’s for sure. We see a significant improvement in the market, and a lot more budgets have opened up. We see a significant movement in both private and government sectors.

Scott: This has been great, and we’ve covered a lot of ground. Do you have any closing thoughts?

Mihir: In my experience with SIs, I found out that, of the total test automation market, about eight percent is currently in automation. They see a significant market potential for that to go up to about 30 or 35 percent, and everyone feels this stagnancy in the tool space in terms of the tools that are out there.

For this new market, they’ll look for new tools that can offer value, and we plan to fit in that space.

Scott: Thanks for taking the time to talk today.

Mihir: Thank you.

Bookmark this: