My youngest son has recently fallen in love with the idea of being a storm chaser when he gets older. Tweet storms are more my speed. There was an interesting one last week from Sarah Mei regarding the contextual nature of assessing design quality:
Context is a recurring theme for me. While the oldest post with that tag is just under three years old, a search on the term finds hits going all the way back to my second post in October, 2011. Sarah’s tweets resonated with me because in my opinion, ignoring context is a fool’s game.
Both encapsulation and silos are forms of separation of concerns. What differentiates the two is the context that makes the one a good idea and the other a bad idea. Without the context, you can come up with two mutually exclusive “universal” principles.
A key component of architectural design, is navigating the fractals that make up the contexts in which a system exists. Ruth Malan has had this to say regarding the importance of designing “outside the box”:
Russell Ackoff urged that to design a system, it must be seen in the context of the larger system of which it is part. Any system functions in a larger system (various larger systems, for that matter), and the boundaries of the system — its interaction surfaces and the capabilities it offers — are design negotiations. That is, they entail making decisions with trade-off spaces, with implications and consequences for the system and its containing system of systems. We must architect across the boundaries, not just up to the boundaries. If we don’t, we naively accept some conception of the system boundary and the consequent constraints both on the system and on its containing systems (of systems) will become clear later. But by then much of the cast will have set. Relationships and expectations, dependencies and interdependencies will create inertia. Costs of change will be higher, perhaps too high.
This interrelationship can be seen from the diagram taken from the same post:
It’s important to bear in mind that contexts are multi-dimensional. All but the very simplest of systems will likely have multiple types of stakeholders, leading to multiple, potentially conflicting contexts. Accounting for these contexts while defining the problem and while designing a solution appropriate to the problem space is critical to avoiding the high costs Ruth referred to above.
Another takeaway is that context can (and likely will) change over time. Whether it’s changes in terms of staffing (as Sarah noted) or changes in the needs of users or changes in technology, a design that was fit for yesterday’s context can become unfit for today’s and a disaster for tomorrow’s.
Form Follows Function 
Very important topic Gene and indeed one of my biggest complaints about the term “best practice” and its usage is the (frequent) complete lack of context, understanding of context and awareness of the impact of context. If it’s “best practice” it means I can apply it without thinking, because someone else has already done that for me 🙂
But anyway, isn’t the purpose of architecture to anticipate these changes in context to ensure that whatever was built (process, system, code, whatever) can survive context-changes within reason and still be fit for purpose?
Sarah’s tweet on spaghetti-code managed by one person is a good example – spaghetti code in itself might not be a problem, but from an architecture point of view spaghetti code is bad because it will rarely survive the context change of the original developer leaving and therefore you do well to avoid it.
This is then in effect where architecture turns from science to art – namely the art of anticipating which context changes are likely to happen and which can be safely ignored 🙂
/U.
LikeLiked by 1 person
“This is then in effect where architecture turns from science to art – namely the art of anticipating which context changes are likely to happen and which can be safely ignored”
Absolutely! The most important (in my opinion) aspect of that art is that it is an on-going process. Far too many view design (and planning, of which design is a sub-set) as a singular, static event. From that point of view, there’s no point in looking very far down the road as you don’t have enough information as to make the right decision. Well, duh!
However, it needs to be understood that the one-and-done point of view is a fallacy. You design/plan like you drive. You pick a general plan and adjust as you go. Sometimes it’s a tactical adjustment (speed up, slow down, brake, change lanes, pick an alternate route), sometimes it’s a strategic one (instead of destination X, let’s go to Y instead). Just as you wouldn’t program a destination into the GPS, put on a blindfold, and follow the directions, you don’t adhere to a plan for any longer than it makes sense to.
LikeLike
‘you don’t adhere to a plan for any longer than it makes sense to.’
Heh, agree. I wonder if the “plan as a tool” vs. “plan as a goal in itself” discussion isn’t deserving of a post of its own 😀
LikeLiked by 1 person
Pingback: This is not a project | Form Follows Function