Getting The Timing Right

I’ve argued for a long time now that getting the right Performance Engineering resources early on in the program can make a big difference, especially on large programs where complex applications, heavy workload and large volumes of data are concerned. This article looks at the merits of bringing on the right set of resources to help the program shape a Performance Engineering strategy tailored to help the program succeed.


Development model doesn’t matter: Every program and customer is different and even within the same organization, depending on the program leadership and complexity of the requirement the choice of development model can differ significantly. Most organizations today have adopted a hybrid model of development which is an amalgamation of the traditional waterfall and Agile development. This new approach to development includes the rigor of the traditional waterfall model while infusing the agility of the Agile Development approach. Either ways, irrespective of the choice of the development model Performance Engineering is always a concern. Having the right capability on the program focusing on the Performance, Scalability, Availability, Reliability right from the start helps build Performance into the design fabric.It’s important to get the right set of eyes looking at the business requirements at the early stages. Working closely with business and IT the Performance Engineering team has an excellent opportunity to work on modelling the Business workload and document the Non Functional Requirements. For systems which are being upgraded or replaced an existing system in production can be referred to when creating the Business Workload. Business workload in combination with the programs Non Functional Requirements will form the foundation of the Performance Testing and Capacity Management approach required later on the program.Working closely with the business, architects and IT teams the Performance Engineering team should be taking the lead in ensuring that Performance, Availability, Scalability and Reliability is built into the fabric of design. It’s important for the success of the program that the essentials building blocks i.e. Workload models, Non Functional Requirements, Scalable design architectures, etc. be put in place so that the Performance Engineering activities scheduled for the latter part of the program can be delivered successfully.

Onshore and Offshore teams: Performance Engineering teams to be most effective should be co-located with the design and development teams. However, due to the nature of activities across a Software Development Life Cycle and the nature of Performance Engineering tasks to be performed this can get quite tricky. In the initial parts of the Performance Engineering life cycle the Performance Engineering leads have to work very closely with business in understanding the application Performance, Scalability, Availability and Reliability requirements. Having done that the Performance Engineering leads have to work closely with business in documenting the Business Workload and application Non Functional Requirements. All of this requires significant interaction with the business team on the program and the IT organization.Once the Business Workload and Non Functional Requirements have been documented and signed off the focus then shifts to working closely with the application and infrastructure architects to design an application that meets the documented Performance, Scalability, Availability and Reliability goals. To be effective a Performance Engineer has to gain the capability to speak to business in a language that they can understand, then work with the architects and speak to them in a language they can understand and then eventually speak to developers and work with them to implement the right set of coding standards towards ensuring that the application delivered will meet the documented Non Functional Requirements and Business Workload.Based on what I have just mentioned above you would have realized that it’s important to be co-located with each of these teams at different times during the application development process to be effective and get the job done.

We rarely plan to fail, we mostly fail to plan: Program fail due to various different reasons and for a large part it’s not the lack of tools or inadequate capability that causes failure but lack of the right approach to addressing Performance Engineering that is responsible. Based on my experience reviewing here are some of the reasons programs fail to meet their business objectives from a performance standpoint.
  • No documented business workload i.e. Txns/Hour, Messages/Sec, etc.
  • Lack of agreement on user experience requirements  i.e. Response Time targets, etc.
  • Lack of clearly defined Non Functional Requirements
  • Lack of understanding of data volumes to be managed
  • Lack of management of customers expectations with regards to expected Performance
  • Lack of the right tools for testing, monitoring, diagnostics and capacity management
The above list isn’t meant to be comprehensive but rather to give you a flavor of what can go on your program if you weren’t to invest in the right set of Performance Engineering resources at the start.

Getting your Infrastructure Capacity and tooling right: Getting on board early on also gives you an opportunity to work closely with the IT teams and the infrastructure teams to validate the infrastructure capacity models. With a clear understanding of the Business Workload and Non Functional Requirements you now have the ability to clearly articulate what is required from an infrastructure standpoint. Armed with the relevant information you are able to help the infrastructure and platform teams make the right decision with regards to investment on computing and storage resources required to help the program meet the document Business Workload and Non Functional Requirements.Starting off early also gives you an opportunity to nail down any gaps that might exist from a tooling standpoint. With a clear understanding of the application complexity, Business Workload, Non Functional Requirements and application architecture one should be able to make an informed decision on the nature of Performance Testing, Performance Monitoring, Diagnostics and Capacity Management tools required to enable the program meets its documented Non Functional Requirements.

Fix what’s broken and get ready for the action: I’ve always advocated that programs start early when it comes to addressing performance. Starting early has many advantages and one of them is being able to address what’s broken including fixing what doesn’t exist. Take the opportunity to understand the bigger picture, understand the customers pains, his business goals and what’s it that he’s trying to do and do the right thing by him. Once you’ve been on the program for a few months, have built a strong understanding of the organizations maturity with regards to Performance Engineering you are in a good position to recommend action that needs to be taken to address the gaps in Performance Engineering across the Software Development Life Cycle that if not addressed would impact your ability to deliver an application that meets the document Business Workload and Non Functional Requirements. These could be gaps in the form of Performance Monitoring, Application Diagnostics and Tuning, Capacity Management, Tooling, etc.Performance Engineering is more of an art that a science. The science is the easy part and can be learnt like most other technical capabilities, it’s the art that’s the tougher bit and the earlier you start investing in it the better off your program and organization will be.

Related Posts

  • Non Functional Requirements and it’s Importance across the SDLCNon Functional Requirements and it’s Importance across the SDLC Why am i writing this article: I find that we keep re-inventing the wheel time and again. Over the last decade I’ve had the opportunity to work at some of the largest organizations around the world and the one sad thing (can assure you that there are numerous good things as well) that i […]
  • NFR Challenges – Is Real End User Experience King?NFR Challenges – Is Real End User Experience King? Importance of Non Functional Requirements - Non Functional Requirements are to Performance Engineers what Functional Requirements are to Developers on a program. Non Functional Requirements are some of the most important (but not the only) and basic building blocks that go towards […]
  • Workload Modelling For Performance EngineeringWorkload Modelling For Performance Engineering Performance Engineering is a combination of Art and Science. Every activity across the Performance Engineering Life Cycle requires the Performance Engineer to have a good understanding of the relevant Application Workload. A sound understanding of the Application Workload is essential […]
  • Let’s not go overboard with our investments in Non Functional Testing!!!!Let’s not go overboard with our investments in Non Functional Testing!!!! Background - When was the last time you were told, “Let’s not go overboard with out investments in a performance validation exercise.!!! On my last project we expended a lot of effort on various Non-Functional initiatives, however the issues we experienced in production were never picked […]