Last week I blogged about setting your performance goals: defining your requirements. This time I'll blog about the importance of a Proof of Concept for performance.
The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.
Such fashion items are for example CORBA, CGI, applets, EJB, Struts, Spring, Server Faces, XML, SOA, OMT, UML and RIA to name a few. Often new, bleeding edge technology is used in a project just for the sake of being trendy. In addition, each technology or framework comes with its own teething troubles and largely uses more resources than its predecessor. Goal of such a new technology is generally improvement of flexibility, productivity or maintainability, and performance usually has no priority or has not even been considered at all.
Therefore, it is questionable if the chosen new technology and architecture will meet the specified performance requirements. In practice, this regularly becomes only evident in a late stage of the project: when it has already slipped beyond the planned production date. Only then it may become clear that the chosen technology or architecture is just not sufficient. And switching to a different technology or architecture usually results in high cost and long delays. Therefore it is essential to execute a Proof of Concept for performance in which all technology and architecture components are touched, in a vertical slice of the application. It is important that this test is performed in a sufficiently representative manner, on which I will elaborate in my next post. By executing this PoC and understanding and using the results of it, the project can early be corrected in the right direction to prevent excessive cost and delay.
Next time I'll blog about step 3: representative performance testing.