Chapter 12. There Is No One-Size-Fits-All Solution
Randy Stafford is a practicing software professional with 20 years’ experience as a developer, analyst, architect, manager, consultant, and author/presenter.
Currently for Oracle’s middleware development A-Team, he engages globally for proof-of-concept projects, architecture reviews, and production crises with diverse customer organizations, specializing in grid, SOA, performance, HA, and JEE/ORM work.
ARCHITECTS MUST CONTINUOUSLY develop and exercise “contextual sense”—because there is no one-size-fits-all solution to problems that 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 (Prentice Hall):
[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.” (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 failure to apply domain-driven design[1] 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.
[1] See Eric Evans’s Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley Professional).