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.
On February 3, this Trace will be 8 years old. EIGHT YEARS!!! Eight years of inspired and inspiring exploration, investigation, probing, discovering, leading, helping this field to know itself and reconceive itself. No? oh....
Well, anyway, until February entries mass, perhaps you might like to take a look at traces from last year? January perhaps? Or February, if nothing else, then for the Trace Turns Seven dragon! Or use the links in the sidebar on the right and let Serendipity drive. Or use the wonderful storylines tubemap by Peter Bakker to find traces by topic.
My Trace turns 8 tomorrow. Don't worry. I don't actually expect the silence to be broken. :-) Those who value it tell me in their own time, in their own way.
But further. I've done enough thinking and exploring. I need to create a better time capsule of what I've learned and get the book done already.
Peter Bakker stands out for being the person who cares enough to do the right good kind courageous thing -- the gapingvoid link is to the "life is too short not to do something that matters" cartoon. (I assume it takes courage, or at least extreme generosity, to point to my Trace, since few do.)
So that got my 5th out of 5 "vanity" retweets. I'll go back to trying to behave in good "ladylike" form again, refraining from vanity retweets. :-) It is a hard call, between wanting to give kind gestures the exposure of a retweet, and not seeming to improperly brag.
8th Traceversary? I like that; thanks Richard West. :-)
It is so neat to frame this Trace as doing something that matters! I'm grateful and touched. Thank you Peter Bakker, and Richard West. (And Paul Harland.)
Thanks to everyone who has, from time to time over these 8 years, been kind about this oddness that is my journal. A few people have wanted to help me "fix" what I do here, so that it would reach more people. It is the still more rare person who has simply seen what I do here as having its own special quality -- one which cannot be "fixed" without breaking it. I delight in and respect and am grateful for both orientations, for both demonstrate a kindness to me that is unusual and which I much treasure. I couldn't come close to expressing how grateful I am for that responsiveness to the part of my work that is shared Tracefully. I know it is quirky and... well, there is a lot to criticize about it. So it takes a generosity of spirit and mind to encounter it with sufficient positive expectation and patience to let it blossom its insights in the encounter between written and reader.
Thank you Gene Hughson (and Tony DaSilva).
And thank you to Dana and Daniel. It has been a long road... too long? Amazing that I still have a husband (very dear, he is!), and good friend!
2/13/14: Thank you ever so much to Stuart Boardman for the kind words too! And to Tom Graves for retweeting Stuart's message. And thank you to Grady Booch, whose Architecture Handbook journal was the inspiration for this Trace.
It stuns me that architects who I really look to as mentors, are kind about this Trace. The camaraderie and collegiality of this group of architects makes this field not just exciting and stimulating, but warm and inclusive -- I am so grateful to you.
Image quote: Alice Walker.
Architecture as set of decisions:
Architecture decision model:
Decisions, and enactment:
To mourn and honor and celebrate Philip Seymour Hoffman, we watched A Late Quartet. This really struck me:
Isn't that great? Doesn't that happen so much? We focus on the parts we can find fault with, happy to think that there's a contribution we can make. But no. That's not (always) it. Our contribution is to find what is excellent, to see that, notice it, applaud it, encourage it. People who are good at what they do, are so because they are self-critical. They have internalized the ability to criticize what they do. Sure, the mind is close to itself, so there are blind spots, and it can help if another helps us see what we're blind to -- helps us reach to where we can see what we have been blind to for ourselves, that is. If we want to make a substantive contribution, we can notice what is significant and good, and support and nurture that. The world is full of petty jealousy and the will to tear down. And everyone can get what is mediocre. It takes discernment and confidence to see what is beyond the ordinary and point it out appreciatively. That. And generosity. The kind of largeness of spirit that is able to see and celebrate greatness in another when others aren't seeing it. Or do see it, but don't say so.
Well, of course, context factors -- those at the beginning of a learning curve may need encouragement from us in different forms.
Well, the year is getting back into full swing so... either expect me to trace too much as a mode of release, or not. :-) Be really nice about my writing, so I can use all the discretionary bandwidth I have on the book. Yes, it works like that.
A client asked for clarification on the overlap and differences between our workshops, and I thought this is probably worth sharing:
Image: from Zen and The Art of Enterprise Architecture by Alan Hakimi
Informal treatments/blog posts:
EBSE (evidence based software engineering) has an important place, but I like to think that longitudinal experience* with many projects also counts in the generation of insights worth sharing. These are a great source of hypotheses for more rigorous study, but we're moving in a fast-paced world and experiential knowledge, building to insights and wisdom, is worth sharing, no? Sure, we have to be discerning, but frankly, we have to use judgment about the results of "scientific study" too. Bias abounds. We're really trying to compensate for blindspots and anticipate challenges and formulate approaches with higher likelihood of helping us reach more the outcomes we want (and want once we're getting them, and find they are a shape-shifting target!). In support of my contention, note:
Life has a sense of humor, because I wrote the above paragraph, then read Mel Conway's comment as I was grabbing the link to his paper. ;-) [Which naturally makes you jump right to Jung's synchronicity, no? ;-) Serendipity? Bliss?]
* i.e., personal experience across projects and contexts, with a serious orientation to reflection, questioning (skeptically, so we take multiple viewpoints) and probing, dialog including exploring counterpositions, reading and research.
2/21/14: Nat Pryce had mentioned that Conway's Law came up several times at The First International Conference on Software Archaeology (TICOSA), so I looked at the program again. When I saw the synopsis for Michael Feathers Process Echoes in Code talk at TICOSA, I was excited by what I imagined the talk would cover. The slides are interesting, but so many of the ideas that the title/synopsis spilled in me weren't touched on. That is what is so exciting about encountering other people's work, isn't it? What they teach directly, but also what they spark uniquely in you because you have such a different vantage point, standing as you do on your unique body of experience and discovery. Aside: Tweetouts suggest Dmitry Kandalov won TICOSA with his code history mining work; do check it out.
2/25/14: "Main trap to avoid is relying on any one opinion, even that of an expert." ... "Especially when that person is yourself." ... "Remind yourself you are probably wrong." -- Duncan Watts, The Myth of Common Sense
3/10/14: The following come from Buckminsiter Fuller's Synergetics:
Busy Busy Busy
Loaded on the work front, with lots of exciting, along with unexpected, developments.
Still, made time to work out to Amélie -- it is a wonderful movie, rich in interesting technique and artistry. It rises above the do-gooder trope imaginatively and with charming quirkiness. Among the techniques is a neat pattern in the intro that is again repeated further into the movie when new characters are introduced. It has a neatly recursive aura of being a man's fantasy of a woman's fantasy that is very well done, full of rich fundament for exploring the human condition -- including the fantastic playing out of fantasy or imaginatively unlikely, audacious conceptions of responses to various predicaments. I watched Lady Chatterly recently and it is similarly French in sensuality -- without the Hollywood pop-fizz idealizations of body-types. Funny that while Amélie is iffy to mention in a "work journal" (air quotes being used in high drama there), it was shown in one of my 15 year old son's high school classes... ;-)
2/22/14: Very pleasant 20 mile-ish bike ride today in hilly Indiana (the "dragonback" to the ridge along the lake, with lovely views). Back to snow in the forecast for tomorrow though. But some of the proffered Allen alternatives in this list look to be interesting substitutes for lake and ravine views on frigid days.
Reading this awesome David Foster Wallace piece on leadership, I was first struck by:
Someone can be sparklingly unique without being a leader. We need more. It goes on:
And then this gem:
Now, with my promise/threat to trace some thunks on principles running the Bliss-filter on that, I seized on the relevance. Huh?
Let me back up, again, to DFW's leadership points:
In a social or organizational setting, a leader helps us discern, and articulates compellingly (in actions and by example, not just in words and images), a big thing worth doing together, and helps us feel that though it is hard, we can do it by working together. It is big. It is very worthwhile. It is about what we uniquely want to bring to the world we are trying to create, to move toward, to build and shape, together. And we sense it can be done, even if there are obstacles, challenges, risks. It is worth doing, but we need to rally together, act with some concert, to make it possible. Because it is too big, too important, to do only on our own.
This trace was going to be about principles. Huh? How does that relate to principles? Well, cliffhanger. ;-)
Hopefully I can finish jotting this trace tomorrow. :-)
2/25/14: See minute 7:37-9:05 for Stephen Wolfram's articulation of the design principles (coherence, maximum automation) that underlie the Wolfram Language. You can see that these principles do not specify decisions, but do create "fences" or "guiderails", if you like, that designate both direction and outframe whole terrains of decisions.
3/4/14: [GOV.UK] Government Digital Service Design Principles
Image (right) source: Guardian
The views of the architecture allow for a separation of concerns to assist thinking through, and making and communicating, architectural decisions.
It is useful to think about the formative, shaping, key abstractions of the system and expose these to the "stress tests" of how well they stand up to various challenges we throw at them, considering how well they stand up to supporting the capabilities of the system and considering what properties they enhance or reduce. And it is useful to do, before we spend time nailing down interface definitions and protocols. Hence the separation between Conceptual and Logical views. Moreover, the Conceptual Architecture provides a grok level view of the system that is useful when the system is too large to be understood in detail by all, but a general sense of the system is needed by many (so as to avoid duplication and inconsistency, and so forth).
The Physical Architecture is important because we want to take physical system characteristics into account in our system design, but by dealing separately with a Conceptual view allows us to focus on responsibility cohesion and crafting crisp resilient abstractions that will be modular and loosely coupled and then consider the impact of (physical) system boundaries and considerations like latency, iterating on the design. Keeping these views separate even after the design matures is helpful, as it allows us to separate concerns in our communication and explanation. It is a way to simplify, and layer attention.
Then there are concerns like security, which we can address on "overlays," as it were, to the conceptual, logical and physical (alternatively known as execution) architecture views.
In addition to these system views, there are decisions, such as key technology choices, deemed architecturally significant, that may be documented using an architecture decision template that serves as a reminder to keep trace of rationale and alternatives considered but ruled out, and such.
We could choose a different separation of concerns as the basis for architectural views. But whichever we choose, we will have to name them and explain them. And as with any separation of concerns, we will need to work across the views not just within them, to create a coherent design.
It's the stuff of architecture, applied to architecture.
Image source: NASA
Just so it doesn't get lost in translation, in Visual Architecting, we use Execution Architecture instead of Physical Architecture. Again, it is a contraction of "views of the architecture focused on execution-time concerns" into a simpler handle. It includes deployment and concurrency (timimg diagrams, and such, as relevant) related views. Anyway, the Microsoft Application Architecture Guidebook and others call it Physical Architecture, so that term bounces around.
Also, in Visual Architecting we separate the views of the architecture (the inside-the-system views, focusing on the architecturally significant system structures, interactions and mechanisms) from the system-in-context and context views. Again, these views serve a separation of concerns, but we also have to work across the views. As we work towards the design, it is all very iterative and messy, but the views help by giving us key thinking/designing/communicating tools (which we will supplement or discard as the extraordinary moment demands). Oh yeah, and also. ;-) In the VAP architecture decision model, the (sadly maligned) Meta-Architecture or Architectural Strategy sets technical direction. It is where we put Architectural Principles and key organizing ideas like system concept or metaphor and sketch strategies for addressing key challenges/risks/uncertainties. Here's an important snip from that "yawn" (impish grin) trace:
And this about decision models or document templates:
Architectural views helps us reason about and present our design, and help others navigate the system, locate information and understand the system, identify the impact of changes, and so forth. The views do not prescribe a sequence of decision making. Though, generally speaking, we'd want to do more technical strategy setting and conceptual architecture work before we do the specification level work of logical architecture, for example. The point being that we need to iterate across views, assess tradeoffs that become evident as we consider various views, rework the design and come up with alternatives, etc., in a rather messy, non-linear way. We factor and refactor, factor in and factor out. We consider from various perspectives, make judgment calls, decide what to explore further, when to address challenge and risk, to surface and resolve strategically and architecturally significant uncertainty. To be responsive without jitterbugging the team and organization. And more. The stuff of "at this extraordinary moment, what should I be thinking about."
Oh, right, and I wrote about views from the point of reference of software architecture. (I should write the mirror trace for EA?) I dance between various frames so many times every day, I don't necessarily notice when I've shifted context on you... :-)
3/16/14: Some examples:
2/25/14: And, since writers and directors are a nice source of analogy material to put a finger on what characterizes architects, this caught my eye (making a coffee break social with a spot of Twitter; hey, I'm trying to give it up, but I have to fake the connecting thing since boohoo ;-):
A lot of people have pushed back about the notion of a foreman in software, and I have to hand it to Uncle Bob because he has addressed the concerns with (from what I've seen, anyway) equanimity. He's doing what he does so well -- stimulating discussion and getting people to think. Which is a euphemism for saying he's stirred up quite some controversy. Again. ;-)
The discussion is important. But it can get quite dismissive and put-down-y.
Remind me never to come out of the Trace closet. Pitchforks and hooks all lined up if you so much as mention leadership???
Agile not Fragile
Mixing It Up
I was excited to read this, and just have to share this snip and encourage you to read the whole post:
Great points about the "rising tide that lifts all boats" with more powerful language and library abstractions, as well as the architect-developer as source of innovative ideas.
2/25/14: Talk about rising tide -- Stephen Wolfram's Introduction to the Wolfram Language.
Image right: Banksy (?)
The debate around offering programming classes in schools seems to be one of those some people get quite... um... passionate about.
I wouldn't argue that every child has to take 12 years of programming classes, or anything like that. I do think that it is patently ridiculous that in 2014 there are plenty (the majority?) of middle and high schools in "middle America" (where I live and have some perspective on) that do not offer any computer science classes. Let alone elementary schools. Even in schools that offer music, art, photography, and "technology," there is no programming class??? Seriously, that is a state of affairs we should find SCARY.
If every kid was introduced to software development in school, they wouldn't all be expecting nor even want to become software developers. But more would. And more from economically disadvantaged groups would have exposure to the joy of coding, to the empowerment of making things that work and the wonderful ego-feedback one gets from doing so. As it is now (as I understand it), young adults who are drawn to tech fields tend to have been into gaming or have had role models in tech. That leaves a lot of kids out.
Of course, that isn't the only reason it is a good idea. Here's another:
Many fields, from research in the humanities to various fields of STEM, rely on data-driven research and analysis, and on presenting results in interesting, often novel, ways. Being able to take charge of one's own destiny in these fields is assisted by being able to take charge of that analysis and presentation. In short, when a domain expert can write her own tools, she has greater degrees of freedom. She can still use off-the-shelf-ware, but she can invent new ways of collecting and looking at her data and doing her analysis.
Would this do those who specialize in software development out of a job? I hardly think so. Hard software is hard. It takes years to get good at.
So there is room for people to write code recreationally, supporting their maker-space hobby. To code as a buoy and power-assist function to their career in many fields. Or to code as a specialist in various fields focused on software development, such as embedded systems, software and IT systems. We will still need our maestros of software, guys. No need to panic! ;-)
Just because everyone learns math in school, doesn't mean everyone becomes a mathematician. But doors to many fields are closed if a child doesn't learn math.
Consider music. Privileged children have access to many, many hours of music lessons and pricey instruments, giving them the opportunity to become musicians. By the time they go to college, the door to music schools is pretty much closed if they haven't already taken years of music. Exceptions prove the exception of course. But when you're talking in the main, we're looking at general tendencies and trends.
We have much the same issue in computing, because college entrants with little or no background in programming are intimidated by those with years of programming behind them. Of course, not all gamers become developers, but there is enthusiasm and respect in the gaming community for developing games, and it has its draw. Not every kid is drawn to gaming, though. So we need more avenues of introduction to software development. Code clubs are doing a wonderful job, but kids have to find out about code clubs. Maybe they are the answer, as they tend to be run by people passionate about coding and that is infectious. Still, I think that getting more of that into the school base would be good. Programming exercises and develops logical reasoning skills and has strong feedback loops. It is a shame not to let every kid have a chance to experience coding.
To try to shut down the conversation based on spurious arguments like CS will come to dominate the curriculum, or programming will be taught so badly it will put kids off, is a sad punt. Math has not taken over. Nor has the fact that many teachers are bad at teaching math caused us to give up on math in schools. Kids who take a class in music or math -- or coding -- don't get undue expectations that they are automagically ready for careers therein. So. We have to try to do better, to serve all kids better. With balance in the curriculum. And not closing doors. And empowering children's sense of self and self-directed-discovery. Coding can wonderful for that.
I need to draw a cartoon with coders on a walled island and kids in a boat called "the future" not being allowed to land... ;-) I know. Hyperbole. Rhetoric. We have to get so much energy into something to get the stupid thing to budge at all, it can overbalance. But first to get it moving!! I think it is charming* that there are people who perceive that advocacy for making programming classes available in schools is going to be so effective that curricula will become dominated by CS. Would that anything dramatic were to change in school systems! The biggest event in the past several years was getting pizza declared a vegetable.
Oh right. Obama thinks every kid should learn to code. So that's going to happen. He made universal access to health insurance happen. So it is totally for reals likely. Soon. Okay. PANIC!!!
* That may sound snarky but I mean it sincerely. I'm by no means the most jaded person around, but some rocks are just mighty hard to push uphill... when we don't value educators very highly and don't put very much into giving children learning experiences they thrive on. We cater to the fortunate few, and keep the deck stacked.
2/27/14: Add this, and stir:
You like? Alright! Add a little of this (as an appeteaser):
2/28/14: Grady Booch adds the point that we are building [our evolving] civilization on computing, and few understand it. We need to broaden the base of understanding, as well as access to careers that leverage, and careers that build, this threading of computing through our world.
Math and science, and literature and humanities, provide foundation understanding supporting modern life. And, as Grady Booch indicates, since computing has come to be threaded through modern civilization, enabling and pushing frontiers in diverse fields from arts to our understanding of the cosmos, we need to support greater understanding of what underpins these advances. It is about access to careers, but also the development of understanding and hopefully wisdom, so humanity can make progress towards better human and planetary outcomes for all of life on earth.
3/4/14: Multifacted, insightful view:
2/22/16: What is really exciting is that the picture has changed so very much since February 2014! It is exciting to see how quickly school districts and teachers got on board, and more and more middle and high schools are offering coding classes. Things can change, and they can change fast! We're not there yet, but it's moving.
Superficially, one might say that Duncan Watts presentation The Myth of Common Sense follows somewhat the same pattern as Dan Ariely's Are we in control of our own decisions? TED talk. But of course there is important difference in the detail and I got a lot out of Duncan's talk (and love the structure and design aesthetics of his slides; oh, and that southern hemisphere accent ;-).
Here are some key points (and a preview of the format, so you notice the attention to structure):
The remainder of the talk focuses on what to do -- the "ramps" to accommodate for our fallibilities, to return to Dan Ariely's analogy. ;-)
2/26/14: A little piece of satire (at least, that is how I read it), reminding us that judgment factors.
2/27/13: Via Paul Harland:
Watch the video (bottom of the page) before reading that article... that's what I did. And I got it right off. But that doesn't prove anything. ;-)
Maps and Territories
This... tells us something....
but not everything. :-)
Happy Birthday Grady Booch!
Four years ago I roasted Grady Booch on his birthday. Well, the man of "a life of ands" has added still more to our world, with his work in cognitive computing and on Computing: The Human Experience. Here are wonderful lectures setting high expectations for the Computing series:
"Things a computer scientist rarely talks about":
Do go wish him a Happy Birthday y'all!
If you need to check your timezone in relation to Hawaii, here you go. :-)
2/28/14: Delightful stories and insights: Nikola Danaylov interviews Grady Booch. Lots of gems of various sorts and sizes, like "Watson's a pipe and filter architecture".and "[oh, IBM just made a $1B bet based on recommendations I and some other folk made]" ;-) (I put that in  because I paraphrased what Grady said. ;-)
Dung-beetles and EA!
Now there's an image! As Martin says:
Tom Graves did a mighty fine job with his "The dung-beetle's tale: systems-thinking, complexity and the real-world" slidedeck. I agree with Gene Hughson -- I wish I could have heard Tom's words to that, although the slides tell a fine story.
You should bring Tom in to do an in-house seminar, you really should. He'll inform and inspire. Invaluable, but do check in with Tom on what it would take.
Martin Fowler Sketchnoted by Lynne Cazaly
How cool is that?
BIG Thank You
I always feel so conflicted (shy, improper/*nice girls don't self-promote*, and exposed/*target on my back*) pointing anyone to my work, that it is nice to have some support in response. So, really grateful!
Oh yeah, I need to remember not to worry about negative response. I'm invisible. And it's not just the word-veil of this Trace. Being a woman in this field is invisibility shield enough. [She says, simultaneously demonstrating and depending utterly on the invisibility shield continuing to work. ;-)]
Well, there are more important things in the world.
It's Not Just Heroines We Know About!
We systematically overlook women and fail to encourage women; we make women invisible.
Many of us have bases to understand the painful diminishing expectations that we impose on others that shrinks their opportunity to make their difference felt in the world. Most of us have been left out, felt ignored, been on the outside of something we wanted to be included in. And some of that is socially systematized through stereotyping, for example. We can choose to use those experiences to have empathy for those who have it worse than us.
Life is over in a flash for each and all of us. Encourage those who aren't encouraged, rather than those who get de facto attention, and you make a bigger difference in someone's life and in the world.
Say nice things to and about those who have earned it -- seeking out those who aren't otherwise getting the attention breaks their work deserves. By noticing, appreciating, putting words to what you see as the contribution in another's work, you will indicate your own questing curiosity and interest in broadening and deepening your understanding, and your confident expertise and discernment and aesthetics. It is win-win.
By paying attention, we can make a better world for each other.
My Trace could be called Invisible Woman, so let's review these words by Ralph Ellison, in his acceptance speech for the National Book Award for Invisible Man:
Just translate fiction to non-fiction, and today. ;-) Overstated? Hmph. I've barely begun. Emphasize this:
Definitely overstated. So? Who are we going to offend? There are distinct benefits to being a women in software/architecture/technology! Yes, yes. Indeed. Invisibility has it's benefits. You can tease frightfully audaciously, without fear. ;-) And when you do, you ensure continued invisibility, for who would know quite how to deal with so frightful a creature as a woman? ;-) Okay, now that the invisibility shield is fully deployed (you know, "Talking much about oneself can also be a means to conceal oneself." @NietzscheQuotes), what do I really mean? Let's highlight and adjust some phrases:
Seeing it? No? Oh. Oops. Well, I tried. ;-)
What keeps women invisible, are low expectations that make it okay to not attend to women:
3/3/14: Didn't you just love how Ellen Degeneres took that "We can't have a woman host the Oscars! What would she do? Feed and connect people? Great jumping jabberwocks man, she'd order in pizza!" So she did. ;-) And didn't you love how people showed up with goodwilling playfulness in response? In Dolby Theater, and in making RT history. Ellen took a risk, being playful and inclusive, bringing the people of $10k gowns and extra large pizzas together -- and bringing the twitterverse into the house. Goodwill is goodful and we don't give enough credit to people who facilitate and bring that out in others.
Also standing out at the Oscars:
I Have an Idea!
No, no. This:
What do I mean? I mean I need to hide my head from the world, and just get work done.
What did you think I meant????
Though the question of "which is to be master" in the matter of uncertainty and creating realms of stability is a delicious meaty topic. :-)
The history of various branded camps in software is interesting to me in so far as it exposes real challenges we face that they do and don't address well. We have experience to draw on.
As for Agile being a word that has to do a lot of work -- hatterly brilliant, Mr Harland! And we're paying extra.
Ps. Don't overlook that The Economist article on Climate Change.
I also write at:
- Bredemeyer Resources for Architects
Architects and Architecture
- Todd Hoff (highly recommended)
- Anna Liu
- JD Meier
Architect Professional Organizations
Agile and Lean
Agile and Testing
Other Software Thought Leaders
- CapGeminini's CTOblog
CTOs and CIOs
CEOs (Web 2.0)
- Don MacAskill (SmugMug)
- Wired's monkey_bites
Social Networking/Web 2.0+ Watch
- Dan Roam
- David Sibbet (The Grove)
Strategy, BI and Competitive Intelligence
- Freakonomics blog
Um... and these
- CNN Money Business of Green videos