As Prince Charles (you know the one once married to Princess Diana) might say “Beautiful Architecture is there to be admired, stand back and enjoy the view”.
No, I haven’t posted to the wrong blog, this is about computers not buildings, but this post is not about the detail it’s more a ‘stand back and think about what you want to see’. SaaS architecture comes in many guises and, like most things in life, adapts and evolves over time, so when you are sketching out your architecture and standing back to admire your work, keep 2 thoughts in the front of your mind:
- My company is on a journey, therefore my architecture is too – be tactical
- We’re all a long way from Nivarna
In the early days of SaaS (when we used to call ourselves ASPs), the vast majority of SaaS businesses evolved from web apps that had been successfully sold to one or more customers in a traditional licence deal, where the CEO suddenly get’s a “Michael Caine Moment” (“Hang on lads, I’ve got an idea”) and henceforth this software company calls itself a SaaS company. More often than not this also means the architecture (hardware and software) isn’t exactly “designed” its more “acquired”.
Don’t be fooled (or let anyone else fool you for that matter), into thinking that you need to have pure SaaS, all singing all dancing architecture with a tinted gearbox and double overhead wobble board from the word go – it just ‘ain’t true. There is nothing wrong with transitioning through the “hosted – hybrid – pure” models. Also don’t get hung up on single points of failure.
On many occasions I’ve been approached by a member of the sales team asking for architecture diagram (hardware) because a customer has requested it along with details of how we avoid single points of failure. I always politely decline such requests as nine times out of ten the salesman still has a little more to do in his sales cycle and the customer is looking for excuses, usually these come in the form of single points of failure.
Now, until you really have more cash than you can spend, don’t give single points of failure too much thought, Here’s why:
- Practically you need 3 of everything to avoid a SPoF (up to and including 3 datacentres).
- The vast majority of hardware (good stuff) will outlast your financial write down.
Instead concentrate on 2 things that should be entirely within your control:
- Uptime
- Performance
If you are using good hardware the amount of unplanned downtime you have through, say, CPU failure will be negligible – it doesn’t take long to swap out a CPU.
Software Architecture is where your efforts are best employed as this directly impacts performance (but you probably didn’t need me to tell you this!). For this an API structured architecture that allows you to add (and remove) any form of functionality or extension by way of a service or API will give you the best foundation from startup.
Most companies, SaaS or otherwise, end up selling a variant of what they started out with, natural evolution. The point here being that the more modular (or “pluggable”) you make your architecture the more agile you can become in responding to trends and opportunities. It also allows you to easily manage performance bottle necks. (Remember bugs tend to affect a small proportion of your customer base where as performance tends, more often than not, to affect all of your customers).
Spend time planning an architecture roadmap that supports (not leads) the overall business roadmap. Remember for any software business to be successful it must be sales led. There’s little point in having a pure SaaS architecture that can support thousands of users if the business isn’t likely to get thousands of customers in the coming 3 years. Only go straight to pure SaaS if you have the cash in the bank to fund it. If it’s not in the bank, evolve your architecture through the “hosted, hybrid, pure” path and concentrate resources on more tactical development priorities. Do plan on having pure SaaS architecture though – if your business succeeds you’re gonna need it!
Leave a Reply