There Is No One-Size-Fits-All Solution
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.
As an example of this problem, I was recently engaged to conduct an architecture and performance review of a high-profile application whose architecture featured a data grid tier. The architect of this application chose to use a single class, implementing dynamic properties [Fowler Props], for all objects cached in the data grid. This choice was not reasonable in the context, because the application had a fixed problem domain easily modeled by someone practiced at domain-driven design [Evans DDD], and the use of a single class with dynamic properties precluded leveraging advanced data grid product features, resulted in monolithic modularization and separation of state and behavior, and contributed to poor performance in the application. Instead of force-fitting one generic data modeling approach, which may have been the architect’s habit, it would have made more sense in the context of this application to implement a more considered object design [Wirfs-Brock OD].
As another example, I’m frequently involved in engagements and communications related to performance optimization of systems based on Oracle’s BPEL Process Manager product. This product uses message-driven beans internally, and the size of the thread pool for executing these MDBs is configurable as a tuning parameter. But the MDBs, and therefore the thread pool size, only come into play for certain archetypes of deployed BPEL processes (namely, asynchronous or durable processes). Invariably, during performance optimization efforts, someone will suggest increasing the size of the thread pool. But that action is not reasonable in the context of a BPEL system featuring no durable processes. In fact it can be detrimental, because the native stack space taken by those threads reduces the amount of heap space available to the Java virtual machine, thus worsening performance by causing more frequent garbage collection. The performance analyst must be aware of which root cause hypotheses and corrective actions make sense in the specific context of the system being analyzed.
These examples illustrate that the most important knowledge of software patterns is the knowledge of when to apply them and when not to apply them, and that 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.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page