12/3/08 Requirements and the Architect

The debate around the architect's role in requirements comes up over and again. If you say "architecture is about right system built right," few disagree. It seems like that's what architecture should be about. But what does that mean?

Even if we are using a spiral or agile process, so our system life-cycle activities don't map to a sequential timeline the way a "waterfall" process does, we do still have activities that address system envisioning and system definition. These are focused on "the problem" or characterizing stakeholder needs and defining the product or system requirements. This is the stuff of "right system."

And we have system design, focusing on structural design and designing the internal behavior or system dynamics in the process of designing the structure. This is the stuff of "built right.'

Both system definition and system design have strategically significant aspects, and finer details that generally are not (but could be).

I believe that the architect should be responsible for right system built right, but to be responsible for right system built right, the architect has to be involved in, and in many cases ideally should lead, system envisioning and system definition. Yes, this means that the architect needs to partner well with business/requirements analysts and marketing, just as the architect needs to partner well with the development community. There is deep understanding of the business, customers, markets and so forth that needs to be drawn on to create the definition for the right system. And deep understanding of and ability to apply technology is required to build the system right. The architect can't do either of these on his or her own, unless the system is more simple than most today.

Then the question is why? Why does the building architect elicit customer goal, needs, desires, aversions, constraints, and so forth, and design the architecture? Because system definition and system design are mutually influencing. This is because "requirements" are an artifice. They are a man-made construction; they are interpretation, creation, choices, etc. And these "requirements" interact, with each other, and with the structural design.

Charlie Alfred has a blog post that poses this question. The companion article positions the relationship between architecture and requirements, and the role of the architect in requirements, very compellingly.  

I've articulated my position in Getting Past "But..." (and elsewhere, including this journal). I think the architect should be right in there when the system (use) concept is being explored and elaborated. Not in every meeting, not in every stakeholder interaction. But in every one that the architect assesses is strategically/architecturally significant. Of course, gatekeepers may prevent this partnering. In that case the architect can try to lead by following well—by showing an interest and a willingness to pitch in and help the requirements team be more successful. But the context is tough and the power structure ideally should be changed so that it is not all up to the architect's powers of influence through enthusiasm and skill at making others successful.

If Frank Gehry didn't talk to his clients, understand the musicians, the audience and the building owners concerns, goals, desires, frustrations, passions, could he have designed a Concert Hall that is both an architectural feat in a structural sense as well as in an contextualized aesthetic sense that says the building fulfils, even promotes, it's purpose as space where music takes first place? But Frank Gehry gets to set the terms of his engagement. And we need to work on changing organizational expectations around the role of the architect in system definition. Hence the "Getting Past But" attempt at providing a Trojan horse (or donkey).

[12/9/08] Charlie reworked the article somewhat and it works really well! I especially like the last paragraph:

"At the end of this process, the architects and domain experts have collaborated on the solution to a problem than none of them were capable of doing on their own.  They haven’t solved the entire problem.  There is still much work remaining.  But together they have discovered an architecture strategy - the DNA for the eventual solution.  And this DNA came from the best available minds on the various subjects, which means that the approaches are pretty likely to be complete and consistent." Charlie Alfred, Requirements vs Architecture

12/4/08 Another Standout Post by Dan Prichett

Dan's done it again! All it took was one blog post, and I'm convinced to ditch my "To Don't" list and start watching TV today! Uh, too bad we put the TV back in the attic to make way for the Christmas tree... (Post-election inertia is the only reason it was still out.) 

But seriously, Dan makes some great points about failures:

I love that! All of that; but that last sentence deserves special recognition on both the literary and social science front, while the first point is a great engineering insight.

Modern Marvels is a great pointer too—studying how things fail, and thinking about how to make things more failure resistant, is definitely architecturally significant.

12/6/08 A Quote to Become Great By!

“Men acquire a particular quality by constantly acting a particular way... you become just by performing just actions, temperate by performing temperate actions, brave by performing brave actions.” Aristotle (384 BC - 322 BC).

Of course, you get to pick the qualities you want to develop in yourself through practice. It helps to have a clear personal circle of excellence that you're working on—you know: “You can’t hit a bullseye if you don’t know where the target is.” Tom Gilb.

12/6/08 Architect as Consultant

I was reminded of the movie The Englishman who went up a Hill but Came Down a Mountain. To me, the main characteristic of a good consultant is dedication to making others successful. The architect, as consultant, needs to embrace this responsibility. It is our role to make others successful—to make the system successful, and to make those who work on it successful, and to make the business team successful. Anyway, the movie really speaks to that quality of empathy and enthusiasm, that willingness to build others up, that willingness to help them find a way to meet tough standards. So I've added it to my Movies I Like page.

12/7/08 Speaking Truth to Power

I listened to Grady Booch's Speaking Truth to Power podcast on IEEE. Grady certainly has a great radio-quality voice!

In other contexts, Grady has mentioned that his personal heroes are icons who never shirked speaking truth to power, and this is obviously an important quality to him. So it doesn't come as a surprise that he has held to the principle of speaking truth to power even when it put an engagement at risk. Of course, we have to recognize that the consultant may have less skin in the game than an internal architect. Whether your job is on the line or not, Grady's guidance is pertinent: "Don't speak the truth too harshly or too personally."  

The second part of the piece focuses on the contradictions in how software is used (for good and for evil), who software stakeholders are, what architecture is, and wraps up with "every stakeholder deserves the truth."

These IEEE columns are short/space limited, so it'd be nice if, in a follow-up column, Grady discussed the kinds of truths that need to be spoken to power. Grady has touched on "bad smells" elsewhere, but it'd be great to have more attention focused on: What are the "bad smells" one should be watching for and bringing to the attention of those in power? What are "early warning signals," and what bad smells should we watch for, when?  How do we look for them, and where (or what are the symptoms and root causes)? Essentially this is the stuff of architecture assessments, and Grady may have covered this topic, or still plan to, in his On Architecture IEEE series.

I do like the provocative title of this column! It is really an important part of architecting, but not one we typically list in the top duties of an architect. I'm glad to have attention drawn to it. And it makes me think there's more to go after in terms of how to bring these bad smells to the attention of those in power. For example, in Leading Up there's this great lesson about not doing so in a public setting. If you disagree with someone, or have criticism or bad news for them, do your truth speaking in private. Yes, and definitely, definitely do not speak your truth too harshly. Where I can, I prefer to go after the truth with questions, collaborating with the person or team on discovering the truth. Even when I think I already saw "the truth" there's often more to be discovered this way, than what I was seeing from an outsider's perspective.

Another point has to do with how to organize for "truth seeing" and "truth telling" within an organization. One chief architect we work with has created a setting where the project architect is not the person tasked with finding the project-stopping bad smells, because this would set the project architect up in opposition to the team she or he is working to make successful.  Instead, the chief architect is responsible for asking the hard questions, and yes, calling a failure a failure as early as possible. This puts the chief architect in the hot seat telling the top management he reports to the bad news, but he's a big guy.

So, this is another case of seeing the yang that complements the yin.  And I expect there is more to go after on this topic, but I'm on Harry Potter reading duty tonight...

12/8/08: This reminded Dana of Paul Simon's lyrics from Tenderness:

Put a little tenderness
Beneath your honesty

It helps to put yourself in the other person's shoes, try to see from their perspective, "think like a stork." As soon as you do, the complexities of the situation become more clear, and you're likely to be more compassionate. Yes, the truth in the code, the truth in the architecture (all of which probably belie a deeper truth in the process or the organization) may still be harsh, but your delivery will be more empathetic.

Discussing how to give feedback at a recent workshop, an architect said he always tried to give praise before he gave criticism. Another person advised that when you're praised, you should look for the hidden agenda. That's a rather cynical attitude to praise/compliments/recognition—like every person who compliments others is the Disney version of Kaa (distinct from Kipling's original), trying to advance their own agenda with insincere flattery. But perhaps she has encountered that praise-before-criticism pattern before. Especially since, given this pattern, it is probably going to come across as being damned with faint praise—let's face it, when you're looking for a piece of praise simply to soften your criticism, celebrating the person or project is not top of your agenda. Far better to be in the habit of finding and expressing the good, giving recognition, as a matter of course so that it does not come to be associated with a persistent stroke and slap behavior pattern.

If we are going to build a culture that embraces failure, we mustn't make people feel like failures when we need to make a course correction, call a reset, a restart or even a dead end. It really helps to have a process that finds failures quickly and cheaply, and celebrates these discoveries, making the people successful for having tried an approach that didn't work out. And it really helps if the process helps those most impacted find the failures and navigate away from them. Then the failures are their successes. But it is hard, from inside, to see the weaknesses and blind-spots, and so the process needs to pull in fresh perspective. Fresh perspective, but not perspective that is on the offensive, looking to take the project down. Rather, fresh perspective that asks collaborative questions, and collaboratively and with humility (not subservience; humility which assumes a position of strength and credibility) makes suggestions, offers experience, tells stories with a lesson the team can draw out together.

In Nick Malik's blog post on giving feedback, he urges architects not to "seagull the project"—not to come in to every review, make a lot of noise, c-word over everything, and leave. Nick noted that if you have to give bad news or negative feedback, don't just come with the problem, come with a solution. An alternative is to come prepared with questions (not attacks; neutral questions) and ideas for solutions. Then, rather than exposing the problem and pitching a solution, collaborate on discovering the weakness and coming up with the solution approach. This is not just "teaching to fish, rather than handing out fish;" it is that, but it also builds ownership of the problem (rather than defensiveness and rejection of the problem) and partnership. I try to do this, but it's not always easy; I get excited by the contribution I can make, quick and easy, and forget the human dynamics (defensiveness) that ends up making the whole process take longer anyway.

It's so not worth getting into a fret about this not being efficient—the very person who gets upset at not being able to just lay the s-word on the table should watch how he responds the next time his missteps are pointed out to him. We like to think we'll take deserved "constructive" criticism "like a man" and improve and grow, no sweat. But the path to that enlightenment is often a rather rocky, painful one, that takes quite a bit of time to navigate, and in the meantime our spirit is damped and we get much less done because we're dealing with the loss of a piece of ourselves; something we wrapped our ego in. Again, there's salience in Paul Simon's Tenderness:

Oh, honesty,
oh, honesty
Ooh, it's such a waste of energy
No you don't have to lie to me
Just give me some tenderness
Beneath your honesty
You don't have to lie to me
Just give me some tenderness

The tenderness beneath the honesty is empathy, compassion, caring. As soon as we go there, we discover that the "truth" isn't so black and white anyway.     

Software developers like "the code is the truth." But often it is a messy truth, and it becomes messy not by ill-intent! It becomes messy despite all our good intentions. It becomes messy because behind the code are bigger truths. Truths about power structures, truths about the process, truths about perspective, truths about complexity and uncertainty. Many interacting truths.

Again, it's so not worth getting into a fret about this not being efficient, not being a mechanistic control system with feedback loops and automated gates.

Oh, right and wrong
Right and wrong
Ooh, never helped us get along    

Creating great software systems is about creating great software with and through other people, often many people. The sooner we recognize that the time this takes is time well spent—is time spent on the joy and success of the people we serve as their leader—the better! Happy people are productive and creative—they have all their resources at their disposal. Upward spiral. Hurt people are defensive, unfocused (except on their pain), unproductive. Downward spiral.

So feedback, course corrections, are vital on projects, especially projects that are trying to embrace the tough, enigmatic, self-contradictory notion of succeeding by failing fast and cheap. And feedback is a delicate matter.

If you tell a hard truth and the doors close on you, and nothing is done (soon) about your hard truth, you've done a hard, important, right thing. But did you do it right? There are no simple answers to that. Honesty, harshly delivered, impatiently delivered, can thwart the help you seek to give. And honesty, gently delivered, can get the same reaction! You can try to take on the perspective, get on the same side of the table, be in the same game, as the project or person that needs your tough feedback. You can do all you can to show tenderness, to show empathy, to be part of finding the solution, and still be rejected. If you are bringing bad news that comes as a big surprise, that may trigger denial and rejection of the truth you're trying to shed light on. There are lots of ways this can get messed up. But they shouldn't start with you! You need to speak truth to power when that truth will, if not seen and responded to, be the undoing of the team, the project, the business. And you need to do so with grace that is Grace indeed.

Try to speak the truths that must be spoken

• early, when the truths cost less in terms of egos, (re)work and resources
• privately, so you don't embarrass and raise defensiveness
• indirectly, through questions, using a checklist or analysis, and by telling stories using a metaphor or describing experiences, so the truth is discovered in partnership
• in solidarity by being in the game, showing up as being on the same team, demonstrating goodwill and out-framing any inclination to blame

When I say "indirectly," I don't mean dance around the truth, alluding to it but not being willing to call it what it is. I mean, being cognizant that the "truth" you see is probably only a partial view, so it behooves you to work with the team (the project team, or the management team) using mechanisms to aid the truth discovery process. That way, you, and they, better understand the truth. And if you find a truth that must be escalated, engage in collaborative truth-seeking at that level, for the context will be different, shading the truth with new nuances that need to be discovered and addressed.

Speaking Truth to Power—what an awesome title! When the praise-before-criticism piece of advice came up in that workshop a few weeks ago, I put an action item on my list to pull together advice on giving feedback. But I would never have come up with such an awesome title! Of course, I've really been talking about giving potentially troubling feedback to any person or project, but it could pertain to our own survival when it is truth to powers who rule our (immediate) destiny!

So, thanks to Grady Booch for the title and launching the discussion, and thanks to Dana Bredemeyer for engaging in the discussion and sending the lyrics to Paul Simon's song my way.

P.S. Obviously I'm not generally talking about feedback along the lines of noting a case of feature envy or some other code smell indicating a refactoring—unless the person involved takes particular pride in their code craftsmanship and design skill. Generally speaking, if it is an area where the person seldom messes up, then it is likely to be a sore point to bring it up, especially if you do so in public. I've also fallen into the trap of using a red pen, and that, together with my scrawl, made my suggestions seem like angry, impatient reactions. So, while I am generally talking about feedback on the big stuff that a person or team's egos and success are vested in, it is good to be alert and careful on the smaller stuff too.

Also, when you're on the receiving end of "constructive criticism," try to stay in possession of your best resources so you don't get defensive and resistant. It helps to remember Indra Nooyi's advice "Always assume positive intent."

Some links of giving and getting feedback:

• Grady Booch's Speaking Truth to Power IEEE On Architecture podcast
• My iteration on Booch's Speaking Truth to Power, Journal entry 12/7/08
• Seth Godin "How to give feedback"
  Seth is addressing people giving him feedback on his blog posts, so his first point, in particular, should be read in that context. We don't want to disqualify people's opinions out of hand, just as much as we don't want them to (mis)label or attack.
• Nick Malik, "Don't walk in with a problem until you have a solution."
• Howard Morgan, How to Give Feedback to Your Top Performers, Harvard Business Publishing, "Express the cause and effect of their contributions/role in the organization and the appreciation that you personally feel."
• ELO's Don't Bring Me Down♫ [warning--link plays music]

And counterpoint:

• No to praise: Feedback is information, not evaluation, Esther Derby
  Note: Esther Derby writes: "Praise is a form of manipulation—and most of the time people can tell. If you want to appreciate someone, do it genuinely and directly, not in the form of praise." I don't understand... how do you appreciate someone genuinely and directly without giving them praise? If I say "Thank you, that refactoring really simplified this part of the architecture" is that praise? If I say "I really like the way you used a story to make your point," is that praise? Praise—or genuine words of recognition—but not flattery. Recognition is for something significant or remarkable, a job well done, a contribution that moves us forward. If you genuinely appreciate someone getting to work on time, and say so, I'm going to assume something else is going on—like the train route they usually commute is closed today! Derby's Rosenberg quote is very provocative... I use compliments/praise to recognize a remarkable or stand-out contribution because I believe that this recognition creates more joy in the workplace, and I want to create joy because it is good for people and it enhances productivity and creativity. So am I "dominating" my colleagues by "manipulating" them to be more productive because they are more happy?? And I am sorry, but is it just me, or do you find it a stretch to call that "violent"?  

[12/9/08] That Rosenberg quote bothered me, but then I thought there are so many ways that despair and pain enter our lives, we really ought not to invent positive, affirmative appreciation as the new oppression and make people unhappy with one of the sources of joy in work! Yes, I get a lot of satisfaction from my appreciation of my own work and my application of attention and talent. And it gives me a glow of happiness when someone expresses appreciation for it too, and I certainly don't conclude they want something from me! Most days, weeks, months, I get my feedback from indirect signals—like repeat visitors to my site, repeat customers in my workshops, and so forth. People are chary with praise because it takes time and attention and they don't have a lot of either, so I take deep pleasure in what does come my way. And praise gets more scarce the higher up you go (at least in our software world), because no-one wants to come off as a sycophant (an evil that ranks with incompetence)! Senior architects also tend to get less feedback on opportunities to improve, in part because retaliation, conscious or subconscious, is feared and you're in a position of substantial influence if not direct power. Still, high achievers are achievers because they set themselves high standards and are good at finding ways to improve themselves and the work they do, based on self-awareness and reflection. Yes, external input in the form of positive feedback and ideas on places to explore and expand our horizons, is very valuable to us, but just as we don't rely on external input to be motivated, we don't rely on external input to set goals for our own improvement.

"If you were all alone in the universe with no one to talk to, no one with which to share the beauty of the stars, to laugh with, to touch, what would be your purpose in life? It is other life, it is love, which gives your life meaning. This is harmony. We must discover the joy of each other, the joy of challenge, the joy of growth."

Mitsuge Saotome (by way of Grady Booch's blog, 5/18/08)

We don't simply find purpose in sharing the stars, Bryce Canyon hoodoos in the snow, or the beauty of words like Saotome's. We find purpose in having our beauty, our complexity, our value, our good work, be meaningful, and this meaning is established not simply alone, but in a social context.

Returning to what I believe is a fallacy in Rosenberg's ostensible claim that praise is manipulation and hence a breed of social violence: We have come to accept "paying it forward" into our value-set—doing good because the person on the receiving end will, some time later, do good for someone else. It is utterly, utterly bleak if we think that making a person feel seen, recognized for the value they have contributed, is manipulating them—even if we think the outcome will be that they will pay that goodwill forward in enhanced creativity or enhanced appreciation for another person's contribution, etc. That is, even if we believe that the consequence will be an action taken, an attitude shifted, it is counter-productive to label that as manipulating and violent!

As for taking negative feedback, Ryan just told me my "archman contemplating negative feedback" drawing looks like a cheese wedge, and then promptly drew what it would look like standing up (not flattering). Should my feelings be hurt? Of course not! I appreciate humor, and I'm certainly willing to laugh at myself!

Anyway, this discussion is about the big stuff! 

But it does remind me that I have wanted to draw the Schroeder Stairs from time to time in interactions with teams to remind people that perception can play tricks on us, and while we see one view we don't see the other, and as soon as we see the other, the first tends to pop out of view.

"How dreadful knowledge of the truth can be when there's no help in truth!" — Sophocles, Oedipus Rex

"Cynicism is an unpleasant way of saying the truth." — Lillian Hellman, The Little Foxes

12/9/08 Booch is Back!

It is so great to have Grady Booch blogging again! It is important that our industry's leaders work on the frontier of the big moral issues of our field, and it's good to see Grady fostering dialog and raising awareness of the role of software in overt and covert war, and engaging with the question of how to encourage women to enter and stay in the software field. Not shirking the responsibility of speaking truth, even to power, indeed.

And, perhaps, if we can solve the problem of getting women into software and leadership, we could just play a nice game of social networking and leave wars to the historians. Ok, maybe not any time soon. Even so, it is worth remembering that by working on economic and social upliftment around the world, we make progress towards peace and stability. Bringing higher standards of healthcare and education, and social justice including equal opportunities for women and minorities, doesn't just help the people in disadvantaged economies—it helps us, not by making us feel good (it may do that too), but by giving evil less fertile grounds to fester. 

[12/12/08] It is significant that Grady said "note how few women are counted." Because interestingly, Frances Allen was not counted. She was also not counted by the ACM until 2007 (when she was ~74 years old), when they got around to recognizing her, making her the first (and still only) woman to be awarded the Turing Award. I think that makes her famous, don't you? Certainly she got a lot of press, being the first woman to receive the award. I believe she was "not counted" because she didn't (and still doesn't, as of December 12th) appear on the wikipedia list of famous programmers, though there is a wikipedia page on Frances Allen. It just goes to show that as good as wikipedia is, it can't be counted on to be the ultimate authority on everything!

12/10/08 Leading by Example

Well, it occurs to me that in the last couple of days I superbly demonstrated the distracting, unproductive nature of criticism! I felt my stance on recognition/praise, even my stance on enthusiasm, was being questioned, criticized, and worse, named an oppressive social evil that relies on immature management practices! And I spent all my journaling time across the span of two days self-justifying my notions of meaning and joy in our social world of work. So there you have an immediate example of the time that can be sunk into negative feedback (albeit very indirectly delivered)! Grin.

Speaking of leading by example, it struck me that Gandhi provides a good metaphor for making the case that the architect needs to have project code responsibilities, and it's not enough to code prototypes and evaluate new technology (the fun, sexy stuff any technical person wants to do). That is, the project architect needs to live the life of the project team, pitch in with cleaning the latrines/doing the work of the "untouchables. " Uh, one always has to be careful with analogies... I think I just ran too far with that one.

And the analogy also gets more difficult to apply, the more broad the scope/strategic the contribution of the architect, because at that point, the architect's true community is as much the business and senior management as it is the development community.  

12/10/08 Not Impressed by Hierarchy

Dana Bredemeyer asked a gathering of top (I mean senior, but also really top notch) architects in The Netherlands what characteristics they think they have, that enabled them to succeed in their role. These architect very generously, honestly and openly shared the qualities that they have learned to value in themselves, and in each other. Of one architect, another pointed out "he's not impressed by hierarchy." I am a self-described "flat-lander" myself, so I like that alternative way of describing my non-hierarchical landscape. I also relate it to a networked-collaborative leadership style (in contrast with a dominance hierarchy style of authoritarian leadership), which for me, at least, entails a willingness to enter a dialog with anyone regardless of formal status. I'm much more focused on outcome than hierarchy.    

It is hard to talk with openness about our personal qualities (especially our strengths because we are schooled not to "brag"), but this audience of peers was superbly supportive, and if one person left something out (like "not impressed by hierarchy") others pitched in for him.

Yes, sigh, all men. These are system architects, and if we think its bad in software architecture, I've encountered even fewer women in embedded systems (MEs, EEs and embedded software architects who tend also to be EEs). Embedded software, as it happens, is where I started out, programming in Assembler and Forth.

Anyway, Dana took his notes on a napkin—maybe we can get permission to share his napkin with you. 

12/11/08 Connections, connections

Dana caught that I'd quoted Mitsugi Saotome and wrote (from a high speed train to Paris):

"I saw the quote in your journal from Mitsugi Saotome. He was one of the original students of Morihei Ueshiba, the founder of Aikido. He was ... my favorite of the original guys. Very beautiful aikido, very strong and exuding love. I trained with him a few times."

Dana Bredemeyer, personal email, 12/11/08

12/12/08 Feedback

Daniel pointed me to a useful article, and I'm going to take the liberty of quoting Daniel because he (indirectly) raises a bigger question for me:

"You might like this The brilliance of creative chaos article. State of mind...  I associated with one of the article's comments: "Chaos breeds new ideas whereas as Order simply perpetuates old ones." ...

You might ask yourself why I am bringing this up. Well, because I am hinting that I am finding your "un-ordered" undercover journal more useful, enjoyable, and having life."

When I forked my journal into the more elemental surface version and the wordy stream of consciousness undercover version, I wondered if I would lose more readers than I gained. It took a few months, but now my undercover journal hits track at about 60-80% of the surface journal hits. And the visitor return rate is growing.

I've raved about Scott McCloud already, but I find his conclusion that the artist desires to be appreciated, yet remains unwilling to succumb to market pressure, is astute and pertinent.  

12/16/08 Looking Forward

I had an interaction with an architect in the energy sector that was really inspiring. Ok, so times are challenging, but he was so enthusiastic about this point in time that we're at—a point in time when we get to (and must) change the course of this planet!    

I saw a picture of Obama on the cover of Rolling Stone magazine and it brought tears to my eyes. He looks so humble, but it was more about how very much is riding on him—keeping hope alive is a heavy burden in times like these. Still, if anyone can pull it off, I believe it is Obama! The media is such a pendulum swinger—it damped recognition of the recession until it had dug a deep trench around the world, and now it exacerbates the recession with the worst of doom and gloom, spreading pessimism. If everyone acts in alarm, it is self-fulfilling! Yes, over-confidence over-heated the economy, and now panic could have it spiraling well beyond the point of self-correction. So, Obama will be vacationing in Hawaii over the Holidays. Good for him! I sure hope he gets to have fun and relax, because it is going to be a challenging year gearing the US up for hope and renewal. And with the US, the entire global village, for this recession has certainly demonstrated how intertwined the global economies are.

12/17/08 Scaling Agile with VAP

VAP (the Visual Architecting Process) is all about being agile even when the complexity of the system, and the organizational unit(s) building it, demands some upfront design (use concept and system concept)—for example, to launch concurrent agile teams. What VAP emphasizes and enables is parallelizing the requirements and architecture iterations, with intensive stakeholder involvement as pertinent to the quick cycles. VAP can be applied during coding cycles, but for complex systems, early VAP cycles use the cheapest possible artifacts (e.g., models and prototypes) for learning quickly about stakeholder value and architectural challenge. This concurrency, together with the principle of stakeholder (including but not just limited to end users) involvement, is a major value and contribution of VAP. We talk about JEDUF and agile architecture in the Getting past But paper.

So far, there's been no advocacy for the Getting Past But report around the I-way. Is it the story? I don't want to believe that! Yes, it was audacious to use a children's story to point to the universal human challenges of getting teams working creatively and productively together. Yes, it was audacious to use hand-drawn images to demonstrate the power of pictures each person can draw and leverage to create layers of meaning, to create visual metaphor, to synthesize and pull together ideas, that goes beyond just words. But the content of the report is so important to the conversations we're having, to the challenges of organization after organization as the hype around agile pushes larger and larger projects to experiment with agile development. As we do so, we need to leverage all the lessons of our histories creating complex systems, as well as the lessons and values of agile development, to adapt a process that works for concurrent development of complex systems.

I posted a synopsis of our Getting past "But..." paper to my blog.

12/18/08 Architectural Style—Again...

The Microsoft Application Architecture Guide again raises the question of the definition of architectural style. I rather like architectural style to emphasize "characteristic features of design", and wonder if object-oriented, for example, is a construction style (emphasizing characteristic features of construction). As for SOA, I tend to think of that as genre rather than style, because the criteria for inclusion are rather loose... 

Of course, the work done by Rob Boucher and the rest of the team at Microsoft is first-rate. I'm just wondering if the architectural style definition that the software industry seems to have settled on is much less useful than the definition in the building architecture space.

12/21/08 A Break over the Break

I'm planning on taking a real break over the Holidays, so if you celebrate Christmas--I'll wish you a merry Christmas. And if you celebrate the New Year on January 1, I hope you have a happy and safe New Year, and I wish you a richly rewarding 2009 (in the personal fulfillment sense, but it'd be nice if retirement savings got back to where they were before the recession, too).