The chosen architecture doesn't give the required performance


The non-functional requirements will include requirements on throughput and response time, and possibly various other performance requirements.  These feed in to design; design needs to meet both functional requirements typically arriving as an analysis model, and non-functional requirements.  The architecture is the most important feature in assuring performance requirements are met.


Performance requirements could be ridiculously strict, or even theoretically impossible.  These should be identified and referred back to the stakeholders so they can choose alternatives.  They may require technical help in doing this.  Otherwise, performance may not be as good as theoretically possible.  All design involves warping the ‘pure’ analysis model away from its ideals to meet the demands of reality.  This ‘warping’ should only be done where necessary; it helps maintenance to keep the concepts as clear as possible.  Performance tweaking is rarely justified on 90% of any system; the tweaks on the remaining critical 10% will produce most of the possible improvement.  Poor architecture, however, can be a major source of performance problems.

Prevention, Amelioration, Cure


There are various techniques of performance modelling that can be used to screen candidate architectures and keep traffic across inter-component interfaces to a minimum.  In avoiding performance problems from the architecture, it helps if the ArchitectAlsoImplements, otherwise he risks losing contact with the realities of the technologies.  With detailed designers, it is usually better to develop without more than basic consideration for performance, then use a profiling tool to identify hot-spots, and have specialists to tweak performance in these areas.  RUP has an Elaboration phase to develop and ratify the architecture relatively early in the project life cycle, thus classifying Architecture as one of the major common sources of risk.


Modern Agile approaches have few specific approaches for performance, but typically have an “Architectural Spike” equivalent to the Elaboration Phase.  Agile approaches are flexible in response to risk, but there are few cases where architecture will not constitute a risk that needs early amelioration.