I would have never had them separate in the first place; we had separate divisions for a good reason. It allowed the CRM division to grow very fast, but I think that we and everybody else learned at the same time that CRM wasn't really a set of applications, it was really more of a business practice issue. It was more of a culture that you had to sort of bring into your company.
CRM is not a sales problem, it's not a marketing problem, it's an enterprise problem. How you treat your customers is something every party in the organization needs to be aware of, conscious of and have a strategy around. The idea of having different systems responsible for how you're selling to customers, servicing customers and managing finance for customers is crazy. None of those systems will understand the overall strategy for driving your business and driving a more intimate deeper financial relationship with customers.
For the last six quarters, we've grown every single quarter in CRM revenue. CRM has been very good growth for us. Where we really know we're going to grow our own revenue is with our own install base. We probably have as many developers, if not more developers, building our CRM technologies than they do. We have more total applications customers than they do. The reason SAP has jumped to the front of the CRM space is because they suddenly realized that they have thousands of ERP customers running an order management system, and from that there are other systems.
Companies are realizing that maybe it's more important to stick to your ERP vendor rather than having a separate vendor running CRM. Oracle has a very big ERP customer base. We have thousands of order management customers and 10,000-plus financials customers. There is a natural discussion we can have with our customers in terms of the things we've done with our CRM products. Suite vendors are on the rise tremendously versus best-of-breed vendors in CRM because people realize none of these things operate in isolation; they all have to operate in a very integrated way.How was the Customer Data Hub developed? Isn't this a repackaging of existing technology?
The customer data hub evolved over the last few years. When we started building our CRM products, we learned that we had to build an adaptive attribute driven model and figure out a way to share a view of the customer across the whole E-Business Suite. We created what we call a trading community architecture that lets you model persons, organizations and relationships among them. It really became the basis for how you describe the customer and the contacts behind the customer and how you work with them and partners and everything else that you would want to describe in your customer.
We learned that this model was really catching on and was successful, so we branded and packaged it. It is the central model of the customer with the appropriate attributions around the things you care most about your customer. Instead of data cleansing tools, we give you a set of data librarian routines to keep the data clean, regardless of what the source of it is. We think it's a really exciting technology and it's getting a lot of attention. It proves a point that everybody wants a more comprehensive view of the business starting with their customer.
If you end up with enough of these data hubs, there's no question you should ask yourself, "Do I want to take a different approach where more of these things are integrated to begin with?" Adding a Product Data Hub next to a Customer Data Hub should reduce complexity, not increase it. It is still better to have a place where you can go to a singular view of your customers and another place to go and have a singular view of your products and inventory than going to five different places for your customer information and four different places for your product information.