Friday, March 15, 2013
Why Enterprise Software and Databases Equals Fast Growth For Confio
The enterprise software market isn't as sexy as mobile apps or the latest social-mobile-local internet fad. But, recently, it's been clear the enterprise market has clearly beat out all of those areas in the area of growth and revenues, and become one of the fastest growing part of the high tech industry. One of those companies is Boulder-based Confio (www.confio.com), a maker of database management software. The company has been one of the fastest growing companies in the region, and has reporting strong growth over the last year. We sat down with Matt Larson, founder and CEO of the company, to dig deeper into what's driving the growth of the company and its markets, and the secret to growing in the enterprise software market.
For those readers who haven't heard of your company, what does Confio provide?
Matt Larson: Confio has a number of different products and product lines. Those different lines address different customer needs and pains. One of our product lines has to do with database performance. Basically it's solving a number of pains. One of the pains is database administrators spend a lot of time trying to solve performance issues, and existing tools don't do a very good job of it. Those tools are focused primarily on health metrics of the database. We have a different approach, where we're looking at things from a response time perspective. We're much more focused on if it took ten seconds for a transaction to occur, and where did that ten seconds go, and what was it doing in the database, whether that was reading from a table, or using the CPU, or if it was locked with some other user fighting for resources.
That's one group of customers. Another group we have is developers, who are writing code against the database with SQL statements. They also have the same needs, to figure out why their code isn't performing how it is supposed to, what is slowing it down, and they're interested in that same response time analysis. Then, there are those two groups working together, something that Agile has changed a lot.
What is that change that Agile has caused?
Matt Larson: In the old type of development, what would happen is a software team would develop for three to six months, then do a release. When they did a release, they would have a meeting with the operations team, in this case the DBAs. They'd show them the new code, train them on it, and then leave the operations team in charge. That code wouldn't change very often, at most every six months. With Agile, suddenly, code is being promoted as much as hourly, and we've even seen faster than that. That means that new code is going live every day, and that changes everything. Developers are now more likely to go ahead and let new code into production every day, and that means it may not work as well. They're willing to do that, because they can fix it the next day. However, because they are constantly deploying new code, they can't have meetings every day with the DBAs, so that they can see what they're rolling out. That means they almost have to self serve, and need the ability to see what's happening in production based on the code that was just released two hours ago, and isn't acting like it should, so they can fix it today for tomorrow's release.
They need that visibility into what is going on in the production database. The database administrators are saying they just don't want to be in the middle of this, because they don't understand what got checked in yesterday and what was checked in today. That problem has now been defined as DevOps, a big industry buzzword, which means that development needs to work with operations in a more efficient manner. Our other product line is related to databases which are being virtualized.
Can you talk about that product?
Matt Larson: In the past, a database was sitting on a physical server, and was pretty much owned by that server. However, now, not only is the database on a virtual server, that virtual server is sitting on another physical server and sharing that server with lots of other virtual servers. They're fighting for the same resources. However, a DBA can't see that, and can't tell who the other virtual servers are that they are fighting with, and why their database is running so slow. We have a product line, IgniteVM, which lets them see what is happening in the virtual world, so that they can make sure things will continue to run the way they're supposed to. The virtual world is a very rapidly changing world. In the old world, it was only every three years that you'd get a new physical machine. In the new world of virtual machines, things change literally every hour. You've got developers checking code in, virtual machines changing all the time. That makes the existing tools not work anymore.
We also have another line of products related to database storage. One of the biggest expenses outside of information technology is the amount of money spent on storage and storage area networks. For example, an EMC storage area network is expensive--they'll spend as much on storage, as they might for all of their servers. It's a very big cost. We have a product that tells users where they are storing their database data, and a product which shrinks the storage used by their storage by sixty percent. It saves them 60 percent on the cots of all that storage. At the same time, it speeds their database up by 30 percent. You save space, and your performance speeds up.
What's driving the growth you've been reporting?
Matt Larson: The problem I described of developers and DBAs needing to work together is a big driver of the growth, as well as the fact that databases are being virtualized, essentially disrupting all the current tools. Lots of them don't make sense anymore in this new world. Another trend is big data. I forget the exact percentage, but there's a large percentage of big data initiatives that are actually occurring in traditional databases like Oracle and SQL Server. That means the amount of data growing in these databases is growing dramatically. The concept behind Big Data is that you don't get rid of data, you collect as much data as possible, because there is latent value in that data. The only thing is, you have to be able to find it. That Big Data mentality is making database grow much faster than they did in the past. It's those three things, number one, DevOps, driven by Agile Development; number two, databases being rapidly virtualized, and number three, the explosion of data related to Big Data.
What makes Confio a must have versus a nice to have for your customers?
Matt Larson: That's a good question. It's not a marketing thing. The traditional way of doing this is to say, here's the product we have, and let's try to convince people this is a pain. That's not the way to do it. A much better way, is to figure out what products we need to bring to the market. We have a philosophy that we go by when we decide to take a product to market. We call it our pain list. What that means, is for every potential customer, they have a pain list. They might not know what their pains are, so we'll ask questions to understand what their pain is. We'll also ask questions like what are your material expenses, and where are you spending your money. Because, we know that where people are spending their money is where they have pain. You might not think to answer that when someone asks you what your pains are. But, it is a pain for you. You don't recognize it, because you accept it as a fact of life. Most pains on the pain list are accepted facts of life. When we ask the question, where are your material expenses, and see how this might cut your expenses dramatically, you probably didn't realize that it would be that big. Another questions we ask is related to the time and tasks you're doing. We have you walk us through your day, and figure out what your projects are, and what is taking up your time. We want to figure out how we can automate that, because time equals pain, and doing work equals pain. By asking these types of questions, we can effectively come up with the pain list, and solve the pains on your list.
By the time we're out with the product, we're not trying to convince you of a need you have, we're only coming up with products that we know are going to solve big pains for them. The second thing we do, is we don't want to create products where we fight into a company, and have them eventually say they can't buy this tool, because they don't have a need or product fit.
For example, there's a vendor of databases, Informix, which has a very small market. We don't want to come out with an Informix product, and say we have this great product, and spend lots of marketing dollars, which lots of companies will see, but we can't sell to them because they don't have Informix. That doesn't help us with sales. To avoid that, we come up with products we can pretty much sell to everybody. So, if a company is going to see our ad, at least a couple will buy it.