Picked up a couple of posts over the last few days with respect to on-premise SaaS offerings. First up was Gianpaolo Carraro over at Microsoft talking about intra-preneurial SaaS. This is a topic that I’ve discussed a number of times and whilst I’m in complete agreement that taking the benefits of SaaS into the enterprise is a good thing I also feel that it’s in enabling business capabilities to be delivered as services that the real value lies; i.e. conceiving of the organisation as a set of collaborating service providers rather than just encouraging the IT department to make applications available in a new way. Such a model enables greater focus on the capabilities that actually add value to the organisation and prepare the ground for future unbundling by raising management purview to business capabilities in place of applications and technology. In this context I was also delighted to see Gianpaolo describe the supporting infrastucture as a ‘service delivery platform’, since to me the need to deliver such future business capabilities as viable services with proper management, reporting and monetisation is a critical requirement and one often overlooked by SOA implementors. Taking this argument a bit further – especially given that the question originated from Sinclair Schuller over at SaaS blogs (who is connected with Apprenda) – the question for me is whether the service delivery platforms to enable intra-preneurial SaaS are better built in house or leveraged from external platform provders? For me the answer is that enterprises should absolutely use external utility computing platforms to support the service enablement of their business capabilities and stop wasting time, money and brain power grubbing about in the weeds of technology. A big issue with this currently, however, is one of trust; many large companies have not yet achieved a level of comfort with externally provided, multi-tenancy service platforms that would enable them to make this giant leap forward.
As a result of this I was delighted (again) to read a post by Phil Wainright over at ZDNet talking about SaaS appliances. In this context I’m thinking more of the service delivery platform being delivered as a ‘SaaS appliance’ but the argument still holds. As I stated in this post, I believe that there will be a place for both multi-tenancy and onsite utility computing provision and so again, I am in complete agreement that the provision of SaaS offerings need not always be across the network. In fact I believe that ‘utility computing’ platforms will be available both in a centralised, multi-tenancy form but also as an on-premise option linked into the wider management processes of the service provider. Either way the service provider can take advantage of standardisation and economies of scale across customers, even where some parts of the platform that they support are physically located outside of their data centre. This ability to provide standard service delivery platforms across customers is, however, a key element of IT industrialisation, a topic discussed by Nick Carr in another recent post. Nick’s post basically summarises an article that he’s written for the Guardian newpaper in the UK where he points out the increasingly onerus tasks of managing the infrastructure needed to deliver services in the new on-demand world; as an end enterprise who wants to concentrate on differentiating myself in my chosen market why wouldn’t I take advantage of the investments of infrastructure providers in the creation of bullet-proof service delivery platforms rather than continue to invest and suffer the pain of creating smaller scale, less reliable infrastructures for myself? The beauty of all of this, however, is that I will increasingly be able to start small by delivering some initial services on utility platforms deployed within the bounds of my own organisation – since even there my costs will be lower than extending my current environment due to the infrastructural providers’ economies of scale – and transition away from my bespoke, costly environment over time.