A Trace in the Sand

by Ruth Malan

 

 

 

 

October 2006

10/3/06 Call of the outdoors

Bloomington is looking really pretty with Fall upon us. This is the month when the work load is high while the call of the outdoors is strongest. Lovely colors, low humidity and perfect temperatures for good long hikes. This is the hardest month to strike that work-life balance: the camera is a more compelling companion than the computer today, but alas, I have work to do.

Since October has barely begun, by all means take a look back: September, August, July, June, May, April, March, February.

10/4/06 Leadership

While I was facilitating (I hesitate to say teaching; with 17 smart architects in the room it is part dance—under friendly fire—and part being taught!) the Software Architecture Workshop in Chicago a couple of weeks ago, an insight jelled. I have always believed in the importance of vision—the way we can make something happen if we set our minds to it, we just have to know what it is we are setting our minds to. And what we can achieve is all the greater if our communal mind, that great melting pot of all our individual inspiration and creativity, is set on achieving a shared vision. Also, I have always believed in the importance of being ethical—as a person, and as a leader.

I wrote about this in a late September post, but I'm still trying to articulate the insight sharply: as a technical leader we take on a big responsibility; the responsibility to lead to success. We tend to knock management hard when projects fail. But if we step up to the leadership plate, then we need to step up to and share this responsibility. So, we need to be confident that we are leading to a destination that will bring value to our community of followers—developers, managers, our business. To do this, we must deliver (differentiating) value to our customers. And we need to be confident that we are leading along a path that will make our community successful in delivering this value.

Being ethical in this context, to me, means not setting out to be self-serving. Rather it means to honorably, responsibly, seek out the value that is compelling to our community, build a shared vision, build passion and commitment to attaining the vision, and lead the decisions and the action that realizes the vision. It is not about power or dominating the will of others (as in, telling them what the system must be, how it must be organized, how to make it "perfect"). It is about leading to value delivery by facilitating the best joint effort of the community, creating the spaces in which individuals can make their best contribution to a system that will be successful and, in the process, building their own self-esteem and satisfaction with what they are spending the better part of their daily lives on.

10/4/06 Process as Differentiator

When I was managing the Team Fusion (next generation of Fusion, the OO analysis and design methodology) project at HP, we were gathering best practices in software development projects around HP. For the most part, architects and designers shared very freely with us what they were doing, what they believed made them successful; what they felt the pitfalls were. One architect stood out because she was upset that HP was sharing its best practices (by improving Fusion, which was a method open to all). She saw these as a clear differentiator for HP. We did too, but only if these great practices were spread from the few across the company. To do this, we knew we had to establish the  practices as leading practices, and the way to do that was to get external recognition. If Fusion was not seen as better than Booch (the OOA/D method, not the person) and OMT outside HP, then it would not be seen as better inside HP. Simple as that.

Most development organizations have process intolerance, so those that make headway with any kind of process discipline already have distinction. To make headway with a process that focuses on identifying clear, differentiating value, and then leading the best efforts of creative people to delivering this value in competitive timescales is a strategic differentiator. The beginning of this insight started long ago with Sue's recognition that a great process differentiates just as surely as innovative, great products differentiate—because a great process brings us greater certainty of creating great products in (more) predictable timeframes. And this insight was reinforced in a recent conversation with Charles Alfred, who made a similar point. Charlie is ahead though, because he has others on his executive management team aligned behind this recognition. But we have to start from where we are, recognizing ourselves that the process we use, and the process we ask our teams to pour themselves into, can make the difference between tail-spin and success.

10/4/06 Leadership and Process

So, as technical leaders we are on a crash-course if we have:

  • no vision: we are leading our faithful development community, but without a clear sense of where we are going

  • no shared vision: we think we are leading, but no-one is following

To lead, we must have some destination in mind—in our own mind, and in the communal mind. To establish a vision firmly in the communal mind, it must be a vision the community sees value in attaining; that is meaningful for them personally and as a community—the social organism that is the business. The tricky part is establishing a shared vision without having it be an unmercifully drawn-out process unto itself. To do this, leaders ask that the job of articulating the vision be delegated to them by the community. This is a job of trust, and a balancing act between participation and traction. Then it is a job of informing and influencing, inspiring and persuading.

Here, a nugget I mined from The Tipping Point is relevant: enthusiasm persuades. Daniel Stroe pointed out to me that

"Enthusiasm (Greek: enthousiasmos) originally meant inspiration or possession by a divine afflatus or by the presence of a God. Today it simply means intense enjoyment, interest or approval." (http://en.wikipedia.org/wiki/Enthusiasm)

The origin of the word is helpful, no matter what your belief system. And I realize that by enthusiasm I mean fervor, eagerness, zeal, warmth of feeling, intense excitement, even delight. Being positive, but not just that. Being energetically caught up; passionate.

Our own lively engagement with the vision is infectious. By the same token, if we are dispassionate, that travels through the community and they will not delegate leadership decisions to us.

This is actually a cogent point I've stumbled upon: that leadership is delegation in both directions. If we do not accept leadership, we are not delegating decisions to the leader but trying to keep control over those decisions instead. As architects and technical leaders, we're asking the development community to delegate over-arching decisions, decisions with systemic impact, to us, and we're delegating local decisions to smaller teams and individuals that own that scope. 

But back to the main track of this thought thread.

So then the question is, how do we get enthusiastic, how do we raise our own passion, that we might lead?

Well, this is related to vision and strategy. We have to have a sense that what we are doing is important, and that we are going about it the right way; in a way that will lead to success.

Which speaks to the importance of a process that will help us build a vision and strategy that we are excited and passionate about, because it will make a difference, be valued. And then we need to lead execution on the strategy, make architectural decisions that we have confidence in, and build confidence in our development community that we are on a good, right path to success. We have strived to make VAP that process.

I tend not to position the Visual Architecting Process (VAP) strongly, just letting the architect's experience motivate the process; letting the process speak for itself to the architect's own particular struggle points. But Steve commented that it only became clear to him two days into the workshop that I was indeed leading that group of (strong, individually-minded) architects. This made me realize again that it is hard to put blind faith in a leader. So I need to do a better job of positioning VAP right up front. It does remind me that this is another lesson I learned early on with Fusion. I was co-teaching (my first) Fusion workshop and one of the lead developers who had brought our team in to do the training pulled me aside and told me it was important to position Fusion as the leading methodology, something for his team to be excited about and get on board. We were HP to the core. HP products just are great. You expect that. You don't expect HP engineers to tell you that! We weren't doing anything to sell Fusion. We just expected the design team to expect that, trust that it was so. And here I am, still doing the same thing. And what is worse, I am very quick to tell architects that their architecture decisions will not sell themselves. They have to advocate their decisions. We have to advocate VAP. Well, I haven't been entirely remiss on this point, but I have tended to do it from behind, as it were; letting the realizations percolate up, rather than selling them upfront.

Some learning is single-event learning—and that event need not even be 1st-hand. I learned that you should not put your head close to a candle from my sister (no real damage, but the smell of burned hair is etched in my memory). None in my family ever repeated that mistake. And hopefully my children won't either. Some learning is multi-event learning. I tell my kids that the mark of a smart person is not repeating mistakes. Apparently I'm not all that smart!

So, I'll try to do better, to be more clear that I am leading by asking architects to delegate to me the responsibility to pull together just-enough process, not less, and not more, for good, right and successful architectures, and leading by delegating to architects the decisions that will in fact make their architectures good, right and successful!  At least, my vision is compelling to me and to you, I think. I am on this path to help architects create and sustain great architectures—great by the only measure that makes sense: they deliver value.

And while you're reading on the topic of leadership and responsibility, George Ambler has another great post titled "How Leaders Take Responsibility" (9/11/06). Remember, if you want to work through others to get big things done, you are asking them to delegate to you the responsibility for where they are going, and for charting an effective course to get there. In turn, you are asking them to take on responsibility for playing their role as contributors well. These responsibilities are interdependent. But it is your responsibility to inspire and influence, and guide to success—remembering that in "investigation" success can mean canceling a project that has no reasonable chance of success, because the value is too low or the risks too high.

10/5/06 Pursuing the art of persuasion

The sheer wonder, the joy, of working with architects, is that I get to interact with people who shine; smart, creative, investigative, multi-dimensional people. People who lead me. So, thanks to Rishi Khullar for slides and Keith Frampton for more system thinking papers and pointers. And, thanks again to Daniel Stroe—this time for the Greek word logos. Indeed, a deep pool of a word; rewarding to dive into. In engineering, we tend to use and appeal to logic as our principal tool for persuasion; logos, standing on the shoulders of ethos. We tend to eschew pathos, the appeal to the emotions; we neglect enthusiasm, the importance of building it in ourselves that it may light in others; we neglect to tell stories that connect personally, appealing to the common history and aspirations of those we would persuade.  But Daniel pointed out that logos is layered with meaning. As architects, we seek the underlying order, the logos, not just the logic. I'm eager to learn what else it means.

On the subject of persuasion, there's Gladwell's triad for infections of epidemic scale: connector, maven, salesman (The Tipping Point). Alternatively put: relationship builders creating conduits for persuasion, knowledge that imbues the message with meaningful value, and the emotive power of the carrier. Overlapping with, but importantly extending the triad of rhetoric: logos, ethos and pathos.

Gladwell also makes the point that the message has to be sticky. This has two aspects: the message must be compelling but the environment also must be receptive—a surface that the message will stick to. Egos so bloated they jam closed the doors to the mind, make for a troublesome, unsticky surface, I do acknowledge. I took this picture in Alaska (hurriedly, while driving past). It doesn't help deal with the puffed up people who impede us, but it's worth a smile. And that by itself is worthwhile. Infectious. A light that lights in others.

(The sign says: Knowledge humbles great people, astonishes common people and puffs up little people.)

Persuasion, influence, is at issue because we want to accomplish something but there is organizational impedance that prevents us. It is not that we do not have a vision; it is that we can't simply move minds into alignment with our vision. Good people act in more, or less, helpful ways depending on their perception of the context. If we are part of their context, we can help shift how they see that context. Provided that we stay resourceful.

That is why we focus so much on context leading up to vision and strategy. Not only do we need to build a shared sense of where to get to, but a sense of the context that behooves us getting there—our history, our present context, and the forces that will reshape our context. The really neat thing is that we don't place ourselves in the forefront, trying to persuade and otherwise bludgeon. Simply getting people in the room to talk about context, their view of it, and others view of it, builds a sense that this view, this context, is shared, and more than that, it has its comfort and its motivating force. And yes, by being careful about inviting key individuals with various important perspectives, we play a shaping role in creating a valid shared context view.  If the vision that comes out of this sense of our shared (business or project) context and the forces that will reshape it, and the opportunities it opens up, is not the vision we hold, then we need to take a hard look at ourselves.

It is hard to be at the innovative edge. Timing is key: there are visions whose time has come and the organization is ready to make it so; there are visions whose time has come but the organization is myopic, focused on the short-term, and does not see it; and there are visions that the market is not quite ready for. The third will be claimed in the case of the second. So, are we pushing for the third, or do we need to get the organization to take in the long view?

And it is hard to try, and be redirected from our vision. To vest ourselves in finding the best outcome for our business, to try to shoulder the changes that will bring it to this outcome, and face resistance in all its guises, from loud ego to fearful risk aversion, hurts! The architects in the last workshop asked how many times we can do this. This experience of trying and being impeded is so common, they're asking how many times one can stand it! Yes, it calls for resilience, indomitable will; enthusiasm and enthusiasmos.

We can be creative in a small corner of our world, but if we want to do big things, we needs must do them through others. To do that we take on the challenge of leadership. The challenge, the responsibility, and the reward; the challenge, the rebuffs, the energy it takes to build again, and again, enthusiasm in ourselves and others. We need to take heart, we're in the position we're in because we are valued. We can't let the rebuffs quell our spirit.

Companies inevitably become loaded with inertial forces that the architect has to battle to deliver differentiation through innovation. But innovation is the rewarding work of this age we are so fortunate to live in.

Architect after architect asks how we become better at persuading, or as variously put, influencing. So this was a primary theme of my first month writing in this journal. And it continues to be a not-yet-satisfied quest. But thank you  Daniel for illuminating the passage.

10/6/06 Booch is Back!

Between work and a day or two off to host Gerrit Muller and his wonderful wife, I haven't done much architectural surfing this past couple of weeks. But I did stop by Booch's Blog (too early this morning) and was relieved to find he is back at it! He quoted from Foote and Yoder's Big Ball of Mud pattern. It's a good place to (re)start! He means so much to the software field, changed it, stands to change it paradigmatically again. I'm so happy he's back!

10/6/06 Balancing Agility and Discipline

David Thomas brought Boehm and Turner's Balancing Agility and Discipline: A Guide for the Perplexed book to my attention. David emailed:

"Software Architecture happens in a context; a common problem with context is assuming that a process can replace people, or that people can ignore process. Boehm and Turner do a good job of illustrating the strengths and weaknesses of various methodologies.

This is not core software architecture content, but rather about setting the context for that work to occur."

Thanks David.

10/6/06 Still Beating that Leadership Drum!

I was working away on a set of architecturally significant quality statements for a project, and this investment image flashed by and I had to grab at it and jot it down: We ask our community to vest themselves in achieving the vision we advocate; what is the ROI we hold out? Achieving the vision, and with each success along the path, fuel for self-esteem. Yes, even puffed up Cheshire cat egos need to be stroked—too. And, because failure is so devastating to self-esteem, we need to avoid that emotional crash by being responsible in the vision we hold. Responsible in creating a stretch that the heated competitive market demands, responsible in creating a stretch that will not shear our organizational will.

Most of the architects I work with feel devastatingly at the mercy of management; that success—or some variant of it—is under management control, not that of the architect. But management is in the SAME situation! They feel devastatingly at the mercy of the engineering community! This is a partnership. A dual responsibility. So, start Leading Up, too. And embrace this responsibility for success, even if, at times, success simply means the way we interpret early failure.

Talking about architects and authority, in Chicago I admitted that I thought that at least as a parent I would get to tell people what to do, and they would do it. And every day I am disabused of this notion (talk about multi-event learning; but hope springs eternal). Even if we have positional authority, and as architects we generally don't, we still don't get to tell people what to do—and have them do it, at any rate. We get to invite them, inspire and incent them, communicate urgent context to them. Yes, with positional authority we can threaten and bully and maybe get grudging compliance—where compliance is visible. But ... well, you're smart, you got the point long before I did. Back to work on those qualities!

10/6/06 Value, Strategy and Architecture

An interaction with Charlie Alfred had me returning to his superb papers on Product Strategy and Architecture, and Architecture Challenges (sorry folk, this is another one of those places where you have to sign up to download the paper, but it is worthwhile). When I first read them, I mentally checked off all the ways his work is synergistic with ours, all the way to common metaphors and images between us. For the record, it is worth mentioning that our metaphors and our approach reach back to the mid-90's, in terms of formalized content; further, of course, in the experiences that bred the insights. And for the record, on re-reading Charlie's papers, I see ways to improve what we do too. So you will see an influence. I hope Charlie will see this leverage as a compliment.

10/7/06 One Man Can Change the World

Stories inspire. Some people are more susceptible to inspiration. So, find those that are. Seed a network of proponents who take on your vision. This is very much a John Wood model.

John Wood's book, Leaving Microsoft to Change the World, is a great, I cannot emphasize this enough, source of stories. Some are stories for us to personally take to heart, change our life. And some are stories you may want to share. If you don't come away with at least something that impacts you in a profound way, that makes you do something differently, then I'll be frank, I'm worried you're sleeping through this life, and I'm honestly surprised you're reading this! So there you have it. In people, unlike magnets, likes attract; at least on some level there must be common ground. Speaking of which, for as many times as John Wood mentions his sorrow at his single state, I'm sure he now has the opposite problem, fending off all who would relieve him of his loneliness.

So what stories do I especially want to highlight? I suppose I'm a LIFO kind of person (or, like a bulldog, once I seize on something I have a bad habit of not letting it go), and given my current tack on the responsibility of leaders, I find the story of loyalty (starting on p. 145) useful. Since, as architects, we lead from the middle, loyalty for us is "up," across and "down" (in traditional organizational structure terms). We need to be loyal, and set a good example of being loyal "up" and "across," and we need to be loyal to our followers. The ethics of leadership. And yet another balancing act to perform.

Since John Wood is telling his own story, and since one tends to portray oneself in a positive way (even with a few well-chosen chinks that expose the frailty of our human condition, and mark us a fellow man), let me hasten to add one point John mentions in an off-hand way: through the beginning and at least years into, and in spite of the growth of, Room to Read, John Wood was not drawing a salary, but living off his savings from his Microsoft years. So, truly a great and rare man. Worth your attention; well, sorry, worth mine. You will decide what is worth yours, but do at least look into it. Of course, the day after I bought my copy at Barnes and Noble it got put on the "20% off new releases" pile... so you could look for it there, if you want it even before Amazon or GiveLine can get it to you.

Well, I just had to say that. Now a gleaming Fall day beckons, and then, more work to focus on.

Bother, I'm packing up, shutting down, and I remember a John Wood story that my bulldog brain is still dragging along. So, to free me that I might turn my lens upon the Fall: when bloated egos turn deaf ears on you, John has a story you might take heart in: it begins on p.159.

Ok, I'm not totally smitten with this book, or the persona it presents (though offered a chance to write the script for the movie, and au revoir architecture!). John Wood is, after-all, human. Chinks, some deliberate, some I think not. Oh well, I guess John would write the script; he is a superb writer. Wouldn't that be something? To be author of one's life and write the script—twice! You'd get to say all the clever things you wished you'd said the first time through. Never make a fool of yourself with a too-hurried email... All that. Well I suppose, one solution is to never write an email. There's a thought.

And just in case you'd somehow missed it, there's the Madison story (which you can download from Cutter for the price of your contact information).

10/7/06 Whose Vision?

I get challenged on the question of vision. Is it management's responsibility to come up with the vision, or the architect's? Well, this is my push-back: the architect needs to be sure there is one. Remember: no vision, no destination, a random walk. So, if management has established a shared vision, and we have a shared understanding of this vision in terms of what it means for the technical community, great! Job done; get to work on architectural strategy. Still, I can't tell you how many projects I encounter where the technical people feel there is no vision. So, is there really no vision, or no vision the technical people relate to? Either way, the architect has an important leadership role to play. And moreover, even if management "leads" on the vision thing, the vision will be the better for the architects involvement. The architect is (or should be) responsible for the goodness of the architecture (value delivered, structural integrity and resilience under change) as it is sustained through the incarnations it will take as market changes and internal forces impinge upon it. The project manager is responsible for each release, one release at a time. There is a tension there.

10/7/06 Qualities

Ok, enough of that fluffy stuff (I'm going to have to get heavier on that editing hand before those entries can be allowed to rest in the internet ether).  Digging around in what others are doing in the qualities space, I'm (again, in some cases) looking at:

 

10/8/06 Related work on (architecturally significant) qualities

The following have implications for, or include, qualities statements:

Work being done on Architecture Mechanisms (for achieving qualities):

10/8/06 Leaders Set The Tone

Well, it seems that the harder my left brain works, the more likely it is my right brain will throw out a teaser to grab some of my attention. So, my right brain is still at work on leadership, quality of an architect, while my left brain is teasing out a better (set of) quality (of service) statement for availability, quality of a system. When I'm done, I'll translate these over to HelpMatch, so I can share a piece of that work. But this is the anecdote that popped up as relevant to the leadership thread:

I was at the Barnes and Noble cafe (where I go to force myself "out-of-the-box"—dilate the blood vessels in the brain, change context), and the IU student-aged assistant behind the counter greeted the elderly lady before me by name—Mary. Then he asked her how she was doing. "I'm having a bad day," she said. That to me would be a sure signal to stop right there, but the young man probed, "Oh, what's wrong today?" ... or something along those lines. And he was regaled with everything that went wrong, from getting up too early and going back to bed for a nap and... Gosh, now at Starbucks you hear a recipe of friendly lines coded up to make customers feel "special." But I got no feeling of recipe recitation here. I was impressed. A young man, talking in a caring way to an elderly woman he's not related to. I mean no sexism or ageism here; I mean only to point to a gap in their social worlds. (I'm getting to the leadership point, really I am.) So, settling into my work, I hear the cafe manager arrive and buoyantly greet Mary by name, and ask her how she's doing. She got the same short answer. The same signal that a long (and, to most, boring) story lay in store. Yet she probed for more.

And then it clicked. This manager is leading her crew, setting a tone of caring, in a personal and personable way, for customers. I saw the broader pattern in her interactions, and the way, by example, it shaped the interactions of her staff.

This is a point I've been struggling to make, and right there is a story that makes the point (to me, anyway): Leaders set the tone.

Yes, there may be times where you have to alter the tone, change the pace. There are times in the architecting process when you need to allow, even encourage, divergence, and times when you need to facilitate, even drive, to convergence; exploration first, then leading to decisions, action. Over the course of the project, the tone you set may change, but you set the tone. By example, by principle (and a list of other things my up-since-5am brain is running dry on)...

Balmer boomingly demanding not only do you get great results, but you know exactly how good they are. Balmer knowing what results you got, even in your personal endeavor. Balmer realizing you, a person, need to solve the logistics of a shower after you're shared a run with him. (Yes, now I'm referring to the Steve Balmer chapter that includes the loyalty piece I recommended you read in Leaving Microsoft to Change the World.)

I mention Balmer because, though I could not thrive in that public dressing-down kind of environment he creates, I also do not mean to convey that I think architects need to be zealously happy, rah-rah cheerleaders, or anything like that! But at the same time, I do want to emphasize that as a leader you need to be self-aware, and aware of how your self impacts others. Your attitude shapes. It shapes expectations, behaviors (and a list of other things...). If you are excited by possibility, passionate, that conveys—in more than one sense.

10/16/06 Foresight and wisdom

As architects, we need to be good at scanning the environment, looking for opportunities to strengthen our vision and strategy with innovative and meaningful value propositions, and identifying threats that raise architectural risks or challenges so that we can address them in good time.

If our business leadership sees our revenues doubling over the next few years, we need to be in front of that demand deluge and ramp up the IT systems that support all aspects of the business operations to enable this kind of growth. As IT architects, we must be out there educating our business management, helping them understanding where we need to invest in systems and processes to support the kind of responsiveness and scaling that this anticipated growth will necessitate.

If IT isn't ready, the business isn't ready. If the business isn't ready, customers will go somewhere else! At that point, it simply isn't going to be effective to insist that IT be better aligned with the business. The business needs to invest ahead, to position IT to be aligned with where the business leadership are taking the business. We have to invest ahead to keep innovative products in the pipe; we have to invest ahead to ready the business to deal with the growth we see these products bringing.

We don't have a crystal ball, but we rely heavily on self-fulfilling prophecy. We create demand by understanding customer values and concerns, innovating and creating products that open and lead markets, and then we need to have all the pieces in place to fill that demand stream, and to scale as it grows. This is why architectural thinking is not just reactive, dealing with the heat we are in. It is about strategic thinking, getting out of the "now" trap, getting out front and leading.

We need both foresight in innovative market-space creation, and wisdom in being ready to meet the market demand we stimulate. Wisdom: not just knowledge, but lessons learned informing our action.

10/16/06 Booch is (Definitely) Back!

In Texas last week, I observed that for a good many organizations launching into SOA, architecture is at the end, just like the A in SOA. Booch is dealing eloquently with the subject of the A in SOA, and his recent post is worth a read. It's good to see him back in the saddle again.

10/16/06 Ben Ponne and GEAO

Ben Ponne is the director and a key founder of GEAO (the Global Enterprise Architecture Organisation). Ben has been collaborating with us, and encouraging me along, on enhancing and tailoring the Architect Competency Framework to the EA space. He has passed along a number of good papers that will show up in the references to the Framework that will be published in the next issue of GEAO's Journal.

Anyway, Ben has been helping to draw more attention to GEAO through a number of conferences in Asia-Pacific, and some of his slide sets are on the GEAO web site. Ben is a very smart, creative and remarkable architect. He has and will shape this field of Enterprise Architecture; he is passionate about it and pours his energy, intelligence and experience into it.

10/17/06 Anshu's Landed in the Blogosphere

Another architect has ventured to open up his discussion and experience to the blogosphere. You'll find Anshu Gaind blogging at http://on-architecture.blogspot.com/. He's already succinctly expressed several key insights for the architect role and its relationship to other roles. Good job, Anshu!

10/17/06 Telecommute!

My September 8th post (Crowdsourcing: Working from Home) was prescient: see "Telecommuting hits the Corporate Mainstream," Management Issues, October 4, 2006.

10/19/06 Benefiting from the Long Tail

Last week, I found two of my old Jane Olivor favorites on CD at Barnes and Noble. I bought one. I found I still really like it, so this week I went back to get the other. This time they had every Jane Olivor release I know of (and Tuck and Patti's "Gift of Love" which I somehow took 2 years to get around to finding).

So, is Barnes and Noble watching demand in the long tail and stocking accordingly? I'd like to think so. Business events down to the smallest detail. Yes, now you're getting to know me, and you had to know there'd be an architecturally-relevant point in there! IT does matter (and reliably great lattes matter too)! And IT architects need to be watching for where it can and should matter.

There is this perception that Amazon and the like can better serve the long tail. Physical storefronts have to have physical inventory which costs both in terms of the inventory (actual cost) and shelf space (opportunity cost). Every long tail choice made, is a choice to not stock another product, mainstream or long tail. Tracking purchase patterns and making stocking decisions—analogous to technical trading, in some sense—becomes a way to differentiate. Building the systems to find the patterns, decide on the event triggers, and then trigger the fulfillment system that gets on-demand inventory out to the stores quickly takes a powerful team of business and technical innovators working together. Yes, the stuff that differentiates—even in tough retail businesses where a 1% profit margin means you're doing well!

So, if your business people have you cast as the alpha geek, remember, you can take charge of the impression you create, even if you have to fight the tendency to stereotype. We need to be able to speak in terms that are meaningful to the business. This is not just language. This is insight. Understanding what matters to the business, and being able to speak from that frame of reference, rather than the technical frame, in the business conversation. (And we need to be able to switch language, talk in technical terms and from an understanding of technical implications, with the technical community.) So, we need to work on gaining insight into how to compete, how to differentiate, how to get up-front in marketplace and lead, even as we try to build credibility and gain access to the business conversations that will give us this insight!

We're not helplessly caught in a catch-22. It's not only Ghosn, and CEO's of that ilk, that need to get out into the business and customer space. If he can carve out the time to spend at Nissan dealerships, what excuse can we possibly come up with? And you've already subscribed to Harvard Business Review, right? right? That's 101 for architects. Get on it! Now, you have to actually read the thing! Well, I generally find a (manageably small) set of articles in each HBR issue very pertinent to leadership, strategy, organizational politics or, from time to time, consulting. Oops, I have at least two issues to catch up on... Oh well, there's life and there's life. We live it somewhere in the middle, between what we hope for ourselves and what external factors allow. Pressures and priorities. But if we always let our technical side dictate where we focus, then we must expect to reap the seeds we sow; hmm, technical seeds grow technical crops. Well, something like that...

10/20/06 Software Architecture Workshop near Washington DC

The Software Architecture Workshop in Arlington, VA still has 5 seats open. Naturally, I'd like to see those fill, so much obliged if you can recommend the class to anyone you know who needs to "get" that architecture is as much about leading to value delivery as it is about solving the top technical challenges that are most visible right now. And then there's the small matter of a process that helps you be successful. I've been doing this architecture consulting and training thing for more than a decade, so I've seen architects move through their careers from promising, aspiring tech leads to chief architects and CTO's in the product space, and enterprise architects and CIO's in the IT space. These chief architects now strongly champion our work in their companies, and this is both rewarding and confirming.

10/23/06 Confessions of a Trusted Counselor

I was scanning about in my memory for articles relevant to the consulting domain of architect competency and I remembered an article by David Nadler titled "Confessions of a Trusted Counselor." I had to dig back through a year's issues, but found it in the September 2005 issue of Harvard Business Review. Nadler talks from his experiences as consultant to CEO's and has some take-aways for architects consulting "up."

10/24/06 Seize the Day

I took the morning off. Mid-week. I went walking in the woods. Fall colors are peaking, and it was the only clear day in more than a week, with more rain coming: a moment to be seized or lost. That's the rolling forested hills of southern Indiana for you. Glory, and rain. It leaves plenty of time to work! And exceptional days to make the spirit soar. Days without parallel.

10/25/06 That Vision Thing 

I gathered up various fragments from writing over the past few weeks into a Blog post titled "That Vision Thing." Nothing new if you've been reading this journal serially. But it does draw the thread together.

10/25/06 Who Does What When?

An interaction with a client who is working on development lifecycle and roles, prompted me to try to (more succinctly than I'm apt to) capture why the architect needs to be involved (I urge lead) in the front end:

The Init/Commit and architecture requirements deliverables are important for the architect to play a (lead) role in. It becomes very expensive to live with these early decisions when they are made without architectural insight. Most architects get this importance. They also have a hard time convincing their organizations of it. So in practice, there is a lot of variance here as regards who does what when.

If you formalize the business analyst role as the role that makes requirements decisions (implicitly or explicitly), then you make it very hard for the architect to have influence early, when expectations are being shaped and value versus cost and architectural challenge is determined. Early decisions limit later decisions. Architecturally significant early decisions must be made by the architect. The early engagement of the architect is essential. This means the architect is partnering with business (or requirements) analysts and users to shape the requirements, and with management, to scope the system.

10/25/06 Charlie's Value Modeling Blog 

Well, this evening I discovered (via some degree of indirection that ultimately is attributable to Charlie's humility) that Charlie Alfred has a blog. Serendipitously, Charlie's latest post is on context, which is a central theme of my post today.

So, there you have it, context is important. And different contexts are important. Your business context, the various contexts your product will fit into, the value context and the system context that places constraints on it, even the context your components or services fit into. Context in context! 

10/25/06 Stories from a Day in Your Life 

I'm collecting stories for the framing around an Enterprise Architect paper. If you are an enterprise architect (by title or by job responsibility), I'd love it if you could email me a story/scenario (or 2 or 3 or...) from a "typical" day in your architect life, to share in the GEAO Journal article we're working on with Ben Ponne. I'm looking for some real stories (in your words) that help show why the architect needs diverse experience and skills, including, but not necessarily limited to, leadership, strategy, consulting, org politics and technical content/design areas.

I can, but don't have to, mention your company by name (if this would be a show-stopper with your legal folk). I'd like to mention your name, but don't have to either. I do these things in a positive way, and it would be hard for organizations to get such good press even if they were to pay for it... but it also slows things down to have the legal beagles in the loop, and I'm not looking for any slow-down.

So, I hope you can think of a good story (or 2 or 3…) that illustrates the pulls and strains walking the line between strategy and technical details, business and technology, creative aspects, political aspects, whatever, in a day in your life! Just some vignette (or 2 or 3…) that illustrates the demands placed on you, the kind of things you have to pay attention to and be good at…

I need this... yesterday! or better still, last month! But if you can manage the miracle of getting a story (or 2 or 3...) to me this week, that would be stupendous!

10/27/06 Time for Fun 

As both my son and I get more ingenious about morning fun (my son insists he can't go to school if he hasn't had fun yet), he reached a new high in justifying procrastinating on getting ready for school: "I have to have enough time to notice I'm having fun."

Isn't that great? Noticing that we're not noticing is a step toward realizing how much fun we really have.

10/27/06 Design and Reuse Center for SoC 

Working through a piece of analysis, I came across the Design and Reuse site for IP based SoC design, and got stuck there for a few hours! If you're embedded in the SoC space, I expect you're tracking this site.

And Daniel Stroe pointed me to "The right video architecture can make all the difference" by Ron Wilson, Executive Editor, EDN, 9/1/2006. This article explores differentiation and architectural choices. I join Daniel in recommending it.

10/28/06 Added Links 

I updated the Architect Skills: Blogs, Essays and Websites page on the Bredemeyer Resources for Architects website. Thanks to Daniel for pointers. I also added a link to Arnon's blog on the Dr. Dobbs portal site, which I've linked to in various other places but had somehow neglected to link to in the main section of this page.

10/28/06 Gus Grissom 

Today we visited the Virgil ("Gus") Grissom museum in Mitchell, IN, where Gus grew up. There I learned that Gus was very involved in the the design of both the Gemini and the Apollo I spacecraft. He was hard-working, thorough and demanding—the ultimate partnership between the "business user" whose neck is on the line with the system, and the system engineers designing and building the system! Wikipedia has this to say:

"Because of his Mercury experience, Grissom, one of the smaller astronauts, was very close to the McDonnell engineers and technicians who built the Gemini capsule, and the first three spacecraft were designed around him. The spacecraft was familiarly dubbed the "GUSMOBILE." By July 1963 NASA had discovered that 14 of the 16 astronauts could not be fitted into the cabin as designed, and all later cockpits had to be modified."

I think this is a good story for Charlie Alfred and his value contexts.

The Gus Grissom story is also a great story of an American hero whose bravery and honesty was called into question (over the blown hatch), though he was finally vindicated just years ago.

And Kennedy's quote still echoes a reminder to us architects-as-leaders that leaders inspire with great visions and great rhetoric: "We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard." It is said that Kennedy's challenge inspired Grissom and he was determined to go to the moon. He ultimately gave his life to this endeavor, but in important ways moved the space program forward.

10/29/06 Leaving Microsoft (again...) 

Speaking of rhetoric, John Wood has a great story, and it, too, is related to NASA. I'm referring to p.236. About to take Room to Read into Sri Lanka following the tsunami, an aggressive act that made some on his team fearful of over-reaching, John sought to inspire and reassure them. John made a handout for each team member with a picture of the Ed Harris character from the Apollo 13 movie, with the words: "With all due respect, gentlemen, I believe this will be NASA's finest hour."

Now, how many of us would do that? Oh, it's all very well for John Wood; at Microsoft he headed up regional sales after all. It would never work for us, not with a bunch of engineers... would it? I have to tell you, every time I work with clients, I feel I walk to the very brink of my capacity to be audacious. But people are kind. They see you take a risk, and they step up to the plate and take it with you. It is not about being flamboyant; it is about calling on our teams to rise to a challenge with us. If we worry about being vulnerable, seeming foolish, then we will lose the chance to rally our team precisely when we need to show them that stretching ourselves will pay off.

As inspiring movies scenes go, I like the barroom scene from A Beautiful Mind—this is a great one to use when you're trying to inspire product family development or EA work (though you might want to check with any woman architects on your team first). Finding the Nash Equilibrium, of course, is central to product family development!

A scene that impacted the way I do things comes from Saving Private Ryan. When the team is rebelling, and with a gun to his head, the character Tom Hanks plays tells his personal story. It diffuses the tension and inspires the team to go on. Personal stories that explain our genuine and human motives, inspire. We may think that they will leave us vulnerable, but taking this risk puts the listener in the situation where they must either be a heel or rise to the challenge we put to them.

So, next time you need to rally your team, do something audacious; find a story (your own, a movie scene, something you read or heard about) that will inspire your team to stretch with you. If you end up with egg on your face, you can throw it right on at me. But, I have confidence in confidence alone!

Why yes, that's another movie reference, and it sounds much better in the Julie Andrews rendition! The Sound of Music opens in London's West End on November 14th. My allusion to a childhood favorite will not be so recondite in Britain, where the producers (I assume) cleverly garnered attention for the production by holding a competition on TV for Maria!

Oh, and if you have any good movie scenes you use to make points about architecture/architecting/architects, please do tell me.

10/29/06 Hedge Hogging 

Dana is taking care that I don't become horribly unidimensional, in this case reading bits and pieces of Hedge Hogging to me. I have to say, it is well-written and quite funny! My kids are also doing their part, and we're reading A View from Saturday together. It is very funny in an intellectual sort of way—so I have to stop when they don't laugh and explain, and then my son, who has airplane-loads of people in guffaws every time he watches a cartoon on a trans-Atlantic flight, bursts into delicious giggles.

Meanwhile, I'm reading Controlling Design Variants: Modular Product Platforms by Anna Ericson and Gunnar Erixon, and so far I haven't chuckled or spilled a single tear (actually, I have to confess, Leaving Microsoft had a completely singular effect on me for I'm totally not a drippy sort of person) but I do like it! It is about product platforms rather than software product lines; still, I find it useful. I must have mentioned, but just in case I didn't, or you missed it, another product-focused book I like is Karl Ulrich and Stephen Eppinger's Product Design and Development. It is now in it's 3rd edition (2004). Modularity is a key theme; I scribbled a bit on the subject in my Trek blog piece. I guess no-one else thinks it's important in the software space, judging by the silence on the topic. Which reminds me, I'm very grateful to Charlie Alfred for commenting on my "vision thing" blog piece. 

10/29/06 Mr. Magoo

Last Christmas, Santa gave my son a Roomba Vacuuming Robot, which we promptly dubbed "Mr. Magoo." Where, oh where, you sigh, is the architecture point in this one? Well, I just thought it would be fun to write about, so there isn't one. Just kidding. Reading the case study in Controlling Design Variants, it occurred to me that if the Roomba architects had taken "vacuum" as a requirement, they might still be at the design board. Roomba cleans with brushes, not suction. There is a technical solution to "remove dust (and pet hair)" that is belied by "vacuum" that would have been overly constraining if imposed as a functional requirement (as is apt to happen in IT). Ericsson and Erixon have a nice diagram on p.47, where functional requirements are translated to technical solution, which is translated to functional requirements, and in turn to technical solutions. This picture makes it quite clear that the architect needs to be actively involved from the get-go.

So how did Santa get to have a Roomba on the list? An enterprise architect friend who has dogs recommended it to me. I figured kids and dogs create generally the same kinds of requirements when it comes to daily cleaning; the main difference is that with (only) dogs, you wouldn't want to explore the contents of Mr. Magoo's tummy after he has done a sweep through the family room; with kids, you do have to empty Mr. Magoo's tummy onto a plate first, to find all the scarce tiny Lego pieces, Battleship game pieces, that sort of thing, that Mr. Magoo gobbled up in his adventures under the sofa. I'm already working on my son to put the Scooba (mopping version) onto this year's Christmas list! Yes, iRobot has this nice little product line of home cleaning robots... and PackBots now serving in Iraq!

"Mr. Magoo" has my son rolling on the floor in laughter at his blind antics; slapstick never was so good! Now, you might want to look into iRobot stock, given that I've taken on the task of marketing for them! Just think, my talent at spin, at no charge! (The vacuum imagery there was too good to resist.) But then again, both the Santa and the son in my household are atypical. I wonder where that comes from? Ok, that one's rhetorical.

So, here's the test: what did you find in the last two paragraphs that is architecturally significant? Now, I find relevant snippets even in Dr. Doolittle (at least, there's this great little piece on leadership that I dog-eared and meant to return to). And I think it would be a stretch to find much of significance in the last two paragraphs. But I do want to say this. As architects, we do well to think like (and work closely with) marketing when we're working the value proposition/value context angle. Roomba's market is not just shedding-dog-families, although they are talking up Roomba and recommending it to their friends. So, what are our market segments? What are the likely and unlikely ways this product will be used, and what will create delight (Roomba needs video footage, for the giggles alone will sell it) that will get this product sold by its users, cause it to take flame and spread through blogs and word-of-mouth? If you're thinking this is not in your job description as an architect, you may be right (did you write it in?). But who better to be thinking this through, than the person (or team) who is shaping the system? I said this before (on my blog):

To compete today, we have to be differentiated in customers’ perception. And in today’s complex world filled with overwhelming choice, perception is shaped by subjective experience, stories, feelings—not a rationalized conjoint analysis of the feature set. We architects need to take this into account; great software, that is software that makes products and services great, is not just a technical matter any more. We have to integrate customer experience into our value-cost strategy and design decisions.

10/29/06 This just in from Mexico

Thank you Felix for:

"I was invited to be part of the architects team, and I am searching for information and your site is one of the best I found; you have many useful documents. Congratulations!!"

Felix is referring to the Bredemeyer Resources for Architects website, of course. The site gets between 1,400 and 2,100 unique visitors (around 10,000 hits) per day, yet this is the first compliment in several weeks, so you'll see why the little bit of trouble it takes to say something nice gets my attention; indeed, makes my day! 

10/31/06 Happy Halloween!

Dana estimates we had 50 trick-or-treaters coming by our house; I estimate 200 (carloads of kids get brought into our safe middle-of-the-road neighborhood where there's a big welcome, lots of good candy and the houses are not a trek apart). Splitting the difference, I suppose it was about 125. Dana did the rounds with our kids and I stayed at the door. Yes, for once, Dana was home for Halloween, because a few months ago a caring client refused to buy his time on this great family occasion, reminding me to block it off this year. Every year we get more trick-or-treaters, and every year we over-predict by about 4lbs of candy (so the teenagers who come at the end get bag loads). 

My son, on returning home with his candy, promptly started handing that out too. Next year, he declared, he is going to do things in reverse: start out with a full bag of candy and hand it out as he does his round of the neighborhood. He's a path-blazer; not bound by convention. Two Halloween's ago (when he was 6) he went as Lincoln (totally his initiative; he was on a history kick). Last year he went as a great Northern Pike—a stretch for me on the costume front (especially since he gave me barely two days notice), but I pulled it off, save for the top fin which I hadn't thought through and it flopped over. Seeing the picture (Dana proudly had it as the background on his laptop this month), a Texas group of architects said "So, you shipped the prototype!"  See, I'm not the only one who draws parallels to our architecture work!

One group of teenagers was collecting cans of food for a food-drive. Not bound by convention. There is so much promise in our youth.

10/31/06 More Architect Stories Needed

Thanks to Al, Jim, Adrian and Ben for "day in the life" stories. Scott, I'm sorry you had to cancel—but there's a story right there! Barry, I'm still coming after you! And, I haven't tired of listening to your stories (not by a long stretch), so email or call me and tell me more. Between all of you, you will make this paper much more interesting than I can make it!

 

 

Copyright © 2006 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: October 3, 2006
Last Modified: January 25, 2015

I also write at:

- Bredemeyer Resources for  Architects

- Trace In the Sand Blog

 

By Topic (October)

- John Wood Leaving Microsoft

- Leadership

- Process as Differentiator

- Leadership and Process

- Art of Persuasion

- Booch is Back

- Leadership Drum

- Strategy and Architecture

- One Man Can Change the World

- Whose Vision?

- Qualities

- Related Work on Qualities

- Leaders set the Tone

- Foresight and Wisdom

- Booch is Back

- Ben Ponne and GEAO

- Anshu Blogs

- Long Tail

- Confessions of a Trusted Counselor

- Who Does What When

- Value Modeling Blog

- Time for Fun

- Gus Grissom

- Leaving Microsoft

- Hedge Hogging

- Mr Magoo

 

Archives

2014

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

 

2013

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

2012

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

 

2011

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

 

2010

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

2009

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

2008

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

2007

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

2006

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