Skip to content →

Month: March 2013

Designing a Target Architecture for a large scale website built on Amazon Webservices

I am currently helping out a friend of mine with their startup. They wanted me to design an architecture and technology roadmap for their platform so that they can look to get funding to move things forward. They are already hosting their minimum viable product on Amazon Web services so that seemed like the obvious place to start.

To build a tech roadmap your need to start with the target architecture. I used the Amazon Visio Stencils  to draw up what I consider to be a pretty simple but scalable architecture for the site. The site is predominantly a readonly site so there is not a large requirement for a scalable async workflow, as a result scaling will be provided by adding more web & search nodes and caching, caching, caching.Image

There is a requirement to process a number of feeds which would be delivered using Elastic Map Reduce workflows rather than traditional ETLs and pushing the results out to Amazon DynamoDB for fast, scalable read access.

I have also added Solr as the search platform however this could easily be replaced with ElasticSearch or even the new Amazon Cloud Search (still in Beta)

I then plugged in all the details into the Amazon calculatorto get a monthly run cost of $3617.73

I find that cloud architectures tend to be quite prescriptive and thus the above architecture could be considered to be rather generic for a large scale webapp.

I would be really interested to hear what people think of it and what could be improved.

Leave a Comment

A/B Testing – Should you use it and if so, when?

Imagine making a change to your site based on a gut feeling and then moving on to the next thing without actually being able to prove categorically, that the change had a positive influence on your business. Perhaps you don’t have to imagine that – you do it every day! So imagine being able to make a change and actually measure whether it has made a positive or negative impact on your KPIs (Acquisition, Activation, Retention, Referral, Revenue).  All the big companies (Google, Microsoft, Facebook etc.) are using A/B testing to enable them to measure each change. But when do you use it?

A/B testing presumes that you’ve already bottomed out your problem solution and are now working on scaling, or product market fit. So in essence you know what your product is and now you need to optimise it. Those optimisations could be big or small and we would advocate for being bold in trying out big changes to get some strong measurements back out to learn from. But here’s a presentation that gives examples of what you can do with A/B testing and why a test someone else has run should not necessarily be used to determine what you do.

[gigya src=”” allowfullscreen=”true” allowscriptaccess=”always” width=”500″ bgcolor=”#ffffff” flashvars=”prezi_id=huzarjynislw&lock_to_path=0&color=ffffff&autoplay=no&autohide_ctrls=0″ ]

Leave a Comment

A working app in production in a week?

I strongly believe that the only way to build successful products is to get them in front of your customers. This can often be rather difficult when it comes to setting up a project as you have to buy production hardware, set up a delivery process etc, something that is often ignored at the early stages of a project and as a result the architecture that gets built becomes expensive to manage and the cost of change starts to increase. To prevent this from happening I start with a delivery runway.

You could consider the runway the equivalent of a production line in a car factory. You could build the car in your shed in an adhoc process, but this will not scale as you want to build more. So I look for and adopt technologies that make sure that the first line of code written is deployed into a working production environment. Further to this, I like to deploy to production everyday or even multiple times a day. By reducing the amount of change thats deployed you reduce the amount of risk associated with it, reduce risk and we reduce cost. That means more money to spend on the features of your product that will make a difference.

Having run many enterprise scale solutions in the past it is incredible how much time/cost can be consumed in compiling a release together when a delivery process is absent. Doing this at the end of a long term development cycle creates such a barrier to delivery that it makes many software products uncompetitive. By embracing change and building an infrastructure to deliver that change we can adapt to market shifts.

I am definitely not the first to implement a continuous deliver process and the below presentation from Chad Dickerson CEO of Etsy explains the process and value with a few graphs thrown in.

Leave a Comment

How to justify an agile process?

I often get asked “How much will it cost?” and “How long will it take to build?” which are really difficult questions to answer when you dont have all of the information. This is often compounded  Agile world because the person asking the question may not really understand everything they are asking for.

Why? Building great software is really hard. Infact most software projects fail. As a result it seems pretty obvious to me that we need to change the way we think about projects and that can start with the commercial negotiations.

The below slide deck from the CFO of SolutionsIQ explains, in real money terms, why agile projects win hands down. It also includes graphs and stats that provide a more quantifiable reason to use Agile instead of the Waterfall process

Leave a Comment

A getting started check list

  • Product solves a problem for a specific target customer
  • Capital-efficient business – operational @ < $1M funding
  • Primarily internet-based distribution – search, social, mobile, location
  • Simple revenue models – transactions, subscriptions or affiliate
  • Functional prototype before investment (or previous success)
  • Small but measurable usage – some customers, early revenue
  • Small but cross-functional team – engineering, design/UX, marketing
Leave a Comment

Business Architecture and the Business Model Canvas

One of the challenges when modelling a Business/StartUp/Project (proposition) is to make sure that you capture all the inputs & outputs that can effect your decisions & architectural design. There are often so many unknown factors that effect a proposition that it is all to easy to focus on the visible and happy path aspects rather than digging into the deeper elements that could reveal unhappy truths. Stakeholders can unconsciously hold back important and relevant information that can be critical to your decision making process. Effectively teasing out requirements from stakeholders is a skill set in its own right as people tend create solutions in their minds rather than focusing on the problem. It is our job to get to the problem and that can often be rather hard when the stakeholder has already got a predetermined solution in mind.

Over the last 6 months I have been effectively using the Business Model Canvas as a communications tools to document, validate and brainstorm my clients ideas.


Its a fantastic tool because its structured in a way that poses questions across the whole business model that may not have been thought of, and because its a visual tool it becomes clear very quickly where there are gaps in the vision.

You start by getting your clients to document all their assumptions onto post-it notes and stick them into the relevant cells on the canvas. I have seen many people print off large versions of the canvas that they hang on the wall, however I tend to draw mine onto a white board and then stick post-it notes onto that.


The original Business Model Canvas was developed by Alex Osterwalder and is documented in his excellent book Business Model Generation. The Book is a great introduction to business models and provides a number of default models based on well know established businesses. My only complaint about it would be that it is targeted at the Enterprise, as a result the models are rather too “big picture” for me. I like my models to be rather granular as this enables me to define clear actionable next steps. As a result I tend to blend the Business Model Canvas with elements from the Lean Canvas developed by Ash Maurya author of Running Lean. The Lean Canvas is more product centric which I find to be more helpful as my clients tend to think in products and services rather than businesses.

Once you have gone through the process of documenting the idea onto the canvas I tend to draw it up on a PowerPoint slide deck so that I can capture the Business Model as it develops. The PowerPoint slide deck also makes for a convenient method for distributing the Model to your clients or stakeholders.

Leave a Comment