A Trace in the Sand
by Ruth Malan
What's a Trace?
My Trace is a playground for developing ideas, for exploring architecture and the role of architects. It is a journal of discovery, and traces my active reflection. I've been journaling "out loud" here for over eight years. To get a sense of the span, calibre and contribution of this body of work, there's a selection of traces linked here. When reading a trace in isolation, it may feel like you've been dropped into a thought fray unprepared for the action that is already in progress. It's okay. You're smart, and my Trace assumes that. You'll get your bearing quickly. Just give it a chance.
It is a journal. That is, it is an informal trace of wandering, exploration, discovery. The insights are there in their sparkling bucketfulls, but there are fewer clear onramps and offramps to and from them. ;-)
Sure. It may be difficult, textured, relying on emergence and recursive structures, polythematic, playing with delicate and intricate harmony sometimes, discordia others... So?
Shouldn't writing for smart people expect us to rise to the occasion of it? And this is an occasion! It is the writing of now, as it unfolds. It can feel unsteady, foggy. But in the clearings, how gorgeous it is! No?
No? Oh. Well. I try.
July?!? And Me, London, October!
Goodness me, June went by in a flash!
Well, whatever else happened in June, it was largely overshadowed by this kindness:
Richard was being playful and that kind of wry humor so works for me. Of course, if this field had the sense to be interested in what I do, I would be legendary, no?
No?!? Well. You're just no fun. :-)
I insisted on the "different" framing of my speaker image because my workshops are very much like that -- about me not being the central figure, but rather creating space where we all contribute to building the experience together. I am forceful, but I apply that force to enacting and creating what I value. It's about inspiring and enabling, not dictating. I bring a lot of experience and insight -- and questions -- to the table, and so does everyone who participates. Let's do this!
Oh. And while we're allowing ourselves a rare moment of seeing Ruth in a kind, perhaps even overly generous, light, do please take a moment to relish my framing:
Puts all those characterizations/definitions of software architecture in their place, no? ;-)
<What is she getting at?>
I heard that. You know. It's not just "high cost of change" but strategic and structural significance.
While we're on one of those "would you just take a moment and marvel at what I did there" kicks, let's also revisit:
Aaaand. As awesome as that is, and all that, it is also wrong. ;-) Well, wrong if you interpret it to mean hierarchical decomposition. There is some aspect of that, but (technical) wisdom applies, and design/technical wisdom has multiple facets. Among them, is insight into side-effects and action at a distance (spatial/organizational and in terms of time), with implications for priorities and significance, and timing and what needs to be tackled sooner and what can be deferred without undermining strategically significant outcomes. You know the refrain: Judgment factors. And factors and refactors. There is working different facets, there is back tracking, considering alternatives and trying different things out, there is sometimes working in the details, and sometimes drawing back out to design at larger scopes of impact, influence and interaction.
Aaaand. If that weren't enough. The very intention changes, as we learn what is possible and desirable. Sometimes more. Sometimes less. And in all this, we need to get ground under the feet, so to speak. Gain traction. Make something that provides value, makes a contribution.
Design ascertains what it is we want to accomplish, and how to do so, addressing the inherent challenges -- technical and non. It is not a linear process. It is not a do-once sort of thing. There is a lot of discovery -- the interaction of the thing with its containing system changes the containing system(s), and hence what we want from the thing. And hence it's inherent challenges. And so on. Messy. Mixing creativity and engineering, working towards creating value, but also engineered integrity -- structural integrity and resilience, adaptability and agility, sustainability. And design integrity, harmony. Even, where it matters, delight.
And architecture, as system (of system) design and art.
7/9/14: Delightful discussion of Feynman's delightful "There's Plenty of Room at the Bottom" speech:
Reading that, I was thinking about something I read on the development of the iPod Touch, and how the innovation process is similar, from the point of view of coming up with questions and probing approaches. Sure, there are more big challenges and big unknowns with disruptive new technologies, but development of anything that pushes some frontier or other -- even just the complexity frontier of new features piled on legacy features -- has challenges and uncertainties, necessitating exploration of possibilities.
7/9/14: Thought provoking (thanks!):
While I do incline to characterizations of design as decisions (outcome: prescriptive/intention or enacted/actualized) or making decisions (process), I sense that the lines aren't so clear cut as Carlo is proposing.... that is, design can describe how something is intended to be structured and to work, or how it is structured and does work, without describing why it should be structured and work that way. That is, addressing "why" suggests a more explicit, reasoned decision process. We can -- arguably do, often -- design intuitively, making a myriad implicit decisions. For significant decisions, we want to make the rationale -- that why -- explicit, to weigh and resolve the design tensions better, and to better convey the decisions and how they were arrived at, but also to offer the reasoning -- what was taken into account, what tradeoffs where being considered in the design envelope, etc. -- not just to justify and connect the dots, but to encourage assessment and probing and improvement. As well as for conveying design savvy, mentoring others in the design process by making more of the design thinking, the considerations and the workable solutions and approaches, accessible to them. We externalize our designing thinking to advantage ourselves of various avenues of cognitive assistance -- memory enhancement (our working memory is limited) and reasoning tools like modeling and engineering tools from math to simulations and prototypes, reflection and conversations bringing various perspectives to bear, etc.
This is a useful observation and reminder:
7/5/14: One of the awesome things about reading here, is that you get to be coached by Dana by proxy. Tonight he used the analogy of one DNA strand coming from "the business" and the other from "technology" to make up the solution. I like that image!
7/22/14: To which Paul Harland responded with a pointer to Spiral Dynamics -- thanks Paul.
Atypical -- in a Good Way? [And: Thanks for the Signal Boost!]
I love the insight cast in sparkling turn of phrase here:
And I'd like to suggest that my trace is full of insight, some scooped up from others, but many wrung from (my own and others) experience and reflection. Each trace may seem like a playful and disrespectful waste of time... until you see the insights it tickles to dancing life.
7/5/14: Also. Many thanks to Amitai Schlair, Paul Harland, Stuart Boardman and Gene Hughson for amplifying my signal through the kindness of mentions and retweets. I am so grateful to them. (Yes, Peter Bakker, you too. :-) Love your photo stream, but I also wish you'd get back to tweeting and sharing where you look and what you see in the systems architecting and mapping/visualization space.)
Since these are people who have special powers of seeing, if you aren't following them, may I suggest you do? And since it is such a long way from the jubilant thanks a couple of traces up, I need to add: follow Richard West too, of course.
As for me, I have to resist every impulse to self-censor putting my Trace in a positive light. It is an unusual approach in any context, but especially so in a field that tends to the more formal in writing for our profession. This is ... highly informal and trace-y... Conversational, yes, but not just a conversation, no? That said, conversational and exploratory are important here. Participating in shaping the identity, self-concept and approaches of a field is important work, must be delicately done, in dialog with others, right? Anyway, my Trace needs someone to say "look, it may be different, but it is different in a good way, in a way that aligns with all the values we are professing. Values like collaboration and flexibility and openness to discovery and... Um. Failing." Hm. How'm I doing? Persuaded? I can self-promote in this little postage stamp lot on the i-Way? ;-)
Does that make sense? An unusual work has to be positioned positively, or people will overlook it, not knowing what they are looking at, or past. Because traces aren't designed to be structured nuggets, they are atypical and the casual glance is not going to uncover how powerful the style can be. It is powerful, isn't it? It lives its message, really -- design has to embrace being sketchy and informal and collaborative and dynamic, at times, even though, at others, it needs to be more rigorous and structured, achieving "industrial strength"... So isn't it good to also make allowance for embracing the messiness of the process that moves frontiers of understanding...? And isn't that what this Trace does?
Have I done rationalized this good? ;-) Well? Are you persuaded?
Image: went to fetch the dancer girl, and got to enjoy watching the pelicans fishing in Florida -- got lucky with some dive action shots too. If you think I'm fishing for compliments, you might enjoy the image. ;-)
Technical Debt, Extended
These snips are here to remind me that the conversation on extending the "debt" metaphor loosed some thunks to trace... when I get a moment...
I'm going to make another of those attempts at regrooving habits, and take a digital break. :-)
The Power of Pairing
The architect competency model includes consulting (mentoring and coaching, pairing to problem solve, etc.), which I think of as, in large degree, enabling others to be successful.
I wasn't meaning, by proximity, to suggest any direct and foregone connection between "we design" and "has a design" -- that is, I wasn't meaning to suggest I am not mindful of the incidence of accidental architecture; prompting that notion to emerge, was an accident of the structure. :-)
I was merely pointing to "design" having two substantial and different meanings (act, and outcome), which has implications for approach and medium (for example, are we seeking to support the act of designing, versus "seeing" the design in the built system). I illustrated the distinction with "design a system" (act) and "has a design" (outcome). Sure, this is the classic verb versus noun distinction that appears in the dictionary. The point was to rephrase in a way that helps us think about code as a design medium for the two different understandings of design -- design as act, versus understanding and communicating the design as built.
Of course, putting the two in close conjunction, does tend to prompt to mind the disjunction that occurs when system design is neglected, so that the system is pretty much a kludge of granular parts. In that case, the design may have been, for the most part, limited to design (thinking/acting/deciding) focused at narrow scope (like the scope of a class or function or some such narrower unit of abstraction and composition -- as opposed to system or "subsystem", etc.). That is, there is still design going on, but not explicit system-scoped design that contemplates and designs for system outcomes, such as system properties -- emergent properties that arise from interactions among the parts, not just the parts themselves -- and system integrity. We'd characterize the resulting architecture as accidental. And being accidental, it may not do a particularly good job of supporting some key intended outcomes; may even prevent them. This points to the importance of having a notion of design happening at different scopes of impact (ranging from unit to system) which gets us back to code as design medium -- while good as a local design medium, it doesn't particularly support reasoning about (all) system properties and resolving tensions and tradeoffs among them.
Anyway, what I was going after in the trace, was getting us to ask how well code supports design reasoning and expression. Clearly it does a great job of building systems, and a more or less sufficient job when it comes to design reasoning and expression given that it is often the limit, perhaps supplemented with a rough sketch or two, of the design tools we use to give ourselves some cognitive assist and to communicate and express our designs to others, not just the compute systems they run on. But relying solely on code and individual's mental models, means we lose some design information and we arguably don't give ourselves enough cognitive assistance given the complexity of our systems, and the myriad competing tensions and dimensions we need to weigh and resolve and better address. The F-35 is a case in point -- complex systems can't be approached as merely many, many "parts flying in formation, trying to be an airplane" (Wim Roelandts).
As growing understandings goes, Gene Hughson has been sharing concerns around mashing up microservices in cohorts to attempt systems in the absence of architectural design and understanding.
Michael Feathers comes at it from a different angle -- more a questioning and push-back on rampant complexity and scale. This is an important observation:
Keep it small(ish).
Create concert among small.
What could possibly go wrong?
The matter of architecture. Resolving forces that stress the system.
When I say "local" in the above, I'm distinguishing a locally focused design/decision scope like a class or function from more broad design/decision scope (like system). We use the "umbrella diagram" to talk about scopes, and scope ranges, depending on the system and what we are talking about. The scope of a design decision (set) may be a feature or capability. It may be a mechanism involving a collaboration of components or classes. It may be an algorithm. Or a class. Or a method.
I also write at:
- Bredemeyer Resources for Architects