

The Connected Web

Phil Wainewright

Selecting the Right Platform for SaaS

Vote 0 Votes

Listen to my interview with Colleen Smith, managing director of software as a service (SaaS) at platform vendor Progress Software.

In this podcast, learn about some of the new factors ISVs have to think about when creating software as a service offerings, and how to evaluate the capabilities and strengths of platforms, from both a development and a deployment perspective.

Listen to or download the 9:38 minute podcast below:

Download file


PW: Colleen, we've gotten to know each other very well over the years — and in fact, I think Progress was one of the first platform vendors to really invest in supporting and helping ISVs make the move to SaaS, long before it became fashionable. Today, of course, everyone is talking about moving to the cloud. Do you think it has become easier for ISVs to make the transition over that time?

CS: Well, I wouldn't say it's easier. In terms of making the transition to software as a service, it might be easier for them to sell the concept — whereas, four years ago, they had to do a lot of educating about what is software as a service, what is the cloud, what are they really talking about. So, if anything, I think, maybe it's made the process of — the fact that more people are knowledgeable on what's going on in the industry, it means they have to educate less.

But I think, if you think about what it takes to move or transition to software as a service, it's still just as hard, if not even harder — because there are more competitors, and so you have to make sure that your offering is more reliable than the competition and more cost-effective than the competition. So you've got some other factors that have been brought into play.

Well, of course, one of the things that has come up has been this whole wave of cloud computing options. And so, in the sense of having a platform that you can run on the cloud, [it] has become easier to find and more cost effective. So to that extent, it's perhaps made it easier.


Do you think that if someone moves to Amazon or platform as a service, that's a good way for an ISV to get into SaaS?

Well, I'm not sure if they have to build on the same one that they choose to deploy on. At Progress, we take a little different tack, in that we provide the SaaS platform to develop the application on, and then we leave it up to the ISV to decide where and how they want to deploy. For some, it might be Amazon, and clearly, they've come out with being one of the lowest-cost providers today. But for others, it might be somewhere else, based upon geography, or based upon reliability, or the type of customer they need support.

And so support and reliability play a big role in making that determination. From a Progress perspective, we don't want to force them or limit them to choose a specific deployment option.

But I think that the cloud deployment platforms are still fairly new in terms of the enterprise application development. And so, they have — there's still a lot of fallout, and there's still a lot of things that they need to think about. If I were an ISV, clearly there are a lot more offerings. But that just means they have to do their homework in terms of choosing the right platform for their particular business application.

Right. And of course, as you said, the platform as a service options maybe don't have the same breadth of development capability that you would get on a traditional development platform. But of course, the other side of the coin is that they do do the — what I call the — service delivery management side of things, all of the extra bits and pieces that you need when you're delivering software as a service, rather than as a CD [or] as a product that comes on a CD. And I think that's often an area that traditional ISVs trip over, because it's less familiar for them when they move into software as a service.

Yeah, I'd agree with that. A lot of the times, a traditional ISV thinks about develop, pack and ship, and they don't really understand or really have a full understanding of what needs to happen for the service delivery side. So because they don't think about that separation, or they don't really have a full realization, they don't always put as much emphasis on deliver as they do on develop.

So as I said, at Progress, we've separated the two. But that means that an ISV needs to think about who they're going to partner with and the development side that they choose — and make sure that it has all of the capabilities they need to develop the application. But at the same time, it means then, they also have to think about who is the right partner for them to focus on to deliver the solution.

In some instances, for some ISVs, in some markets, it might be the same person that they can really go to and look to develop and deliver on the same platform. For others — in a more enterprise-focused [market], or somebody who thinks differently, or who has some real specific requirements about delivering — they might need to find a different partner. And it might need to be somebody who's very strong on the deliver side and then work with somebody else on the develop side.

So you have to know where your core strength is and where your partner's core strength is. And that's one of the things that we've worked with our partners on, over the years, because we realize that our core strength is on the develop side so we've partnered with folks like Amazon and OpSource — and we look at them and say, okay, your core competence is the service delivery side, ours is the develop.

And so our ISVs actually end up working with both of us as a partner. And together the three of us bring the solution to the market. The person who knows the develop side, the person who knows the business app side, and the organization that knows the service delivery. And so it really is that ecosystem that together brings a successful solution to the market for their customer.

And of course, the service delivery side, we're talking about things like packaging up the application, having automated provisioning of it for users, being able to bill for it on a monthly basis, all that kind of thing that the conventional ISV might not think too hard about when they're —


— first looking at the SaaS option. And so it's not just a matter of taking your software and plonking it on Amazon. You need to think about all of that side of things as well.

Absolutely, yeah, because there's a lot more to delivering software than just to have it available somewhere hosted.

And, of course, a lot of the multi-tenant vendors in the platform-as-a-service field will say that, well, the benefit of actually running on our development and delivery platform is that we're pooling all of the learning of all of our ISVs — that everyone benefits from all the advances that are being made from the shared knowledge and the shared experience. Do you think that with a conventional packaged platform, that you can have the same level of knowledge sharing?

Well, yeah, sharing is absolutely critical and that is key to their success. It's why from Progress' perspective we're not just a platform, but a big part of our SaaS offering is the community of developers and the ISVs that get together on a regular basis, whether it be online or in person, to share what's going on. Just a couple of weeks ago, we had a virtual conference with over 2,000 companies worldwide from, I think it was, 54 countries around the world [who] got together to talk about SaaS, cloud and what they were doing. And we had chat, and we had interactive sessions, and there was a lot of information sharing about what others are doing. And we have forums, and it's absolutely necessary to have that community of users to share their ideas and capabilities.

But it doesn't necessarily mean that they all have to be hosted or using the same database. What you learn from building and deploying applications is more about best practices. And so, that's the way we look at a platform with a collective use of users. We basically say, let's make sure that those best practices and keys to success are all shared amongst the organization, because it's more about that information about how they built it, or what they found with their customers, that's most important.

But the other thing to keep in mind is that customers are different. And so sometimes an issue, for example, with a healthcare provider, is something that they need to understand what other healthcare providers are doing. But somebody who's in the newspaper publishing industry has something very different because their issues are extremely specific to that particular industry. And so it's sharing and learning best practices, but that doesn't necessarily mean that everybody looks exactly the same — because customers are different.


Phil Wainewright

Phil Wainewright specializes in on-demand services View more

Recently Commented On

Recent Webinars


    Monthly Archives