• Home
  • RSS Feed
  • Log in


Web performance in seven steps; step 2: Execute a proof of concept
Posted by Jeroen Borgers at around evening time: June 15th, 2009

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.

Share

Tags: Architecture, Java, Performance
Filed under Architecture, Java, Performance, Quality Assurance, Requirements Management, Testing | No Comments »



No Responses to “Web performance in seven steps; step 2: Execute a proof of concept”



Leave a Reply

Click here to cancel reply.


Xebia Sites

  • Xebia Corporate
  • Xebia France
  • Xebia India
  • Xebia Sweden

Categories

  • Java (311)
  • Agile (181)
  • General (136)
  • Scrum (67)
  • Architecture (64)
  • Testing (59)
  • Performance (46)
  • Middleware (56)
    • Deployment (38)
  • Xebia Labs (39)
  • SOA (31)
  • Podcast (31)
  • Project Management (28)
  • Tools (26)
  • Uncategorized (20)
  • lean architecture (20)
  • Quality Assurance (17)
  • Articles (13)
  • Requirements Management (13)
  • Virtualization (19)

Tag Cloud

    XML Xebia Grails Spring Ajax Hibernate Oracle JPA implementation patterns SOA JPA lean architectuur Groovy Agile Eclipse product owner Maven TDD Javascript Scrum Moving to India Java lean architecture ACT Concurrency Control Frameworks agile architectuur Scala Architecture Flex Lean

Archives

  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
Avatars by Sterling Adventures