Performance

Engineering
Services

What is an Architecture Assessment?

An architecture assessment is a formal review that examines architectural decisions with respect to their impact on performance as well as other quality attributes, such as reliability or modifiability. Ideally, it is performed early in the software development process.

An architecture assessment:

• Is relatively quick and inexpensive to perform.
• Identifies potential risks within the architecture with respect to performance and other quality requirements.
• Identifies solutions for reducing or eliminating those risks.

Architecture Performance Assessment is Vital

Performance assessment of a software architecture determines whether the architecture will support the system's scalability and responsiveness requirements:

• For problem systems,it determines the extent of the scalability and responsiveness improvement that can be achieved with tuning and other minor modifications, where to focus efforts, how to achieve requirements, and how long it should take.
• For new development, it uncovers potential problems early in the development process when they are easier and less expensive to fix.
• For legacy systems, it determines whether to continue to commit resources to the current architecture or migrate to a new one.

The PASA^SM Method

PASA is a rigorous, systematic method for the performance assessment of software architectures. It was developed by Dr. Lloyd G. Williams and Dr. Connie U. Smith. PASA uses the proven performance engineering principles and techniques described in their book Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software.

A PASA assessment consists of the following steps:

1. Process Overview–The assessment process begins with a presentation designed to familiarize both managers and developers with the reasons for an architectural assessment, the assessment process, and the outcomes.
2. Architecture Overview–In this step, the development team presents the current or planned architecture.
3. Identification of Critical Use Cases–The externally visible behaviors of the software that are important to responsiveness or scalability are identified.
4. Selection of Key Performance Scenarios–For each critical use case, the scenarios that are important to performance are identified.
5. Identification of Performance Objectives–Precise, quantitative, measurable performance objectives are identified for each key scenario.
6. Architecture Clarification and Discussion–Participants conduct a more detailed discussion of the architecture and the specific features that support the key performance scenarios. Problem areas are explored in more depth.
7. Architectural Analysis–The architecture is analyzed to determine whether it will support the performance objectives.
8. Identification of Alternatives–If a problem is found, alternatives for meeting performance objectives are identified.
9. Presentation of Results–Results and recommendations are presented to managers and developers.
10. Economic Analysis –The costs and benefits of the study and the resulting improvements.

¿Qué Pasa?

Scalability and Responsiveness Must Be Built In

Performance, both responsiveness and scalability, is critical to the success of todays software systems. Many software products fail to meet their performance requirements when they are initially constructed. Fixing these problems is costly and causes schedule delays, cost overruns, lost productivity, damaged customer relations, missed market windows, lost revenues, and a host of other difficulties. In extreme cases, it may not be possible to fix performance problems without extensive redesign and re-implementation. In those cases, the project either becomes an infinite sink for time and money, or it is, mercifully, canceled.

Performance cannot be retrofitted; it must be designed into software from the beginning. The "make it run, make it run right, make it run fast" approach is dangerous. Our experience is that performance problems are most often due to inappropriate architectural choices rather than inefficient coding. By the time the architecture is finalized, it may be too late to achieve adequate performance by tuning.

Managing Sofware Costs

Software functionality is obviously important. Over its lifetime, however, the cost of a software product is determined more by how well it achieves its quality requirements such as performance, reliability/availability or maintainability than by its functionality.

Architectural decisions are among the earliest made in a software development project. Thus, they are the most costly to fix if, when the software is completed, the architecture is found to be inappropriate for meeting quality requirements.

Architectures: Strategic Business Assets

Software architectures, the software components that make-up the systems and the interactions among them, are strategic business assets for organizations that depend on software for products or business processes. While a good architecture cannot guarantee attainment of quality requirements, a poor architecture can prevent their achievement.

Balancing Performance and Other Requirements

Software performance is not achieved in isolation. Performance must be balanced with other software quality concerns including: reliability/availability, safety and modifiability. Sometimes, these quality requirements conflict. We can help you identify areas of your architecture where conflicts occur and quantify their impact on your system performance so that you can make informed trade-off decisions.