A Trace in the Sand
by Ruth Malan
I'm reconsidering how best to use this space, acknowledging the privilege of your interest. An unfiltered view of my journal is too much and I shy from judgmental reaction to that, but creating a filtered view puts me in the critic's shoes and I can't find any entry that (unequivocally) passes my own judgment! I'm currently experimenting with a daily 2c, with a summary of a penny that dropped the day before. This is called applying the Tom Sawyer Principle. :-) Just kidding! I'm simply reducing your exposure to my propensity to apply a word fire-hose to even the simplest question or notion.
A system is a complex of interacting elements giving rise not just to behaviors that deliver the functionality of the system, but the properties of the system. If a system delights, we attribute design greatness. If it continues to do so, through stresses and strains, we attribute structural integrity -- another dimension of design greatness, but viewing the system over various timeframes so that resilience, robustness, scale, evolution and so forth play out. When we step back and view the system as meeting a complex of concerns -- interacting, conflicting, evolving, spoken and unspoken, etc., concerns -- we see that the architect has to be interpolating, integrating, synthesizing, guessing, estimating, balancing, compromising, elevating, and plenty of other *ing (that for the sake of my and your time and interest I'll leave implied by the * iterator).
And yet we can't deal with the whole hairball! It is just too much to hold in mind to manipulate/reason about or to explain/advocate/defend. So we needs-must work with separations of concerns and with threads of reasoning. Different models deal with different concerns, and we accept this simplification, knowing that we need also to work across the various views of the architecture (expressing in models and accompanying explanations and articulation of our reasoning and rationale) and synthesize and resolve the impact of decisions across views, reworking where needed.
Dana Bredemeyer points out that in system design (including during development when many design decisions are made), we make an extraordinary number of decisions -- choices. Even if we don't explicitly see and reason about them, there are endless alternative ways we could have done things. So, sometimes we'll make a "wrong" decision -- where "wrong" can be very detrimental to the system, and sometimes seeming innocuous but over time more significant. Etc. Right? We are human, not all-knowing, all-seeing, so we simply are going to make some choices that turn out to be bad/detrimental/erode system structure/impact performance/inhibit functionality/increase cost/etc. So our process isn't going to save us from every mistook. But it can help us to think through, to find and fix more impactful ones earlier. More than if we just proceed in an ad hoc, unchecked fashion. That has implications for views, and for the threads of reasoning and iteration across the views!
If the architect is to be held accountable for the architecture, or the design of the system, the architect needs to own (sign up for) creation of that design. Not that she does the work alone, for that is fraught with all kinds of traps. But she realizes that design is leading thought about what the system is and how it will be built. Really leading. Seeing what needs to be done, and shaping expectations and aligning minds so that it gets done! Some of that is making the stakeholders feel good that their concerns were factored, though they can't all be addressed simply as initially stated!
So we need to concern ourselves with views that serve the architect in the design thinking that must be done, in getting input, in improving, in validating. And with creating compelling ways to excite and empower stakeholders to play the role they need to play.
Does that make sense? In order to convince a stakeholder to embrace our approach to security, we may have to talk to them about not just other stakeholders' concerns about security, but about performance and functionality and consistency of business or development practice, etc., too. Concerns are inter-related, and the design has to be thought of as a conjoint act that doesn't always balance but does weigh and sometimes diverges from what a stakeholder (group) wants or even needs for the achievement of system goals and imperatives. So now if we take a concern like security, to fully think through just that concern, we're working across a variety of decision spaces from deployment infrastructure to system functionality to responsibilities of components to interfaces to algorithms to ... The various security-related concerns of various stakeholders are being addressed across a complex space of decision vehicles and structures. We can highlight the security approach we're advancing on the deployment view. We can pull out and highlight steps in use cases or user stories, we can ripple these through interaction diagrams, draw out the security facets of the conceptual model. Etc.
In short, what the views are all about, is bringing the thing the architect sees in her mind's eye into a form that she can interact with, and invite others to interact with, shaping and reshaping it until she is excited that it is what must be done and she knows how to do it well enough to get the expertise and passion (or just goodwill and time) of developers aligned and applied. And it is about getting other people to think it was their idea all along. No, not necessarily. But to enable them to shift their position so they see too that it is the good right thing to do, and turn their minds (and budget and whatever else) to making it successful. Shift their positions? Well, for example, they may have been asking for something different, but in the process of exploring what would really differentiate (in key ways delight), something somewhat different may have surfaced as the compelling thing to do. It doesn't do for the architect to wear initial requests and expectations as a straightjacket and ignore the pull of good sense and compelling value without at least testing the water to see if the stakeholders are stuck or willing to explore "compelling"! Very often what the stakeholders are asking for is just a best guess -- a shot in a shadowy dusk -- that they full know is just that, but they feel on-the-spot to indicate a direction. And they do, hoping that exploring what will be great, will resolve what to do, what direction to take, how to shape the system. And even if that were not so, if you know what great is, and it is different from what is being asked for, you have a dilemma which you may as well face! If you kowtow to power without attempting to lead, without at least trying to facilitate a shift in mental map, in ideas and beliefs, then you give up an opportunity to be great. Greatness doesn't come easy, without opposition, doing just what you are told. It comes from doing simple things, from finding natural paths, and so forth. Yes. But doing the things you know are needed because they aren't yet being done, doing things right and well when this is hard to do in the crush of daily demands.
Don't you just love today's xkcd? Simon Munroe's ability to see the human in technical terms and vice versa is just staggering! There is a lot of give and take, of communicating and transforming, in relationships -- organizational and "personal" ...
Cynicism may creep up on us, but we have to route it out of ourselves! Leaders can't be cynics and pessimists! Seeing and dealing with risk strategically, yes. But not seeing things as undoable, too hard, too constrained and brittle... We have to know that we can invite people to contribute to a better future and they'll pitch in.
11/3/10 I'm in Love!
My latest book d'amour is Everyday Engineering. Funny that I should call it that -- wrongly, I'm sure, but doing so caused me to look at other uses which led me to Theatre D'Amour. The latter is also a visual set of emblematic images (though in the theatre of love, not engineering)! Serendipity!
Anyway, I am enamored with the little graphic engineering book and excited by what it makes me see and think about! Take the cover: there is a cut-away to reveal the internal structure and binding! How cool is that?
Everything we've ever seen in software systems is (metaphorically) visualized in this book (though that wasn't the intent). Ok maybe not everything, but a lot. The organization of the book speaks volumes too. Just so you don't expect what it is not -- it is mostly simply photos, organized into sections like Unseen, Interfaces, Function follows form, Sequences, Challenges. Many of the images could characterized as visualizations of anti-patterns, but not all.
Image source: a page from the section on interfaces in Everyday Engineering.
11/4/10 All Downhill From Here!
Well, Amazon has already declared "Best books of 2010"...
Anyway, Dana will be thrilled to know that Oliver Sacks The Mind's Eye is one of the top 10 in science...
11/4/10 101 Things
Everyday Engineering reminded me that at a workshop earlier this year a really talented, technically acute architect full of the "'satiable curtiosity" I so admire (especially since his questions came from such a well-read, deep thinking, playfully problem solving place), recommended a book which I wrote down on the flipchart for others to copy down, but I forgot to take a photo of the flip! And I wonder if it is 101 Things I Learned in Architecture School by Matthew Frederick? I'll have to check with him, but in the meantime 101 Things looks like another treasure of a book. Here are a few snips from 101 Things:
Well, that, and the visual that accompanies each of these gems, are enough to persuade me to buy the book! The very next time I'm spending money on books, that is. :-)
11/4/10 The Sounds of Silence
I've seen in my mind's eye how I would illustrate the "hairballs" post (11/3 above), but... why bother?
In architecture, we strive for simplicity in various forms. For instance, capturing in simple essential form something very sophisticated. I try to do that with archman. Take my first Archman sketch (right): a simple little conceptual architecture of a figure bearing the behavior of the system. The figure that so many poke fun at (meaning the box and line drawing that is the conceptual architecture diagram) -- that sketchy simple figure that conveys through abstraction, metaphor, visual and textual cues to unfolding narrative, the whole system. Archman is simple. Sometimes whimsical. And generally conveys some quite sophisticated insight, hard-wrung from experience and close observation and attention. You know, like the point about structure that conveys behavior. Obvious, yes, but how many definitions of architecture neglect this?
So, again, why bother? Because it's fun! In the cold silence, that has to be enough. Then again, why not? Because there's a lot to be done! What would tip the scales of desire (we do, you well know, mostly what we desire with what time is left after we do what we must)? Oh, yeah, right. Again, why?
“The unexamined life is not worth living.” -- Socrates
But you do get the point behind the point don't you? That simple figure can speak volumes if the viewer anticipates that it will. How it (the archman sketch) is seen, depends on the viewer (that's you), on how you view the (ahem) artist/architect (me), and the thing itself. So, if you come across Archman "cold," it is just a crude sketch, and you need me to explain how it is more than just boxes and lines, to tell you in so many words the import of the figure. Likewise with conceptual architecture. Some stakeholders will willingly read into the names and the relationships, will willing hold the thing in some creative suspension without dinging your credibility as you unfold the meaning of the boxes. And some will just go "it is simple and stupid" -- like a number of reviewers of the Everyday Engineering book who would not credit the book for its visual metaphor and the lessons it holds so compactly because it invites us to engage with the author(s) in making the meaning. Any kind of metaphor, analogy, condensation of meaning into some simple representative abstraction, is going to require goodwilling on the part of the viewer -- giving credit to the person who distilled complexity into such simplicity, and actively entering into a dialog with the meaning of the thing.
If you didn't get that, the short of it is: we need to write words that explain the visual abstractions, the elements and relationships, the meaning or purpose... It is a form of representational re-description that Howard Gardner talks about in Changing Minds. And more.
So we have archman as a conceptual architecture figure conveying the behavior of the system. Conveying -- illustrating, describing, moving from my mind to yours. Conveying -- conducting, being the conduit for, enabling. Conveying -- serving. Serving the development team with models that illustrate. Serving users with behaviors or functions. Serving the business.
If you have goodwill towards me, we can assume that in your view I have (intellectual) authority or command of my zone of expertise, and you will assume there is something interesting there. And you will look for it. The whole tenet of the Everyday Engineering book is that it will speak to an audience who credits it with something worth looking for. And when one looks with positive expectation, at least in the case of Everyday Engineering, one finds vividly portrayed insight into so many dimensions of engineering.
So, if you're going "oh wow, I never saw so much in the little sketch" remember that with respect to your conceptual architecture diagram! Named boxes and lines. How simple and stupid. Not at all! But you have to work on the attitude of your audience with respect to you and your work, and on the words that elaborate the boxes and lines just enough to convey the intent, in some cases, or considerably more to specify, in others. Words. Spoken words because they are interactive and participative and so vivid and engaging and can be dynamically redirected to explore or address a concern or point of interest. And written words because they endure, and are thought-out and can be rich and exciting too especially when they invite an asynchronous dialog or inquisitive questing/questioning/responding in the mind of the reader.
Interesting that it can take quite so many words to talk about one little sketch. A little optimistic, playful figure, perky and willing. How many words, then, would it take to probe The Bullfrog in Parsimony? I do admire David Troupes (Buttercup Festival) and really have to order Parsimony. (There's another glimpse here.)
But given all the words of our million LOC systems, what simple pictures should we draw? Alexander said of patterns, "if you can't draw a picture of it, it isn't a pattern." At what point will we say "if you can't draw it, it isn't architecture"? Architecture is (at least) the structure of the system designed to deliver, through collaboration and interaction among the constituent elements, the desired capabilities* of the system. And we ought to (be able to) draw that! But drawing -- designing those elements at varying degrees of elaboration and abstraction, taking different views on the complex of structures to design and elucidate how various capabilities are to be built or evolved -- is not everyone's "cup of tea."
These diagrams are a medium for and the visual expression of design thinking. Of course I don't mean it is only or all about visual models. For example, technology choices may show up on models, but not necessarily, and certainly the reasoning behind the choices needs to be expressed in words so that our thinking, deliberating on stakeholder goals and concerns, connecting to business drivers and assertions we make given a diligent, honest look at technology capabilities and directions, is communicated and preserved. And, frankly, thought about more rigorously, because writing, as with visual representation (whether in "art" -- subjective, or in a "model" -- "objective"), makes us think more thoroughly, investigate more angles (if we listen to those various voices in our minds that "help us get more thinking done"**), etc.
That said, visual models are good for thinking about and seeing relationships, which may be structural or temporal or cause-and-effect. Oh dear. This is starting to sound like ☼PICTURE IT.
And... a whole lot more that I don't have time to write and you don't have time to read because insight is all well and good but some things, not just understanding and passion, have to be built in the world too.
* behaviors or functionality with properties users and other stakeholders care enough about to make the system compelling and useful, even meaningful -- and sustainable
** I'm just quoting an earlier journal entry so that I remember to link it in my
non-public journal view.
11/6/10 A Beautiful Life
While I was dusting some of the lovely pieces of art we've collected over the years, I was thinking about what constitutes a beautiful life, living a beautiful life (you know, because the juxtaposition of pet dander/entropy and art/creation raises such a question... I mean, it's what you think about when you're battling entropy, right? Like, how do we balance blazing like a comet with ...um crud...). How complex the matter is! Well, whatever it is, it includes music!
Tim Reed is Ryan's voice teacher, so here's something that is close to us:
"Euphoric Owls" ... Imagine George Winston meets Schubert and Chopin, often with soaring vocals, sung by [Tim Reed] and the amazing Brown Sisters. You can enjoy the music on this CD and help people in need. [Tim is] donating $1 for each CD sold and 10 cents for each download to the Monroe/Owen Chapter of The American Red Cross. ... [You can buy them] on the web at CDbaby. It will soon be available on iTunes and Amazon, and over 20 other websites as well."
You can sample Euphoric Owls here. Tim Reed is amazing -- so talented in his own right, and so joyous and fun that he is able to work incredibly effectively with a very wide spectrum of kids (in terms of their preferred genre, but also personality). They have a recital tomorrow afternoon that, alas, I have to miss to fly to Boston. I heard some of the rehearsal today, and it only made me more sorry to miss tomorrow's performance. These kids are alight with that lively fire that a spirit following its bliss lights up, and I thrill at it!
In Bloomington we have soaring trees and soaring spirits. I love seascapes and rugged mountains, and I miss them! But I do so enjoy the music and the fun people have with it in this town! Who'd have thought... in the middle of Indiana, you'd have hardwood forests and such music (from orchestra and opera to jazz to bluegrass or "folk roots with the dirt still on")! It is fun to have, in one family, a harp playing, ballet-dancing girl and a mandolin and banjo playing, singing Woody Guthrie-styled boy. Ball gowns and blue jeans! IU's gorgeous music halls and downscale pizza places. All the ways, and all the venues, in which we might find a beautiful life, and live it.
11/6/10 Why You're Needed...
Invisibility cloak... we can do that with software, right? And you question whether architects should play a role in requirements.... ;-)
- Strategy, Architecture and Agility: The Art of Change: Fractal and Emergent, 2010
Innovation and Agile Architecting:
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
- Werner Vogels (Amazon)
- Jonathan Schwartz (Sun)
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