Over the past couple months I have got involved with a cloud start-up project with the ambition to build a simple and cheap cloud solution that supports the one-man/two-man/small business order-to-cash process. One thing I've noticed that differs in the start-up situation vs. the usual enterprise conversations that I deal with is that options are both the friend and enemy of the start-up situation. In enterprises certain technical options are usually off-limits due to constraints posed by the business strategy or the business options are hampered by what technically can be supported. In the start-up discussions I have recently been involved in however, all options are open and you can end up in a "chicken and egg" discussion very quickly.
Working with this newly forming project team I found early discussions full of energy but often lacking in structure. Structure in approach with some principles agreed by all participants is necessary to ensure that discussions don't flit around from topic to topic without making progress. As a business technology consultant, my training and experience always keeps my thoughts business focused - what does the market want? what will customers buy? what challenges are they facing? who are they? These are the questions that I depart from and which we sprinkled into our conversation in order to develop a guide for our decision-making. For instance, at the start we had a lot of discussion around the actual solution functionality that we should build. There was discussion about all kinds of apps including eBay add-ons, CRM, inventory management and eCommerce solutions as well as whether integration points to existing solutions were important. Tackling this question from the customer perspective, we did a bit of early market research. Our findings pointed us towards two customer (buyer) perspectives towards today's order-to-cash solutions for small businesses. The first perspective is from the traditional store that is selling goods through a physical shop channel. They buy ePOS systems and usually as a by-product of these systems comes order / inventory / fulfilment and payment management necessary to support the downstream value chain. The other perspective is from the eCommerce channel where solutions can also provide nice looking web front-ends as well as the critical transactional payment and fulfilment functions. Originally, we started with the idea of creating a standalone inventory / fulfilment solution but since doing this quick market research it has become clear that the successful offerings for these smaller businesses are end-to-end. As a small business owner, people are not interested in buying several solutions to support the value-chain they want a simple one-stop solution that will let then focus on their business. So this is what we have decided to now provide. Taking the market perspective into account has changed us to develop an offer that we believe the customer is demanding, rather than what we thought was interesting to provide.
Flexibility in Amazon EC2 / S3 was a deciding factor
When we set out we had (and still do) a plethora of technical options to choose from. Our team is from the java background so they have looked at Google App Engine, Heroku and building directly on Amazon or Rackspace stacks. In the end we have gone for the Amazon choice as it gave us the most flexibility. Heroku was also a final contender with Amazon but their constraints (https://devcenter.heroku.com/articles/java-faq) and in particular their lack of support for sticky sessions put us off that choice. This does mean more for us to do in terms of building out a good framework for development but we found that the flexibility on offer here far outweighed the disadvantages. It is still early days but our architecture plans utilise the options available from HTML5 to the max and use a WebSocket layer to provide rich functionality with good performance. The WebSocket protocol is very basic so we will need another layer over the top. One of the ones we are considering is Nirvana (now part of SoftwareAG webMethods suite ) but the jury is still out. Basically we want to ensure guaranteed message delivery, cope with timeouts and reconnect etc... I'm sure there are some standard ways to tackle this out there but haven't found them yet. (So if there are any other ideas you can suggest then we'd be very interested in hearing your view!) With this set-up there is a risk in my mind about the lack of cross-browser support for the HTML5/WebSockets combo particularly in the IE8/9 domain that are still a large proportion of internet users. However, I'm telling myself (hoping?) that this industry is moving so quick by the time the project is into production the vast majority of users will have upgraded browsers or be able to. (Should be noted that we did this analysis before Google Compute Cloud was launched - maybe we will evaluate Google in due course but for now we aren't going to revisit our choice.)
The challenge of virtualisation and building for the web
Final thing I'd like to remark on before signing off is something I now find so obvious I'm surprised it didn't occur to me until we actually started to look into building our own cloud service. In building a cloud application the technical challenges encountered are basically the same as for developing a web app on virtualised server resources. So on the front-end you need to deal with the challenge of developing a web app (so thinking about browser compatibility for instance) and on the back-end the virtualisation aspect means you have generally weak IO capacity and need to figure out some tricks around that. In addition, you have to assume that the resources are transient and subject to failure and you have to build a robust framework to deal with this. Like I said blindingly obvious, but for some reason I wouldn't have explained it so simply until I actually got to work on this project.
On the look-out for collaborators...
I didn't have any specific purpose to writing this post. It's just been a long time and I wanted to share some of the stuff I am working on at the moment. However, now I get here I think it's a good time to ask if there are is anyone out there wanting to collaborate with us on this. There are two particular areas I would love to chat to someone on. The first is on the technical topic around using HTML5 & WebSockets - this is something we are working through now. The second, is on the business side of running a small business managing inventory. I would be really interested in talking to you on your challenges and requirements to feed into our design. Perhaps you can benefit from our first (production) release. If you are interested, then don't hesitate to get in touch through LinkedIn or Twitter.