Business Transformation in Action

The following is a full transcript from the session on "How the Cloud Changes the Way Applications are Developed," part of ebizQ's Cloud QCamp. This session featured Phil Wainewright, well-known industry guru and ebizQ's Connected Web manager, and his guest Alex Barnett, group manager of developer relations at Intuit.

Listen to the 45-minute interactive panel discussion here.

Phil Wainewright:  Welcome to today's Webinar, the second session in our Cloud QCamp online event.  I'm Phil Wainewright and I'll be introducing our topic today.  Thank you for joining us....

The title of our Webinar today is "How the Cloud Changes the Way Applications Are Developed".  I'm Phil Wainewright, industry analyst with Procullux Ventures and Community Manager for Leveraging the Connected Web at ebizQ.  I'll be the first speaker on today's topic and it's my pleasure to be joined today by Alex Barnett, who is Group Manager of Developer Relations at Intuit.  Alex, good to have you with us.  

And we're glad to Intuit as the sponsor of today's Webcast and Alex will be making the second of today's presentation.  And in fact, Alex has a huge amount of experience with this topic both in his current role at Intuit and in previous roles at Bungee Labs and Microsoft.  So we look forward to hearing what he has to say later on.  And of course, if you have any questions for Alex or I, please submit them in good time for us to take them before the end of today's live session.  

So who is this Webinar intended for and what are we going to be talking about?  As this slide predicts, there are three main groups of people developing for the cloud.  Independent developers have made a lot the early running and often they are professional developers kicking the tires of new technologies in their spare time or they maybe the fabled two geeks in a garage building the next Google, YouTube or Facebook.  Much of what of we're going to be saying today is applicable to them but we're going to be concentrating on the needs and experiences of those two other groups you see there.  

In my presentation, I'll talk primarily about the experiences of enterprise developers building or implementing applications and IT infrastructure to support business users in their organizations.  Then Alex will talk about the needs and experiences of developers at ISVs, Independent Software Vendors who are increasingly using the cloud as a development and deployment platform.  But before I launch into talking about the impact of the cloud on the development process, we better make sure we define our terms.  There are so many definitions of the cloud floating around but to many people it all probably seems as impenetrable as the famed riddle of the Sphinx, which you see pictured here.  And in fact, I tend to think of the cloud as a kind of pyramid which splits up into several layers.  So let's discuss what those are.

The term cloud actually derives from the icon engineers used to put in network diagrams and PowerPoint slides when they wanted to show the Internet.  And basically, it means all that stuff out there that we don't know the inner details of.  So although some pluralists are going to disagree with me, I think it's legitimate to use the term cloud to cover any computing resource that's delivered over the Web as a service.  And my pyramid shows this as a service stack.  You might also call it the cloud services stack.  So starting at the top of the pyramid, we have Software-as-a-Service, which you can call client applications and well known popular examples include Saleforce.com, Netsuite, Google Apps, SuccessFactors and so on.

The next layer down is Platform-as-a-Service and that's what we're going to be concentrating in today's session.  Now another way of thinking about this layer is a three-letter acronym IDE which stands for Integrated Development Environment and has traditionally been the platform that you would use to develop an application for deployment on a conventional application platform.  And so Platform-as-a-Service means the cloud version of that, a cloud IDE.  It's a hosted development environment where you can build and deploy an application there in the cloud and deploy it from the cloud.  

Now examples of Platform-as-a-Service include the Intuit Partner Platform which Alex will be talking about shortly as well as Microsoft Windows Azure, Salesforce.com's Force.com platform, Netsuite's NS-BOS and others.  The third layer in the pyramid is the layer that first got people talking about the cloud and it covers raw computing services such as Amazon Web Services, primarily it's EC2 Virtual Machine and S3 Storage Services and other providers such as (Inaudible), elements of the Rackspace Cloud and so on.  It might also include supporting services such as security, provisioning, and billing.  And this layer we'll call Infrastructure-as-a-Service or IAAS.  And you can also call it the cloud utility's layer as I've shown there on the pyramid.  

And then finally at the bottom, we have the cloud data centers.  Now this layer has got some features in common with clouds but it's really just virtualized machines, and data centers, and some people might say that it's not strictly speaking cloud but this is where you may have private as well public clouds.  And developing for this layer and also for the utility cloud such an Amazon's EC2 has got some characteristics in common with the cloud IDEs that you get with the Platform-as-a-Service layer, which is why I've included it.  But you may miss out on some of the high-level benefits wherefore Platform-as-a-Service as we'll see shortly.

So when first people first start thinking about the cloud, they tend to think about all the things that could possibly go wrong.  It's unfortunate but I think its natural because the overriding feature of the cloud is that it breaks down barriers and boundaries.  And of course, when that trusted perimeter fencing comes down and it's no longer there, people rightly feel exposed to the unfamiliar.  Now for developers, what that means is they have to be aware, we're often taken for parameters that in a conventional behind the firewall environment you simply would have taken for granted but which you can't in the cloud environment.  

And this is a factor that deploys whatever lawyer of the cloud you're working at from the cloud data center layer on up right into the SaaS layer.  Now of course, there's a payoff for this otherwise people wouldn't bother.  And the payoff is the ability to access resources that you don't have inside your organization or your local IT infrastructure.  You can reach out with APIs and mashup external compute resources, information flows, and application services that were inavailable on demand.  The quid pro quo is that you do have to be alert to the security requirements and have good governance processes in place to make sure that those external services are going to be reliable and will continue to meet your requirements.

Now you may also want to expose your internal resources for external consumption or mash them up with external services in new ways.  And here the unknown factor is demand.  You need to build in scaleability in favor of a processes to make sure that you're not going to overload your internal systems or and just as bad, fail to meet contractual commitments that you've made to third parties.  That's the other thing about the cloud.  If you're interacting with external services, then you're going to have to work within commercial relationships, and contracts, and that means having the ability to monitor compliance with service level agreements, and also measure usage so that you can be sure your provider is delivering the service you've paid for and is charging you only for what you've used.  

And likewise, if you're going to provide your services out into the cloud, then you need to be equally measuring what you're providing and making sure that you're charging for it accordingly.  Now, all of this infrastructure is frankly a pain to look after, to setup and make sure that its working and maintain for yourself, which is why many developers are starting to move up a layer.  And instead of doing all of these things and being responsible for them and accountable for them for themselves, they're using readymade infrastructure that is there in Platform-as-a-Service layer.  

And so, that's now having looked at what could go wrong, let's look at what's good about the cloud and let's look at what benefits people get when they move to Platform-as-a-Service and can get working straight away with those benefits without having to worry about all these risks first.  And I think the answer about what's good about the cloud splits things into categories.  The first category is the things that everyone expects.  And then the second category are the unexpected differences that often catch people unaware.  Now there seems to be universal agreement on two huge benefits.  Higher developments saves time and money.  And that's true in many cases with (Inaudible) utilities but it really comes in its own when you move into the Platform-as-a-Service layer.

Now, don't just take my word for that.  Here's what Amitabh Srivastava head of Microsoft's Windows Azure Development Team told me in a podcast interview last November.  And that podcast by the way, is still available to download from the Connected Web blog on ebizQ.  What he told me was that IT at the moment spends all its time managing the machines whereas in Windows Azure, we manage the service not the machine and drives the total cost of ownership down.  That speaks to budget.  In January, I interview Simon Wheeldon who is a mere director of Force.com, that's Salesforce.com's Platform-as-a-Service and that podcast is also available on the Connected Web blog incidentally.

Now he told me customers of Force.com has seen development time sales up to five times shorter than traditional environment.  So what's the reason for these dramatic savings in cost and timing?  It's because Platform-as-a-Service has the technology already ready to run.  You don't have to buy it to build it.  You don't have to debug it or patch it, the provider already did it all that for you.  Sure, it means that you have to accept the provider's security model and other infrastructure decisions that are made in advance.  But the other huge benefit is there's no outside upfront investment require to buy all that infrastructure, you just pay as you go for what you use.

And that means the expenditure comes out of your operational budget rather than you needing to set aside capital funding.  People often forget it also means you can scale usage down later on and pay less if it turns out you're using less than you originally thought as well as scaling up.  The other thing that people know about is the frequency of upgrades.  And what people are often forget though is that those upgrades are always incremental.  A Platform-as-a-Service or Software-as-a-Service provider never wants to have to take its infrastructure down when it does a major upgrade so it avoids getting itself into that situation.  Whereas conventional software vendors have a completely different upgrade lifecycle that more or less guarantees you're going to have to take your infrastructure down perhaps for days at a time in order to implement the upgrade.

And that's a difference in approach that often isn't factored into cost of ownership calculations when people looking at on-premise versus the cloud because they tend to price over a three-year cycle and therefore they miss out that huge cost of those major package software upgrades and in the on-premise environment.  Having talked about some of the more obvious benefits and particularly the time-to-market and the budgeting benefits, what else is different?  Talking to earlier adopters of cloud services especially after those Platform-as-a-Service and Software-as-a-Service layers.  We have a further set of differences that people often don't anticipate.  

Perhaps they're too focused on what might go wrong or on those self-evident time and cost benefits.  But we find that these differences are often as significant and often more so than those that were anticipate it.  There's the instant feedback effect for example.  You see the old waterfall method of software and application development in which the software was where the knees were defined, and then the software was built, and then was pushed out to the users, and there was exceptive testing, and then people started to use it and eventually, sometimes with lags of up to 18 months before the feedback started to come back to the people who'd actually of written the software.

When you're deploying Software-as-a-Service from the cloud, then the feedback that you get from users is instant and immediate.  The very first time that you deploy it, you can start to see what users are doing.  If they encounter problems, they feed that back to you straight away and that makes a huge difference to the way that software gets developed.  And as we'll see, it has not (Inaudible) impacts on the development style that is adopted.  

Another huge difference is what I've called location independent working.  You see when the development and the and deployment platform are both in the cloud, it means that anyone can access that platform from where ever they are so this makes it possible to have developers team from across the globe, for example, or from different sides of the country, or from different organizations, or different companies working together as a team on development.

And it also makes it possible to show application prototypes and development type prototypes to use as on-demand.  You don't have to set up meetings, and going on-site, and take all your equipment with you to demonstrate the software, it's just there on the Web and they can go in and see it in a Web meeting or whatever, or even access it live.  This all adds up to user empowerment actually, because it's much easier to get the feedback from users and therefore they feel more involved.  Or you can even in some cases extend to them the ability to change elements of the application themselves once it has been deployed.

So users do then get more involved in the development cycle.  Now in conventional software, that's often regarded as a disadvantage because at leads to something called scope (Inaudible).  But in the type of feedback group of client development, it tends to be more positive and constructive because the feedback comes and the realignment of the application comes before the work has actually being invested in doing it the wrong way.  And therefore, it can actually be a more productive way of working than in a conventional environment.

Openness to cloud resources I've also mentioned there.  This is the ability to embed cloud services such as for example, post code or currency exchange (Inaudible) which comes from a third-party.  This is much easier and much more convenient in a cloud environment where the platform itself is already there in the Web and therefore all the resources the Web can easily be hooked into the application infrastructure and many SaaS providers are already doing this in their application.  This is perhaps a hidden story of SaaS actually the providers do this because even an application like NetSuite has got components in it that are actually feeding in information for example, currency exchange rates that come from a third-party.

And then the other thing here is the innovation cycle.  Because of this frequent upgrade cycle that I've already talked about, it's much easier to incorporate innovative features.  And the feedback group allows for much more rapid response to use demand about what does work and what doesn't work and; therefore, uses of Platform-as-a-Service and Software-as-a-Service applications tend to find that they're working with the more up-to-date application infrastructure and feature set then users of conventional on-premise applications.

So pulling all of that together, what's the emerging best practice that we see in development on the cloud?  Well, it exist in a couple of areas.  First of all, were seen emerging cloud development styles and because the factors I've spoken of, the waterfall environment or the waterfall approach to doing everything and then pushing it over to the users and going off to another project is really not appropriate in the cloud environment and doesn't take advantage of all the benefits of the cloud environment.  And so cloud adopters have found its much more appropriate to adopt an agile, collaborative on-demand development style in which they adopt typically short iterative development cycles of 2 to 4 weeks and the Scrum methodology which is particular form of agile development is particularly appropriate for many developers in the SaaS and the Platform-as-a-Service environment use this.

This ability to do location independent working and distributed teams means that is much easier to involve users and the clients definition around prototyping and also because there's much less effort involves in setting up the application and perhaps prototyping something as an experiment, then you tend to find people are more likely to do throwaway prototyping in which they might perhaps do a couple of different ways of achieving something in the application in parallel run-up some mockups, some prototypes. One developer working on a (Inaudible), another couple of developers working on another, and show those the user get feedback and decide which way to continue on.

That's all helped by disability to do Web meetings and online collaboration and therefore you do get this tendency to get keep going back to users to refine the requirement.  And in the end, achieve much better alignment of the application with the business results that in the end, that's why people want to have the application in the first place.  And then this tendency to involve use has finally leads also to the right of what I called here delegated development in which users our allowed a certain level of involvement in their own development steps.  This is something, for example, that means that they can find tune or producer their own reporting rather than having to get in a queue for IT or developers to do that.

Or perhaps they may be able to do point and click modifications to particular configurations of the application or particular processes.  And in some environments, they're even tools that can be provided to allow users to model processes without actually getting involved in coding.  Now there is a downside to this because obviously, if you're talking about business processes being automated by software, you don't want users to get carried away and start doing things which are inappropriate.  There still needs to be some kind of governance over these modifications that are being done.

There needs to be some kind of reporting back to the developers and to IT management.  And probably the users need to have more understanding of lifecycle best practice than perhaps they traditionally have.  But this is the sort of evolution or development styles that we're starting to see as people adopt Platform-as-a-Service.  So with that, I'd like to handover to our next speaker, Alex Barnett, who as a mentioned earlier is Group Manager of Developer Relations at Intuit and he'll talk more about their platform and how their customers and partners are using the platform.  Alex.

Alex Barnett: Thanks very much Phil.  My name is Alex Barnett.  I'm Group Manager for Developer Relations at Intuit.  I wanted to just pick up on a few of the things that Phil discussed there with respects of some of the characteristics around the Platform-as-a-Service, in particular, the kind of benefits that arise from that.  What I would like to do is just spend just a little bit at this time though to be able to provide some context.  Why is Intuit providing a Platform-as-a-Service?  What problem are we solving specifically around small businesses and how are we partnering with ISVs and SaaS providers to be able to take advantage of the opportunities that we see?  And so hopefully, give you some kind of understanding and context around our motivation in terms of providing a Platform-as-a-Service.

So there's one kind of big trends that we're noticing amongst our small business customers.  We got about 4 million small business customers in North America, about 25 million users within those companies and we're seeing their adoption rates of Software-as-a-Service as being a big megatrends that we're noticing.  One question that we went out and asked of our QuickBooks customers is around their adoption or their willingness to use or adopt Software-as-a-Service solutions.  The good news is the majority of those customers told us that if the solution is right for them and it solves the right business problem, that they would be willing or already using it.  I mean 12% said that they wouldn't and that they may vary because of -- the reasons for that maybe around security, or not familiar with the SaaS model, or not comfortable with the idea of using web-based solutions.

So there's a kind of data point to help understand why we are getting involved and driving forward around the connected services strategy.  Now in terms of defining a problem that we hear from our small business customers is how do all these SaaS applications connect with each other, and speak to each other, and work with each other?  And the fact is that they don't.  So here's a straightforward example.  So Webware 100 recently had a number of SaaS applications that went up for voting.  These were anything from CRM, to scheduling, to project management and finance.  And the question is really if you're subscribing as a small business into these different applications, how are these different applications from different vendors connecting with each other?

So imagine in a project management application the project is now complete.  How does a CRM and how does the back office systems now know that that's the case, and that they can invoice, and trigger other processes?  And the fact of the matter is that small businesses are less to have to do with a lot of the wiring themselves.  And the fact of the matter is that they just don't have those resources.  And what they end up is with a suite of applications from various different SaaS providers that don't connect each other, don't speak to each other, and they do a lot of manual work that's required by the business owners and end-users to try and kinda of make sure that these processes are connected.

Now at a conceptual level, you can imagine that if there's a notion of a common data model across these different applications that at least show in common schemer, at least have the ability to be able to map to each other across this common data model, the light might look a little simpler.  You have then potentially the chance in having these different applications to connect to each other, speak each other, and share the common data that are required across these different applications but in different context and for different types of users.

Now, this is where I want to introduce the Intuit partner platform.  What it does is effectively solve that problem for the small business and so the Intuit partner platform is a platform that allows multiple different applications including your QuickBooks data that might be sitting on your desktop to interoperate with each other.  And so an application that happens to be connected as part of the Intuit partner platform now has the data synchronizing across these different applications as well is your QuickBooks data and gives the opportunity for these different types of applications to connect with each other, work with each other, and have data consistency and integrity across these different applications.  So there's just a tiny bit of contact.

Now, our proposition with ISVs and SaaS providers is how do we solve all these different problems that small businesses have?  We can't solve them all and enter it ourselves.  So partnering with ISVs and SaaS providers to be able to provide this suite of applications that connect with each others, that talk to each other, that share this data across is our proposition to developer and then help them take them to market.  Take those applications and using our channels our relationships with those 4 million small business customers, is take those applications to our end users and help solve that problem.

Now with respect to the actual Platform-as-a-Service stack, what we provide ISVs and SaaS providers is an entire end-to-end Platform-as-a-Service.  So where Phil had talked about feel like the cloud services stuck in that pyramid, we have different components of that built-in to the fabric of the Platform-as-a-Service so the various lowest level you got a physical infrastructure on the hosting.  Intuit has been provided Software-as-a-Service on this kind of infrastructure of a number years and its mission-critical, business-critical type applications.

On top of that, the ability to be able to develop data aware applications, we got a fantastic asset in QuickBase.  And QuickBase is a Database-as-a-Service.  It's the way that developers are able now to program against data that happens have to be out in the cloud.  Along with that, with QuickBase, and big advantages that we have is a whole bunch of security models and mission model that is built-in as part of QuickBase that the developer just doesn't have to worry about.  The next piece is QuickBooks.  And obviously, the ability to be able to have your data connect and program against QuickBooks' data is critical to the (Inaudible) proposition we have for our customers but also creating an opportunity, an integration point there for our developers to make their application and their SaaS solutions relevant to the QuickBooks customer base.

On top of that, we got Flex.  So we partnered with Adobe to be able to provide an integrated developer environment that's built on the Eclipse framework, it's actually part of the Flex framework.  We provide a plug-in that now provides all the tooling support inside of Flex to auto program against QuickBooks data against the APIs, to be able to develop and program against QuickBase, and then provide the entire site software life cycle management piece.  So the ability to deal with it and deploy, and manage, and do the QA, and your testing in the staging environment.  All of that gets taken care of as part of the Platform-as-a-Service offering.  And I think we speak about -- when Phil spoke earlier around getting about ready-made technology implementation, and think about low start up cost.  If you think about that faster time-to-life.

For an ISV, those are also critical elements and not necessarily core to their business where they want to actually develop applications and not all the infrastructure that's required to be able to build the application.  And because its delivered as a Software-as-a-Service resulting application, the ability to be able to get that feedback from customers and (Inaudible) very, very quickly also comes as part of the Platform-as-a-Service.  In addition to that, we also have the billing, and the identity, and the permission modeling that comes as part of this Platform-as-a-Service and, of course, then it's about taking it to market.  So we have the very mature channels and Intuit marketplace, and a newer destination called Intuit workplace which is where the applications actually get deployed to and end-users use those applications to connect with each other and across the data in the cloud.

An example of the kinds of applications that we're talking about are customer explorer that is able now to look over your QuickBooks transactional data, your customer data of all your customers and now being able to use that same data in very different ways compared to maybe the contradictional applications that end users would have had.  So in this context, you're able to see your transactional data in a spacial context across geographies.  This is just one of those examples you're able to go off and subscribe and use this application.  What that means is that for the small businesses now they have these very different applications not just from Intuit working with each other but across multiple partners that are providing great solutions that are solving a very wide range of businesses that are partnering with Intuit to be able to provide.

And because of the common data model, because of the cloud that were providing and the platform with a service is now the end-user and the small business is able to have really this connected set of experiences across these different applications working together for the various different types of users that exist.  So that's a real whirlwind tour of the Intuit partner platform.  We got a Platform-as-a-Service there.  If you'd like to find out more or learn more, you can go to the developer.Intuit.com.

We got the IPP Developer Center that'll let you know how you can get involved and what all the moving parts are and how to sign-up.  if you interesting in experiencing the kinds of applications that we're talking about here, you can go to workplace.Intuit.com and Marketplace is where we actually market those applications.  And one of the many channels that we provide to our ISVs and SaaS to go to take those applications built on our platform to market.  So with that, I'll hand back over to Phil.

Phil Wainewright: Well, thanks Alex.  Thanks for talking us through the very rich capabilities there of the Intuit platform and that very interesting example of how software developers are building on it.  We're going to pause there for a few seconds and then we'll take questions.  I already see that would have one or two come in but we got plenty of time to take more so please take the opportunity to submit them now using the "Ask a Question" button and we'll be back with you in a few seconds.

Alex, one thing you didn't really go into in your presentation was the announcement that Intuit made today about how its extending its partner platform which I think is a good thing because we're debating here the nature of developmental on all cloud platforms and not just Intuit's.  But I do know that we got some questions coming in about that so I'd like to, especially the ones that are relevant to the board or picture here, time permitting.  We are quite time constrained.  We got about 15 minutes for Q&A and then the next session which is on a discussion of SOA and cloud is bearing down on us.  That'll start at 1 PM Eastern.

The other thing that I want to throw in as that we've have some discussion of this topic already this morning on ebizQ Forum site.  And actually, Neil Ward Darden made an important distinction I think between developing in the cloud and developing for the cloud in the sense that there's Platform-as-a-Service which is in the cloud but there may also be developers who are developing on other platforms but doing so for the cloud.  Are those two different things or are they the same things do you think Alex?

Alex Barnett:  I think that there's continuum of purely developing in the cloud and for the cloud.  So take an example of the web-based IDE for example, where no installation is required for a developer (Inaudible) to be able to build applications, Web applications versus having on the other end it of the spectrum having things like Visual Studio or other IDEs that are just fully installed on the desktop and then they're connecting obviously to software life cycle management software that could be sitting out on their network while in the cloud and then developing applications for the cloud so I think that distinction is kind of important.  

from our perspective, what we've done is just -- the majority of developers today develop on local desktop IDEs where it's incredibly rich using all the facilities and the capabilities of a desktop and then you just kind of like deploying to the -- the code out to the staging servers, and Q&A, and then production servers out on the Web.  The opportunities for collaboration though  I think even in that more kind of traditional mode of developing the applications are on you given the new services that are coming online for development organizations and developers.  So for example, being able to run tests (Inaudible) cloud against a code that you developed on your local desktop.  The ability for collaboration between developers on code based that happens to be hosted out in the cloud.  So I do expect that we'll see more and more of the tooling the developers use to develop applications to go out into the cloud.  But I think that choice will still be something the developer wants and whatever suits them, a little bit like the current desktop software for business users.  Some of the like the desktop richness others are moving out to the cloud and are comfortable with it.

Phil Wainewright: Right.  And actually as one of our other commenters on the form Scott Morrison said earlier on that the cloud has an effect -- because of the collaborative elements of the cloud, it has an effect on not just on development but also QA, on documentation on all of the lifecycle processes of application development as much as on the development itself.  So I think there are very various impacts wherever you're developing for.  But I think when you do it in the cloud you've also got this dimension of connecting into the cloud and I think that's one of the big benefits of the Platform-as-a-Service offerings that they all by definition already connected into the cloud.  And I think that's quite an important differentiation.

    We've got one or two questions, I think, this is an interesting one which was also brought up by Dennis (Inaudible) who was blogging earlier today about the (Inaudible).  It's a generic one really because what is if I've developed for a particular platform and I want to change providers.  I mean in the Intuit case, do I have to recode the application before I can move from one platform to another?

Alex Barnett:  Okay.  I think there's a -- just make a couple things clear because I have been reading Dennis' comments on this morning.  And one of the points came out is well, is this really kind of agnostic from a technology perspective?  So the main thing about federated applications is that we've got -- of the five partners that we announced today, there's SaaS applications that went live.  One's running on .NET, pure .NET stack.  The other one's running on the Java stack.  The other one's running on Ruby On Rails and (Inaudible).  And the other one's built up on Flex.  All of those applications are hosted on infrastructure and data centers and built on technology that has absolutely nothing to do with the Intuit partner platform.  Some of them already exists like mature application, SaaS application such as (Inaudible) Response.  And others are actually startups that are looking for ways to get to market to small business customers.  On the technology --

Phil Wainewright: And that's and important differentiation of the particular offering that you've announced today.  But there's still things that people have to do specifically to tie into your delivery infrastructure aren't there?

Alex Barnett: Totally.  And I think that if we were just talking about the cluster of just Web apps that you're able to just point to a URL, and sign-up, and even if it was kind of single sign-on, that's not very interesting.  I think what we're trying to solve is a much bigger problem here.  And I'll just come back to those integration points in the second Phil.  But I think the important thing to understand is small businesses today as they're subscribing to SaaS applications, are not having those SaaS applications work together.  And what I mean by the critical integration point increasingly is the data.  How does this data interact and interoperate across a suite of SaaS applications that a small business might be running to run a backoffice and frontoffice applications.

So the integration that we're talking about is the kind of integration that solves this kind of disconnected dilemma that SaaS businesses have and they're not going to spend the money to fix it for themselves.  How do these different apps work together and then get the flexibility back to the customer around which apps they want to subscribe to knowing that the data is just going to work?  If changed data in one application it's going to be reflected in all the other applications across multiple different teams.  So therefore, the integration that's really there is apart from a single sign-up and apart from user permissions and the whole kind of invitation of other users into your application and model which are that they're important things to be able to provide (Inaudible) where you're dealing with those various different functions from the end-user perspective.

If a application developer just wants to sell their app as a standalone that doesn't work with the integrated data, that's fine they can do that.  They don't have to have to buy an Intuit product in order for them to do that.  If they want that data now to be able to integrate across those applications, even then they don't have to buy an Intuit product.  So we're providing this kind of level of integration for these SaaS applications that immediately that advantage of the existing data that a customer has in a completely different context, in a different application, and leverage that in a new application become immediately of high-value because they tap into that data.  So I don't know if I'm answering precisely the question, but I think that there were a couple of important things to understand about how we've designed the federated apps and the whole data API piece.

Phil Wainewright:  Well, I think there's an issue here in terms of the amount of work that you have to do for each particular platform.  And remember of course, that this is one of Dennis' points is that ISVs out there may actually want to develop for several platforms and lock-in not just the Intuit Ecosystem, but other Platform-as-a-Service ecosystems.  And therefore, they got all of those different API sets to develop to in the same way that they used to have to develop in the conventional on-premise world for a whole set of different deployment platforms.  So when I think it's just a cloud version of the same problem.

But rather than continuing along that discussion line, I just wanted to open up another line of discussion because I think someone --and this is the broader topic, but someone has posted a question in here which basically I think is quite pertinent.  It says could you outline some best practices that an application developer needs to be aware of developing a cloud application?  And I know Alex you've worked with a lot of developers developing for the cloud over the past year or more.  What really are developers finding they need to learn as new best practices when they're developing for the cloud?

Alex Barnett:  I think that the model of both development and deployment and the distribution of software as SaaS Web-based across the web and predominately through the Web browsers with an interface means that there's huge opportunities to be able to get to a (Inaudible) and its rate very quickly over the feedback.  And I think that in general that it's better to get to market quickly with solving a critical set of problems that you've defined and that y you're solving for from an application development software solutions standpoint.  And get it to the market, getting it in the hands of the users, be incredibly tuned into the feedback that you're getting, not just from a user usability standpoint but also from feature set and the capabilities, and let your customer base who are using your applications be the drivers and coders (Inaudible) of your solution, and then use the inherent kind of speed that the cloud provides to then (Inaudible) quickly over and over incremental changes.

You don't -- the nice thing about this is that you don't have to go from a V1 to V2 and this enormous work that's required to be able to make that change happen, and having to deal with legacy software, and the upgrade cycles, and all the rest of that.  The beautiful thing about all this Web-based software is that it instantaneously updates inside of the browser for the user so take advantage.  I think that that's probably one of the single biggest best practices is get to market fast, hear the feedback, get (Inaudible) fast upon the feedback.

Phil Wainewright: Right.  And one of the questions that came in on Twitter earlier and I think it's a bit of a summary question really.  But I mean what are the benefits in moving to Platform-as-a-Service?  I mean if you could say it perhaps two top benefits from your experience, what or maybe three what would they be?

Alex Barnett: Well, one is the whole cost conversation and money.  I mean to be able to develop on a cloud-based application requires -- doesn't require the huge upfront capital investment that's required if you want to setup your own data center with your own infrastructure and the overall stack.  

Phil Wainewright:  Right.  Yeah.

Alex Barnett:  And so, that's I think clearly -- and then the ability be able to pay almost like on a utility-based and pay-as-you-grow model means that a) you're getting to market fast and b) is not be putting the dollars.  And maybe if you're startup, for example, spending those dollars on stuff that really doesn't differentiate you out in the market, its important, its critical stuff to have but where's your IP and where do you want your engineering team focused?  Is it on the underlining infrastructure which adds to the value of the application that you're building out.  So there's that kind of cost benefit immediately.  And I think the second one is speed, speed-to-market being able to have this infrastructure it's just done for you, its set up and you're off actually developing an application rather than spending a lot of time trying to get just the infrastructure right.

Phil Wainewright:  Right.  Okay.  Well, we'll have to wrap up there.  We have other questions that have come in.  Hopefully, we'll be able to get to them in our other session later on during today's QCamp podcast.  So I'm Phil Wainewright, industry analyst with Procullux Ventures and Community Manager for Leveraging the Connected Web at ebizQ.  I've been joined by Alex Barnett who is Group Manager of Developer Relations at Intuit.  Thanks Alex for being with us on what must be a pretty hectic day for you today.

Alex Barnett: Hey, it's exciting.  You do all this work and finally get people to get to hear about it and use it.  It's quite fun.  Thanks a lot for having me on Phil.

Phil Wainewright:  Okay.  Great.  And thank you to our listeners.  Have a good day.