Showing posts with label strategy. Show all posts
Showing posts with label strategy. Show all posts

19 March 2011

Tightening the Definition of SaaS and Cloud

I've recently been exposed to two vendors offering "cloud" and "SaaS" options to replace two in-house legacy enterprise/corporate (not customer facing production) systems.

In this process, I connected some mental dots that there are really a few flavors of SaaS, and the distinction is quite important with respect to enterprise architecture.

The two service offerings can be roughly thought of in this way:
  • The offerings were touted as SaaS and cloud
  • New software that is better than our current in-house legacy systems (regardless of whether we host or they are "in the cloud")
  • The software is hosted by the software provider, unknown what type of "cloud" IaaS is under that provider, if any (perhaps just virtualization in their own DC).
  • The software instance is spun up by the provider specifically for us.  It is a copy of the software, dedicated to us.
  • The software can be extended a lot - add-on modules can be activated through configuration changes, bespoke modules/code can be added.  Kinda-sorta like a pick-and-mix or evolving PaaS model
  • Software upgrades must be rolled out with associated consideration of any bespoke changes that have been made.
  • Security restricted to only be available within your corporate intranet
  • Flat monthly rate per user charging model with volume (# of users) price breaks
As the two service reviews went on, the dots finally connected, and I realized I had been *marketed* too more effectively than I'd like to admit.

The above isn't "cloud" or SaaS, at least not with the definition I'm going to take here.  It is actually a hosted managed service offering (MSP or ASP).  At best it's a halfway-house to cloud and SaaS.  All you've really done with this approach is shift some techops and infrastructure responsibilities from in-house to the service provider and reduced your in-house economies of scale (assuming you have to maintain those skills).

For something to be a cloud/SaaS offering in my terms, here is what it needs to be:
  • Public Internet facing
  • One centralized installation shared by many customers
    • Powering the service is an IaaS
    • Can quickly scale up/down with virtually no cost to make the change (costs changing proportional to increased/decreased usage)
    • Horizontal fault tolerance design (HW redundancy becomes irrelevant)
  • Focused offering
    • Service addresses a specific functional requirement, it isn't an omnibus offering
    • Vibrant user community making suggestions of how to improve the product
    • Quick time to market for new features
    • Strong product management and vision
  • Product improvements put live appear immediately for all customers
    • One exception: "beta" version may be option in by the customer, but certainly under the customer, not vendor, control  
    • No rolling upgrades for each customer once a new release is ready
  • A complete set of APIs ("API as a storefront")
    • Almost all functionality available via the application is available via API
    • Well documented
    • Hardened (API security, rate limits, et al)
    • Ready for mash-up integration with other focused offerings
  • Usage based billing
    • Proportional to amount of computation, storage, and connectivity you use (IaaS transparency)
    • Additionally factoring in the value of the SaaS itself
    • No billing related to seats, users, or CPU cores
In noting the difference between the two, I'm not advocating one or the other.  The choice of course depends on circumstances and strategy.  I'm also making no effort to address the common enterprise concerns of cloud such as security, data ownership, and business continuity.  However, I do have a very strong view which way the IT world is going and given the choice, I know which I'd select.

10 January 2009

How to keep IT aligned with the business

1. Stay in close mental alignment with your CEO and other key strategy and opinion leaders in the business (they are "the business"!). Written strategies and project plans are too cumbersome at this level (they are useful for some across and most down management into the organization). Talk frequently with them - where is their head at today and is IT supporting them as best as possible at that moment?

2. Keep those same opinion leaders engaged in IT priorities and deliverables. The IT leader should be able to prioritize with 95+% accuracy because of (1), but you still need their help and support. Keep discussions in their terms, not technical ones. Talk primarily about costs, benefits, and really material risks. For bigger projects, keep reminding them of commitments made between IT and the business in terms of upcoming benefits.

3. Strike a balance of short and long term investment with your opinion leaders. Some IT work only indirectly support the business over the longer term (typically "wiring and plumbing" infrastructure type projects). Visibly balance these with projects that help you "make the sale" or get short term revenue in the door.

4. Align speed of IT delivery with speed of the rest of your business and the market you play in. Speed costs - align views of time-to-market with budget, quality, risks, and aspirations. Kill projects that have missed the market - don't fiddle while Rome burns. If you can't deliver to market requirements or beat the competition, you and your business are in trouble.