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.