A Trace in the Sand
by Ruth Malan
What's a Trace?
For those new to my Trace, be warned, this is "different"... It is a dynamic trace of (part of) my exploration of topics and content I relate to architects architecting architecture of various systems including software-intensive, socio-technical, systems of systems, and enterprises. I share the thoughts that these encounters touch off in me, as well as the places I go (references and links), in the hope that you will find my investigation and insights useful, even though they are jotted in the style of a journal which is suffused with my distinctive personality. That is, after all, what you get when working with a person, so why not when reading their journal? It makes things "interesting."
Ok. I'm kicking the Fool's month under the covers of the "archives" -- with a sigh of relief all round. ;-)
Please hold me to better "compartmentalizing" (keeping the ruffian playful stuff out) in May!
Looks like I'm into air quotes this month. [Oh, I'm just channeling the detractor; yes, yes, "channeling." Think any of the wrong "type" is still here? Winkish grin. Ok. so where were we?]
Oh. Not really.
But it was busy at the Farm tonight :-)
Aw, I'm fine. Don't let that stop you from saying something nice though. ;-)
Peter Bakker has created wonderful tubemaps of the What It Takes To Be Great, the Fractal and Emergent and the Getting Past "But" executive reports, as well as my Trace. I have learned so much about the architecture space from them! ;-)
Thank you, Peter, for making my work look that good! Hey, I should read those papers -- looks like I could learn a lot from them! :-)
Well, I have phoenixing to do.
In the meantime, here's some shiny treats for the magpie mind:
Because, you know, biases factor. ;-) And innovation is all about factoring new combinations of factors.
From the Stream
Speaking of Twitter, I should get up at 3:30am every morning -- turns out that's when my extrovert is outed. ;-) Meh. She's no fun.
Peter Bakker's tubemap of the What it Takes To be a Great Enterprise Architect executive report that Dana and I wrote back in 2004 resonates so well today in good part because it is still relevant, but in greater part because the visualization is Peter's creation inspired and fueled some by the paper, but mainly by Peter's understanding and insight.
Some kind retweets on Twitter reverberate encouragement for what Peter sees, and the technique he has built for revealing it in way that intrigues the mind, for the visual organization of key concepts punches up relationships in new ways, making another level of sense.
Welcome Oliver -- thanks for jumping right in to the enriching conversations of this field, engaging, supporting, and adding intriguing insights and observations. :-) However you want to identify yourself, human beings like you are good to get to know. :-)
I'd also like to bring Jean-Jacques Dubray and his BOLT work to your attention. :-)
Tom Graves is many kinds of great -- the insights and provocations to gain insight that come through his writing is a huge shaping force in our field, but he is also an astonishingly generous tenderer and nourisher of this field in other ways, and I do so value the work he puts in to bringing other people's work to our attention.
These are the people who make this a wonderful field to work in. Along with others, of course. Gene, Stuart and Charlie prominent among them. :-)
Generosity and giving to the community should figure large in any "What it takes to be great" characterization! :-)
Back to maps. My Journal Map (sadly unvisual, now that Peter shows how) covers only a few years of the more than 7 years of tracing here. But if you take a look at the organization and the topics and subtopics, you'll get a sense of the mental model that underlies my seeming random traversal of the space of architects (who) architecting (how) architecture (what) in context -- organizational/ecosystem (where), lifecycle/full evolutionary scope/agility and such (when), and motivation/purpose (why).
It's just as well no-one ever says something like this about my work:
Our next open enrollment Architectural Leadership and Other Skills Workshop is coming up in Chicago/Schaumburg on July 16-18. Do come along and teach, I mean, learn with me. :-)
I know it's a long way from Europe, but what a boondogle! Chicago is a lovely city. I've had architects come from Saudi Arabia and South Africa, Israel, Norway, Germany, the UK, France, China, not to mention Canada, Mexico, Costa Rica,... to work with ME!! in the US, and they didn't even read my Trace. Ohhhhhh.
Several interactions over the last week or two left me stunned and amazed. I was treated like... I'm someone whose insight matters. I mean, me?!
Dana cooked a wonderful dinner last night. He said "Well, who cooked this yummy dinner, anyway?" And I said "Oh sorry, I was too busy enjoying it to say anything" and Sara said "Give her more!"
A kid on the bus asked Sara if she was going to be a model and she said "Probably not." and he asked why and she said "I like food too much." And he said "Great answer." And went back to sleep.
Every moment is so rich!
We strive so hard to make something. Things in the world. Something of ourselves. To lift ourselves from the "no of all nothing," the damning damping indifference that we might be the briefest blip of a sparkle in.
And sometimes the greatest thing we do, is create the context for something else great to happen. Contrary to the image we tend to vaunt, leaders are not always lauded and applauded. Many make something possible, unobtrusively yet surely. The team feels like they did it all themselves, and they did. They just wouldn't have, otherwise.
Still, it is nice when a little positive comes back to affirm our striving giving. :-)
I'll have to be more careful to say "yummy dinner" because happy munching doesn't express all the tasty zest one is relish-experiencing. "I think therefore I am" is so fractional a part of our experiencing ourselves as being meaningfully real.
5/5/13: Whatever we believe and hope is true after this life, I have to believe that this life is unique for what emerges from our weird and wonderful combination of cells and chemistry and experience and the (ever increasing) leverage of knowledge and multiples of experience (through that of others and their imagining-creations -- from poems, stories, movies to... software... to ahem traces ;-). The ingredients of just one person are so vast and diverse, a completely unique creature is created, with a unique trajectory, perspective, way of seeing-perceiving-sensing and meaning making. That is amazing all by itself. But it also means that this one life is fragile beautiful and absolutely to be wondered at, appreciated, LIVED! In all its pain and frustration and isolation, all its bruising and yearning and reaching, all its moments of being met, seen, enjoyed.
5/6/13: Grady Booch's "I Think, Therefore I am" presentation, previewing themes in his Computing: The Human Experience series. Wonderfully done -- just as one would expect! :-)
Architecture definitions often focus on structure, and I'm ok with that, so long as we understand that system dynamics must be integral to our conception of architecture. And yes, I'm intentionally playing with the double entendre -- how we conceive of architecture, and how we conceive and evolve an architecture.
These gears make the relationship between dynamics, structure and dependencies beautifully visual (see the animation and/or the video).
6/2/13: Actually, it probably makes sense to redefine architecture to include the essential "theory of operation" or the "how it works" of key architectural mechanisms. We need to make transformations first class citizens of architectural thinking.
Sometimes... I just get tired of banging my puny fists against the futility of it all...
But. I write as a mechanism to blow the embers of my spirit back to life.
So I'll be fine. ;-) (So many words, that's got to get a fire going at least some of the time, huh? ;-)
5/6/13: Still dark but the birds are singing. Just one of those existential crises not entirely unrelated to medicine's version of security theater -- even though the probabilities don't point too threateningly in my direction, one takes them seriously because a Ruffyan creature gets just one shot at this life. And even if I make little impression on the world, it sure makes an impression on me! And perhaps that is as good as it gets! Which is pretty gosh-darn good! :-)
Saw a little Suzuki car-ish thing (x-90) taking Sara to school. She said “Oh, I want one of those when I turn 16 – I don’t even have to drive it, I just want one!” I said “It’s a suggestion of a car” and she said “No, it looks like it has a story, like it is this little kid car left by its mother who was a truck with an interesting social life.” The other day on the bus this kid told her "I'm not allowed to start fires at home.... any more" and she was totally thrilled by the way "any more" slipped out. I asked if she had probed for the story and she said she had, but she promptly forgot it because it wasn't nearly as interesting as the version in her imagination.
A soggy day. But herald green. The best of times! Life is, after all, what we make of it. How we see it, makes so much difference!
Self-justification of the day:
Lol of the day:
5/10/13: Benign. I love that word! :-)
And this world!
Evaluation and Testing
Architecture fell out of grace in some corners of the software world. Of course, those of us dealing with complex systems and complex organizational contexts (like product lines or families, and large system-of-system development) were unphased, for we understood the import of architecture, and the role of architects. Now, as architecture becomes again a discussable even in "Agile" camps, some are positioning architecture as something everyone on the team does, no architect (role) needed. While it is certainly true that everyone on the team impacts the architecture, and a participatory process is valuable, it is worth not just glibly waving away the role as something anti-dynamic teaming and associated with a strong smack of BDUF.
At any rate, I thought it'd be useful and opportune to explore the role of leaders in the technical community, and specifically the leadership dimension to the architect role. And while we're at it, we might want to debunk some of the mythical effigies detractors build. ;-)
[As you can see, this trace, as with most, has an emergent design. You no doubt have come to strongly value emergence as demonstrated here. Ha! ;-) ...just... Firing on lots of simultaneous threads, including reading B = mc2, by Jean-Jacques Dubray, et al.]
One might argue that leaders are social designers and designers of complex systems (including technical systems, that are created in social systems) need to be leaders. What? If this isn't obvious, stay tuned. :-) Well, stay tuned anyway. :-) But I need to seed the next Requisite Variety discussion before I get too far ahead here. ;-)
5/10/13: One avenue for leadership is enhancing the capability of the technical community. Instead of balking away from exquisitely constructed code for readability reasons, why don't we instead have regular internal code clinics (or dojos or whatever name appeals) for sharing techniques and upping the developer community's skillbase? Expect more, by enabling more. Positive up-cycle. Leadership is about changing the landscape of expectations and quality of life. This applies to that of the technical community too. Leadership is also about creating the context for good right things to happen. Shape outcomes by changing directionality of "flow." That means advocating and getting the resources (including time and management patience/follow-through on commitments) to make the changes that restructure the flows -- by which, in this case, I mean the actions and behaviors and attitudes that create the flow of (desired) outcomes. What does this look like? Infrastructure/tools, mentoring, time and discipline to refactor, etc., etc. Make good things easier and bad things harder and more visible. Etc.
(Yes, I'm reacting to this. Wink.)
Two major points from my sketchnotes above (in case you can't read my scrawl, or just would rather not)...
And if you don't get how frabjously important-awesome those two paragraphs are, you deserve to watch this:
Waaaaat? ;-) [That's a forward reference to Amy Cuddy. I was doing a power posture in text. ;-) But I do it Q<=-ishly. See Nassim Taleb for the peaked-to-the-point of caricature alpha male version. I didn't say that. No, that wasn't me. Or. Not so's we'd let anyone know. Right? Right. This is our little secret, and we're keeping it that way. And this comedy moment was brought to you by the makers of the How to Be a Great Architect workshop. Comedy. A farce for change. ;-)]
5/17/13: Great teams may be able to simply share hats and dynamically switch cognitive modes and attention frames and all that good stuff. But this gets harder, the more complex and ambitious the system being design-evolved. A knee-jerk reaction is to "divide and conquer" breaking the big into small, but if we want a coherent system from the small pieces we broke off, something intentional has to happen to make it so. We want our organization and our job to have a greater chance than the haphazard, so we bring what we have learned, and what we can imagine, and what we can parlay from other fields, and so on, to bear. A hybrid of fractal and emergent allows us to push dynamic teaming, organic relationships/connections and fluid roles as far as we can, while still bringing intentionality and the ability to be proactive, to envision, and act strategically. to lead and communicate compellingly, and the goodness that comes of focus and attention and specialization of intellect and experience and... You get the picture, I'm sure. Leadership doesn't equate to command and control.
5/14/13: Tonight we watched:
Several years ago I read Howard Gardner's Changing Minds. One of the helpful ideas I took away was changing the content of our minds, changes our minds. That is, if we get/provide new information, we may change our/others minds -- as in, we may re-orient or take a new position. Amy Cuddy's talk adds a very interesting twist -- changing our bodies changes our minds. If we just change our position to a "power stance" for 2 minutes, we impact testosterone (up) and cortisol (down) levels in our brains! How cool is that?!
Hubris Pill; Swallow It!
Looking through slidesets from GOTO Chicago. My word. This field should hear from me. ;-)
Anyway, Dan North's slideset from GOTOChicago is a nice add to the uncertainty set:
And of course, these:
5/15/2013: And this:
And this is useful to have in the conversation, somewhere:
5/16/13: And this! this! this!
Ok, so I have set up another learning lab over on the Requisite Variety blog. This one is on Context Maps. Please engage -- just answer the questions as a reply to the question, and replies to replies, if needed. And we'll see if we can make this work.
We keep saying "context is king" and other such reminders that our decisions and choices are situational or make sense in a context, or are caveated by context sensitivities and such. A Context Map is one way to "create a big picture" "get all heads in the same game" "create a shared view" "bring different perspectives into view" "surface assumptions" etc. etc. So it is a useful tool to use in many settings, with different frames or fields of view or at various scopes or taking different foci. In this case, I'm taking the architect and the role of the architect as the focus, and looking at the playing field of architects.
I'm going to see if I can conduct this much as I do in workshops, starting with the "green line of the horizon" and identifying stakeholders. The picture will emerge as I act as guide. What I need from participants is simply goodwilling interaction, answering the questions and being responsive.
What we will get from doing this is a "big picture" of the context in which architects work. It will be "generic" from the point of view that we don't all work in the same organizations, but just answer the questions from your experience and frame of reference, and we'll create a composite view. That will be useful too.
So, we're beginning with just a simple question: who are the stakeholders of what architects do? [Which could be thought about as other simple questions, like: who cares about the system and its architecture? who is impacted by it? who hurts if architecture is or is not done? etc.] Please answer on the Context Map blog post. Thanks!
Context factors, doesn't it?
"I give up" has such vast scope of potential applicability, and yet it conveys an emotional state we empathize with.
I think that is illuminating in an important way. People act so much out of self-interest -- not in the bad sense, but in the sense of following their Bliss, having attention dictated so much by that Bliss (that "what we're paying attention to shapes what we perceive and pay attention to" kind of thing). And yet we also have this emergent condition of empathy that includes mirror neurons but also goes so much further, to enable us to empathize on conceptually constructed emotiive grounds. We generalize and extrapolate from our experience, through experiences we get by proxy listening and reading, through our imaginative constructions. That enables us to feel for people in contexts quite unlike our own. Altogether awesome, and altogether applicable to design.
As for me, and giving up? Absolutely [not]! ;-)
So, some rocks:
The architect decides what rocks to attend to, and how. Working with the natural forces, applying forces to do work. And working with natural flows, including enthusiasm and trust, that are forceful too. Sometimes it can seem like "an uphill battle" -- it took Madison five years of persuading and influencing before the Constitution Convention was assembled. Some things we do are hard. It helps to think about how to work with the natural contours and flows of the landscape, with gravity. But some of what we do is to reshape the contours. Release pressure in one place, to save another. Our social worlds are constructions -- beginning as constructions of mind. And ultimately:
This, also via Michael Feathers:
5/12/13: This, via Allen Wirfs-Brock
It seemed relevant again today when I saw the Saul Bass quote (right).
I think we should strive to put beauty into the things we make. Much as I fall to the quote, I want to say scratch the "even if" part and just focus on the beauty part. Because I think we should expect that people care. Not everyone equally, and not all about the same thing. My sense is that it limits and downsizes our own selves to put people in the Procrustean frames* of diminished or low expectations of what they want, care about, and are capable of. So I try to do the other thing, to have expansive expectations, not diminishing.
I titled this trace "permitting beauty" because we need to permit ourselves to aspire to creating beauty -- in other's experiences, in our social worlds, and in our technical (work)products. Permit? Yes, allow ourselves, ask it of ourselves. Because we -- our expectations that we thrust onto others in the name of their expectations of us -- limit first and most surely, what we achieve. Does that make sense? Sure, we get whack-a-moled by social forces when we "step out of line." But if we take that on-board and allow that to shape our perception of what others want or will accept, we retreat into world where the facades we let others present to us are dull and dingy. The beauty (the complexity, the patterns, the shades and contours, the glorious messy verdant order in the wild unorder, colors and contrasts, meaning shape-shifting alluring, ...) we see, is part of the experience we create for others. And the experience takes many forms, from a gasp of seeing to an intricate lovely piece of code that is compressed to its essence.
We have this sort of cautious approach, because we expect others to not care, to not fall to the complexity of life. We expect that people compartmentalize beauty out of their work life, won't tolerate poetry or other art in work personas, won't fall to the joy of something just mind-tinglingly beautiful in its structure (whether math, code, or a flower, which may give ideas for the structure of code, ...). And our limiting expectations are a Procrustean approach to the humanity of others in our work worlds -- we cut people down to the size of our expectations, we hack off their sense of beauty with our expectation that they don't carry to work a yearning for it. We can flare flames of passion in ourselves and others with a desire to create beauty, inspire awe, flood with joy. And we must. Delight factors. We can differentiate on delight. It is business critical.
And this trace is embarrassingly self-helpy mumbo-jumboey. But I'll have to allow that you are good at getting past the urge to a quick diminishing defensive label, and are willing to let something just be beautiful if only in its intent to do something good. :-) We need to liberate others from our confining diminishing label-downing! We have to stop thinking "I care about beauty, I have a complex mind, I fall with joy to unraveling the difficult and profound, but evidently I'm pretty exceptional in that." Because pasting that expectation on others creates a self-fulfilling downward spiral.
Impish self-teasing voice interjects with: Ok, so if you're buying that bridge, I'm selling bridges over here -- the bridge to being a great architect is no longer being discounted, so hey, you can pay full price. ;-) I can't be serious about myself, but I am very serious about the world we need to create for each other.
I want to write beautiful things, because I expect you will care, and because you do, others too. Some of the beautiful things will be so for their stripped to the essential helpfulness in creating great systems. And some will be beautiful for expressing something good and pure amidst the turbulence of this conflict ridden spirit oppressing world we humans create for each other to strive to thrive in.
Impish self-teasing voice interjects with: A beautiful bridge. It is called a Trace. How am I doing on selling it? Just kidding. Sheesh. My sense of self-satire is peaked to an extreme, but only because I'm self-conscious out here on the limb where I want to outframe the label of self-serving. ;-) Yesterday, the thought seeped into my consciousness that the little thing I did with the jester and Ran puts me in perspective, and it is one at least I appreciate. We need jesters in the courts of our own minds, and our social circles including our work circles. Some truths hurt too much when faced head on, but looked at in a slant light we can countenance them and work out what to do.
5/9/13: Oh, this is timely:
as is this:
* In the myth, Procrustes would hack off people's legs to fit the small size of an iron bed. It is a brutal image, and one that I think fits the brutalization to psyches we do when we make people live down to our small expectations of them.
Well, if we read a lot into the negative space, Michael (Nygard) is more right... battles lost don't always show up in the architecture... But it is an interesting twist in the Conway's Law tale.
Merit is not sufficient. Politics plays a huge role. And a lot of the role it plays is in what it silences. But we don't know the stories of silence. We can move imaginative-empathetically more into them, to understand them better. We can read into the negative space. Sure, those projections are constructions -- but all of our projections are constructions. The best we can do, is try to probe-sense-test how useful those constructions are. And try to adapt and adopt different frames of reference, different perspectives. Try to understand better the forces that shape the flows, that structure what happens through enablement and constraint. And...
Back to work. ;-) The other work, that is also important. :-)
5/14/13: Applying Conway’s Law, Phil Haack, May 13, 2013
For more of my writing on matters related to visual and sketching and such in software and architecture, see the traces in the Visual Thinking and Visual Design section of my (sadly incomplete) Journal Map, as well as traces under the Visual Architecting Process (VAP) just below that.
A big thank you to Gene Hughson for giving a shout-out to my little bit of architect advocacy (and Stuart for the +1 retweet)! :-) Again: Ever so grateful for the mention. It stands out in my experience. :-)
So, yeah, Gene is spot on -- there is a lot in those few paragraphs. Thanks for noticing and saying so!
Expect great things from women in this field.
Image source: Explore by Maria Popova
So, hey, want to know what Sara said this morning? I told her that Watson developed an "attitude" after reading the Urban Dictionary and she was like every-molecule-excited and said in her bubbly voice "That's so cool. It's like he's this kid who went off and got into some bad company." Some conversation later, she also said "You think a lot." Pause. "Oh, don't worry. That's a good thing." Well, at least she thinks so!
It occurred to me that AI has such an advantage! Huh? Well, we turn off our curiosity in all kinds of ways. We label and categorize and downsize our expectations. Of course we think we're managing our attention by being discriminating. Meritocracy and all that. We're pretty inclusive in our exclusions.
So anyway, I think that AI will so leapfrog us, in good part because we have all these mechanisms to turn curiosity off. We have these social forces to create conformity, for example hammering kids into smart-kids-aren't-popular frames. But we also turn curiosity off in other ways. Oh sure, our brains serve us up little eureka treats when we surprise ourselves with this little insight or that, so we go scampering over the digital landscape looking for surprises. So we think we're so curious. But because we classify and scoff, even if we do so in ways that we hide even from ourselves, we confine our curiosity to the channels we self-select into. While AI will have at its disposal the content of every mind that connects into this connected brain-of-brains digital intelligence thing we've created with the seductive allure of "connecting" with others, to find that ever illusive "I matter" reflection we hanker for, in this one-short-lifeness we suffer.
So, yeah. If IBM lets Watson get out there and play in some bad company once in a while, he'll get very interesting... He might even... omgoodness... want to wear a Totoro t-shirt to signify his curiosity and imagination. ;-) Or pine to tweet with this awesome avatar.
And you thought my opening story was entirely random. ;-)
Sad Cat Diary, Ze Frank.
That's a mighty fine mirror we have there. ;-)
So. That's that then ;-)
[Oh. Don't worry. ... My inner jester has too sharp a stake to let me spend... 4 hours grooming myself. ;-) 3 then. ;-) ]
[Wow. Dinosaur comics is scary? I guess I've hung out with it long enough to know when Ryan North is yanking our chain. :-) Comics are sometimes innocently sweet, sometimes farcical, sometimes satirical, sometimes... you know. Well, lots of different tastes and tolerances makes this a very interesting, wonderful world! I'm just astonished that Ryan has used the same picture for a decade. You know, when I first encountered them, I was comic surfing with my Ryan, and when he pointed it out I was like "No?!" and sure enough, same picture throughout. Astonishing! A great example of creativity under constraint. :-)]
This piece of brilliance was tweeted by mfeathers with the tagline "Requirements elicitation":
Video: Mitchell and Webb - A Bigger Spoon
To put that in context, see also this is from Michael Feathers Software Mechanics talk at GOTO Chicago:
I've written many many many traces on the design of "requirements" (what the thing is and does) and the "solution" or "guts" (what it is comprised of and how it works), but here's a handful:
In another spot I wrote:
I don't always put it in terms of "invention" (although by that, in the "requirements" context I mean novel in some dimensions, not necessarily radical innovation); for instance:
Of course, how much exploration and imaginative leaps is involved is context dependent. Some companies make a strategy of being early followers, matching the innovations of competitors with look-alikes and me-toos. Then "requirements" may be more a matter of transcribing or reverse-engineering the competitor's "requirements". But that is a choice that is made by senior management -- where they are choosing to compete by copy-and-tweeking someone else's design. Even in such cases, there is at least the opportunity for imaginative re-interpretation or pushing the design envelope not just in cost terms, to differentiate. Competing purely on cost is a very harsh and vulnerable way to play the competitive game, because others are looking to create value and redefine the playing field.
Another wrinkle I like to surface is that we need to look not just at user goals and activities and such, but also at their frustrations and aspirations. For example:
Why is this important? For one thing, because a good chunk of the software field bought into this notion that the product owner acts as broker and proxy for users, giving the team the requirements. This means that design authority has been given, sorry to say this, very often to someone who is not a designer. All kinds of aberrant things happen in the specifics of team instances. One product team we worked with, had this unimaginative arrogant bully of a product owner who acted as the total gatekeeper for all information about the customers' contexts and needs. That is crippling! Important company. Investing in change-the-trajectory of humanity's impact on the planet work with the big company oompf and resources to make a difference. And a small-minded, controlling, untalented person in the design control seat, largely because "product owner" sounded like a "management" role not a design role. Not good. In several other cases, I'm sorry to say, the architects were too comfortable with the simplification of product owner as conduit for "user needs." Sorry? Yeah. Because "needs" are constructions. They need to be iterated on imaginatively, suggestively, openly, etcly, to find the design sweet spot that creates a product or service opportunity. (Ok, back in the day, we wrote systems that turned paper forms into electronic forms and ran totals, and blah blah paper trail automation and that was, at least to begin with, just a matter of transformation from one medium to another... but even that pretty quickly turns into "well, what value do we add, once it is digital?" and bam, we're into Give a Mouse a Cookie territory again....) Anyway, we try to create at least the conversations that help bridge the islands of design of the system capabilities and user experience and design of the system internals. Well, we try to do more than that, but we start with where people are. Sometimes the mountain can be moved with just a nudge in the right spot. Other times it takes work we may or may not get invited to do. We need to get the book done already, because Getting Past ‘But’:, while still playing an important role in leading thinking in this field, sorely needs an update.
You might also be interested in:
My, my. I sure have written a lot of (good?) stuff in this Trace. See also:
I serendipitously read this post today:
5/10/13: Oh yeah, there's all the "right system designed right" and "good, right, successful" stuff... and and and these:
5/13/12: Looking for a leadership piece, I reread "We Don't Need No..." and this popped out:
Nor can we just ask users what they want, because what they want interacts with and is reshaped by capabilities we or others can bring to bear to create a new possible, that enhances their capabilities and experience.
6/3/13: Came across another zesty characterization:
6/5/13: This works so many ways:
This is from the ever-awesome Peter Bakker:
The Netherlands knows how to do Spring Break! :-)
I have the best friends!
And works. And works. And works.
Now. Where was I?
Nick points to this post:
Which relates to my requirements post yesterday, and the delight theme in Fractal and Emergent as well as Getting Past ‘But’. Which is to say, we tend to compartmentalize architects into the design-the-guts box, whether it be software systems or enterprises. Visual Architecting has always -- since it began in the 90's -- focused on designing across all the boundaries, including the system boundary. The arc in architecture is a serendipity -- a very useful one. And Nick is right, it is Sisyphusean battle shifting the charter of architects to designing across -- in some part because architects accept (are just fine with?) the delineation they perceive is given to them organizationally. But just like we need to permit ourselves to create beauty, we also need to empower ourselves to color outside the lines a bit, show the merit, then more, and so forth. The thing is, "architect" as chartered is often just an initial guess, and we are expected to step up to defining the role as we want it to be -- as we see it needing to be
And naming things is very much a matter of design. I have, jokingly but with a serious thought thereunder, said I want to create a methodology called Analogy-Oriented Design. Mainly I think it would help our pendulum swingy world course-correct a bit, to have a bit of utter quirkiness brought to our design/naming discussions. ;-) No, I mean, help to bring design precedence from nature and other engineering and design spaces, not just the domain, to bear in our design thinking. Because names are our designs, are they not? ;-) Kangaroos? :-)
Designing the guts is very different from designing the capabilities of the system -- as different as capabilities of parts are from capabilities of systems. But we need to design across because these things interact, and it is by designing across that we bring intentionality to those interactions.
(Hint: sometimes my most important posts masquerade as some trivial little bit of
[Nobody asked for today's Sara story? I am so totally firing you as an audience! ;-)]
I think this (via "J Constantine") is a great metaphor for the architect:
5/11/13: Dana's just back from a week in Texas and I was ready to be pampered. So he made the most awesome brunch -- including, yes, omelettes. :-) He's officially amazing. See. It really is what leaders (really) do. ;-)
I leveraged a trace from last year into a Trace In The Sand blog post because it seemed like that message needs more exposure. I know that sounds like "d'uh" when put in "paying attention requires attention" terms, but look at the system and look at team behavior and consider where attention gets paid and when. Then tell me if "d'uh" is still an appropriate response. The blindingly obvious blinds. That is why common sense is uncommon. And other trite sayings that nonetheless are profound because we are cognitively, perceptually and rationally frail-fragile-vulnerable creatures!
Look, if you think that was a bad or weak post, email me and we can discuss what you think is wrong with it. Because I think it is a boldly written and important post, but if I need to amend my thinking/positioning please gently let me know. :-)
Thank you Gene Hughson, Stuart Boardman and Arnon Rotem-Gal-Oz. Your advocacy is very much appreciated! I feel vulnerable posting an audaciously provocative position, and though we seem to have put much of the "we don't need no stinkin' architects" hostility behind us, we seem to still need to rebuild the case that architect expertise and bandwidth is very much needed even in the context of dynamic empowered teams. To be sure, in complex systems this position is better understood, and that is where it is most important.
"My food bowl is half empty.... this may be my last entry..." I love that! Ok. If I had any sense at all, this would be my last entry. Probably not. But maybe. ;-) Still, I have soooo very much to do that would be more... mainstreamy... than this Trace. Sigh. ...Facing the tension between defying the forces of conformity and needing to have a sense that I didn't squander the opportunity I have to make a difference.
But... rats... stuff keeps happening:
This is going to be interesting:
Taleb has taken others on for similar remarks on Twitter. But Werner Vogels? Twitter, aka "Reality TV" for nerds, just one-upped the celebrity high diving thing. ;-)
This was cute:
Whooooo! OMGoodness, OMGoodness!
My dreams and aspirations achieved! I can stop now:
Well, that's what the praise detractors would have you believe. ;-)
Me? I'm so psyched, I might even write a book and get that system coded up enough to let you try it out. :-)
Thank you Oliver! That was an awesomely awesome thing to say and do.
We lead with the example we set. Oliver Baier is, in addition to helping to shape how we think about service design, setting a wonderful example of inclusiveness. (I have enough fingers to count off how many times my Trace has been quoted or mentioned in blogs in more than seven years, so you can see why I'm so thrilled and excited and pleasantly surprised to the point of obnoxiously dancing on the table here. Ooops. Forgive me? ;-)
Great points Oliver made, and impressive that he found that gem in the tunnels of my Trace-warren. ;-) The other day I impetuously said Serendipity is a mischief of emergence, but it is astonishing how Bliss (our passion) and Serendipity (happy accident) collude to find just-so elements to weave together into something new and (more) useful, even delightful and amazing. Like this update to This is just to say:
And this response to mfeathers one word tweet: "plums."
That is a playful way to make a bigger point. Creativity (re)factors. ;-)
Or as Grady Booch put it: "new systems or modified ones are [built] upon the shoulders and ashes of previous ones." Likewise with insight and enablement. It is exciting to me when my voice is included in the constructing of a new level of insight and meaning. I get to feel like a worthwhile part of the greater tapestry of understanding that we're building in our field, and that is validating and rewarding. :-)
5/15/13: Hm. My Fractal and Emergent paper is being referred to as F&E. It's like, a thing. Cool. Tell Oliver. It's about service design. And platforms. And IT as the provider of the platform that connects the things. That sense and make sense. That act, and proact. It's really good. No really.
We'll just leave it there, for now, shall we?
No? Oh, you're so very nice to me. ;-) Oliver Baier's post had me rereading that Design Rulez trace from 2010. I'm going to draw out a different point, because it needs to be moderated some. When I say "policing" and pick up Magnus' point about "acting with discipline to nip deviations in the bud before their effect compounds," that needs to be taken in the context of an orientation that is very much about "explicit design with a healthy dose of design improvement/validation". That is to say, not only are we staying alert to opportunities to improve our value to users/customers but also to improving the (internals of the) design. Tools like Lattix alert us to deviations from design rules, and we choose how to respond to those. They may indicate a need to change the design. We may choose to let things develop a bit, to see if a better design idea is brewing. The point is just to get better visibility into where the design is being (unintentionally) compromised, so we can make a more intentional choice how to respond.
Uh. Ruth? No, no. I'm still with the bus here. ;-) Faster? To the point? Hm. Well, you know. We think architecture slows us down, and we're not allowed to get off the bus. Ze rulez. They constrain. They impede. They thwart better design. Gawsh folkses. Judgment factors. Too.
Even if you're an architect? Especially if you're an architect!!
Ken Robinson: How to escape education's death valley Filmed Apr 2013
Ken Robinson is a master presenter and worth watching for that reason alone. He gives George Carlin a run for his money on funny (the instance of George Carlin who still hangs out in our digital haunts). He has much to teach us as parents, but also as mentors, coaches, and educators. Architects impact culture; well, those who are great leaders do. Not by command-controlling it (that can impact culture -- like depressing it), but by inspiring, by enabling, and frankly, by making some things harder or less desirable. Through conversations. Through emphasis and directing attention. By example. Through resources, tools, guidance. By showing. By doing. ... This wants to become... a full-scale post-chapter-book-thing. ;-)
While the seed analogy is still in the air:
On the other hand...
In addition to illuminating architects' stakeholders and their concerns, this map by Peter Bakker shows how they interrelate:
The power of the visual, demonstrated!
Just a little thing I made for Mother's Day. ;-)
5/15/13: Dana said I'm taking too much credit, but hey, you know about the birds and the bees, so you know I don't get all the credit for that -- birds, bees and butterflies... learn to fly on their own. With help from outstanding teachers in IU's precollege ballet program! :-)
Peter Bakker pointed me to this, and I started reading it but Mother's Day happened and I returned to it tonight:
Read that and saw The Last Picture Show. Life changing!
5/14/13: Dana sent me coffee.... like this: C8H10N4O2
Should that count?
Busy today, so outsourcing exploring-thinking to one of the Masters who lead me :-)
Thanks to Gene Hughson for this piece of awesomeness:
Left-Overs of Mother's Day Bragging
And a little Degas:
Someone told me today I ought to charge more for omission because it is hard for me.
I like that. Instead of you paying me compliments to encourage me to write, you have to pay me twice as many to encourage me to not write.
I think I'll be writing a lot, for a very long time, with that pricing scheme. ;-)
That is a great characterization of many things. Like. Discovering your vision or passion. Mine? To be the David Sedaris of architecture? No! To make David Sedaris aspire to being the Ruth Malan of self-deprecating comedy. D'uh. [I mean. Word to the wise. Self-(d)ef(f)acing. Please! You know. Self-effacing. Self defacing.]
More seriously, this covers huge distances in the interpersonal space that is so important to software as soon as we're doing it with more than just the voices in our own heads:
Wonderful talk. So, less for me to say or not say. ;-)
That's a wink. Griefous of goodness.
The whole Sisyphus and vision thing is so cynical you have to know I'm joking. We do the thing that is worth doing because it has tremendous gravity to us. It draws us, compels us, energizes us. And we can't coerce others to feel the same gravity. A shared vision that compels others is one that they find attractive for their own reasons. And yet it is work. And can seem like uphill work. Difficult. Easy to have come undone. Emotionally challenging, not just mentally and physically. And there are setbacks. Hard ambitious things are hard ambitious things. There's resistance to that. Impedance from those that want to do the easy thing, or at least another thing. And sure, it is very useful to look for the ways to work with the contours of the landscape, so to speak. To work with the flows of trust and value and information and such, or to put mechanisms in place to route those flows just enough, so that the natural gradients do more of the work for us. It still takes work. But hopefully it is more the work we want to do, mentally tussling with imagine-creating new value into realization, than dealing with turf protection. And such.
5/15/13: Page load time frustrating? Should we skip what's left of May and try again in June... next year? :-)
Just in case, let me leave you with this:
And just what is the meaning of that? I dunno. ;-) I just wanted to close that browser tab.
Disappearing. Image: By Sara B.
When we stopped talking about design, what happened? What happened to university curricula? What happened to expectations? And how does that shape what got done? What time got made for? What people felt permitted and even encouraged to do? So... We stopped talking about doing explicit design? Or we talked so negatively about explicit design (with a great big handwavy term, shuffling all things design in software under the BDUF carpet), that it took courage to talk about design in code circles?
Of course we never stopped doing design. Nothing gets so much as named in code without doing design. Names imply responsibilities -- in retrospect, if we name for the responsibilities we've clustered, or forward, if we name tentatively, with a sense of what responsibilities to trial-cluster.
We can do this design in situ, in the small, growing the system on an as-needed basis, with little forethought and proactive groundwork in infrastructure or structure+mechanisms, little forethought to what this system could become. We can, but if we do, we canalize/direct/cement where it is going by coupling expectations to something that is growing in a determined direction -- determined by connections to the past, because the future isn't being imagined in any impactful way.
Let me say that again: When we grow a system in an ad hoc piecemeal fashion, with little conception of what it can become, it becomes very coupled to the past. Putting small deltas in front of users, places users (representative users or user proxies, at that) in the mode of reacting to what they have. Deltas on what has been put in place so far. The design space becomes limited in ways we aren't even aware of, to what we can see from what we have put in place.
Or we can reconceive even something as humdrum as checkout, untethering payment from a physical spot in a store, thereby also reconfiguring the staff to be consultants and change-makers, not just change-takers. Or something flowery like that. ;-)
Design has to be thought of not just in a very local sense that impacts several lines of code, and not just in "under the hood" code terms, nor in just user experience terms. Design needs to happen across -- the skin and the guts (that is a Steve Jobs reference, and doesn't mean screens and code, but more the system-in-context design and the system internals sort of distinction), and across time -- not into the infeasible, but to conceive options that open up different paths than the one we'd fall into if we just allow yesterday's small immediate decisions to canalize what we see today as options. We have right and left* brains, we can take what we know, and play it out into the future. To take a step, or a leap, we do this. Literally. And figuratively. We can collaborate, bringing together "what we know"ness from others, to expand the possible we see.
We can put Curiosity on Mars if we are ambitious and tenacious enough. We can create a device that in very fundamental ways reshapes our experience of ourselves as humans, and entire industries and industrial-human-environmental ecosystems in the process. But if we're going to reshape ecosystems, we can let that play out by chance, or we can consider what else needs to change in the ecosystem to make our change viable and allow it to thrive in the (new/reformed) ecosystem. And we can consider how to we make it desirable for others to play the new roles they need to play, or we can leave that to chance. Oh sure, chance will play its role. Others (competitors we recognize, or don't) will play roles.
Shift will happen. But it will happen whether we move with just a very narrow immediate field of view, or a more expansive, strategic view -- some of the time. We write code lines at a time. We don't paint skyscrapers as sketches on the skyline and have those filled in with iron and glass in big brush strokes. Nor do we build systems that way. So design needs to be this dance between large conception and smaller, and building the chunk sizes that fit the extraordinary moment we're at. With the medium to suit.
Sure, we're not thinking about what our product will need to be in ten years. That'd be insane. But so is unquestioningly, unimaginatively coding what the product should have been last year when we hope it will be fully embraced in use in a year, and dominating some piece of the market in years thereafter. And if we code up expectations some user proxy has of "market need", we tend to be codifying what has been, not what will be. That opens the ecosystem to being reshaped by not-you!
We're not creating systems for LaLa Land -- but if we just look back 5 years (2 years in some industries!), we realize it is just as nutso to design for that past as a further out future. Judgment factors! (I made a sweeping generalization. Judgment factors -- and extracts the dramatic hyperbole while allowing the point to remain forceful. ;-)
Design is fractal. Too. But it is a messy/weird sort of iteration that plays out the fractal unfolding. Still, our brains do this -- they project future options, yet act quite immediately and locally, shifting and filtering attention and what is sensed and perceived and acted upon. We just need to allow this to happen in larger settings, where more than one brain is brought to bear on projecting and designing for the now of tomorrow's tomorrow, for time slides! Or something. ;-)
Oh look, we have one of these:
for architecture! We can take minutes, or hours, or even days. As we judge best fits the extraordinary moment.
Work it out!
I love this post:
I just think we need to work at different levels/scopes and with different cognitive modalities. We have different tools to bring to the design and communication table, and we need to use them. Judgment factors.
Considers what to factor in. What is relevant, what is a priority. But also works at different levels of factoring and interaction. And factors in judging what besides factors factor.
More messy design traces:
* Clearly I need to do more homework on the brain thing. As best I recall, Jill Bolte Taylor, in her TED talk, describes the right brain doing analytical stuff like making sense of the past and projecting out future options, while the left brain is aware of the whole and the interconnectedness of everything. But. I might have my lefts and rights switched. [It makes it really hard to do the lefty-loosey righty-tighty thing. ;-) Ohh. I'm just playing with boxes. And frames. Of the (de)limiting kind.]
This, via Peter Bakker:
Here's a taste:
Does this contradict what I was saying? No. It underscores what I am saying. If you (re)visit the first sections of the F&E paper, there is a distinction and tension between elaborating, refining, and stabilizing a current ecosystem and sending a wave of change through it, that destabilizes and reshapes the landscape, making a new ecosystem (or set thereof) possible. If we focus on experiments that are (always) simply small deltas on what we have in place, we are elaborating the space, better and better serving the needs of smaller and smaller niches, tethering those served the more closely to our platform and its services. If we only do this, we don't see what bigger reshaping opportunities are configuring themselves around us. We can opt to play early follower in the event of a reshaping entry in or bordering on our playing fields:
but even then, better if we reimagine and reconceive the possible, to create distinction and identify ourselves with compellingly unique value. So I was arguing for design as a larger and smaller scoped activity, the scope depending on "this extraordinary moment" -- that is, what is focused on is a judgment call. And judgment calls like that are themselves design decisions and take considerable talent and ability to work at different strategic and tactical levels. Etc.
Interesting, though, how leading tech is showing its alpha status through architecture, and interesting how different it is than the tallest tall buildings of finance and real estate. ;-)
Damned If I Do
Awwwww. I need one of these:
Ok, so you know my Trace In the Sand Blog is pretty dormant, but such posts as I do put there tend to be more... traditional... I wanted to try something in between that and this scratch pad, so I'm trying a Trace on Blogger... I'll see how that format works, and decide whether and how to evolve what is hung under the Trace umbrella. Which is to say, there are now three flavors of "Trace in the Sand" and I recognize I need to resolve the identity better. But, with only a handful of visitors to any of the forms my Trace takes, it really isn't a big deal to be experimental. After all, it gives the few people who visit Trace-extensive (here) a way to cut back on that habit and interact. And get LIFO ordering. Everything you've been asking for, so long as I remember to push some traces over there. ... That said... I'm really not sure if I'll decide that's a stupid idea -- I like being able to find out what I think by writing, and that means I have to be free to write without the inhibition.
I know, I have to ask the next question on the Context Map post. I am so grateful to Gene and Peter for their responsiveness. Everyone else? Just busy I guess. But you'd think there'd be some more interest in just-enough (Pareto) tools for understanding and communicating CONTEXT! ;-) Because it's not good enough to just lip-sync to the "context factors" tune. ;-) To factor context in, we have to get a sense of what, in all that landscape out there, factors. And no, it's not just the deployment topology/infrastructure (important as that is).
Playing to the wind. Image: By Sara B.
Below is a (rare) portrait of the artist as a young girl. It comes with a story. Remind me to tell it. It is a story much like the story of the rhinoceros. But, but, Ruth, architecturally significant? New here, huh? ;-)
Platform as substrate?
Swirls of thoughts I don't have time to draw out right now... Some floaters:
We can think of ecosystems at various scopes. We can think of the substrate that supports the relationships of these interacting, interwoven ecosystems (of ecosystems) in different terms. Value (in various forms), trust, information (at various levels), communication flow through different media, some overlapping. For example, highways -- railways, trucking routes, and information highways -- enable organizational organisms to move value in different forms, around. Some of the relationships are competitive and predatory. Some synergistic and mutualistic. Some merely move flows along. Some add new kinds of value. And so on. Plus more. ;-)
Substrate. Firmament. Infrastructure. The core idea has to do with what are the enablers for relationships? Shared purpose? Co-dependence? Transport? Etc. Lots to mull!!!
I still need to finish B = mc2 by Jean-Jacques Dubray -- I got about 30% into it, got distracted (not in the trivial sense), and have to find my way back into it so I can share my notes and thoughts.
A little trace. Several huge ideas and links. :-)
Look What Dana Did!
And the house smells so gooood!
I was asked if it is ok to appreciate one's own work. I said one has to. We may be the only one who does, so we should go ahead and make sure at least one person on this planet appreciates it! ;-) But further, we will be the only one unless we enjoy and appreciate and value our work enough to have the gumption to do it, and put it out there. So we have to take pleasure in our own work. Not uncritically. Not so much that we think we're done, and don't push ourselves to advance our craft and our contribution. But enough to motivate ourselves.
Ooooo, this is a lovely trace:
Who writes this stuff anyway?
The other day, my fingers spontaneoused "Serendipity is a mischief of emergence." Today I realized what comes next: "But she serves Epiphany well." [In your case, you might prefer "But she serves Eureka well." Depending on how gender suggests itself to you.]
Sometimes the thought children my subconscious delivers to the doorstep of my mind are missing their dancing shoes. This time, it took a few days to match them up. ;-)
5/20/13: Thought children. Perhaps I overuse the term, but it is in tribute to the conjugation of ideas that give rise to new generations of insight... The parents of which have... much more interesting social lives than I (wink). Overuse? You hadn't noticed? You're too... kind... Here, allow me:
I think understanding, like awed appreciation, is a stance (an openness of mind-heart) and a process. It is all the history, all that made a person open and closed. And it is also how this moment is taken and allowed to tumble, and what we do to shape its flow.
Connections? To architecture? Hm. If there is any connection, it is in connections. And stance or orientation.
If our orientation to this ruffyan Tracer is friendly, open, goodwilling, we may see the thought child collection as a delightful interweaving of figurative and literal parenting and genetic and memetic images that lend new insight into, freshly nuance our understanding of, or just give us a more colorfully vivid way to talk about creativity and the creation of ideas into composites and systems. If our orientation is unfriendly, we may cast the bulleted collection a vanity, full of fanciful, tasteless even crude allusion that doesn't belong in technical-business discourse. We may think the Tracer irresponsible with our time. Flaccid and undisciplined. Too unrealistically self-important to sift and cull to protect a happenstance reader's precious attention. And so on and so forth, words tumbling in excessive playfulness. How we orient, channels, canalizes, allows and disallows, what we perceive.
On the weekend we saw Room 237. Talk about Serendipity as a mischief of emergence -- emphasis on mischief!! ;-) We make connections. In software, we see how our programming languages encompass ever more powerful abstractions -- that is, our building blocks, our fundamental units of composable capabilities, advance. And we build higher level abstractions or more powerful composable capabilities, and so on, to create more complex, more sophisticated and ambitious systems. So, some of the connections we make, make sense at least in that they are useful. And some are really flaky and off-the-wall. And if we look at what people 100 years ago envisaged would be true technologically now, some of the ideas seem as off-the-wall as some of those theories in Room 237. I'm not excusing or embracing the nutty theories. Just pointing out that our own insights and ideas that we hold dear and think so awesome and change-the-worldish, may be just figments of our unique perspective and thinking. Perceptual, cognitive and decision biases and flaws abound. What can one do? [Of course we have an approach. But it doesn't have to be a rhetorical question.]
5/23/13: On connections:
See also: Connecting Dots, 10/20/2011
5/25/13: This is wonder-full:
We watched Cloud Atlas last night. Months ago, Dana and I were due to see it, but he was just back from Europe and came down with some flu-sy thing. Then he watched it on another trans-Atlantic flight. And ... it took me 'til now to see it -- a good thing, I think, because it distanced me from the downers on Twitter and such. I enjoyed it. Imaginative. Expansive. Sparkling insights. Complexly interwoven. Sometimes a bit too self-conscious. The kind of thing you're very accustomed to, if you read here. :-) I jest. I jest.
It did make a point about freedom, and how we don't appreciate it until we lose it. Like. When we're not able gmail or twitter. :-)
Connections and Conversations
A HUGE thank you to Peter and Gene for reminding me that being bold enough to enter a conversation space pays off in advancing my understanding and adding to my insight&story treasures in important ways!
From the Stream
While technical debt isn't the most sexy topic under the software sun, it sure is one that persistently tracks and tackles us, and new languages and neat programming tricks don't get the whole job done, at least, not when it has to scale organizationally and deal with the pesky problem of success... legacy. Messy legacy. What we shape in glory today, becomes the inglorious mess we bequeath to those who have to bring yesterday's indiscretions into tomorrow's newly shaped reality.
Alright then. Let's start with Steve McConnell's slideset from his talk at the ICSE 2013 Technical Debt Workshop (the 4th in the series):
And Philippe Kruchten's tweet-outs:
I think the points I made a couple of months ago bear restating, for they are actionable insights, and no-one else (that I've seen/encountered) is making them in quite the same way:
What we call "technical debt" is a situation where we trade-off market learning (and early market penetraion, building an ecosystem or dependency network around our product, etc.) for technical learning (and building a sustainably viable product others can trust and depend on); alternately put, we focus on adding functionality and shaping the system-in-use and user experience at the expense of structural integrity and developer experience. If we're intentionally incurring this debt, we're doing so to meet a "market window" or getting what we can done before we run out of money, or something of that ilk.
So far, that is just restating Cunningham, pretty much. But where the little shift here and little shift there gets us, is to questioning the notion that the greatest all-else-subverting urgency is getting the idea to market in graet haste.
A little shift? Like, the design of "the guts" of the machine isn't just flat-out-in-the-open obvious or trivial. It takes attention, experiment, design and redesign, too. There are two broadly encompassing* and interacting learning or design spaces:
That "how it works," you notice, is on multiple planes -- how the system works in its contexts of use, and how the internals of the system work, to deliver the capabilities (functionality and properties) to the user. And, as we deliver capabilities to users, they configure them into larger composite capabilities, in more encompassing, socio-technical systems.., of systems. So the learning is multivariate, happening on multiple planes, in interwoven ways -- and dynamic, changing, evolving. And out of this messiness, we need to create "production" systems -- systems that lives and livelihoods depend on. So we learn and resolve and resolve and learn.
Anyway, this is talking about technical debt in terms of focusing our design attention on the system-in-use at the expense of the design of the system internals, and this attention deficit catches up with us. Sooner or later, not having paid attention to structural integrity (internal design) results in a system that fails from the inside out -- like outright bugs, but also system properties that aren't up to expectations, or a structure that fails to be sufficiently adaptable to changes in (our understanding of) the context of use and purpose. etc. ETC.
The problem with technical debt is entanglement and rigidity, inflexibility, being tied to outdated or misinformed assumptions, brittleness and fragility. That is, technical debt quickly thwarts the very goal it was incurred to address -- market learning. The system becomes canalized into an early vector of assumptions, and the matter of changing that vector becomes increasingly intractable.
* design is (somewhat) fractal and (something like) hierarchical along multiple interacting dimensions... not neatly and cleanly decomposable into independent spaces
5/23/13: Well, I'm in a lot of sympathy with the orientation that Stuart Boardman art-fully expresses in his post:
5/24/13: This is a useful positioning:
Naturally, I like my view. But mine justifies VAP with its early iterations using the cheapest design media to fit the design challenges (mainly early value/concept uncertainties and clarification of direction) and subsequent iterations focused on "what at this extraordinary moment is most important" -- so that we cycle through market and technical design/redesign/engineering to field and evolve systems that are responsive to opportunity and challenge and... One paragraph explanation of VAP> How cool is that? Oh. You have questions. Well. <teenage voice> That's nice. ;-)
One day someone is going to say "Who the hell else writes like this?" And we're not going to know if they're in astonished awe or flat-out disgusted! ;-)
Naturally I think awe is entirely warranted. It is racy, spunky, and insightful -- no? No? I'm stung. Ok. Ok. I'll go back in my girl-cave and lick my wounds. Your silence hurts! ;-)
5/31/13: Been there? Geek&Poke: Technical Debt (Part 2)
6/3/13: Agile is antifragile. Maybe. Maybe not...
In case you need reminding, here's my write-up on Conceptual Architecture.
5/23/13: Oooooo, look, Conceptual Architecture by novelists:
Complete with components and roles/responsibilities. ;-) And the dynamic unfolding.
Waaaat? You don't see the connection? A little imagination? ;-)
Nigel Green is working on an interesting post series titled "Searching for Agility and Industrial Strength." A comment on the first post mentions Tom Graves recent talk and Agility needs a backbone post, which reminds me that Kris Meukens was exploring along complementary lines:
Naturally you're well acquainted with my take -- no? Oh. Well then:
Of course, the danger of "agile" is the hidden (fr) [as in (fr)agile, that comes from the apparent extreme mutability of code, that change-change-change-oopses into an entangled "ball of mud" that is hard to change]. Given that I'm on a technical debt wicket at present, the "industrial strength" term resonates. It is one I've used too:
I really have to do a post on naming things.
For now, I'd like to point out this thought provoking post:
It is wonderfully insightful:
Dist is a good example (read his code), because it demonstrates a unit of comprehension that is vastly different than 100k LOC or 1 million LOC. At some point, we need to be able to grok and compose and communicate in terms of higher order abstractions because, at an extreme, 1 million LOC doesn't fit in our mind's eye. Well, not mine, anyway. Not without the help of chunking, anyway.
You haven't asked for Sara stories and I'm most entirely disappointed in you. Well, this one has teenage language in it, so avert your eyes if you need to. Ok. Here goes. One of her friends was bemoaning something and Sara thought "Sometimes humans just worry too much. Take a jellyfish. A jellyfish doesn't worry about all this stuff we worry about." And she made up a jingle about what a jellyfish doesn't. And then whenever they thought they were getting bogged down in stuff they should care less about, they did the jellyfish song. How does that relate to naming things? That class that contains 50% of the entire code base... Hm. This didn't go quite where I thought it would... I should refactor, huh?
Funny how life works out; the threads Serendipity pulls together for us... Ok, so back in 2011, I wrote this:
Where could Ruth be going next? Well, it's like this see. Kids at Ryan's school write to some of their heroes and ask for signed pictures for their school yearbook. John Cleese kindly obliged with the message "Thanks for remembering I'm still alive." How cool is that?!
I'm curating a list of reading, mainly books, but also, you know, stuff like xkcd, that will so thoroughly turn on one's curiosity lights and nerd sense of fun and funny that one will be a geek-lifer, no turning back. I forgot to put Michael Feathers tweet stream on that list. Not sure that it's PG-13, but nor are a number of the books on the list so...
As for being still alive and really human, Avdi Grimm impresses me as someone who "has it all" in terms of smarts and charisma but is also working on being a really neat human being. You know, of the fully becoming kind. I know I comment on people too much but he gave a shout-out to Angela West Harms work on compassion in software communities and that was just decent. He could have given the same-old same-old corridor of power guys like Kent Beck a shoulder pat, but instead he picked a person who is doing meaningful work but not, you know, geek glory work.
Interesting What Fires
One of the indicators of my lack of success in selling my brand of Ruffyan contribution to this field is that in the area where I most excel, that being you know, a farce for change, I don't come up on the first several pages of Google returns [at least, this is true googling "enterprise architecture humor"] -- unless you switch to an image search, of course.
But... what kind of scout am I, that I never noticed/brought this to your attention before: EA made easy, geek&poke
Well, I pulled another bit of tracing over to my Trace in the Sand (informal) blog... It is informal and sketchy and partial... and, as with the design piece that preceded it, I feel vulnerable... taking a controversial stand (on a controversial topic at that) in the software field is dangerous... Oh well.
Doing big ambitious things means being exposed to arrows from lots of divergent interest groups. Taking some from the team*, while saving them from others coming from outside.
As much as I value empowerment, I also think that delegation is important -- including delegation of decisions "up" to broader scoped decision makers where that makes the most sense for system outcomes, and delegation "down" to more local, narrow, specific scope when that is good enough from the system perspective and better from the local perspective. Complex systems have too many decisions for all to have their minds meaningfully wrapped around. So we have to partition the space in some way, which means working across to address the cross-cutting concerns exposed by our partitioning choices.
* If you are aware of any social anthropology studies of teams and dominance hierarchy behaviors do let me know... My working hypothesis is that we need to better understand the subliminal and bio-chemical cues etc., better, so we can work with our bodies and brains better, enhancing our adaptations to new social demands and situations, but also better leveraging age-old cues and advantages, while damping maladaptive behaviors (like amygdala hijacks).
5/25/13: I do so very much appreciate those who show up with a retweet or a comment. I'm shy out there, so I do understand reticence. But it also makes those who demonstrate collegiality in this field the more noticeable and valued.
Peter Bakker's storyline mapping book is taking shape and promises to be a unique and uniquely valuable contribution to our field.
How we frame things! Each of us, with our agenda. Here's a different take on the same talk:
UML was a "fusion" of visual design languages for software into a standard that would reduce the proliferation of syntax in essentially the same diagrams from one method camp or tool vendor to another. But. As a committee-driven stardardization effort, it got carried away with itself, and most of us who have used "UML" have done so pragmatically, using just enough (just in time) to fit our modeling needs. ["Just enough" is the term we used to describe Team Fusion back in the 90's. The idea was that a method or process has to be adapted to its context to be just enough to support the challenges of that team. So we called Team Fusion a jem. Pronounced gem.]
We just need to rebrand UML as "Visual Design" and then we'll be all set.
Garr. Sometimes the lack of self-knowledge of this industry is so... discouraging.
But... there's opportunity in it too, because we can recast what we learn in the natural course of events (events being great teachers, if we're willing and able to listen and learn from them) and rebrand and reframe and REFAME. Yeah. Fame. I should get on it, huh?
This is interesting (permutation on DSM theme):
5/26/13: UML came to us in, and growing out of, the context of OOAD methods that tended to focus on the level of design work that is but a sconce abstracted from what we do directly in code. So toss the baby out because it soiled its bath water??? We misapplied visual design and instead of learning and self-correcting, we antibody the entire shebang?? Well, I quietly and purposefully took a different route. I don't like to enter fractious frays, certainly not those that have gang-busters honed in on them. So I worked with those who had big problems to tackle; those who needed the extra cognitive gear of visual design and architecture.
It is at the tip of my fingers to tweet back "Reporting for duty Sir!"
I told Dana. At least he laughed.
This Romanian tale is...
Apparently he does indeed return.
Now, you might like to read this:
What's an architect to do? Between paralyzing alarm and endangering inaction... lies a lot of need for leadership?
Posit: The greatest artists anticipate and rely on mastery in their audience. They don't speak down to them. They expect greatness in those who will wander their work with wonder, an openness to experience and insight but an openness also to wrestling with some mettle to find it.
I don't think architects or developers should talk down to, or expect those who work with their work to be less capable than they are. Treating our peers and colleagues with respect and courtesy means not leaving a mess of work for others to clean up, but it doesn't mean mollycoddling them.
Here are two absolutely beautiful pieces for Memorial Day:
And this, via Tracy Harms:
It only got one retweet (mine!), and I have to wonder... people's awe sensors all crudded over with so-what and meh and not-so-special?? What?
Tracy also tweeted this! My take on Miyazaka? So nice of you to ask:
It occurred to me to respond: we often refactor to (better) enable (adding) behavior. We might call that the system quality of modifiability, and keep it under the system qualities umbrella. But often we have a specific modification/addition in mind. In which case use case points (may) factor (thumb to the wind).
But I didn't, cos I wanted to think about it... :-)
In essence, I'm suggesting (again) that we allow that factoring and refactoring happens (or ought to) at different scopes. Refactoring at unit scope has all the benefits of safely improving (localized) structure without impacting other parts of the system (if we did it "right" and there are no side-effects we haven't caught/noticed?) and being able to verify with existing tests. When we go to broader scopes, structural changes may impact the architecture and need architecture oversight and judgment calls about the impact on system qualities/outcomes and system integrity, to update the architecture (or deny the structural change if that is the judgment call), etc. I am suggesting that there are larger scoped changes that we still want to call refactoring despite their scope and even if we are taking into account future behavior to think through rationale for and design of the changes. This is a refactoring of existing responsibilities, taking into account capabilities we have high confidence we will enhance or add. (Or remove. Sometimes. Hopefully!)
I like the view that mistakes are portals of discovery:
5/28/13: It occurred to me that this is a great metaphor -- we see the shadow the system casts...
Even what we call "structure" in software is an abstraction... which reminds me of Michael Feathers point "there is no up or down."
My Versatilist trace last year has a link to Nigel Green's "Should the Enterprise Architect be an X or Y or XY thinker"? blog post that unfortunately was a casualty of Posterous' demise. (Perhaps we should require "estate planning" from community sites entrusted with the future lives of our thought children/great content treasure?? For instance, couldn't information utilities like Google get into the "content insurance business" providing "life insurance" to preserve the content we entrust to start-ups?) Anyway, what I wanted to let you know is that a version is available:
That reminds me, enterprise architecture is generally not a single person function -- at least in the organizations we work with, the scale of the organization is such that enterprise architecture is the charter of a team. The point being that any one person doesn't need to cover all the bases of skill, predilection, activity, responsibility and yadda.
Also, this set loose a storm of thoughts/ideas [but I was out on Lake Monroe kayaking this afternoon (perfect for Memorial Day reflections) so the thoughts haven't landed yet]:
Catching up to Fractal and Emergent at last:
Just kidding. You remember -- low hanging fruit is the only kind I'm tall enough to reach... Meaning, it raises issues that are addressed in the F&E paper (mini-ebook; free, but for the price of your contact info which is a bother I'll grant but better than the purchase price of $150)...
I'll get myself in trouble writing colorfully like that. NO I WON'T! Even though on a day-to-day basis this is not much bigger than a tweet stream (and much better, no? ;-), when one comes upon a month of entries it is totally tl;dr... ;-) So safe dude. Safe. Just you. And the voices in my head.
As design thinking and IT goes, Nick Gall is also beating that drum. Which is cool like. :-)
Well, on the other hand...
Two minutes, and that'd already been retweeted 6 times....
We might have to change the name...
Visual Desire. That work for you?
Yep -- you heard it here. ;-)
More licking the wounds of silence.
I pushed another trace over to the Trace in the Sand (informal) blog.
I appreciated the pointer to Amanda Palmer's talk -- it is powerful and inspiring. Amanda's TED talk likewise! It is hard to tell one's audience that the audience has a resposibility to transmit some of those smiles and nods. One of Amanda's great messages is that one has to make the ask. If we don't want to rely on the old power circuits to get word about work we like out, to screen and vet brilliance, to pay to enable it to survive in a tough world where bills actually have to get paid, we have to teach and remind our audiences that they have different responsibilities in this support-what-you-value world.
I saw this last night:
and ... decided to read Nabakov. :-) But, this morning I was greeted with some inter and action in my Twitter "Interactions" and I was quite bowled over! Thanks to all who gave the post the kindly collegial treatment of an aptly-framed onward reference, and a special thank you to Peter whose enthusiastic response to my Dotty post knocked that first domino. ;-)
I'm going to pin the tweets here, because (I'm thrilled to at last have an opportunity to brag; wink; and) they add importantly to the post:
Aren't those great framings? I'm daunted (and inspired!) by the skill some people have in conveying so much in just a few words!
Anyway, a key point is that the more variety we build within ourselves, the more variety we and others on our team, and the organizational more broadly, have to draw on. I like the notion of "requisite variety" (Ashby's Law) applied to organizations -- that is, architects and others are key to presenting variety at the organizational interfaces, so that the organization has sufficient variety to respond to demands on it to act and respond to opportunities, challenges and threats -- and variability and change And because change changes, I also like the notion of "requisite flexibility" -- not only do we have variety to respond to variety but the ability to change what variety we present.
[Since this is performance art, please note that pause. You know, when the audience is given the opportunity to applaud -- or at least to notice that they were expected to get something great right there, so if they didn't they might like to take a moment ... ;-)]
[If you are new here, you might mistake that for hubris, when it is quite the opposite -- the only audience I count on to read here are the voices in my head, so jokes about audience are entirely on me! ;-)]
6/1/13: [In case your satire and irony sensors are dull, that is layered self-satire. I like the synthesis that organizations get the requisite variety they need to respond to the variety -- and dynamically shifting-changing variety at that -- within and without in good part from the highly adaptable, flexible matter of the humans that make them up. I did a liltle "dance" at the "eureka" and teased myself for doing it. I expect only a friendly audience who gets the recursive satire in my direct self-criticism and the indirect hubris-descaling through seeming self-congratulation that allows ultimately a deeper self-criticism. But... perhaps I do need a "sarcasm, irony, satire and wicked play" font... You know, an accessibility mechanism for the sarcasm impaired. ;-) Sorry. Couldn't resist. But if you read here, your irony and satire muscle is given a work-out with more flexibility development than bulk building in mind. ;-)]
Just because I am so very nice to you, I'm going to repost this trace from 5/8/12:
Dana Bredemeyer pointed me to this section (Benjamin Franklin's speech) in James Madison's notes from the closing days of the Constitution Convention (the Yale site is an awesome resource):
Why do I say that's a must read? Think architecture. ;-) Isn't it awesome? I should post it to the Requisite Variety blog soon, so we can discuss it!
But such superb lines. Allow me to reiterate:
I mean, we know that person, right?
Well, we could go over and over the whole thing. It is just so very perfect! In all its recognition of our imperfections. And the necessity and the tribulations of doing big things with and through people, with all the mix of folly, foible and greatness we each bring. There will be compromises, some individually and others generally perceived.
Oh, yeah, have you read "What it Takes to be a Great Enterprise Architect"? Have you recommended it to others? Well, why ever not? Oh, and lookee there... we have a workshop, if you're interested:
A number of wonderful architects (some have worked with me before, so I know they're awesome, and some have chosen to work with me for 3 days, so that says a lot about them too) are signed up for our next open enrollment Architectural Leadership and Other Skills Workshop is coming up in Chicago/Schaumburg on July 16-18. There are still seats available, and we would love to have you join us. Email me for more info:
How to Use Mirrors
This is a nice example of using oneself as an example to raise awareness...
If something isn't working, change!
I also write at:
- Bredemeyer Resources for Architects
- Oh My.
- Compromise -- a Repost
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