Why Team Foundation Server should have been SaaS'ier!

  • Article

I read the first of a part series on SaaS this morning, called Architecture Strategies for Catching the Long Tail, and something occurred to me. Back in November, 2004, I got stuck into Team Foundation Server (it was the November CTP). As I was using it, I thought, this is going to become big. But for some smaller companies, who require it as part of their core business, the sheer infrastructure and maintenance overhead in releasing and maintaining this software is going to be a differentiator as to whether they adopt TFS or not. To me this seemed crazy, that you could forsake a critical piece of software, just because it was too hard or too expensive to deliver. I started playing around with the idea of hosting TFS, because, if you could centrally host it, and rent portions of it out to customers, then they get the silver service, but only pay a fraction of the cost.

So as I’m reading this article on MSDN, a couple of things stuck out, and made me ask the question, why wasn’t TFS designed with SaaS and Multi-tenancy in mind from day 1? Some great aspects of this article are:

  • What is SaaS? Software deployed as a hosted service and accessed over the Internet.
  • With traditional software licensing, you never own the physical binary bits anyway, you just have the right to use the software, so with SaaS, there is no difference. But customer perceptions have always been, I’m buying something tangible that I can control, in terms of deployment, use, support and maintenance.
  • If you spend 40% of your budget on software now, and the rest on maintaining and delivering that software to your business, then in a SaaS model, you off-load that cost to the SaaS provider. So aren’t you just moving the cost to someone else for hardware and services? Not really, because they charge you a fraction of that cost, and spread the overall hardware and services cost across all their subscribers. Makes a lot of sense for some applications.
  • Ahh, the SaaS maturity model, now I’m getting it! Four levels; Ad Hoc/Custom; Configurable; Configurable, Multi-Tenant-Efficient; finally Scalable, Configurable, Multi-Tenant-Efficient.
  • SaaS is not the Application Service Provider model with botox!
  • Three factors which effect SaaS delivery model; Business, Architecture and Operations
  • Security is dealt with using a centralised or decentralised model; both having an impact on overall application architecture complexity

For my part, I can’t help but think the real value impact of SaaS is going to come in the form of high-value, tenanted web services being consumed by SaaS aware Smart Client applications; almost going towards a mash-up meet metadata concept. You know, you run a SC app on your tablet that connects to a swag of SaaS endpoints provided by many vendors, and the SC app is capable of integrating (mashing) the services together. Now that would be powerful! Can you imagine, having your SC app able to pull map info from one service, feed that to a shopping search service with your location data, and voila, you can find the closest book store to where you are at that moment.

Anyway, I’ll be getting onto this article next, Multi-Tenant Data Architecture, so will do a quick review of it soon.