Listen to my interview with Bhaskar Himatsingka, CTO of spend management vendor Ariba, which over the past few years has shifted its business model from conventional licensed software to software-as-a-service .
This is a two-part interview. Part II discusses How SaaS is Changing Ariba. In Part I below, learn why Ariba decided to switch to the SaaS model and find out how it managed the transition both financially and technologically.
Listen to or download the 9:50 minute podcast below:
PW: Bhaskar, Ariba originally got established very much as a conventional software vendor selling licensed software, which enterprises installed on-premise in the traditional way, in their own data center. But in the past couple of years, you've decided to shift over to software-as-a-service. And, first of all, I think one of the big questions is, what made you decide to do that?
BH: The transition of Ariba as a software company started around 2001, when the tech bubble burst. And after we realized that the bubble had burst, we went back to basics, which was really procurement that is what the company had originally started, trying to automate that process. And what we realized was that along the way, we had lost focus on that original vision of bringing excellence in the spend management process.
So from 2001 to 2004, we spent a lot of time broadening and deepening our solution portfolio. And just in early 2004, is when we merged with FreeMarkets. And as we expanded our solution portfolio as well as things changed in the market, and with the acquisition of FreeMarkets we started hearing loud and clear from our customers that total cost of ownership, faster time-to-value, and ease of deployment as well as expertise was very, very crucial to them to be able to really get value out of spend management especially, if not other solutions.
So we took a pretty hard look at where we wanted to go. And about that timeframe, early 2004 timeframe, is when we decided that [the] time had come for us to allow our customers to be able to leverage the benefits of spend management, not just on-premise, but also in an on-demand or SaaS offering.
Now, I know a lot of software vendors are thinking about this at the moment how do they introduce a software-as-a-service option if they've got an established conventional licensed software line. And there are various ways of doing it of course. The simplest way is to just take the software, and just start hosting it in a data center and offer it to customers on subscription. Now, I know that you probably it was beneficial I guess that you'd acquired the FreeMarkets guys because they could tell you that, hey, there are actually different ways of doing this. Because I remember FreeMarkets always was provided as a service, I think, wasn't it?
It was. And in fact, Ariba itself had an on-demand or SaaS offering with Ariba Supplier Networks since 1999. And so in 2004, when we really embarked on this journey of transforming the company to be an on-demand company, there was probably about $60 to $70 billion of spend going through the Ariba Supplier Network. We had FreeMarkets, which used to have its technologies in sourcing, especially at the entry level, offered as an on-demand product. As well as, they had a services organization which had actually figured out how to offer services predominately in a centralized on-demand fashion with complement services on the ground. So we had good ingredients on the technology front as well as on the services front that we could look at and learn from, to figure out exactly how we would actually transform the rest of our business.
So what was the choice that you made? Did you decide to go with a very gradual change in terms of just starting to host your software and then transition it over a period of years or did you decide that you just needed to re-architect it as a software-as-a-service, multi-tenant infrastructure?
There were two aspects to it; one was the financial model. So we started shifting our financial model to be more, from a license-based selling model, to a subscription-based selling model.
You can continue to do that of course while the software is still being conventionally licensed
you just change the way customers pay for it, right?
Exactly. And so, on the one hand we were transforming our financial model to shift from the license-based model to subscription-based models, so it kind of took a dip along the way. While in parallel, we actually decided to go all hands on deck for about an eighteen-month period to re-engineer/extend the technology that we used to offer our on-premise customers and make it SaaS SaaSify it I guess is the best word I could use. And so we started that in May 2004 and in October 2005 is when we had the first version of our SaaS offering.
And the decision we made was one was, go all-out, so it was all hands on deck. And the second was, don't try to have all the solutions be available in SaaS in one shot. So we have eight to ten modules, maybe a little bit more, and we decided to go a module at a time. So in October 2005, we enabled two of our modules, Spend Visibility and Ariba Sourcing. And then the following spring, we enabled probably 80%, we enabled the procurement modules as well as the invoicing modules, and then six months later we enabled all our modules in on-demand offering.
Right, so that enabled you to spread out the task and I guess make it more manageable. But at the same time, the actual architecture and infrastructure that you were building, what was moving right across to a complete multi-tenant stack, I believe?
Yes, it was. We in some sense, you can think of it as we got religion. I used work at Oracle the time when [CEO] Larry [Ellison] used was trying to sell the Network Computer and the analogy he used to use was, "If you want electricity, you don't go build a power plant in your backyard" even though his house has actually a power plant in his backyard. But I remember that analogy from fifteen years ago and it is true. I don't want to see the 'blue screen of death' every couple of weeks on my laptop and I don't expect people who use our solutions to have to worry about how to manage [our software].
So it was very clear to me and to large parts of our leadership and organization that we had to transform our offering to be a service-like offering, meaning a software-as-a-service. And once you decide to go down that path, it was also extremely obvious that using the electricity analogy for you to have a grid, you really need to create the right architecture. You can only get along so far by having multiple instances of single-tenant hosted software. You had to really go all the way top-to-bottom on the technology front and more actually. But at least from a technology perspective, we needed to build an architecture which would scale and allow us to manage it as a true multi-tenant offering where we could bring customers on and off it as necessary, without having to worry about managing a hundred different customers each in their own little part.
And was that a difficult task? Did it involve a lot of new skills needing to be learned by your engineering team, for example?
Good question. As I mentioned earlier, we already had an offering, which was the Ariba Supplier Network, which was provided on-demand. So from a hosting operations perspective, we had the right skill sets and the DNA.
From an engineering organization perspective, the rest of the product the technology Ariba applications are built on top of what we call our platform, which is a set of libraries, an application development framework, to allow our developers to build applications. [It's] fairly sophisticated, I'm very proud to say, and it's been developed and evolved over the last ten years. And one of the unique aspects of that technology of the framework is that it's very metadata-driven and it's very componentized, that's one. And two since we were deploying our solutions in typically Global 5000 or $5 billion-and-above companies on-premise, who have lots of business units, and lots of backend systems, ERP systems, and they wanted a spend management solution which had visibility across all of them our architecture was very good in terms of allowing people to unify multiple ERPs or multiple little companies within their own company.
And so the underlying platform actually had a lot of the core components of how to partition the data across customers, or how to allow various customers to be able to configure their business processes based on their own needs. And so we leveraged that and extended on that. So that way, from an application development perspective, we could bring over ninety percent of the IP [intellectual property] that we had in on-premise without really much changes. And then we had to spend time trying to figure out how we could really allow customers to configure and customize the processes in an on-demand fashion rather than in an IT-like fashion.
This is a two-part interview. We'll be back with Part II.