April 30, 2013 | Written by: Dominique Lacassagne
Share this post:
In part 1 of this post, I’d just returned from a traditional independent software vendor (ISV), and I showed that moving toward software as a service (SaaS) is much more than just choosing an infrastructure as a service (IaaS) provider; it’s about reinventing one’s business. On the road to SaaS many challenges have to be met. Here in part 2 I explain how I would handle these challenges.
So, what is the right path to SaaS?
When I consider the challenges traditional ISVs face, I’m left wondering whether the right thing to do is to create a whole new business unit, with its own culture and go-to-market strategy. It avoids many of the transformation challenges.
A new business unit, however, would be left with the challenge of handling their existing code, which was not built for the cloud in the first place. How would they handle this? There are basically two options:
- Cloud-enabled: start by using third-party tooling to provide cloud capabilities to the legacy code and evolve the code from there.
- Cloud-centric or cloud–aware: make a bolder move to better leverage the new paradigm.
Choosing between the two paths is not just a technical decision. There are business considerations to take into account, such as time to market (very important in our case) and the necessity to succeed in introducing one’s SaaS. Tags such as “cloud-washer” will deter part of the market from using your solution.
I’m eagerly waiting to see the path my ISV is going to take—when they manage to make a decision. I’ve seen so many cloud projects postponed in the past three years when decision makers begin to grasp the size of the transformation and all the related challenges awaiting them. In this case, though, it’s a matter of survival. How long do they have to be credible in the SaaS market? I’d say a few years because of the strength of their ecosystem. Yet, a few years is what is needed to build “Company 2.0” and evolve the code to the right SaaS readiness. So time is scarce.
What would I do?
Coming from a pragmatic IT operations background, living in a risk-averse culture, and leveraging the experience IBM has had in successfully helping other ISVs to move along their road to SaaS, I’d favor an incremental, experimental and iterative approach. That is, I’d go the cloud-enabled path. Also, of course, I’d focus on the core of my business transformation and delegate the rest.
In other words, first I would:
- set up an organization dedicated to SaaS;
- build my service provider organization by leveraging off-the-shelf capabilities and services;
- focus on the first round of my Enterprise Resource Planning (ERP) SaaS enablement by working on features such as deployment and configuration automation, removing licensing, exposing APIs;
- focus on instrumentation and metrics such as operations costs per seat or infrastructure costs per seat to understand and master my new SaaS model; and
- recruit a select few partners and customers that will help me experiment with my go-to-market and partner strategy.
This list is not exhaustive, but you get the idea.
Back to choosing an IaaS provider
To address my ISV’s initial focus, for my infrastructure needs I would use a custom, managed IaaS infrastructure such as the one IBM has put in place successfully for other ISVs on their path to SaaS.
Why? There are many reasons, but again most boil down to managing risks and focusing on core value:
- Keep the ownership of the infrastructure agenda: there is non-neutral technical adherence even with IaaS.
- Leverage managed services (monitoring, backup and so on) on top of IaaS.
- Avoid ties with some public IaaS providers that are becoming competitors.
And you get that without losing public cloud benefits such as a pure operational expenditure (OPEX) cost model.
Last, I’d look for an IaaS provider leveraging technology such as IBM Service Delivery Manager (ISDM) to get a cloud management platform that has been designed for cloud enablement and that provides off-the-shelf goodies such as a multitenant self-service portal and a workflow engine to orchestrate the interactions with my partners.
Those choices would be a good start to experiment in my new service provider life. Don’t you agree? Please share your experience in the comment section below.