Software Architect Category: Software Architect - Page 46 of 52

97 Things Every Software Architect Should Know – 13/97

Business users specify their needs primarily through functional requirements. The non-functional aspects of the systems, like performance, resiliency, up-time, support needs, and the like, are the purview of the architect. However, often the preliminary testing of non-functional requirements is left until very late in the development cycle, and is sometimes delegated completely to the operations team. This is a mistake that is made far too often.

The reasons are varied. There is presumably no sense in making something fast and resilient if it doesn’t actually perform the required function. The environments and tests themselves are complex. Perhaps the early versions of the production system will not be as heavily utilized.

However, if you aren’t looking at performance until late in the project cycle, you have lost an incredible amount of information as to when performance changed. If performance is going to be an important architectural and design criterion, then performance testing should begin as soon as possible. If you are using an Agile methodology based on two week iterations, I’d say performance testing should be included in the process no later than the third iteration.

Why is this so important? The biggest reason is that at the very least you know the kinds of changes that made performance fall off a cliff. Instead of having to think about the entire architecture when you encounter performance problems, you can focus on the most recent changes. Doing performance testing early and often provides you with a narrow range of changes on which to focus. In early testing, you may not even try to diagnose performance, but you do have a baseline of performance figures to work from. This trend data provides vital information in diagnosing the source of performance issues and resolving them.

This approach also allows for the architectural and design choices to be validated against the actual performance requirements. Particularly for systems with stringent requirements, early validation is crucial to delivering the system in a timely fashion.

Technical testing is also notoriously difficult to get going. Setting up appropriate environments, generating the proper data sets, and defining the necessary test cases all take a lot of time. By addressing performance testing early you can establish your test environment incrementally avoiding much more expensive efforts once after you discover performance issues.

'Coz sharing is caring

97 Things Every Software Architect Should Know – 12/97

Architects must continuously develop and exercise “contextual sense” – because there is no one-size-fits-all solution to problems which may be widely diverse.

The incisive phrase “contextual sense” was coined, and its meaning insightfully described, by Eberhardt Rechtin in his 1991 book Systems Architecting: Creating & Building Complex Systems:

[The central ideas of the ‘heuristic approach’ to architecting complex systems] come from asking skilled architects what they do when confronted with highly complex problems. The skilled architect and designer would most likely answer, ‘Just use common sense.’ … [A] better expression than ‘common sense’ is contextual sense – a knowledge of what is reasonable within a given context. Practicing architects through education, experience, and examples accumulate a considerable body of contextual sense by the time they’re entrusted with solving a system-level problem – typically 10 years.” [Rechtin SysArch] (emphasis in the original)

A big problem in the software industry, in my opinion, is that people are often responsible for solving problems requiring more contextual sense than they‘ve accumulated. Perhaps this is because the software industry is barely two generations old and growing explosively; perhaps it will be a sign of maturity in the software industry when this problem no longer exists.

I encounter examples of this problem frequently in my consulting engagements. Typical examples include failures to apply Domain-Driven Design [Evans DDD] when appropriate, straying from a pragmatic outlook and over-designing a software solution for the essential need at hand, and making irrelevant or unreasonable suggestions during performance optimization crises.

The most important knowledge of software patterns is the knowledge of when to apply them and when not to apply them, and the same is true of different root cause hypotheses and associated corrective actions during problem analysis. In both activities – system architecting and problem analysis – it is axiomatic that there is no one-size-fits-all solution; architects must develop and exercise contextual sense in formulating and troubleshooting their architectures.

'Coz sharing is caring