Business Requirements, Solution Architecture, Infrastructure Architecture, Application Architecture, Detailed Designs and followed by code. A common pattern and sequence of artefacts which are delivered in the Software Development Life Cycle that most of us are familiar with in Enterprise System Development. By the time a single line of code is etched we have already made a number of design decisions, selected key frameworks and began building and implementing the solution for the realisation of the business system. Till this point, most well thought out and managed projects will have already made an attempt to specify the performance requirements of the system through Non Functional Requirements, where response times and volumetrics are explicitly stated for the purposes of sizing the capacity of the system.
Typically, the volumetrics can be used to model the work which the system must perform to process the business activities using metrics like throughput and transactions per second. Response times are then used to constrain the system wait times and ensure the system can respond back to the end user or client system in a timely manner. These performance dimensions are both efficient and accurate methods to ensure architects can design the system to meet the business capacity requirements.
From a functional perspective, system testers verify the business rules are correctly implemented and the system is fault free and tolerant in all business scenarios. Then from a non-functional perspective, the performance volume team ensure that the system is fault tolerant and performs to specification throughout the expected usage volumes. As performance volume testing is typically performed very late in the SDLC, performance problems especially in custom build scenarios, can cause significant rework to the system and potentially jeopardise production deployment timelines and cost the program in schedule overruns and budget blowouts. We can raise program risks and issues throughout the program to track and put mitigation plans in action to avoid performance problems, however its very difficult to ensure a system will perform as designed without having a specific focus on performance throughout the design and development life cycle.
Enter The Performance Architect.
Having a focus on performance during all phases of the program (starting form requirements) is critical in managing all performance risks inherent in all large scale programs. The Performance Architects first job is to ensure the non-functional requirements are focused on setting the correct business objectives so the performance requirements are accurate, valid and achievable by the system. Having set accurate and achievable performance targets, the following solution and technical architectures will remain in check and will ensure the designs are performance considerate. How is this achieved? Architecture reviews, design reviews, infrastructure design reviews and finally code reviews. Furthermore code refactoring provides a very powerful and potent method of ensuring the system attains our performance objectives through the deployment of Code Profiling and Component Performance Testing patterns. An implementation of this pattern is what l call the Performance Unit Test which l discuss in detail in my blog entry.
Typically we generate a plethora of Architecture documents as part of the SDLC and l’m definitely not an advocate of adding more documents to the pile, however the humble Performance Architecture or Performance View should be used to augment a solution design and provide clarity and guidance for major system components such as Web Server and Application Server configurations. A good example here is the need for a Web Server cache. A performance architecture will define the need and configuration for a Web Server Cache like CacheRight to ensure bandwidth requirements are modelled, provide view for metrics collections and model the response times of each sub system.
At Odecee we have created an architecture practice that involves specialisation in performance through formal offerings in Performance Architecture. The uptake in our performance services in and around our performance architecture competency have added direct value to their SDLC and its pleasing to see the outcomes achievable by deploying and augmenting performance centric practitioners into client architecture teams.
So Ill finish by asking my readers a simple question; Can we afford to neglect this vital design elements of an enterprise business system?
Categorised in: Uncategorized
This post was written by Oscar Huseyin