A Trace in the Sand

by Ruth Malan





Architects Architecting Architecture  

May 2014


What's a Trace?

My Trace is a playground for developing ideas, for exploring architecture and the role of architects. It is a journal of discovery, and traces my active reflection. I've been journaling "out loud" here for over eight years. To get a sense of the span, calibre and contribution of this body of work, there's a selection of traces linked here. When reading a trace in isolation, it may feel like you've been dropped into a thought fray unprepared for the action that is already in progress. It's okay. You're smart, and my Trace assumes that. You'll get your bearing quickly. Just give it a chance.

It is a journal. That is, it is an informal trace of wandering, exploration, discovery. The insights are there in their sparkling bucketfulls, but there are fewer clear onramps and offramps to and from them. ;-)

Sure. It may be difficult, textured, relying on emergence and recursive structures, poly-thematic, playing with delicate and intricate harmony sometimes, discordia others... So?

Shouldn't writing for smart people expect us to rise to the occasion of it? And this is an occasion! It is the writing of now, as it unfolds. It can feel unsteady, foggy. But in the clearings, how gorgeous it is! No?

No? Oh. Well. I try.

Sure. It responds to the discourse of our field, but also leads and shapes key conversations (in my own head, anyway; smiles). It connects, and weaves. It leads, inspires and enables. Not with a heavy handed didactic approach, but with more the approach of placing learning objects in a crucible of encounter, of thought and the mulching, compost adding/turning, seeding, watering, weeding, tending and attending, growing of wisdom. ;-)

That's not how you see it? Well. Hmpf. You can make it great, by expecting it to be! And encountering it so. It is not just what is in a work that makes it great, but what is brought to it, how it is interacted with, allowed to become.

Buying it? I'll throw in a freebie:

True art does not look like art." - Lao Tzu


Food Fight! [Alt: Design Wars: Part I: TDD kills System Design; PART II: A New Hero, the Daughter of TDD and System Design...]

Say what? Twitter was getting boring? It was, wasn't it? I mean, there is only so much "novelty" one can be enticed by, before novelty gets old. ;-)

So. We should start to reassess the foundations, and call out the shifting sands on which we've built this field. No?

I was trying to figure out why such a firestorm spun up around DHH's TDD is Dead and Test-Induced Design Damage posts... Why was the reaction so strong? What was the sensitivity he set off? Does he have a point, triggering defensiveness? Or is he wrong, and the concern is that people follow him blindly -- cultishly? Is the unspoken fear that lemming-masses follow the arc of DHH's rhetoric without reflection? Or that the field is ripe for charge, creating a chance to restake the boundary lines of our field? A Putin offensive? [That last is, of course, an impish wink for those whose playful satire sensors tripped out somewhere in the field of TDD is or is not dead. Performance art in progress. Watch that amygdala. ;-)]

Looking back, the last big land-grab, in the form of the Agile Manifesto, redrew the lines of dominance territories, reclaiming territory from design... Leaving a gaping hole in the field that TDD was crafted to fill -- TDD kills two birds with one stone, accomplishing design along with construction of the machinery to prove -- well okay, establish -- that the code doesn't break the design (intent and responsibilities and interface, and, to some extent, surfacing assumptions/boundary conditions, etc.). At the unit level. ... Of course... Systems are built with units. So design just scales emergently from there. [Sensor check -- twisted wry and blinking arrow noted??]

Want to know how successful that rhetoric was in shaping the thinking of the field?



Selective snips, to be sure. But I simply wanted to point out how much of the "why TDD" discussion is about design -- which is good. But unfortunately tends (through emphasis, on one hand, and neglect, on the other) to reinforce the notion that unit test creation is the medium for design thinking. That, taken in the absolute, is a weak position. And DHH attacked* it. The Achilles heel he went after, was an emphasis that skews design thinking towards unit testability over other concerns. The counter-attack has been rallied on the grounds that he was throwing the unit testing baby out with the soiled design bathwater. And so fervent has been the protection of TDD, that several glaring points are, generally, lost in the blood-letting, dust-raising of the kerfuffle:

  • tests are not the only medium for design (thinking, communicating, documenting)
  • mechanism and system design are important (too) [this is not just an issue of design scope, but also a matter of when (architecturally significant) design decisions are investigated and made]

It is interesting to me that the debate, in so far as it touches design, overlooks matters like design medium and scope (broader than units), interaction and emergence. The Agile Manifesto gents so successfully swept models under the rug that it is dangerous to bring them back out? Integration tests must be the right best medium for (driving) system design... because unit tests are the right best medium for unit design... Cause for pause?

Say what? Cause for pause?

Yeah. What should give us soil-our-pants fear and loathing for ourselves, is that we have made it unsafe to have discussions about how to accomplish being better at creating software systems. We go all pack attack. So we don't scrutinize ourselves, route out the flaws in our approach and discover how we might do better?

Why is it a problem that DHH used <gasp> rhetoric? She asks, in wide-eyed fear for her life! With a playful wink.

Oh. Wait. Was that potty talk/"soiled" theme too... organically colorful? Distastefully so, I do declare. A point of view strikingly put, too often leaves some feeling struck. Out**. And yet we need to be able to hold these various styles of conversation in creative suspension, weighing the various points they make, and figuring out where they lend new insights, or useful nuance to our own views.

How much of what we do in our field is about zealotry? We'd attack anyone who asks that question... So I didn't. Well, not so's anyone'd notice.

In seriousness, it is useful to revisit TDD and reflect on its contribution -- experience brings insight and it is just as well to draw out what we have learned into the shared thoughtspace of our field. It is also useful to reflect on what else is important. When test driven development becomes test driven design, or design shaped by testing instead of outcomes-focused-design, how does that bend the system design? That is a very useful question. It should be asked! A variety of answers, and even styles of answer, need to be tolerated.

I don't mind the color and flash of the debates, so long as we recognize that that is what they are -- energetic discourse, sort of the colorful pageantry of knights of our era. But... let's keep it to mock battles, and not seek to hurt and undermine and belittle people. If we can avoid being fearful and defensive, and instead stay resourceful, all of the different perspectives go into the mix of our growing understanding. TDD and related approaches play an important role in quality engineering, including covering key aspects of design. Other design approaches help in different facets and at different levels or scopes of design. A "unit" in the TDD sense is but one granularity of design frame, where we consider the chunk in more "black box" terms, framing its intent, boundaries and interactions across its boundaries, before (and then iteratively as we learn more) we get into the matter of designing the guts of the chunk. This happens fractally at different scopes, but the fractals are multi-dimensional and cut differently across dimensions. So we have to hold these different design "slices" and scopes in creative suspension, designing across them sometimes, and focusing on separated concerns at others. I think there's an issue if TDD is our only (explicit) design recourse, leaving other design mediums and scopes out of our cognitive-assist kit.

5/4/14: I wrote that trace yesterday, but pulled it undercover; touchy topic. This morning I laughed at myself -- next to no-one reads here anyway... And those rare few who do, are kind -- kind enough to read here, at that. This is not a matter of "confidence" but a matter of the penalties for women who stand out being, generally, high, making it not worth the risk. When so few people are there to get one's back, to support, encourage and signal boost, it is not worth standing out. Even when what you are standing out for, is urging and enabling discourse in our field that isn't about pack attack and fear.

Discussion/Debrief/What I did there: I made nested points.

  • The core is a demonstration of entering the fray of this debate, summarizing key points of view in vivid terms, and adding my own. That is, I entered the ring; a vulnerable place from which to make my point. Vulnerable because, depending on whether you feel alignment and engagement with my position, or threatened and have your defensiveness roused, you likely feel something.
  • The other went "meta," asking that we reflect on this whole matter of "fray" and figure out how to allow and enable lots of different styles of interaction and discourse to advance our field, but to also be more tolerant and careful not to attack so viciously that we make people fearful and elect to refrain from sharing their views and experience.

Whether my perspective struck you as useful or not, hopefully you at least want me to feel safe offering my perspective. The line between "vivid" (a persuasively positioned point of view) and so confrontational as to damp interaction and shut down discourse can be fuzzy and hard to see, until too late. design stakeAnd we tend to be defensive when it is our "baby" (upon which our livelihood hinges) that is under "attack." So it is hard. But it seems like we need to orient to finding a balance where we can be interesting and vivid and impassioned, but not ridicule others, not attack them nor be disparaging and disrespectful.

If we want our field to be healthy, we need to be able to have open discourse -- without shutting the conversation down by making it unsafe to have different opinions to those that are popular... just now... ;-)

While I have you shaken about wondering if you just saw the real roadrunner, or the dizzying mirage of an argument, let me put this stake in the ground of your thinking: we need to get better at design and no, unit tests aren't enough. Meep meep.


The point of design is mindfulness. Different techniques bring more mindfulness to bear at different points in the design process. -- 1/9/14

* DHH's subsequent post has a shift in emphasis, I am aware. David has been stirring up some useful, albeit energetic -- sometimes confrontationally so -- discussion. Here are some examples from the current flurry, along with some meaningful pieces of the discourse over the years (more are linked in the text above):

Others we should add in here?

TDD hangout wiith the Luminaties

Ummmm. Should I be this tickled by that "watch myself" phrasing there? What an opportunity for Martin to show his self-awareness and sense of humor, by chuckling at what he did there. He should indeed watch himself. ;-) Me toooooooooooooooooooo...... ;-) [Everyone who reads here sees me with my foolish out plenty enough for me to feel permission to smile with someone when their little slip is showing.]

Well, Van Gogh's letters are a favorite. I hope this works, in the age of social media:

Love as armor against opinion

When we write or talk in public, we take risks. We will make silly mistakes sometimes. We need to be kind and tolerant -- of ourselves, and of others who care enough and have the courage to stand out for something important, like furthering the state of our field's art and our mastery thereof.

** Aside: Fecal innuendo is slurry; I wonder if it is worse still -- if it hits parts of our brain in the way that mention of lavender lights up smell areas of our brain. That is, the very mention is akin to monkey expression... The things I wonder about. ;-)

That is, if "there is evidence... the brain responds to depictions of smells and textures and movements as if they were the real thing" (NYT), then is that why scatological references and the f-word are powerful ... and worth avoiding, in discourse where we don't want to subliminally cue aggression...?? Do we sling the words that cue the brain up with equivalences with as much effect as other primates sling the real thing??? Etc. [And perhaps overuse, and use in non-charged situations, discharges the effect in some degree.... but we don't know for whom the effect is stronger... so better to avoid...??] [7/29/15:Oh, here is RAW on the uses of scatology among primates (smile) (via mfeathers).]

5/7/14: Hear yee:

Hmmmm ;-)

Can I, pleeeeease. Oh please oh please oh please?!?! :

oh please oh please oh please

Oh, I was only having fun with how words are factional with us, and Lisa's suggestion is so full of unjaded positive expecation, it is charming! Seriously. In the best way... [When Sara says I'm cute, it comes with a condescending shoulder pat. I find it quite touching, really. You know. How sincere optimism is synonymous with gullible in today's world... ;-)]

5/8/14: Ha ha ha... ha ha ha... ha ha ha... [or whatever sound a hearty ROFL makes] Whaaaaaat? Oh. Nothing. Well. There's this:

trying to learn something

We need to put my imp on time out? Oh, come now; see -- this:

Devil's Advocate that! ;-)

My inner curmudgeon got license to come out. ;-)

Just kidding! Sheesh. Playful. Okay. Just playful.

Crumpets folkses. I'm looking forward to learning too. And I don't think over-protective, highly charged and defensive confrontation is the same thing as "ritual dissent." I'm happy they convened a respectful discussion. [And I hope they really dig into the design aspect, too.] Sure, we don't want to over-correct and sweep TDD under that rug where modeling was relegated in our over-zealous over-reaction to too much, too much that produced killer BDUF. :-) As a field, we do have a tendency to go all camp-y, flipping all the bits with passionate zeal, overlooking how much our course and choices should really be moderated by reflection and negotiation of tradeoffs. Negotiated the way we negotiate and navigate a tricksy path, strewn with challenges, obstacles, uncertainties. Compromises. Allowing that personal style enters into it. Too.

Different contexts and needs, different people and personalities, lots plays into... different choices around TDD, and the flavor of TDD (mock intensive or not, etc.)... Judgment calls. Of course, I have no room to speak, since I've shown poor judgment all over this trace. But with the intention of "kneading the dough" so to speak. We have to stay flexible and tolerant, share our passion, our approaches and what we have learned, and just allow that different situations surface different pressures and considerations, and different people just see things differently. So. Share those perspectives. Be colorful. Be passionate (or not, whatevs). And allow that if we want to have the right to do so, then we need to allow others the same leeway. We don't have to follow their path, but it sure helps our field along if they (feel safe enough to) share the lessons they learn as they follow it. No?

6/6/14: I do need to catch up -- only watched the first of the DHH/Beck/Fowler debates so far. So so busy! This trace started before the debate series, and it'd be nice to see if/how they treated the other parts of design that are not explicitly being handled when taking a (small grained) unit and designing its boundaries and interfaces ("interaction surface") out of the context of designing interactions among elements and mechanisms to achieve desired outcomes (capabilities built through collaborations of elements and properties that emerge/address cross-cutting concerns).... We hold these design considerations in our heads, to be sure... where we can... But, you know, amazing as our minds are, they are flawed and fallible... And we need those cognitive assist boosters (of which TDD is a significant one, to be sure; still not the only one) to better enable judgment and...

8/24/15: We tend, as a field, to place high value on individual differences and style, yet we aren't very accommodating of those differences... Differences in context or situation, as well as individual and team style, create opportunities for various objectives to be pursued, different people to thrive, and for innovations to emerge. Large, complex systems that can only be design-built by large numbers of people to get them done in competitive timeframes, under the constraints of regulatory environments and safety concerns, etc., have different needs and pressures than a relatively small application created to serve some focused area of a business where the stakeholders are internal to the organization and local to (perhaps even in the same building as) the developers.


More on Design and Testing

The other day, when I told Dana about the TDD-fusseria, he said "But, of course! All design is testing." That wasn't so obvious to me, but I hold Dana in (very) high regard, so I thought about it. Elaborating on the design characterization in the above trace, *...design

  • establishes (understands and ascertains what is relevant in) context,
  • understands and articulates/constructs intention (desired outcomes, capabilities and properties),
  • surfaces grounding assumptions, makes assertions (what we hold to be true) and projections (seeks out trends and shaping forces), identifies challenges to be addressed
  • negotiates boundaries (negotiates/assigns shapingly significant roles/responsibilities, makes trade-offs across boundaries)
  • designs interaction surfaces and interactions across the boundaries to achieve the intention, and
  • addresses how the intention will be delivered -- and associated challenges tackled (forces resolved/balanced)...*

messyDesign iterations (*...*) are messy, incomplete, and, while there is some "recursion" implied by that last bullet, it is not not not strictly hierarchical or "top-down." Where our design attention moves and what design medium we use (ncluding, but not limited to, tests and code), is a judgment call (the extraordinary moment principle). Not only is there working at different scopes (sometimes "high level" and sometimes in the details, creating/evolving the "big picture" sometimes, coding units, building features/slices/services at others, etc. at others) as guided by judgment calls, but we also design across different facets, taking different (cross-cutting) concerns into account, and taking these different dimensions into consideration separately, sometimes, and together, sometimes. Accommodating for our (un)bounded (ir)rationality, for novelty and complexity, for multiple perspectives, and more.

And part of the design loop is testing -- ascertaining as appropriate to the design stage, if the design is on the right track [iterating between "right system" (fit to context and to purpose) and "built right," as there are trade-offs between what we are building and how it is built that ripple across not just what it is but how it works, and what it costs, and what the challenges are, and such]. That is, we're not simply elaborating the design. We're uncovering and resolving design trade-offs, assessing how we're doing against complexly interacting desired outcomes of various stakeholders, even as those outcomes come into clearer focus and potentially shift. We're learning -- about the context)s) into which the system will fit, what the system needs to be, and how best to accomplish that. So we may back-track, try different approaches. What makes it a design "loop" -- and one that may result in backtracking -- is the "testing," the probing for how we're doing so far, exposing our design to scrutiny and improvement. The style of testing will depend on what we have to test. If it's just a sketch prototype, the nature of our testing is rather different than if we have incremental builds of an evolving system. If our design process is to be responsive to finding things out, we're testing. Testing -- one could say challenging -- our ideas of what is needed. Testing our ideas of how best to create what's needed, solving the problems and addressing the inherent challenges and testing how well we did that.

We design to get more the outcomes we want, which has implicit in it the notion that it is not gobsmack easy connect-the-lego-blocks-into-a-simple-prefab-structure kind of thing. desiging is testingSo we design to figure out the outcomes as well as how to achieve them, and we improve the design to get more what we want.

It is built into the very notion of design that we test. We probe, we explore, we verify -- we test to improve, not simply to prove or establish that we did it "right" and are getting expected results. And we may leave a scaffolding of tests around the design frames (at different scopes), so we can verify that changes within a frame still work within the commitments of the frame. (Alternately, they form a "regression bedrock.")

"Sweetness," as coined by Michael Feathers, is "when a single mechanism satisfies many different needs in an elegant way." Unit testing in the TDD mode has that kind of sweetness. We design a unit that has intentionality and commitments and a boundary (what's in/responsibilities and interaction surface/I/F and protocol; and we may be thinking in terms of boundary conditions and containment of side-effects, etc.), and our design thinking there does double duty, establishing how we will test that unit. And thinking about testing that chunk of intentionality or design commitment, helps us improve the design, so that it is more than just a means to establish that the code is delivering to its commitments (once first built, and as it is evolved and refactored).

But sketch-prototyping does (more than) double duty (i.e., has sweetness) too. Models that lead to simulations, too. Because outcomes arise emergently from interactions and collaborations among various "units," and we don't have all the units a priori (even when we're evolving a system, we don't have the new endpoint, upfront).

We model to think, to create a shared thoughtspace where we can think together about the form and shape and flow of things, the how-it-works things both before we have code and when the very muchness of the code obfuscates and it is all too much to hold in our head, and we need to think about interactions among, cross-cutting concerns, how things work together, and such. And models help persist our thinking -- informally sketched and preserved as digital photos we slap into the project memories "scrapbook"... or more formally, as models we tech up, if circumstance warrants the extra degree of ceremony and/or formality and/or blueprint-y precision. And they help us test our ideas -- in an exploratory way when they are just sketches, but also as simulations. They help us decide what to instrument, to make visible. If you need some nudging along the lines of models help us see, or notice, help orient us to observing::

"Let two persons go out for a walk; the one a good sketcher, the other having no taste of the kind. Let them go down a green lane. There will be a great difference in the scene as perceived by the two individuals. The one will see a lane and trees; he will perceive the trees to be green, though he will think nothing about it; he will see that the sun shines, and that it has a cheerful effect; and that’s all! But what will the sketcher see? His eye is accustomed to search into the cause of beauty, and penetrate the minutest parts of loveliness. He looks up, and observes how the showery and subdivided sunshine comes sprinkled down among the gleaming leaves overhead, till the air is filled with the emerald light. He will see here and there a bough emerging from the veil of leaves, he will see the jewel brightness of the emerald moss and the variegated and fantastic lichens, white and blue, purple and red, all mellowed and mingled into a single garment of beauty. Then come the cavernous trunks and the twisted roots that grasp with their snake-like coils at the steep bank, whose turfy slope is inlaid with flowers of a thousand dyes. Is not this worth seeing? Yet if you are not a sketcher you will pass along the green lane, and when you come home again, have nothing to say or to think about it, but that you went down such and such a lane.’ -- John Ruskin, The Elements of Drawing (via The Philosopher's Mail)

Well, I don't agree that photography always and entirely destroys the art of noticing/seeing/observing.... But drawing is good training in the art of seeing. And sketch-modeling systems is good training in noticing the relationships between structure and function, noticing relationships that give rise to and boost or damp properties, and so forth.

At any rate, we design. We utilize abstractions at different design scopes and in different ways. We test to probe, to learn, to verify the efficacy of the abstractions under multiple simultaneous demands (for they deliver capabilities and qualities of our system). We evolve the design. We factor and refactor; we reify and elaborate. We test and evolve. We make trade-offs and judgment calls. We bring what we can to bear, to best enable our judgment, given the concerns we're dealing with. Sure. It's kind of messy. Kind of wicked. Kind of crucial! We test. That is we probe. We instrument. Variously. Software is a highly cognitive substance with which to build systems people and organizations depend upon. So. We design-test our way, with different mediums to support, enhance, stress and reveal flaws, etc., etc., in our thinking. We probe. We reason. We verify. Not using sketch-prototypes to do A/B field testing. Using judgment. Naturally! (Yessss! Judgment factors. And factors and refactors. But also tests. Informally. And more formally. As fits the extraordinary moment. ;-)

Uh. Now I have to test if that is what Dana meant... Hey I try. Some people call it failing, but I call it trying. I try. And I try. We have to try different things, from different angles, experiment our way to learning and figuring out what we want and an approach to getting it more the way we want it to be. And in this case, I want to learn. So I try. Try to understand. Try to get my understanding expressed, and tested for clarity and serviceability. And so forth. I try. Okay. I try.

Oh. And Tom Graves says I'm eminently quotable so I tried that too -- I quoted myself in a call-out. ;-) Smiles. Thanks Tom. And Gene. Hugs and skips of gratitude. You give all my hours of trying a rewarding moment of blissful recognition of peership on this shared flight on spaceship earth.

5/12/14: Thanks to Paul Harland for the conversation on this topic. It is nice to be taken seriously enough to have some discussion that furthers my ideas. Paul will no doubt see his influence in this trace, and I'm grateful -- thanks Pablo. :-)

5/20/14: Allowing that TDD pushes design, it is just one scope and frame of design.

code...  AND

While we're bringing babies back, let's bring back the notion that code is not the only design medium. Oh sure, code and tests have that beguiling "sweetness." But models have sweetness too. Not one or the other. Not BDUF. But let's allow that models help us push testing to broader scopes and earlier -- to test ideas. Sure. We have to loosen up our notion of testing, but we do so to allow ourselves the benefit of probes for direction, so we can test drive our strategy cheaply and quickly, before it is hard-cast in organization and code structures, with all their coupling -- intended and un, including to assumptions, explicit and im. Which is a nice segue to the next trace. ;-)

5/20/14: It occurs to me that those who thrust their preconceptions onto me, may think that my design loop (iterating between the *s in the 5/9/14 tracelet above) implies top-down. No no! Fractal and Emergent -- remember? And messy! At times. We seed with a notion of significant abstractions, and we factor and refactor, seek out abstractions and design mechanisms -- proactively, and with the benefit of hindsight. That is, we bring learning from past and peer projects. And we learn as we go. We try things out. Yadda.

Oh. You should read this:


Now you understand my traces. ;-)

Oh. And read, or reread, this: Fractal and Emergent. Yes, it is that good. How good? Worth giving your contact info to get, duh. Hey. Think short ebook, written by the awesome (trumpets please) moi and db. For just the price of your contact info. Heck, you'd have to give that if you paid with your credit card. But the fractal and emergent, strategy and architecture in tandem, etc., ideas are that important, and it's so, you know, wonderfully written. (cue more trumpets).

5/18/2014: and more maven for the magpie:


5/31/14: See also:

PS. I'm beginning to think "is dead" doesn't mean what we you think it does. It means it has entered middle-age and settled in to a responsible life.



Conway's Law Reverb

Since Conway's Law is in the air again, you might like to catch up on all the awesome I've written about it (smiles):

Tl;dr? Here are some highlighter quotes:

"if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins" -- 2/13/2008

They will co-evolve, because if they don't, Conway's Law warns us that the organization form will trump intended designs that go "cross-grain" to the organization warp. -- 12/17/13

It means that system architects (who we call architects) and business/organization architects (who we call managers) should not work as if one has no impact on the other. -- 2/13/2008

And as put by the inimitable Michael Feathers:

Conway's Law by @mfeathers - "you always ship your organization, so design your organization well" #craftconf -- 3/24/2014

That statement is awesomely profound/has far-reaching implications. Just think about all the "360 degree view of the customer" and "single authoritative data source" efforts we've had to go through. Again. And again. Because the organizational silos around the different lines of business are apparent to incredulous customers confounded by the lack of integration (of information and products) across services from the "same" company... Organizational divides and "silos", from teams to divisions or lines of business, show up in what we provision, from services or products to solutions or systems-of-systems, in the ecosystem.

Michael Feathers used the notion of echoes to talk about how organizational and process influences show up in the code.

Politics echoes:


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. -- 5/8/13

The point that I was making there, is that we only get a very partial view of the history. Echoes, like rings in tree that tell history

Process echoes:

Image right: from mfeathers talk Conway's Law and You (insightful; I like the way Michael structures his talks, including implications and guidance)

So, we can sniff out the echoes, do some archeology, but are they enough to understand the influences, direct and indirect, intended or un, that shaped the code?

[Opportunity for] Symbiosis:


Allan Kelly's Conways Law & Continuous Delivery slideset points to his contributions to the industry understanding of Conway's Law and it's implications, both direct and in dual and corollary form.

And here are some thoughts scooped up from traces over the years:

"Piecemeal growth, or incremental development, is not just desirable but a fact of life in software (even big-bang first releases are evolved thereafter). Even so, we need to build more learning into our process. More learning when it is cheaper to find and fix problems with the vision (doing course corrections toward "right system") and structure (built right). Then, accepting that we will continue to learn and evolve our system, we need to invest in fixing the mistakes—incrementally adding functionality yes, but repairing structural defects too. This investment is the crucial dual to piecemeal growth that we too often forget in software. When we keep marching to a frenetic "add value" drumbeat, we get into a situation where the system threatens to crumble under the mass of deferred structural issues (like the Minneapolis I-35W Mississippi River Bridge that collapsed last year)." --- moi, Refactoring and Lean, 3/16/08


'The system has to bear the "weight", so to speak, of features that delight users (and functions they rely on but barely notice unless we mess up). Hence, the system must have structural integrity which raises different arenas of attention and competency than coding the features. That is, it requires attention to emergent properties associated with resilience and scalability and evolvability and such. Properties are emergent; they arise dynamically from the structure (elements and relationships) and mechanisms (interacting elements, designed to accomplish some function addressing, often, a cross-cutting concern) of the system. But architecting is not just about structural integrity -- or we could just call the role structural engineering and be done. Architecting is about the design of the system to achieve (more) its desired outcomes across the contexts of relevance -- various contexts of use, as well as operation and evolution. And architecting is about bringing insight to the strategy table when those desired outcomes are shaped.' -- 5/16/12


"If we recognize that we have threaded two processes together and then turned a blind eye to their different needs, we have the chance to do something about it! Two processes?

  • Invention and discovery, not just of user needs but of approaches or mechanisms for addressing those needs -- discovery of how to make it work.

  • And engineering of a system with integrity.

Going from the messiness of our discovery-oriented process to the well-factored, tested integrity of our engineered system shouldn't be considered rework or waste! Unless we leave it until after it has sorely impacted users and our business viability. That is waste.

As we proceed in the fog of uncertainty, entropy grows -- and produces more fog! Under uncertainty we "give things a try"; accept good enough, and try the next thing. As entropy grows, it introduces its own uncertainty..."    -- 10/5/11

That is, there is a relationship between the architecture of the organization (and its communication flows) and the architecture of the system (and its boundaries and flows). We need to take this into account, to reap synergies rather than doing the harder thing, trying to "swim against the current." Oh yeah, and this:

Guidelines for the Architecture:

ABATIS, n. Rubbish in front of a fort, to prevent the rubbish outside from molesting the rubbish inside. [a more realistic name for "bridge," GoF?]

RESPONSIBILITY, n. A detachable burden easily shifted to the shoulders of God, Fate, Fortune, Luck or one's neighbor. In the days of astrology it was customary to unload it upon a star. [this relates to refactoring, which, given the preponderance of intent over action, may be defined as shifting the responsibility to factor onto Fate, Fortune, Luck or one's neighbor.]

-- The Devil's Dictionary [(playfully) related to architecture], 10/10/09

Abatis? See points mfeathers makes about interfaces around minute 15 between teams.

Refactoring is the corollary to piecemeal growth, allowing entropy containment. But we have to refactor the organization too? If it would subvert the system (re)design and evolution.

Death Star architecture yet..


5/7/14: Michael Feathers used the tree rings metaphor in his "process echoes" and "symbiosis" talks. So my "what I'm paying attention to shapes what I perceive and pay attention to" mind noted:

I should return to that Software Visualization work -- I think there is a lovely book in it. But first, sigh, that neverending Architecture story. ;-)

5/9/14: Two great additions to the Conway's Law insight crucible:

5/24/14: Very nice application of Conway's Law-derived insights to microservices and "granularity" decisions, given organizational considerations by Gene Hughson (my italics):

"Composing a system of independent, autonomous components, as opposed to a monolith, allows them to be partitioned by business capability as well as be developed and maintained by a permanent team. This transforms Conway’s Law from an observation about the nature of software systems into a principle that can be used to improve the structure of those systems (“The organizational divides are going to drive the true seams in the system.”). The social system architecture will influence the software system architecture in any event, the question is whether that influence will be intentional or not."

-- Gene Hughson, Carving it up – Microservices, Monoliths, & Conway’s Law, 5/24/2014

Great add to the symbiosis conversation, and tie-in to microservices.

Hey, so I snipped another nice add to the conversation:



Conway's Law

6/1/14: The question of self-organizing teams is interesting, in this context.... Tangentially related (well, it just touches at the point of self-organizing, so this seems like a good placeholder for it):

6/22/14: Related:


7/3/14: Playing well together:

As I pointed out early in the above trace, integrating across organizational divides is a challenge and... when left to happy accident, may well have all the smack of accident rather than design -- as in, designed to get more what we want, looking for consequences so we get less unintended side-effecting from being system-blind.

8/1/14: Collection of observations on Conway's Law (via Rachel Davies):


10/7/14: A few more links (because... you're that curious/investigative):

"Organizations for a few years now have understood this link between organizational structure and software they create, and have been embracing new structures in order to achieve the outcome they want. Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system. These independent teams can own the whole lifecycle of the services they create, affording them a greater degree of autonomy than is possible for larger teams with more monolithic codebases. These services with their independent concerns can change and evolve separately from one another, resulting in the ability to deliver changes to production faster. If these organizations had adopted larger team sizes, the larger monolithic systems that would have emerged would not have given them the same ability to experiment, adapt, and ultimately keep their customers happy."

-- Sam Newman, Demystifying Conway's Law

And the awesome:

"The responsibility of architecture is the architecture of responsibility" -- Jan van Til

which I quoted in my Architecture of Responsibility trace, which should have you hightailing it over to my Conceptual Architecture write-up.


Marick on Conway

I responded with a pointer to this trace because "you always ship your organization" (feathers) and the subsequent paragraph is one elaboration. And added that I have my own hypotheses about how Twitter is organizaed, given, for example, how DM content is staged and delivered up so differently across browsers/devices. (But I didn't get a response and then I felt like it was rude to barge in on a side convo even if it showed up in my stream because I follow both. So I deleted my tweet so as not to intrude longer on a stranger's interaction line. Twitter is hard. I'm not socially adept, so I don't know what's impolite...)

11/25/15: And this is great:

Also, from the man himself:

And if you want to see what Mel Conway has been up to more recently (hint: Worry Dream/Bret Victor and visual thinking comes to mind):



Yesterday I learned:

Origin of NEGOTIATE: Latin negotiatus, past participle of negotiari to carry on business, from negotium business, from neg- not + otium leisure — more at negate First Known Use: 1599



Decisions, Decisions

Snagged this in the stream, but can't remember who tweeted it... oops...

a decision framework




Share Your Knowledge? Or Share Knowledge?

Mention other people's work, for crying out loud. You want to be mentioned? Golden Rule, people. Golden Rule. The pack-stack ranking habit of being selfish and mentioning others at a 1:10 kind of ratio (at best!) is really... dominance hierarchical and elitist rather than collaborative and egalitarian. Move on already.

Ideas want to hang out with diverse ideas. Spread them! Like. Hello. Don't just avoid slut-shaming promiscuous ideas; actively encourage them! And encourage others to. Innovation is all about novel couplings of ideas. Sure, we don't want to hold ideas responsible for the company they keep (a tweak on mfeathers), but it helps to mix up the idea forment if we also point to sources of ideas and their own peculiar breeding grounds. Besides. That's just playing well with others. You like to play, don't you? With others?

Whaaaaat? I'm being selfish asking others to be unselfish?

that's just selfish, pointing that out!




  • "Someday, we will see ideas as the drugs they are. They change us and our perception. They have half-lives and side effects." -- mfeathers, 3/27/2013
  • "Life is way better than our ideas about it." -- mfeathers, 3/6/2014
  • "Well, there's that, but I make it a point not to hold ideas responsible for the people who express them." -- mfeathers, 7/28/2013

And, via Maria Popova:

"An idea comes — and you see it, and you hear it, and you know it…

We don’t do anything without an idea. So they’re beautiful gifts. And I always say, you desiring an idea is like a bait on a hook — you can pull them in. And if you catch an idea that you love, that’s a beautiful, beautiful day. And you write that idea down so you won’t forget it. And that idea that you caught might just be a fragment of the whole — whatever it is you’re working on — but now you have even more bait. Thinking about that small fragment — that little fish — will bring in more, and they’ll come in and they’ll hook on. And more and more come in, and pretty soon you might have a script — or a chair, or a painting, or an idea for a painting.

[They come], more often than not, in small fragments."

-- David Lynch




Watch That Silence...

When I read traces from past months and years, I'm glad I did this. But is there reason to trace "out loud"? Oh, a few people have been kind enough to break the silence and direct a few observations to me. I have to conclude those are people of great exceptionality, for they stand out from the broad swathe of unresponsive disinterest. But the scant mention of this Trace to others suggests that people generally don't want to get any of this on them.


Anyway, huge thanks to the few who say anything positive at all, and an especially big thank you to those whose positive mention to others, marshals confidence reinforcements. :-) Since so few do so, I have to conclude it takes truly exceptional generosity and courage. So kudos to you in due proportion!!


If a Trace falls upon the internet, and no-one says anything about it...

Very few people know about my work. Because very, very few people mention it. Fewer still with actual enthusiasm. I don't think it deserves the cold shoulder of indifference.

No. I don't want you to rush off and say something about my Trace now. That would be decidedly awkward and smack of contrivance. It would be nice, when you read something you find exciting or compelling, if sometimes you said so. To me. But also sometimes to others.

In terms of my digitally networked experience... And being marginalized by being ignored... There are very few exceptions. Namedly few. These, in particular, Gene Hughson, Peter Bakker, Stuart Boardman, Grady Booch and Paul Harland.

I should also mention Amitai Schlair, who you should definitely follow. He has special powers too -- he can see women in tech!!! ;-)

Okay. I'm putting myself on time-out. :-) I'll let myself back in when I'm more upbeat about my place in this world. Smiles.



Actually. Reading the YesAllWomin hashtag stream reminds me... I like this being a quiet backwaters place. Don't tell anybody! It's a scary world out there.

Yes, all of us appreciate how wonderful men are, how much men do in the world, how much men contribute to the quality of our lives.

And yes. The shadow side is dark, and it falls a lot on women. It is good to be more educated about how very bad it is, for so many. And yes, bad stuff has happened to me too. Women take this seriously, not because such invasion of our very person is pervasive in the everyday sense of most of our experience, thankfully! But because it does happen -- has happened to way more of us than we talk about, so more than you'd think. The real threat is in our peripheral vision, because we are made aware that the threats do take real expression, more often in small intimidations, but sometimes in real aggression with dire consequences.

Being human is tough. The bio-chem stuff that can get in a roiling boil. The interpersonal stuff is fraught with tricksy emotions, misunderstandings, miscommunications and projections. We make mistakes. We get defensive and offensive. We have failures of courage, failures of seeing, perception, empathy. Yadda. We can do better. We need to try. To understand more. To be more generous. More kind. More compassionate.

That I write here at all is an act of courage. Courage -- not only because I am a woman in a world that can make a target of women who stand out. But because it is hard for anyone to be real, vulnerably so. We are schooled by art and business to make objects of persons, of personal and interpersonal experience. to make it all abstract and out there, distant from the actual individual experience of this crisis of a short life, with all its (in)human (com)pounding... That is a fine approach. The subjective is messy. But is also reality as we experience it, so a relevant and vital format to hold within our compass. We have to be able to work with empathy -- for actual people. And we need to be able to generalize, to abstract, to find the essence, the essential. We need to serve many individuals with systems they relate personally to, in their own way. That is a fine balance to strike, and takes imagination, conceptualization, and realization. And more. The answer, I believe, is not to curtail and crate up the full humanity of people, allowing only flat projections of part of themselves into the workplace, and into the discourse of our field. The Taylorian Era served to accelerate industrialization, but now we find that is a path into a cliff of environmental destruction and wastelands of dehumanized work. So. We can afford a Trace, no? It's a big world. It needs its gentle yet earnestly discerning, questioning, questing places. ;-)



Ship It!




Smacked -- with a Poetry Label?

Well, it could be worse. But really?

Twice... in one week...

I love this so much:

I just love this so much!


So. I get criticized for being oblique. It's an adaptation. But not a bad one, okay?


Social Capital

Based on a highly scientific (cough cough) cursory look at several tech people at the top of the Twitter stack ranking, it dawned on me that they tend to have very monotone profiles. Sure, they have lots of followers. But look at their tweet stream. They, by and large, dominate their own stream -- that is, they are not using their social capital for anyone else. They are the 1% and they collect and hoard social capital and leverage the generosity of others. Others give them exposure; they don't pay the attention on. And they don't give back in other ways. They have a pathetic small number of RTs and favs, meaning they neither pay attention to others, nor do they give positive social feedback to others. They don't signal boost, but they rise in the stack rank based on the signal boosting of others. They think they deserve it, but forget that others deserve it too and don't seek to find out who, and support them.

And what about the tweet streams with few/no women showing up across the screenloads.... no signal boosting women -- is it that they don't pay attention to women, or don't think women worth spending social capital on? The illuminati who set examples in our field might like to be more inclusive, and also be careful to ensure that the proportion of women in their follow set is at least as high as the proportion of women in the field. 10% is about half the representation of women in our field, so... Just a suggestion... If you'd really like to see the ratio change, change your own ratio, and start ripples of influence that will not just help level the playing field but raise the tide for all...

While we're at it. Let me give you a little lesson in social mechanisms that you might find handy. Twitter has a very small number of methods, so there are many creative overrides. Favorite has especially many. You can use favorite for body language (interpreted in "situational context"). It can be "me like" or "I saw what you did there" or "smile" or "smile; thanks" or "this looks interesting but I'm in a crunch right now, so I'll look at it later" or "I'm going to put this in my gallery and stroll by from time to time" or... etc.

What? You don't like it when I'm direct?

Oops. ;-)

PS. It is hard to communicate "laughed so hard I fell off my chair" with just a fav but in a pinch sometimes it has to suffice.

PPS: RT is a stronger response than fav; you might want to consider if you hold women to a higher bar when it comes to your RT versus fav impulse/decision. If your self-image is that you're not biased against women, check your behaviors. If your habits tend to occlude women, then actively set out to reshape your habits. If you're not finding women to read and quote and otherwise support to a proportional extent to their contribution in your field, you may need to _look_ for those women. The system is stacked. And we all participate in stacking the deck against women when we don't give women proportional representation in our social behaviors on and off line.




Too many people give appreciation and praise a bad rep. Flattery -- positives with no behavior backup to signify that the words are meant -- can be bad stuff; used to manipulate subversively. But appreciation that is consistent and underscored by other actions is an important kind mirror to hold up to another.

If someone tells me "you make words dance" but he never seeks out my writing, that has less impact on me that someone who says "glad you put that TDD trace back up" -- signifying noticing it, noticing it was removed, noticing it went back up.

But the hell with it, I still like to be told I make words dance.


Feedback sandwich? Ah yes. I call that "pat and slap." Feedback is hard! But also important. My reaction to feedback is where it gets really interesting -- it shows me what I have been shooing away from my central concern, in all my "it is what it is" denial set.


But. It is what it is. This format looses my fingers. How I think about design and what is missing in the preponderance of approaches to both architecture and Agile, becomes situated in a discussion of TDD. It is topical. It might seem reactive, but it is simply a way to position my thinking in the context of our field's attention tides.

Attention tides? Isn't that a lovely gem? If I don't write in this playful format, I don't get those.

And isn't that paragraph important, positioning not just one trace theme this month, but my Trace?


I say positive things about my Trace because I believe that expectations going into something are important. Sure, some people may get the impression that I'm not humble, or in the stratosphere unrealistic, if I do that. But I think how we orient to things helps shape what we're able to get out of it. And no-one (lately) puts my Trace in a positive frame for others, so I figure I have to do that dirty work or no-one will. (Don't get me wrong -- any not-negative mention of my Trace, even the most neutrally framed, is way generous and much appreciated!) A Trace is "different" so may need a little positioneering so people understand it is not any one trace that makes this great (yes!???), but rather in the contribution to shaping the field's identity -- its self-concept -- and practice, that is the body of the work. So it takes more than reading this or that trace, as much as each has its own dew of insight, to start to grok how the thinking saturates the fabric of this field with color and texture and understanding and critical enablement.

Like. Come on. Isn't that characterization of design just really spiffy? Best. Ever. Just. Brilliant.

Well, if I got it wrong, tell me. Do. I'd love to make it EVEN MORE SPIFFY. Dammit.


Why can't people get excited about a woman's work? What the jabberwock is that about? Scared people will think it's flirting? Even if they do, what of it? Great flying jabberwocks, the flirting that goes on among guys is just lubly. We need more of that in the world. Play gestures. Not overtures to the "bedroom thing"; not harassment. But play. It's 2014. I think we past evolution o'clock, don't you?

I hope so anyway. Otherwise our digital tools have way, way outstripped our point on the evolutionary path.

Evolution o'clock? Blows finger tips. Dance. Words. Dance.



Okay. Those who know me, know that means my workload is crushing me, and play is oozing out the cracks. TTFN.


[Oops. Did evolution o'clock sound too... poetic? My bad. Sorry. [Not sorry.] ;-) I mean, I have only the foggiest notion what I meant by that, but... I'm yanking your chain. I do that. Flush that 'tude and don't worry, be happy. ;-) You think I'm wasting your time with these words? Flagrantly? My bad. Sorry. [Not sorry.] ;-) Put your McFerrin on and be happy.]

[good thing no-one reads here. whew. ;-) Might have caught me with my Marley showing.]

Evolution o'clock whizzed right on by, amiright? No-one's rubbing their knuckles going "er(r), I think she just told us to act our evolutionary age"? <<ducks and ... is about to hide but remembers she's invisible>>

6/1/14: The stand-up comedy festival this weekend was a lot of fun. Laughing at our own prejudices is such a good... how does one describe it... mind/spirit laxative?

Well the only thing that has happened to make me feel like turning the page on this Trace and starting up June... is that it will wrap up and put May behind me. ;-)


6/7/14: I hope that my frank discussion of my experience as a woman in this field is helpful. I realize that some may be feeling feminism overload, since awareness raising has been growing and growing, and some of it is quite... disturbing, for various reasons, including pressured reactions that single out individuals for, in a manner of speaking, simply wearing the cultural wash. Anyway, I assume goodwill and a stance of wanting to understand more about our field, including what it is like to be, and how to improve the experience of, women in this field. There are consequences to quelling the spirit of women and subtly and not so subtly harrying women so women don't enter, or leave, the field.

So many people, not just women, may tend to feel underappreciated in this era of attention overload. But just as there are social forces that make some men feel it is permissible to harass women, there are also social forces that mean that women have to overcome an expectation deficit relative to men. This even shows up in reactions to the names of hurricanes, so it is something that runs wide and deep, even when we think we are completely fair in how we view women.

The sense I make of it is that we're at the head of a new wave of awareness, and lynch-mobbing individuals for being unaware is only going to create fear and shut down voices. We are trying to quell our tendency to blame and punish by "making an example of" when dealing with system incidents. Couldn't we treat these sexism incidents as learning moments not teaching moments? Which is to say, is there a way to raise awareness of how the incidents are harming women, without going pack-attack when one person happens to do something many have done before, and are still doing -- like yikes!

We need to learn, and that means we need to be able to share perspectives, so we can change our minds -- change the very content thereof, by pouring new ideas, perspectives and experiences into them. For example, calling women out for being assertive and using angry language is one of the ways we erode women's freedom to use the full range of human tone and voice to make a case, limiting women in ways we don't limit men (as much)... Personally, aggressive tone wouldn't be my choice, nor the choice of many men, but I want people of both genders to be able to express themselves.




I also write at:

- Bredemeyer Resources for  Architects

- Trace In the Sand Blog




Journal Archives

- Journal Map

- storylines tubemap by Peter Bakker



- January
- February
- March
- April

- May
- June
- Current


- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December


- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December



- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December


More Archives


May Traces





Chief Scientists

- Grady Booch

- Martin Fowler

Enterprise Architects

- John Ayre

-Peter Bakker

- Stuart Boardman

- Todd Biske

- Adrian Campbell

- Louis Dietvorst

- Leo de Sousa

- Johan Den Haan

- Chris Eaton

- Roger Evernden

- Ondrej Galik

- John Gotze

- Tom Graves

- Melvin Greer

- Adrian Grigoriu

- Carl Haggerty

- Dion Hinchcliffe

- Paul Homan

- Brian Hopkins

- James Hooper

- Martin Howitt

- Kristian Hjort-Madsen

- Alan Inglis

- Jeff Kennedy

- Janne J. Korhonen

- Nick Malik

- Alex Matthews

- Brenda Michelson


- Sethuraj Nair

- Doug Newdick

- Steve Nimmons

- Jim Parnitzke

- Ric Phillips

- Chris Potts

- Randall Satchell

- Praba Siva

- Serge Thorn

- Bas van Gils

- Jaco Vermeulen

- Richard Veryard

- Mike Walker

- Tim Westbrock

Architects and Architecture

- Charlie Alfred

- "Doc" Andersen

- Tad Anderson

- Jason Baragry

- Simon Brown

- Peter Cripps

- Rob Daigneau

- Udi Dahan

- Tony DaSilva

- Matt Deacon

- Peter Eeles

- George Fairbanks

- Kevin Francis

- Sam Gentile

- Simon Guest

- Philip Hartman

- Todd Hoff (highly recommended)

- Gregor Hohpe

- Gene Hughson

- Steve Jones

- Frank Kelly

- Kirk Knoernschild

- Philippe Kruchten

- Sjaak Laan

- Dave Linthicum

- Anna Liu

- Nick Malik

- Chirag Mehta

- JD Meier

- Kris Meukens

- Gabriel Morgan

- Robert Morschel

- Dan Pritchett

- Chris Potts

- Bob Rhubart

- Arnon Rotem-Gal-Oz

- Carlos Serrano-Morales

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Michael Stahl

- Daniel Stroe

- Gavin Terrill

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Richard West

- Rebecca Wirfs-Brock

- Rodney Willis

- Eion Woods

- Brian Zimmer

Architect Professional Organizations





Agile and Lean

- Alistair Cockburn

- NOOP.nl

- hackerchickblog

- Johanna Rothman


Agile and Testing

- Elisabeth Hendrickson

- Elizabeth Keogh

Software Reuse

- Vijay Narayanan

Other Software Thought Leaders

- Jeff Atwood

- Scott Berkun

- CapGeminini's CTOblog

- John Daniels

- Brian Foote

- Joel Spolosky

CTOs and CIOs

- Rebecca Parsons

- Werner Vogels

CEOs (Tech)


CEOs (Web 2.0)

- Don MacAskill (SmugMug)

Innovate/Tech Watch

- Barry Briggs

- Tim Brown (IDEO)

- BoingBoing

- Mary-Jo Foley's All About Microsoft

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez

- slashdot

- smoothspan

- The Tech Chronicles

- Wired's monkey_bites



- Marci Segal


Visual Thinking

- Amanda Lyons


Social Networking/Web 2.0+ Watch

- bokardo.com

- Mashable


Visual Thinking

- Dave Gray

- Dan Roam

- David Sibbet (The Grove)

- Scott McLoud


Leadership Skills

- Presentation Zen


Strategy, BI and Competitive Intelligence

- Freakonomics blog

- Tom Hawes

- Malcom Ryder


Um... and these
- Nick Carr

- Tom Peters


Green Thinking

- Sylvia Earle, TED

- CNN Money Business of Green videos

- Matter Network


- xkcd

- Buttercup Festival

- Dinosaur comics

- geek&poke

- phd comics

- a softer world

- Dilbert


I also write at:


- Strategy, Architecture and Agility: The Art of Change: Fractal and Emergent, 2010 

- Innovation and Agile Architecting: Getting Past ‘But’: Finding Opportunity and Making It Happen, 2008

- EA and Business Strategy: Enterprise Architecture as Strategic Differentiator, 2005

- The Role of the Architect:: What it Takes to be a Great Enterprise Architect, 2004


Ruth Malan has played a pioneering role in the software architecture field, helping to define architectures and the process by which they are created and evolved, and helping to shape the role of the software, systems and enterprise architect. She and Dana Bredemeyer created the Visual Architecting Process which emphasizes: architecting for agility, integrity and sustainability. Creating architectures that are good, right and successful, where good: technically sound; right: meets stakeholders goals and fits context and purpose; and successful: actually delivers strategic outcomes. Translating business strategy into technical strategy and leading the implementation of that strategy. Applying guiding principles like: the extraordinary moment principle; the minimalist architecture principle; and the connect the dots principle. Being agile. Creating options.

Feedback: I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I can be reached at

Restrictions on Use: If you wish to quote or paraphrase original work on this page, please properly acknowledge the source, with appropriate reference to this web page. Thank you.


- Links to tools and other resources



- Other Interests






Copyright © 2013 by Ruth Malan
Page Created:July 1, 2013
Last Modified: November 25, 2015