Eric David Benari contributed a post to MIT CIO Symposium’s CIO Corner blog on Building Sustainable IT ROI:
“When analyzing IT ROI, the ROI-sustainability factor is often overlooked. A frequent scenario involves architecture plans that call for multiple diverse technologies that may each be practical choices on their own, but are virtually incompatible together or require completely different skills/teams to integrate and maintain. To build IT ROI that proves itself beyond the planning stage it is critical that the entire IT-infrastructure, including the human-resources that interact with it, are analyzed as a whole.”
I constantly soapbox on understanding and accounting for the value of IT investments over time, so I enjoyed the entire post. One point though, the essentialness of planning (architectural planning) is especially pertinent to cloud computing. [Emphasis is mine.]
“Fundamental to sustainable IT-project ROI is the concept of building/buying only what you need for now, but architecting so that you can expand & scale with growth later. Some new technologies really allow IT departments to embrace this; an obvious example is cloud-servers that are both elastic and instantly-reconfigurable. This convenience invites a perception that utilizing additional cheap hardware is better ROI than establishing proper scalable systems architecture.
“Scaling-up” may be a solution that is immediately sufficient, but successful projects eventually outgrow this and need to be able to “scale-out”; this is where projects built without growth plans get into trouble and need to start re-architecting in order to be able to horizontally-distribute sources of bottlenecks.”
While it’s easy, from a motivation (cost) and implementation (VM), perspectives to just throw stuff into a cloud computing environment, don’t let your business get caught by short sightedness. Just because the environment scales, doesn’t mean your application will. Remember, software design discipline is an enduring aspect of cloud computing.
PDF 
{ 1 comment… read it below or add one }
This whole “scale out” issue is an especially dificult one for application architects. On the one hand, we are tasked with helping teams develop designs that will meet a well-defined(ish) set of functional needs. On the other we have the problem of having to peer into our crystal balls and to divine the future. About the only thing we can say for sure is that “things will change.” True, but not helpful.
It is the change outwards or scale out that is the hard one. We often don’t have “concrete use cases” or “customer cases” for things we know we should do because if we don’t the result will be as brittle as the thing we replace. So what does allow us to scale out?
Make things asynchronous where ever possible – and introduce a buffer.
Don’t use (database) transactions unless you absolutely have to.
Assume that things will change – independently so build that way
Assume that things will fail – and build that way
Isolate components from each other – you don’t want the bad effects of one having bad side effects on something unrelated.