For an Architect, as if deciphering the requirements between Functional and Non-Functional requirements was not enough, DevOps and Technical Debt has opened another head for bunching requirements.

For the uninitiated, DevOps is a movement that is meant to break down the silo approach between the Dev, QA and IT teams, where the code moved in a batch mode from Dev->QA->IT Operations teams. This silo'ed approach meant delay, disruption and duplication of efforts, which ultimately leads to delays in pushing out business functionality.

An organisation embarking on a cloud journey invariably ends up looking for PaaS solutions. PaaS sounds like something that will help me take away all my pains. Creating your application, using drag and drop controls in a browser and everything else taken care (from deployment to running to scalability to back up of data and what not) sounds something exciting and very hard to believe.

Anyway, who wants to deal with the IT folks and deal with all the tantrums they throw, what is possible and what is not.

Capacity Planning is all about managing you resources better. Resources are finite, resources need to be procured, resources come at a cost, resources get consumed, as a result you need to do some capacity planning.

Capacity planning is an exercise undertaken in all the industries. There are plenty of models on how to perform capacity planning. But somehow application of these models in the software industry is too cumbersome, tedious and at times completely useless. These models work best when you have a standardized product and process. In software, every release changes the dynamics of the software product. The code base changes, the code performance changes, the usage pattern might change leading to the failure of the previous capacity planning exercises.

Amazon.com released a one day promotion- Lady Gaga album for 99 cents and the site went down. Lots of customers could not buy the offered album songs. Leaving lot of customers angry and loosing potential business