In this podcast, hear how the cloud encourages the use of agile methodologies such as Scrum, allowing a more iterative approach that's better aligned with business requirements, and find out how mashups of multiple cloud services can help cut the cost and time required to deliver new functionality.
Listen to or download the 7:45 minute podcast below:
PW: Now Simon, you're European, or EMEA, director of Force.com, which is Salesforce.com's online development platform, or platform-as-a-service. So I thought what we could talk about today is the methodology of developing in the online services environment, and how that differs from conventional software development. Simon, what would you say is the difference that developers notice the most when they get started with platform-as-a-service?
SW: Yeah, I think there are three main categories of difference that people will notice. There's a commercial difference, there's a technical difference, and I think also, there's a methodology or approach difference as well. So to go back over those:
From a commercial perspective, what you'll often find is that these environments or platforms-as-a-service are actually free to developers, which gives them access to multi-million-dollar datacenters and architectures free of charge. It's only until they actually sell to their end customer that they then start incurring some sort of subscription model from those providers. So that helps dramatically reduce the cost for those developers and for the ISVs.
I think from a technical perspective, it's really around the speed of build and the speed at which you can change these applications. We've noticed development speeds of five times faster than traditional environments.
A good example here is an ISV that we've been working very closely with, a company called CODA that builds financial systems. They've managed to build a financial application in the space of about nine months, whereas their original prediction for building this with their own software-as-a-service model [was] two years worth of elapsed time. So there's a huge difference in speed-to-market and reduced cost.
And I think the last thing here is around the approach, which what we're finding the most successful approach with developing platform-as-a-service, is to use some sort of agile methodology so something like a Scrum type methodology, where you do a very iterative development, and you can deliver functionality in very short sprints of time. It just keeps you closer to the overall business requirements the sort of ever-changing business requirements that businesses have.
Yes, that's right. And I'll come back to what you were saying about development. But just on the kind of you were saying it's free to get started. So basically, I suppose that means that people actually think of doing things that they wouldn't otherwise be doing, because they can actually kind of experiment a bit more rather than actually have an upfront cost before they've even got anything to show.
Indeed, the risk is greatly reduced. And I think what we're finding is that some organizations are trying two or three applications because the cost is so low and seeing which one kind of sticks, and then building their business further on that. So it's a completely different way [of developing] and lowering the risk of the business model.
And then that follows through into the development. Some of our listeners may not be familiar with all the ins and outs of agile [development] and you mentioned 'Scrum', what does that mean?
So Scrum methodology is an iterative development methodology, which really focuses around fixing the timeframes for a set of deliverables usually two to four weeks in timeframe. And in that timeframe, you'll actually deliver functionality from start to finish.
So you'll have in your Scrum team people that are developers, designers, QA, testers, documentation, etc. And in that space of time, you would deliver fully functional capabilities, which are then ready for release. And then what you can do is, you can group together these 'sprints' as they're called and then produce predictable timeframes in which you're releasing that functionality to your customers or to your business.
So does that mean, rather than building everything all at once, you're building up incrementally in more baby steps, in these one- or two-week cycles?
That's absolutely correct. And in this day and age, what we find is that the business requirements are constantly changing. So the traditional what is called the 'waterfall' style of methodology, where you've got an upfront set of requirements and then 12 months later that's then delivered to the business has very often moved during those 12 months and so your original specification isn't necessarily still appropriate. So to do it in a more iterative approach keeps you much more aligned to the ever-changing business requirements.
And does that mean you're actually talking to the business people as well when you're in that iterative development process?
Yeah, absolutely. And I think one of the things we find is that, again, because of the kind of speed at which you can build the applications on these platforms, is that it takes much more of a prototyping approach, where ideas can be actually prototyped, almost in the meeting sometimes, with the end users: 'Do you like this screen? Should we move it around? Should we do this?' etcetera. So they can see these applications evolving in front of them and, again, meeting much more of their requirements and that ultimately leads to higher buy-in and higher adoption of the systems.
Is that difficult for developers to adapt to? I mean it sounds very different from the traditional development method.
Yes, and I think what we're finding is, this is a methodology that's been adopted by a number of organizations. In fact, internally we develop our product fully using this methodology. And also, in fact, our internal IT department has fully moved over to releasing other types of applications and things internally on this methodology. So we're finding it's an ever increasingly adopted methodology, particularly in this platform-as-a-service and software-as-a-service arena.
So let's talk a little bit about one other element of the cloud environment, which is the ability to use mashups. Effectively, this is reuse isn't it? It's being able to take ready-built components and slot them in. And is that a big difference as well?
Absolutely. And I think this is an important strategy for any cloud or platform-as-a-service provider, which is the really it's about making sure that you can connect all these platforms or clouds together. So a good example is, recently Salesforce or Force.com has announced that it can now connect up with the Amazon S3 and EC2 clouds. It can connect with the Google Apps and the Google App engine, as well in fact, even going into more social networking sites, like connections with Facebook.
So it's about being able to leverage all these different technologies different clouds and for them to be able to talk to each other. Another example is that we've just released something called 'The Service Cloud' which had a kind of a I think some people even described it as a 'leapfrog' event in the delivery of people being able to deliver customer service.
Yeah, we did actually cover that on the 'Connected Web' blog the other day, because I thought it was an interesting announcement although I'm not sure that I would quite hype it up as much as that. But I think it was still quite an interesting because you're taking things that people are doing on Facebook or whatever, and actually moving that through into a knowledgebase, and making it available to customer service reps, and also potentially on the website. So what I find interesting is that you're taking a business process really, and moving it across perhaps four or five different cloud applications and that to me is a really powerful mashup.
Yes, and I think that's where we're seeing, particularly with my position of going around and talking to a lot of organizations around Europe they're wanting to take parts of our cloud, parts of Google, parts of Facebook, etcetera, to actually create the overall user experience that they need. And clouds being able to connect together, they can very quickly mash up these clouds to provide that experience of doing that.
Right, and obviously, that is very, very different from the old way of doing things. So thanks very much for joining us today, Simon.