Since its birth in 2003 SmartBear has typified the changing, amorphous, and ever increasingly agile, world of software development and testing. The Somerville, Massachusetts company of today was largely formed from the merger — completed in 2010 and orchestrated by private equity firm Insight Venture Partners — of SmartBear with two other companies: AutomatedQA and Pragmatic Software in. But as much as anything, it has been SmartBear’s dealings with the open source community that has defined what it is.
SmartBear has made two significant acquisitions of open source API development platforms: Swagger in 2015 and SoapUI in 2011. This year it has acquired Bit Bar, the mobile testing platform and Cucumber, the open source behaviour-driven development (BDD) platform. It is now an automation specialist that can justifiably claim it has a toolkit that covers most of the DevOps lifecycle.
In 2017 majority control of SmartBear passed from Insight Venture Partners (which whose principal software testing investment is now Tricentis) to Francisco Partners, in a deal that was reported to value SmartBear at $400m+ enterprise value. We caught up with Justin Teague — SmartBear’s CEO since January 2017 — to talk about what might come next.
Q: How important is the financial services marketplace to your growth plans?
A: Right now 6 or 7 of our top 10 customers are in financial services or insurance, and we expect that to grow. We are riding wave of new architectures; for mobile apps or micro-services especially. We dominate in micro-services which require a massively increased numbers of APIs.
The reason that financial services – banking and insurance – are so important to our industry is that they have so much on their plate. The diversity of the challenges they face is the opportunity for us.
Q: How do you sum up your strategy in relation to open source?
A: We embrace open source, but open source tools don’t do everything. We’re professionals at enhancing open source. We take up where open leaves off in terms of either complexity, productivity, security and support. That what we’ve done with Soap and what we’ve done that with Swagger. A firm could customise an open source tool to do what we can do for them, but for $500 or $600 per user, why would they spend time doing that? We’ve already anticipated the productivity someone will want over and above open source.
I believe you can see a similar intent with IBM’s acquisition of Red Hat and with Microsoft’s acquisition of GitHub. My speculation is that it’s very much driven by access to the open source community, where it’s very difficult to win the hearts and minds of the developer. We have access to seven or eight million active developers because of open source and that is a very valuable community. So, I get it — if you can get in with cool kids you’ll be driving a lot of business downstream.
Q: Who are you mostly going to be competing with over the next couple of years?
A: Well, it’s a big market with a lot of new projects. And the total number of developers is growing. But let’s say there are five million developers who might start new projects in 2020 — maybe mobile projects or micro-services projects. That’s the business we want to win. We don’t think of it so much in terms of winning a larger share of the existing market, right now. We’re really competing most of all for customers who haven’t done much yet. We are much more in the open, lightweight, democratized class of business marketplace, than some of those companies you might say are our direct competitors in test automation.
Q: And what’s your technology edge?
A: Our philosophy is to provide the best tools. These are what I’d describe as powerful but frictionless, easy-to-deploy tools. We’re going after the middle of the bell curve, where there are the most people with the most challenges. Our market is wide open and if the customer’s entry point is open source, then that’s OK. The next step might be our more advanced, more secure, more professional tools.
Q: Are financial services firms flexible enough to allow their developers to make those tooling decisions; to move up the curve with you?
A: Yes, absolutely. Here’s what’s changed. Ten years ago the CTO or the head of engineering would dictate what tools were going to be used. In a waterfall, multi-year development environment, that actually made some sense. Today, the CTO and the head of engineering, they are largely picking the standardized development or deployment platforms, say AWS or Azure, Jira or Jenkins. But from there on they are leaving the tooling decisions to the team. Because the teams are being tasked with much more rapid deployment cycles.
In 2005 there were maybe 10 choices for testing software, now there are maybe 100. It’s a very democratized, fragmented marketplace. At SmartBear we are industry and geography agnostic. Outside the middle of the bell curve there are specialists — specialists at testing package applications such as SAP or Oracle, or specialists at load testing, for example. But in the middle of the curve they are building software the same way, and so that’s to our advantage.
Q: SmartBear has grown through M&A, but around you the industry is seeing further consolidation. What do you have to do to strengthen your position?
A: We do a decent percentage of our business through re-sellers and integrators, though I think we could do more.
However we are also very much part of consolidation story you are talking about. A challenge thrown up by the democratization of tooling is the fragmentation of the vendor marketplace. That can create islands of automation, individual assets that don’t connect.
So a lot of what we are doing is making sense of that by pulling together tools that we can connect and integrate. For example, you can use Selenium script across five of our tools. That’s part of the integration. BitBar is another good example. It was a pure-playmobile testing platform; an island. Now we’re connecting it to our portfolio of tools.
And we’re working more closely with Atlassian, for example, because we can see that Jira is a very common part of companies’ CI/CD pipelines.
At the other end of the spectrum of opportunity, I do see an opportunity to partner with integrators to provide tooling. At the end of the day we just provide tools. We don’t provide services. But I do recognize that even some of the core methodologies of BDD also require business process change.
