8/2/07 Architecture Basics
1. A system is like a thing—computer, printer, or even a house
2. A system is made of different parts.
3. Architects think of what those parts are and how you put them together to build a system."
by Sara, age 7
An alternative view, is that architects do the hard stuff which often translates into spectacularly addressing each crisis du jour. In this mode, this becomes a self-fulfilling identity—always being pulled out to address crises, distracts the architect from work that would prevent crises, so the cycle continues and the architect is always addressing crises. Instead of planning for scaling by 10x during the next ad campaign, the architect has to react to the load spike on the fly—has to, because the time to address the issue strategically has passed, and now the only recourse is reactive. Right now, you can't put more than one item in the shopping cart at hpshopping.com. How much revenue is that costing HP? And who will be the hero that saves the day today? Wouldn't it be better if the hard stuff was done upfront? Like, what if the system had a health monitor that would watch for signs of shopping cart malfunction and have a strategy for recovery? Use cases, abUse cases, change cases, risks. That's increasing the span of what we need to pay attention to. Inherently, risks are about unknowns, and inherently architects must deal as best they can with an unknowable future in advance if they are to mitigate risk. It may sound good to say let's let tomorrow take care of tomorrow, and do no more than necessary today given that we have no guarantees about what tomorrow will bring:
"Agile architects have the humility to admit that they can’t predict the future and instead have the courage to trust they can solve tomorrow’s problem tomorrow."
from Agile Architecture Modeling, by Scott Ambler, April 29, 2006
But let us also remember that what distinguishes us from other mammals is the prefrontal cortex and the ability to envision the future, to think about future consequences of current activities! We are sophisticated enough not to assume randomness away (though Nassem Taleb argues we are, more often than not, Fooled by Randomness), yet we impact the future by taking action today. We shape the future. Yes, yes, others are all working to shape the future too, and their actions, and unpredictable and predictable forces of nature and society, all impact the unfolding of events. So we need to be strategic, and set direction; and we need to be agile in responding to the course-corrections that come as the future unravels into the threads of the present.
It is fundamentally hard to deal with broad scope and all the complexity that brings. And fundamentally hard to deal with uncertainty. Architects do the hard stuff. Good to great companies let their architects do the hard stuff balancing strategic with tactical. Executives set strategy for the business (ideally with input from senior architects). Architects either translate that into technical strategy and lead the execution of that technical strategy, or they are cornered into a position of always responding to crises—is it really better to respond to a known crisis than to mitigate a likely risk, especially one with serious consequence if it transpires?
And that's just talking about risks! Architects can, and should, deal with much more hard stuff than that! Who else will deal with value delivery across use contexts, finding leverage (real leverage, not just clone and grow separate code trees that quickly diverge), yet maintaining differentiating uniqueness across the product set? Who else will deal with integrity and product family identity, consistency, integration, and a myriad other concerns that cut across the application domain or product family, and generally aren't issues when a user story is taken in isolation. And, of course, there's the basics. The parts. And building systems from parts, parts that collaborate to deliver the system capabilities and system properties. Parts that are units of innovation, experiment, change. Parts that are the foundation for agility. Agility. Not treating past development as sunk cost. Treating past development as a platform for transformation. A platform for response to opportunity.
Well, again,... more thought needed on this...
But... before this thought gets away... Scott Ambler's exhortation to "travel light" with respect to architecture documentation is ringing in my mind. And I can't help thinking there is both an attraction and a flaw in it. Stripped down documentation is so dull, so dry. Does a bare-bones interface document put much distance between it and what shows up in the code? How much does a sketch of the system, outlining key components, convey? How much do we have to do, to communicate the architecture decisions in a way that empowers and enables and motivates the various people in the development community? I like to differentiate between the architecture specification which is the record of the architecture decisions, and "documents" (including wiki spaces, and presentations) tailored for specific communication needs (like the 85 Federalist Papers advocating and explaining different aspects of the US Constitution).
Good architecture documentation, I feel, captures the decision(s) and the rationale, and the rationale is where things get interesting! Explanations, alternatives considered, defense and counterpoint, all add to the knowledge hard-wrought from experience, that the architect is sharing with the development community. It makes the architecture come alive. Makes it hold value way beyond the code. But, it is certainly true, this kind of documentation (and the spoken communication that is paramount) takes time. The time of scarce experts. The time of organizational assets so valuable they should be highly leveraged. But if they can write documentation with this kind of zest, this kind of deeper value, they are leveraged—directly, through an architecture that moves into the minds of the community, and indirectly, by sharing the thinking behind it. This assumes good architects. Architects with experience worth counting on. The kind of architects we want to keep, because our future depends on them. Our future. Tomorrow, and tomorrow's tomorrow. Because of the work they do well today, and because of the insights they share, helping to nurture developers and up-and-coming architects.
Not that we want to belabor the rationale, the explanations, the alternatives. It is not just the architect who is too busy to write; software engineers are busy too! But we want to cover enough of "what we were thinking" to have it hold up; be understood and bought into. Extensive, exhaustive documentation is going to quickly exhaust interest, and serve as counter to our purpose. If even a sentence doesn't add to the system goals, it detracts. All the brilliant thought is squelched by the bulk of it. So, it's another balancing act the architect has to play. And there will be detractors.
Architects walk a hard road, too often with turf protectionism on all sides. Arrows, not pedestals, come to mind; well, let me contextualize that. If pedestals are mentioned, arrows come instead to mind. Still, it is the unfortunate experience that some organizations, or even just individuals or teams that set the tone within them, are outright hostile to architects. They know they need them; the architectural deficit of the past, with its kludge-bondage, is clearly not the way to move forward. But they don't know how to value their architects and enable them to do their work. Other organizations have always valued architects. And others have made the transformation. And in all of these, the architect still has to persuade and influence without authority, because by nature, architecture addresses cross-cutting concerns—concerns that impact local vested interests. Barack Obama's words, which I came upon and quoted before, come to mind:
"We just need to understand that actually solving these problems won't be easy, and that whatever solutions we come up with will require consensus among groups with divergent interests. That means everybody has to listen, and everybody has to give a little. That's not easy to do."
For people who deal every day with the hard stuff, the hardest of all is the political stuff. In the end, it may help to recognize that each role is tuned up to its frame of reference, its charter. People work with good intentions, to accomplish the goals set by and for them. So part of our role, as architects, is to explain where overall business and system goals, cross-cutting concerns, are best achieved with some give-and-take at the local level. To work with enthusiasm, building enthusiasm, for the good of the whole.
well... this is not what I set out to write... but it will have to suffice for now...
Covey's 7 habits for excellence in leadership may serve:
begin with the end in mind
put first things first
seek first to understand, then to be understood
sharpen the saw
8/4/07 The Power of Vision
Along the lines of "everything I know I learned from my kids," we're reading The Wheel on the School, by Meindert Dejong. Yes, this story is set in The Netherlands, home of many great system and software architects today. That is not the point, although the setting is at the center of the story. We are only 3 chapters in, reading a chapter each night. Alright, I'll get to the point.
The point is, it is a delightful description of vision and action. Truly, instead of talking about vision at the next workshop, I just want people to read this book! At least read chapter 3. It's priced as a children's book. But I haven't seen a book for adults working the elements of vision so well! Vision, the power of wondering, the power of being in the future, the power of shared vivid image, the power of finding the actions that will make the vision possible. There's more in the chapter; but that's your assignment.
I have no clue where this book goes. But chapter 3 is a nugget; a keeper. So, all of you who I'll see on August 22nd—you have homework to do! If you're skeptical, just read chapter 3. But if you're open to magic, start at the beginning.
My son groans, and says: to me, everything is about architecture. But that's not true. No. It's the other way around. Architecture is about everything! Grin. Well, ok, not everything. But it certainly is about vision. And it is about being open to influence, open to learning, for we don't know where inspiration and creativity, innovation, will come from. It might even come from staring into our shoe. Oh, read the book (the shoe is actually a reference to chapter 2).
8/4/07 Kayaking Lessons — for Architects
Dana used to teach kayaking in the San Francisco Bay. Before taking a class out of the calm waters of Sausalito into the water that rushes in under the Golden Gate Bridge from the open ocean, he would ask them, "What is the difference between me being out in rough water and handling it, and me being out in rough water, terrified?" The answer he was looking for, had nothing to do with any specific technique, with what to do with the paddle, or where to turn. The answer was being relaxed, confident, comfortable. Having your full resources at your disposal. So, while in the calm waters, he'd ask: "How do you feel about being in your kayak right now?" People felt ok. Comfortable. "Take that with you. That's how I want you to be, when we head out into the Bay." So we find the qualities, our way of being, when we have our resources fully at our disposal. And we can draw on that, when defensiveness threatens to scatter and dissipate our resources.
8/4/07 The Speed of Trust
One of the architects in the Chicago open workshop (back in May) recommended Stephen M. R. Covey's book, The Speed of Trust, when we were talking about the organizational politics/effectiveness skillset of the architect. It's not the Stephen Covey of 7 habits fame; it's his son.
8/6/07 Amazon's Online Reader
Well, I'm trying out Amazon's Online Reader. There aren't too many books available for upgrade to the Online Reader as yet. But worse, at present, the "highlight and annotate" feature is turned off, and one can only "bookmark." Of course, highlighting and adding notes is the critical feature I'm drawn to! Putting a virtual dog-ear on a page isn't really my thing... I want notes in context; tracking my discourse with the material. So, I conclude the Online Reader isn't ready for prime time yet... But it's headed in a neat direction. Dana says he won't use it if he doesn't own his own notes; doesn't store them on his system; doesn't own access to them. That's a serious consideration. I don't care so much if Amazon hosts my notes, though I don't want my notes to disappear if Amazon decides the experiment isn't worth it.
While I wait for my paper copy to arrive, I've been reading The Leader's Guide to Storytelling: Mastering the Art and Discipline of Business Narrative online. Stephen Denning spends quite a bit of time positioning storytelling in organizations. So, if you felt uncomfortable when I suggested reading (chapter 3 of) The Wheel on the School, then you can read Denning's positioning of storytelling in business. Not that I'm suggesting you read The Wheel on the School at work, mind! I do think that it draws out important elements of vision, in an enchanting, child-delicate way, so that you get it without being told, by infusion, rather than contusion!
But, back to Denning, and his positioning, rather than mine. Denning positions the effective business narrative as minimalist and workman-like; no Hollywood drama, no mush, sweat, smells and grime. Just something business people have time for. Doesn't turn them off; doesn't set off alarm bells.
Here are some quotes from The Leader's Guide to Storytelling: Mastering the Art and Discipline of Business Narrative by Stephen Denning (Jossey-Bass, 2005):
"Management concerns means rather than ends...
Leadership on the other hand deals with ends more than means. It concerns issues where there is no agreement on underlying assumptions and goals—or where there is a broad agreement, but the assumptions and goals are heading for failure. In fact, the principal task of leadership is to create a new consensus about the goals to be pursued and how to achieve them. Once there is such a consensus, then managers can get on with the job of implementing those goals. Leadership is essentially a task of persuasion—of winning people' s minds and hearts. Typically it proceeds inductively by argument from one or more examples toward a more general conclusion about the goals and assumptions we should adopt toward the matter in question. Storytelling is thus inherently suited to the task of leadership."
"Analysis might excite the mind, but it hardly offers a route to the heart. And that's where you must go if you are to motivate people not only to take action but to do so with energy and enthusiasm. At a time when corporate survival often requires transformational change, leadership involves inspiring people to act in unfamiliar and often unwelcome ways. Mind-numbing cascades of numbers or daze-inducing PowerPoint slides won't achieve this goal. Even logical arguments for making the needed changes usually won't do the trick.
But effective storytelling often does... Although good business cases are developed through the use of numbers, they are typically approved on the basis of a story—that is, a narrative that links a set of events in some kind of causal sequence. Storytelling can translate those dry and abstract numbers into compelling pictures of a leader's goals."
"There's an old Brazilian proverb that when you dream alone it's just a dream, but when you dream together it's already the beginning of a new reality."
8/7/07 How Much Pathos Belongs in Business Storytelling?
Denning recommends a minimalist, workmanlike approach to storytelling; one that doesn't alert the "he's flying above the ozone" sensors in a staid, and busy, business audience. If you were reading along last September or October, you'll know I was thoroughly impressed with John Wood's book, Leaving Microsoft to Change the World. Still, I was struck by the fact that while we become very intimate with John Wood's life, we don't hear about the lives of the children his work has touched. He personally abhorred pathetic pictures of children in distress, used in some appeals by charities. But he never told the story of the difference a school makes in the life of a child—a specific child. For me, that was a gap; my only quibble with the book. I wanted to read the stories of the children, or at least one or two of them. But would that be inappropriate, excessive pathos for a book intended in good part for a business audience?
Now, if you want the story that reaches deeper into the lives of people, the latest Room to Read newsletter has a pointer to a video by PBS that does just that:
"Viewers of an innovative and captivating video filmed by the team from PBS find out as they follow the visit of Frontline journalist Sachi Cunningham to a small village on the outskirts of Kathmandu. This moving 15 minute video entitled "Nepal: A Girl's Life" chronicles the life of Sabina, a young Nepalese girl living in the Kathmandu valley, who is a part of our Room to Grow Scholarship Program. Following Sabina through her daily life at home and at school, the film illustrates the very tangible ways her scholarship is providing life-changing opportunities to girls throughout the developing world. Though 70% of all women in Nepal are illiterate, Sabina is now guaranteed an education through high school, breaking the cycle of poverty and illiteracy so prevalent in the developing world."
It is a story from the other side, the side of hope, not from the darkness of an unbroken chain of female illiteracy. Not an appeal from the point of despair. Though it is indirectly. This is a child for whom the course of personal destiny has been diverted from the shackles of illiteracy that she was born into. Which leaves us with the implicit plea to rescue more children. An implicit plea, it turns out, that foots Simon Munro's description of the context of the architect in South Africa.
Denning presents a set of narrative archetypes, patterns for given contexts. This should hit a resonant note in our pattern-loving software engineering world. But I sense that where Denning started, going with his instincts, is a good place to start! Wherever our sensibilities land on the line to draw on emotionalism, pathos is an important leg of the rhetoric triad. A leg we should put more weight on! So, use Denning's formulaic approach, or use your intuition, but tell stories. Denning has been paying intelligent and pragmatic attention to making business narratives effective, so leveraging the lessons he lays out for us is a sound notion. But don't put anything in the way of just doing it! I'm sure you already are telling stories. But are you telling stories to change attitudes, to lay a receptive ground for your architecture work?
That's what I've started to say in workshops: Just do it. I have never been managed by the hour, because I established trust that I invested my hours well. So, even if I don't have freedom in the large, I have the freedom to spend an hour here and there. And that is all it takes, to start to sketch—a context map, the conceptual architecture, or a mechanism I'm thinking through. If I am uncertain about doing something, I have to accept I am the first barrier to entry, and the most significant one!
8/9/07 Great Big Ball of Mud
I was rereading Foote and Yoder's Big Ball of Mud (it's worth returning to several times at least) and as much as the essay resonates with my experience, I realize there is a big glaring misconception out there. There is this idea that if you do "upfront design" you're doing waterfall, not agile. That's not true, or at least, that doesn't have to be true! No, indeed! We just start our feedback cycles, our requirements discovery process, with models. But the values around learning, adapting, refactoring, all apply!! And in the process, we head into agile, iterative coding cycles with a better design foundation than the draft set of components/responsibilities/relationships we first conjured up out of our collective, or worse, individual best guess. Yes, we remain open to learning—indeed we strategically seek to learn about both the value propositions we're delivering to users and other stakeholders, and the structures which best support these value propositions. This is not an all or nothing world! It doesn't have to be XP and Agile is only about cutting code. Applying the values, and the values that underlie the espoused values, to architecture lets us learn more quickly, more cheaply, so that we can adapt more gracefully to our changing understanding and the changing externalities of our world.
One other flaw in much of the "we must respond to a changing world" thinking is that it neglects our impact on the world. We aren't mere windsocks responding to the direction of the wind. We make wind! We change the course of history, in small and big ways, with what we create. We change expectations about what is possible. We interact with destiny, don't just simply bow to it. Though, to be sure, we ignore these forces at our peril. But ignoring our role in shaping expectation, shaping the world into which our systems will fit, is just as one-sided as blindly expecting users to force-fit our product offering to their needs. The world of pragmatists is the world of balance, the world of tradeoffs. This is just as true for the process we adapt to fit our needs as it is to the products we generate thereby.
But back to Foote and Yoder's Big Ball of Mud: It is superb—wonderfully written and illustrated with visual and verbal metaphor, and keenly insightful. In short, a delight to read.
8/9/07 Architecture Sketches
What I did, and still do is to carry a sketchbook with me and draw models of the envisioned architecture solution when I explain it to stakeholders. I explicitly redraw the picture each time and validate my drawings with the stakeholder reaction. After having explained the solution a couple of times and gathering valuable feedback I learn how to communicate the architecture effectively. After a while you'll find your own preferred drawing style which is, along with your other competencies, a great tool to add to your "architect toolbox".
There you go; another great Dutch architect. Of course, it doesn't hurt my assessment of him, that Paul recommended our Role paper in glowing, if brief, terms, but that only served to pique my interest and I spent more time on his blog to validate my initial assessment. It is, of course, my goal in life to have the label "great read" applied liberally, but, alas, Paul's compliment (sadly) stands in isolation.
Self-serving innuendo aside, Paul gives superb advice:
explicitly redraw the picture each time: hand-drawn pictures have a "not done yet" feel to them, allowing for more interaction and a shared sense of ownership for improving the picture; it establishes a collaborative stance, and doesn't raise defensiveness
validate my drawings with the stakeholder reaction: watch for cues from the stakeholder—body language and verbal feedback; a negative reaction, whether it is lack of understanding or disagreement, is a source of opportunity to improve—the drawing, or the solution, or the way I talk about it
having explained the solution a couple of times and gathering valuable feedback: adapt and iterate, learn and improve
So, with respect to architects and sketches, let me just say, audacity is more important that the ability to draw a work of art. I've been drawing arrows for years, and I have to say, practice does not make perfect; at least, not in my case. But people are more tolerant of imperfection in arrows or boxes than they are of an ego-bound image of a "perfect" solution. Architecture models are for communication. My whiteboard skills don't stand up to the needs of a formal document. But by the same token, a hand-drawn sketch, even if not very skillfully executed, doesn't raise barriers to exploration and improvement. So, in short, don't be daunted.
see also, Learning From My Mitsakes on Simon Brown's CodingTheArchitecture blog
These are the kinds of lessons architects bring into workshops, and they constantly tune my understanding and insight, sometimes making me more aware of something I was dimly aware of, sometimes re-orienting my perceptual frameworks, and sometimes shifting my position entirely or bringing something new into my experience.
Speaking of which, we're up to 14 for the Role of the Architect workshop coming up the week after next. That will be 14 sources of learning and inspiration for me; but only 3 days. It's so hard to balance my need to hear and learn from the architects in a workshop, with their expectation that they will learn something useful from me... They're paying, but in a sense I'm paying too. There's the opportunity cost of all of our time, and I'm the one bearing the burden of investing our time well. I'm always daunted by that. And excited!
8/9/07 Storytelling Debrief
I have been reading further into Stephen Denning's The Leader's Guide to Storytelling: Mastering the Art and Discipline of Business Narrative. It has set me thinking. Oh, I know that storytelling is already part of your repertoire, and mine. It's just that, given how important it is, I'd do us all a service to get better at it. I had a fleeting thought that I have more chances to practice the "build trust in me" type of introductory story—I'm constantly working with new groups of people. My voice, my size, and frankly, just being a woman in this software field, all ups the ante on the need to establish credibility. But, as I say, the thought was fleeting, because no sooner had the thought crossed my mind than I remembered all the times when I took on a new role, and needed to build a new perceptual set of expectations of me—building trust in me in the new role. Working with the same people, but in a new role, can be even more demanding because it means some preconceptions have to be shifted aside. It also occurred to me that the "build trust in our company/brand" has relevance if we think about that from the start—from visioning, through architecture and development; not just after release when marketing catches the monkey to tip the tipping point of a consumer epidemic. The springboard story (motivate others to action) and vision story chapters speak more transparently to our situation.
I've started peeking into The Classic Touch: Lessons in Leadership from Homer to Hemingway. I guess, it would be so much more sophisticated to draw on Homer and Shakespeare than the latest book we're reading at bedtime (even if they are either Newberry Award winners, or deserve to be). One has to have earned a certain stature before it is safe to draw lessons from Bud Not Buddy, or The Wheel on the School, and I'm by no means confident I'm anywhere close! Now, in a recent workshop, Mike lost nothing by recommending Bud not Buddy to his peer architects, and Peter lost nothing by saying he was going to buy it to listen to on his drive back to Canada. As for me, well, I just have to hope that my joyful enthusiasm is infectious; that my commitment to surfacing what it takes to be a great architect and to get great work done with and through others, is, let's just say, redeeming.
I'm also looking forward to getting into Getting Things Done. No, it's not a 7 Habits-styled time management treatise. Previews brought to mind Lesson 3 in Leadership Lessons from Geese (which Kevin's Architect's Linksblog alerted me to last year*). Yes, it's about organization design, collaboration, and so forth.
* I still rely on Kevin's Architect's Linksblog to be my first-stop guide when I have moments to explore the blogosphere. I told Kevin it saves me a lot of time, and keeps my horizons open. It's fun and interesting to see where he's been scouting.
As for Grady Booch, I look in on his blog and get impatient. What, isn't it against the laws of nature to slog in Hawaii??! I can have a love affair with 4 or 5 books at a time; indeed, it keeps my spirits high. But over 40! Just the notion is overwhelming! I realize that over the course of writing several books, Grady has established a way of going about doing that. But (thanks to Daniel Stroe) I watched an interview snippet with Frank Gehry, the architect. Gehry said that before he started on a new project, he’d procrastinate in sheer terror of the thing. Set appointments, clear his desk, catch up on the literature… no just kidding; he didn’t say this last. J Still, I wonder, does being so successful make it harder too? I want to tell Grady to write, just write, for I know he'll create a masterpiece worthy of his name—a landmark technical book that’s not a slog to read! Oh well, if you see Grady in the UK next month, just tell him he's read enough; he's ready, and we're waiting! Yes, yes, Grady's talks are all the better for his being informed, his scholarly investigation, and he sets a high standard for himself and our field. Still, I'm not eagerly anticipating an academic text full of scholarly reference to the literature that precedes it; I'm eager for a practitioner's handbook.
On the promised books front, last week stands out for me, for I got two reminders that the occasional person out there is actually looking for our book to be done. Gosh, in the deathly silence I just thought it didn't matter to anyone! So, for those two people, I'll have to revisit my priority stack!
8/10/07 Strategic Conversations
From time to time, I stop by Tony Manning's Strategy site. I'm always struck by what a good resource it is for architects. Yes, there is a fair amount that is focused on the peculiarities of the South African context. But there is much that is just a pragmatic approach to strategy and leadership, no matter where you are. The kind of cut-to-the-crux thinking we're used to as engineers.
"Much of our daily conversation is a default activity: it just sort of happens. By contrast, “strategic conversation” is no accident. It’s a deliberate process and the No. 1 leadership tool. All else rests on it. So you need to think about it systematically, craft it carefully, and use it purposefully.
The first task of a leader is to provide a clear point of view – “There’s the hill we’re aiming at … these are the results we want … this is how we should conduct ourselves … here are our priorities … this is what we’ll do to get where we want to go.” This is the context in which people work.
The ongoing task is to focus and inspire them. Talk about the right issues in the right way to the right people, and extraordinary things happen; but get the conversation wrong and you’re sunk.
Strategic conversation must be carefully crafted and meticulously managed. The best leaders are acutely aware of the impact of their words. They handle all stakeholder relationships – with their own people, customers, suppliers, government and others – with great care. And they think through four key issues in order to frame their messages:
1. Their organisation’s
purpose – why it exists, where it’s going, what it must
2. Their business recipe – how it makes money.
3. Their organizational character – how people behave.
4. Their goals, priorities and actions – their targets and what they will focus on to get there."
Tony Manning, Fine-Tune You Strategic Conversation to be Heard in the Market, June 2001
If we think that the 4 issues are all very well for the strategic leadership to be thinking about, we're missing an opportunity. Technical leadership will be more relevant if technical leaders think first about these issues!
We need to be aware of what the business leadership are communicating as their true priorities and goals through their daily conversations, and we need to be aware of the effect of our conversations, as technical leaders:
'Spend just a little time in most organizations, and you’ll hear someone say, “What gets measured gets managed”. But what just about everyone overlooks is the fact that it’s only what gets talked about that will be either measured or managed.
Most critical, of course, is what the leader talks about. For his or her words quickly become gospel – and they determine which way a firm moves and how fast it does so.'
Tony Manning, Fine-Tune You Strategic Conversation to be Heard in the Market, June 2001
So, anyway, I thought this all tied in rather well with my current "kick" on storytelling. Strategic conversations and stories leaders tell.
Quoting Coyne (at 3M?), Manning writes:
“Transformation is a group process,” warned Coyne, “and the leader who tries to control evolution cell by cell is not going to succeed. “Never try to control or make safe the fumbling, panicky, glorious and chaotic adventure of discovery.
“Occasionally I see articles that describe how to rationalise the invention process, how to take the fuzzy front end and give it a nice haircut. I would urge you to make that fuzzy front end as unkempt and as furry as you can because innovation is not neat. We stumble on many of our best discoveries.”
Tony Manning, Innovate or Die, 2000
Now, doesn't that just remind you of the teacher's advice to the kids in The Wheel on the School? He told the children to look where you would expect to find a wheel, and to look where you are sure you could not possibly find a wheel!
Sometimes (not often, of course), I wonder if the software world is too busy looking at it's own navel. I'm sorry folk. But really, we do have to open ourselves up to possibility. And sometimes possibility comes from working closely with end users and and delivering code that fits the stories they tell. And sometimes we just have to get out and find new stories, shape the world before it boxes us in with preconceived expectations. Look in unexpected places, impossible places. And expected places.
Yes, we just read the chapter about the boat last night. Each chapter is a gem. An allegory. Sweet, sweet when read on the surface. But with key lessons if we're only open to them. The quiet voice that prompted me to talk about The Wheel on the School in this setting, is getting louder, more confident. I have to think, well, if you like me, if you read these notes, then surely you'll find this book a treasure. But, if you're disappointed by it, do tell me! It will be a useful barometer, help me gauge my relevance! But by the same token, when you agree, do tell me. That is important too!
Oh yes, and as the story goes, I quite relate—there is but 1 girl in a school of 6 children. Those Dutch, even when they're telling stories they're right on task! Here, we have big dreams, and we make big dreams come true. And part of our big dream, is giving due respect to all people—ourselves, and others. I reread (and then listened to) Martin Luther King's "I have a dream" speech. It is so great! One of the top 100 speeches of all time? Or top 10? Or the top? But Bono's "Because we can, we must" commencement speech (which I referenced back in January, here and here) is important in our time, and one to learn from too.
Relevance? As architects we don't generally give speeches!
No, but the images we use, the stories we tell, the
conversations we have, set direction and orient attitudes,
just as surely. So, we may as well be more conscious of
this, and craft our key messages just as carefully. We may
not change the destiny of people's around the world the way
Martin Luther King did. We may not have the popular impact
of a Bono. But we must see ourselves as leaders, to be seen
8/10/07 The Four Steps of Creativity
'Preparation, incubation, illumination, and verification;
these are the four stages of the creative process. The old
saying by Thomas Edison, "Genius is ninety-nine percent
perspiration and one percent inspiration," precisely
describes the essence of the first stage. Preparation
consists of much hard work and skill acquirement that
usually precedes creativity. During the second stage, the
problem is put away. Ideas, thoughts, information gathered
during the preparation stage submerge into the unconscious,
where they are "brewed" and organized subconsciously. The
third stage — the "Eureka!" stage - happens when the
solution finally emerges into the person's conscious mind,
usually with amazing clarity and shocking impact. The ideas
has been related and arranged in new ways during the
incubation stage, providing the exciting insight. Finally,
during the anticlimactic verification stage, the scientist
or artist simply transcribes the solution into concrete
form. The four steps may cycle through many times during a
creative process, or start in different stages, such as
those creative pursuits first invoked by an "Aha!" response
that aroused curiosity. Clearly, easy as it appears, the
creative process is actually a long and difficult one that
requires much hard work and patience!'
The Mind, ThinkQuest
8/10/07 The Four Steps of Creativity
'Preparation, incubation, illumination, and verification; these are the four stages of the creative process. The old saying by Thomas Edison, "Genius is ninety-nine percent perspiration and one percent inspiration," precisely describes the essence of the first stage. Preparation consists of much hard work and skill acquirement that usually precedes creativity. During the second stage, the problem is put away. Ideas, thoughts, information gathered during the preparation stage submerge into the unconscious, where they are "brewed" and organized subconsciously. The third stage — the "Eureka!" stage - happens when the solution finally emerges into the person's conscious mind, usually with amazing clarity and shocking impact. The ideas has been related and arranged in new ways during the incubation stage, providing the exciting insight. Finally, during the anticlimactic verification stage, the scientist or artist simply transcribes the solution into concrete form. The four steps may cycle through many times during a creative process, or start in different stages, such as those creative pursuits first invoked by an "Aha!" response that aroused curiosity. Clearly, easy as it appears, the creative process is actually a long and difficult one that requires much hard work and patience!'
The Mind, ThinkQuest
see also Lynne Maher, Innovation for the 21st Century, INVIEW December 2005
8/10/07 Entry into Myths of Innovation
I'm a few chapters into Myths of Innovation. In myth-buster style, Scott Berkun sets about disabusing us of any wrong-headed notions we might have about the Epiphany myth in innovation. Ok, so if you thought that Isaac Newton was sitting under an apple tree, got hit on the head by a falling apple, and instantaneously had this revelation about gravity, with no prior thought, work, research, questioning, wondering, endeavor on his part, then the opening chapter is for you. So maybe it's not new news. But that's part of the point, really. Very often an "ah ha" is more about reshuffling the pieces we already know, than about some new information. And sometimes, it is a new piece, even a tiny piece, that makes all the other pieces make sense in some new way. The Eureka that brings Order out of Chaos isn't necessarily a momentous new discovery. (I capitalized these names, for they are the names of the conference rooms in the HP Laboratories floor that housed the Software Technology Lab where I first worked at HP.)
We can have small eureka moments, and large. I woke up last night with the thought that collaboration in architecting is all-important. An insight that had been lurking in the shadows of everything I stand for, jumped into clear focus. Architecting alone isn't just lonely, it is slower and prone to blind-spots. Architecting in big groups is slow too. Two or three architects who work well together are often the most agile, working quickly to surface risks and uncertainties. Yes, group-think can take sway, but a small team that is disciplined about getting external input is less prone to the strangle-hold of vested ego. Ego works for and against us. We invest our brain cells into our work; I mean literally! And we deserve to take pride in it. But it can also blind us to weaknesses. So, it helps to bring in more eyes and hearts and egos early, to bring fresh perspective and new opportunities, widen the band of exploration and chaos, increase the chances for innovation-yielding eurekas. And, as we push towards convergence and order in our design, we also need to bring others in to help us assess the efficacy of our approach, lower the risks, improve our strategies and design. In the Visual Architecting Process we call this "validation," even though what we are doing is gathering input and ideas as much as we are getting a pat on the back for good progress. And believe me, the pat on the back is all important! Positive, enthusiastic response, along with some open-minded questioning, goes a long, long way to stimulating the kind of generative creativity we are looking for from architecture teams. It goes a whole lot further than keeping our architects humble by habitually demonstrating to them that they "don't walk on water."
Ok well, back to Myths. Scott has quite a sense of humor. And audacity. He touched the Rosetta Stone. He touched the Rosetta Stone! Because of him, it is now encased in glass. Well, probably a few others were implicated, but he touched it. His footnote recounting the incident is priceless! Talk about stories, Scott has plenty of them. He puts himself into his work. I mean, literally. I like that. He's smart and he writes with flair. I don't always agree with him, but he does make me think. I like that too.
For a start, the only sentence I read in the Preface was the (almost) last, which reads " And now, since you were patient enough to read this entire preface..." Right there, I knew this was going to be a book that would challenge my sensibilities. After that presumption, I couldn't stomach reading the Preface!* But Scott has a habit of stealing in uninvited. Not only did he breach rule and etiquette by touching the Rosetta Stone, he stole in on a tour of the Google site. And he stole into my mind. Not entirely uninvited in this instance, but deeper than I would have bid on first introduction. Of course, at points he's more of a heckler than a muse to me, but through it all, he does amuse me!
Scott has done a excellent job of pulling together a broad scope of work on innovation, and it is at least a good and well-organized synthesis, and it does stimulate thought. And it is funny!
* Oh, I do realize he could just have been having fun with that... But then, I was too! ;-)
8/11/07 HelpMatch Wiki
I have been "incubating" on the HelpMatch front. This morning I checked in on the HelpMatch wiki, and work I had put there on the strategy and so forth had disappeared, and a whole lot of spam had filled the Sandbox Talk page... Oh, the joys of wikis!
I want to have some face-to-face HelpMatch meetings with HelpMatchers, to understand how others see the vision evolving, to share my evolving vision and get ideas and an assessment of whether it is still something architects feel excited enough about that they will put time into it. I still think it'd be fun à la Traveling Wilburys, and important to the world. Putting social networking and help-specific tools in the hands of helpers would be an important achievement; helping us deal better with the aftermath of disasters would be significant. Almost two years post-Katrina, New Orleans and the region is still on a slow path to recovery. Many organizations and people are helping, but I can only think that much more willingness to help was squandered because people didn't have a place they felt fitted their options to plug in.
We really need to get HelpMatch to the point where it breathes without me! While it relies on me, it will move in fits and starts, because my rhythm has to be broken by client engagements and my need to kick back on the lake a few hours a week with my family during the summer.
Speaking of lake, I noticed that I inadvertently used Monroe when I referred to Simon Munro earlier this week. Oops. But, we live just 10 minutes from a great put-in to Lake Monroe, so I guess that was playing on my subconscious. Sorry Simon!
8/12/07 Architecture as Dark Art
If you're interested in Agile and Architecture, here's an interesting read, including the comments: The Demise of the Gantt Chart in Agile Software Projects, by Tate Stuntz on July 31, 2007. I have to agree with David Christiansen: "I’m not convinced there is such a thing as a methodology or process that can produce good architecture." People create great architecture, just like it is people that create great software systems. But are there things we can do to create better architectures, and better software systems? Of course I believe there are!
In manufacturing we learned that if we inspect quality in at the end, the cost of quality (a term that refers to the cost of poor quality that leaks through the inspection process, as well as the cost of removing found defects) is much, much higher than if we find potential quality problems at the source, to ensure they aren't inserted. It seems to be asking for suspension of disbelief to ask for time on a project where all that is being produced is models, diagrams, stories, even if this work is toward a minimalist set of strategic decisions. Putting features in front of users, why, that is what creating software is all about. That is where we can see progress. But, if progress is moving towards a better sense of what our users value, across use contexts, and all that decision space complexity, then we can make a lot of progress quickly and cheaply with models (and mock-ups and proof-of-concept/prototypes). And by exploring how those features play out over our posited architecture structures, we can refactor early, cheaply, while all we are changing is models and descriptions.
In all we do, we have to find a good balance. Our models should not be belabored, certainly not early on, by putting in too much detail or trying to make them look pretty too early in a tool where pretty is hard to do once, let along with tweaks and changes. What we are trying to do is surface and understand value propositions that users and other stakeholders find compelling. And find and improve the structures (architectural components and mechanisms) that will support the system through the sprints leading up to the first release, and beyond.
8/13/07 As for "dark art," last night we kayaked out onto Lake Monroe at dusk, and spent a few hours star-gazing. I know, we're delinquent parents taking the kids out so late what with school starting back up this week. But, but, it was the Perseid meteor shower and no moon! We couldn't resist, and it was lovely being out on the water in the total darkness, with "shooting stars" now and then. We didn't stay out until after midnight when the shower was to peak, but in the hours leading up to it, it was still lovely with some long streaks and many short.
When I did an MBA back in the dark ages of managementese, MBWA (management by walking around) was all the rage. But now I hear architects talking about the equivalent; walking the architecture talk around, but more, staying in touch with the hot buttons, the issues, the stories that are making their rounds... Looking for ideas, for challenges, and establishing a positive framing. Structural framing, yes, that too. But the way we pose the problem and/or solution, the way we frame it up verbally and visually. Actively understanding what the concerns are, for sometimes all that is required is re-framing the project, the goals, the strategies and approaches in a more helpful way, a way more people can get behind. And sometimes it is becoming aware of an emerging issue that requires priorities to be reshuffled, or new approaches to be sought. Keeping an "open door," being approachable in your cube, all that is well and good. Holding strategic conversations yes. But more, listening. Exploring. Asking questions. Informally, in casual interactions.
8/14/07: I try to get my kids to rely more on the all-important personal tool of reframing; of positioning something to ourselves in a way that we can be enthusiastic about it. Our attitude, the way we perceive something, the stories we tell ourselves about it, can make all the difference between getting immersed and having fun, and spending so much time crabbing that we create a self-fulfilling prophecy and don't have fun. As leaders, framing is a good part of what we do. One way to think about it is connected-dots, creating links between what people care about and the approach we are choosing.
I'm not comparing anyone else to my kids! I'm just saying that with kids, lessons often stand out in higher relief. They're simpler, or we try to communicate them more simply. And my kids are precocious in many ways—at Target my son said loudly (so all the back-to-school shoppers could hear): "Mom, you're ruining my quality of life!" So I told him that was the role of mothers everywhere, and kids usually learn this when they hit the teenage years, but he just had the misfortune of learning it earlier than most.
8/14/07 Consistency and Availability
Today I listened to Werner Vogels (Amazon CTO) QCon presentation on Availability and Consistency on the InfoQ website. I found it really worthwhile. He talked about Scalability Principles used at Amazon, and the CAP Theorem: out of availability, consistency and partitioning, you only get two. He also mentioned the "two pizza" principle at Amazon, which says that a team size can be no larger than the number of people you can feed with 2 pizzas. Which does not say anything about system size! It is just a sizing principle for teams, which are often, I gather, formed around specific services (end-to-end, including UI). I need to listen to it again and take notes. I have seen Werner called Amazon's chief architect, and CTO. I wonder, are the terms used interchangeably at Amazon? It certainly makes sense to me that the chief architect would be considered a C-level exec, especially in a technology innovation dependent company like Amazon.
8/14/07 Necessity is the Mother of Invention (Plato)
Vogels mentioned some productizable ops management tools they've developed at Amazon. I'm sure there is much more on the tools for mass-scale distribution and operational scalability that companies like Amazon, Google and Ebay are developing, that would give incumbents in the software development environment and operations management space a run for their money! Of course, the likes of IBM and Microsoft are onto this, and Microsoft is proving to be a leading player in industry innovation through close client partnering. I'm sure that this has been going on "forever"—at HP in the last millennium we partnered closely with client businesses in new product development, and even had client architects on our architecture teams for leading-edge development work we did collaboratively between HP Labs, HP divisions, and client businesses.
I think of that, and I think of the silos we've created where architects get handed "requirements documents" fait accompli, and I have to think that somewhere along the way, we got lost! One of the things that the Agile "movement" is bringing under the spotlight is the value of putting developers in direct contact with users, working together to figure out requirements. When an Agile project hits a high note, it is a highlight in the career lives of the developers on the team. But this is a shared experience of high performing teams, whether in engineering, or manufacturing, or marketing, etc. Often, it is the experience of cross-functional teams. So there are different ways to get into a team groove, but shared accountability for attaining a shared goal is paramount. Having our collective necks on the line for a feature (or service) delivery commitment creates this "flow." Cross-functional teams chartered with establishing strategic advantage through a combination of unique and compelling value propositions and a sound architecture can too. A lot depends on creating a shared goal, with leadership and strong teaming being central.
8/16/07 Stories, History and Humor
"Too often we use history like a drunk uses a lamp-post - for support rather than illumination."
Yes, Anecdote is an Australian company, with humor to match.
8/16/07 New Entrant on EA Blog block
Brad Meyers has just started an EA blog, reflecting on his experiences as a practicing enterprise architect. Do stop by and give him encouragement!
I've mentioned Nick Malik's Inside Architecture blog before, but thanks to Brad, revisited it today. There's so much out there in the blogosphere, but Malik's blog percolates up time and again as a useful discourse.
8/19/07 Context Matters
Yesterday Charlie Alfred posted an interesting blog entry titled "A Tale of 3 Product Types" that characterizes different types of product development and explores the impact on the product development process.
I think that identifying the dimensions of variability in development contexts is important and useful. It gets us to look at the ways that development projects are not all the same. Moreover, as Charlie indicates, because our organization and process is tuned up to where we have come from, it tends not to be particularly well suited to changes in paradigm driven by changes in competitive context and business strategy. So, in short, I'm happy to see Charlie is blogging again, and I enthusiastically recommend you cruise on over to visit and leave your calling card/comment when you do. Of course, I'm still thinking of something sensible to say, but you're less shy than I am.
Danielle Fafchamps, who had a PhD in Anthropology from Stanford, was a member of our Flexible Software Factory research team at HP Labs. She had no background in software development, but a background in studying tribal cultures; this meant she could see things that some of us thought "obvious" and not worth mentioning, as well as some things which we were so accustomed to we didn't see them clearly. Putting this together, she came up with a set of distinctions around organizing for reuse that were quite helpful. Her paper got a lot of attention at the time, but I suspect it has succumbed to layers of information silt from the general flood of formal and informal publications. At any rate, the article is "Organizational Factors and Reuse" published in IEEE Software, volume 11, Issue 5, September 1994.
Indeed, HelpMatch has to keep moving independent of specific individuals; we are all on different work rhythms due to our day jobs so there'll be ebb and flow in when any of us can contribute significantly. We should all feel empowered to contribute wherever and however we see fit.
We're in the ideation stage. We have a mission, we have the seeds of a vision. But we need to make the vision tangible. At our last meeting, Barry Crist suggested a "vision jam" to work on what HelpMatch will look like. I think that is still a good thing to do.
But I agree with James—we have to get to work. If we don't start to rough this up, we'll continue to have nothing other than a warm fuzzy sense of this being a good right thing to do.
So, what are some ideas on where to go from here? In addition to the vision jam, that is.
One suggestion has been to interview helpers like Lucious Newsome, to better understand how they create their personal help networks and match help to need, and get ideas on how to support them with information + social networking technology.
The important thing, I believe, is to get ideas on the table—doing that will stimulate more creative juices.
Here's a set of placeholders for some of the investigations/work we could start to dig into:
Differentiating value propositions
Architecturally Significant Requirements
There is no magical starting point. Someone (or a sub-team) could pick "help-needs match" and start to explore how that could work. Someone could pick "scam prevention" and start to explore there. In Indy group meetings, we started to chew on the notion of "sponsored networks" or trust networks, but much more needs to be done. We can interview people like Newsome and others. We could assess how far one could go using MySpace or Community Server in setting up a "help project."
The point is that by opening up to ideas, we'll both figure out what this should _not_ be, and what it should be. We don't know where all the pieces of the solution are going to come from, so we don't have perfect answers on where to look for them. But once we put some stakes in the ground, we can assess which stakes need to be moved; where we need to focus more work.
In some ways, this is incremental, leveraging existing ideas. And in many ways this can and should be quite novel. We should be open to invention, to innovation. So we should look where a "wheel could be and where it could not possibly be." (This is an allusion to "A Wheel on the School.")
I've been reading The Great Deluge and I'm reminded again that we need to give people ways to help:
"Ordinary citizens can't do much about a 150-mph wind or a 30-foot wave, other than get out of the way. But the Internet revolution teaches us that ordinary citizens can play a crucial role in creating nimble new channels of information that are more resilient than official channels."
- Johnson, quoted in Dion Hinchcliffe's Finding the Real Web 2.0, 11/15/05
And not just channels of information, but channels to co-ordinate help.
8/26/07 HelpMatch Board
Having put out some initial "feelers" in terms of a Board of Directors for HelpMatch, I have come to the conclusion that what we need first is not so much a business plan as a prototype or proof-of-concept. We need to make the ideas we've been feeling our way toward more tangible. I believe we need to pull together a Board of "heavy hitters," people with experience and a personal network that will pull in the kinds of support HelpMatch will need to scale. A vision pitch isn't enough for that. We need to be able to demo the vision. So, I propose we keep moving forward with just enough "planning" to get the vision hammered into an initial form.
8/26/07 The Great Deluge
The Great Deluge serves to remind us what happens when we think tomorrow can take care of itself. Another call to take heed today, and avert the peril we put our future in by taking responsible actions while we still have time, is coming from the US Comptroller General David Walker. As a nation, as state and city government, as companies, as individuals, we tend to postpone the discipline and sacrifices needed to "clean up"—to get control of our fiscal and environmental debts.
8/27/07 Hell to Serve Over
Daniel Stroe brought this quote to my attention, and I thought it might bring a smile to others, not just me. To Bernard Montgomery, Walter Bedell Smith once said:
"You may be great to serve under, difficult to serve alongside, but you sure are hell to serve over!"
Walter Bedell Smith had somewhat of a reputation for indelicacy and strong words, but I can see myself deserving to have been at the receiving end of that line at various points in my career. Perhaps that's why I like many of the stories, and even the title, of Useem's Leading Up: How to Lead Your Boss so You Both Win.
8/31/07 Katrina Reminder
August 29+Katrina reminds me that TWO years have gone by, and we have not enough to show for all the good intent to help people help! It is hard to do the big things demanded in our day jobs, and harder still to make progress on HelpMatch with what is left of our time and energy. This week my day job has taken every waking moment, and stolen into my sleep besides. But, I remain determined to wrestle time for HelpMatch and the Katrina-theme we've agreed (I think) to rough out over the next several days.
We need to figure out how to stop the HelpMatch wiki from getting trashed all the time. Who would defile a wiki like that? I took the liberty of "protecting" most of the Wiki pages so that only registered users can edit the page. I hope that will only deter vandals, and not anyone who really wants to help. But at this point, we're spending so much time putting pages back to where they were, that it inhibits forward progress. Oh, speaking of progress, I pulled two scenarios out of this journal and added them to "exploratory scenarios" under requirements. This is "low hanging fruit" from earlier journal entries, but I figure it all helps new-comers to HelpMatch catch up on some of the exploration that has been going on.
We need to rev up on the Katrina theme exploration. I'll have limited bandwidth this weekend, but I'll try to steal some time for HelpMatch from work/family/chores to pitch in and get some ideas flowing.
And the Red Cross needs our donations:
"We sit now in the peak of hurricane season… unfortunately with Red Cross financial reserves that are dangerously low, from responding to thousands of disasters in just the last year. I hope you can give as generously as you can, but whatever you can afford, I promise, will be needed, and it will make a difference."
Kathleen Loehr, Senior Vice President, American Red Cross
Feedback: If you want to rave about my journal, I can be reached using the obvious traceinthesand.com handle. If you want to rant, its email@example.com. Just kidding, 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 commit to using what you teach me, to convey it as best I can, help your lessons reach as far as I can spread them. I try to do this ethically, giving you credit whenever I can, but protecting confidentiality as a first priority.
Referencing journal entries: I figure at some point, someone, somewhere, is going to find something I've written worth linking to. I know, it's a long shot. But hey, it's a world full of different people, and if I write long enough, someone is going to stumbleUpon this Trace in the Sand and be delighted enough to want to tell someone else about it.
So, here's how: To link to a particular entry, I bookmark and
link to section titles from the sidebar, so you can copy the shortcut
(from the sidebar).