Over the last 6 months Memia has successfully operationalized and proved a new (for us!), scalable cost model for our software application development business, almost exclusively using cloud infrastructure and services throughout. I'm sure there are a lot of other folks out there who have done the same, but having worked in software for 15 years I wanted to share our experiences - and ask how can you do it for even less? The near-zero financial capital requirements of this model implies that the barrier to entry for software (...as-as-service) is now based almost entirely on how smart your team is rather than how much capital you have.
Business PrinciplesThe business principles we've used to guide our Technology architecture are pretty simple:
- Minimize total cost of ownership
- Opex not Capex where possible - we're a startup!
- Ensure an acceptable level of data security (In particular protection of IP)
- Ensure an acceptable level of usability for staff
- Our priority is to deliver working, tested, software, monthly - we need our IT collaboration services to be available 99.9% of the time at least. However, we can survive the odd outage.
- Content over style: documentation associated with software development does not need rich desktop publishing features.
- Generally we find our team are more productive when they are colocated in the office for core hours every working day
- Trust our staff to uphold security policies and procedures
The first couple of financial principles strongly push towards buying our applications as a service, not as a capital expense. However, when we started out, we still weren't absolutely sure what "acceptable" meant for security or usability: but after trialling some services and reading through the SLAs we decided to see if using the common SaaS collaboration applications which are currently available (in particular Google Apps) would be "usable enough" (they are. With spades on) and "secure enough" (the jury's still out but looking good so far...)
Technology tactics- Bring your own laptop and softphone (each staffmember / contractor gets a monthly allowance to provide and support their own equipment - this is the 21st century everyone has their own laptop, why double up?)
- Cloud for everything. No servers anywhere in our business
- HTTPS and, where necessary, certificate-based authentication for all internet-based communications
- Everything in a browser. (Where possible: most IDEs, application runtimes don't allow for this. There are some examples such as Heroku (Rails) and Force.com are getting there, although that's not so practical yet).
- Wireless internet only
- Work remotely outside core hours if you want (Note: this has implications for Business continuity = go home and work from there!)
- Think of the trees before you print anything - collaborate electronically and round a projector where possible
- Skype is "good enough" for non-sales conference calls
- All integration, system, performance, load and UAT testing is done on Cloud IaaS (either Amazon or GoGrid). Once the testing has finished we wind the virtual servers back down and stop leaking $$$
This means we've ended up with an infrastructure technology architecture that looks (simply!) like this:
...that is, the only capital expenditure on IT Equipment required was:
- Wireless routers (in our case these came free with our ADSL line but we upgraded to our own for better reliability)
- Wireless multifunction printers
- A projector for each meeting room
- PSTN phones (only used for free local calls - looking at getting rid of these as we never use them for business!)
Again: No servers, no datacentre.
Everything else is opex.
Services ArchitectureAbstracting up a level from the networking and infrastructure technology, we've developed a reference services architecture for an software development organisation, shown in the diagram below. This basically enumerates all of the input technology services (ie excluding sales, marketing, HR, real estate) which go into delivering a working increment of the software on a monthly iterative cycle, together with associated artefacts like project management reports and requirements documentation (the output services).
The input application services are divided into two main categories:
1. Collaboration and productivity applicationsWe have become solid users of Google Apps for collaboration as a team - Google Sites especially is a great way for the team to post content and documentation for the rest of the team to collaborate on together. We also use it for our requirements documentation and our BAs work directly with customers to get Use Case and UI screenshots right. It meets most of our requirements, and the real-time collaboration beats client-side productivity tools hands down. We also use Skype for conference calls and, for the most part, it's ok. (And we're at the end of a long thin pipe under the Pacific Ocean here in New Zealand!)
2. Software development applicationsDepending upon what the target application technology is that's being developed, you can mix and match on the software dev apps. (For example for developing ASP.NET applications developers will generally use Microsoft's integrated Visual Studio and Team System toolset, installed on cloud IaaS, but for Ruby on Rails for example you could use Netbeans or Aptana for the IDE, GitHub for source control and then choose your own flavours of continuous integration and defect management).
What I'm still on the lookout for is the best SaaS requirements management tool - any suggestions?
Fundamentally, our experience is that this technology model *works*, and furthermore it *scales*. It cuts the technology costs of running a software development organisation to the bone, and provided that the business in question is satisfied with the security and reliability of using services in the Cloud provides easily the best value solution.
So this is how you design and operate IT for a software development business. How many other industries does this model apply to....?
