Architect your solution around the customer experience

I was at QCon yesterday, ostensibly to give a presentation on usability, but I attended a few sessions as well.  Not being a techie, I didn’t understand much of what Werner Vogels, the CTO of Amazon was talking about during his presentation on Availability and Consistency, but one thing has stuck in my mind.  “Never, never refuse the customer from putting stuff in the shopping cart”.  The context of this was around how your architectural design; do you go for consistency or availability (or something else which I can’t remember).

I’ve blogged before about siloed organisations, but Werner touched on how even internal IT organisations can be siloed.  Something about how your database team may be soley focussed upon consistency; they are willing to sacrifice availability for valid technical reasons.  But the database needs to be seen in the bigger picture, outside the confines of the IT organisation.  It needs to support the customer experience.  And that means the customer must always be able to put items in the shopping cart.  Period.  The takeaway I suppose is to build your architecture around the customer experience; decompose the experience to do this.  The technical requirements for your shopping cart will be different from your fulfilment mechanism from your “see what others are buying” from your “my details”.  Make technical decisions accordingly, rather than a one-size fits all.

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!