A Trace in the Sand
Online Architecture Journal by Ruth Malan
I also write at:
Trace in the
4/3/08 Poof! And then it builds again.
For a brief moment at the beginning each month, the JournalCurrent page is quite manageable—empty even. And, then it builds again. Still, it's early days yet. If you miss my architects/architecting/architecture notes, by all means track back to previous months: March, February, January 2008. To dig back further, follow links to any month in the left column.
If you're just tuning in: these notes are for me, and they are for architect-explorers who navigate outside the box, reaching to be great. Architects who recognize that innovation and strategic contribution, and leadership and personal effectiveness, are as much keys to excellence in architecture as structural design elements. Not one without the other, but one in service of the other. "The tendency ... in business is to focus on the deficits," try to solve the problems, fix what's broke. If you think architecture should be about creating a structure that does doesn't crash under the load placed on it, I'm only partly with you. If you think
then I'm game to team up with you, even indirectly by lending you this record of my travels into what I consider to be territory (sometimes frontier territory, I acknowledge) that architects who aspire to greatness implicitly and explicitly need to explore.
4/3/08 Units of Incremental Transformation
Fred Brooks observed that entropy is a fact of life for software development and we should plan to rewrite our systems every few years. But when you get "somewhere between 10M and 100M LOC" the investment is just too large to treat the whole thing as sunk cost on some periodic cycle. Preserving our software assets means we need to do a better job of crafting our systems from architectural elements (e.g., services) that are units of relative independence. Well-designed architectural elements create boundaries within which we can have considerable freedom to experiment and innovate, as well as to re-engineer, refactor, simplify, clean up, modernize, TEST, etc., without causing unpredictable impact on the rest of the system (or, at least, we get less of less of that). They become the units of incremental transformation, freeing us from the need to do radical transformation quite as frequently.
Architects still need to have a watchful eye on trends and shaping forces. Our legacy investments tend be made around legacy markets. If we have a modular, incrementally adaptable architecture, that allows us to respond quickly to shifts in the market. Up to a point. If there is a paradigm shift in the market, the organization may still be poorly positioned to take advantage of new opportunities. That is, unless it is willing to invest in a new architectural paradigm that is fit to the new market paradigm. Clayton Christensen (Innovator's Dilemma) makes the case that industry incumbents often aren't, because they are tuned up around the market paradigm that is being replaced—they listen to those customers who haven't made the paradigm shift yet, their internal power structures are adapted to the old paradigm, and so forth.
4/3/08 Software Architecture and Role of the Architect Training
There are only 4 seats left open in the Software Architecture Workshop I'll be teaching in Chicago (well, north of downtown, in Evanston) April 15-18. But that's 4 seats I'd really like to have filled, so please ping your network on my behalf! I'm such a poor salesperson, I haven't even pinged my network! But, architects aren't great in a vacuum, and it will serve you well to encourage others to greatness too.
The workshop roadmap is shown at right. The left column is context, the middle two are non-functional and functional (architecturally significant) requirements and constraints, the two rightmost columns are architecture specification. The column on the far right focuses on structure, and the one just in from that on behavior. The progress from top to bottom, is from more high-level and broad-scoped down through the layers of elaboration and refinement. On the two rightmost columns, this corresponds to meta architecture (or architecture strategy), conceptual architecture and logical architecture, with execution architecture and guidelines and policies not shown in the picture. Validation is also not shown in this chart, and is a column "off the page" to the right. More details are shown on this chart.
Oh yes, and Dana Bredemeyer would like to see those of you who are doing enterprise architecture (if not in name, at least the spirit of working strategic architectural issues across internal organizational boundaries) in the Enterprise Architecture Workshop the following week.
We have also set the date and city for the next Architectural Leadership and Other Skills workshop: - Indianapolis, IN, September 22-24, 2008. Naturally we think the workshop is really a fine workshop as it is, because it is designed to draw on the talent and experience of all the fine architects who participate in it. Still, there's always room for improvement, and if you want to influence what is covered in this workshop, by all means give us your input. I've suggested a personal visioning exercise, and Bezos' "regret minimization" approach is another way to position doing desired state on yourself. Mainly, we're looking for input on what other workshops to offer, but tuning our current offering is always on the table. In fact, our workshop materials have evolved continually over the years, and we have had several architects take our workshops more than once (the same workshop, as well as complementary workshops). That humbles me, and I'm not saying it's for everyone. But when architects I admire and rate top-notch, take more than one workshop from me, I'm inspired! This is a life-long quest to excel, and I've barely reached the foothills, but I'm happy to do what I can to help those who are closer, reach their summits.
The wonderful thing about our workshops, is that the architects they attract are smart, active investigators, looking to make highly leveraged contributions to their companies and teams. Everyone, from entry-level architects and tech leads to senior architects, brings energy, attention and experience into the workshop, and because we draw a good proportion of very high-caliber experienced architects (like Mark Mullin and Greg Russell—I feel I can mention them because they gave me a recommendation "in public" on LinkedIn) the workshop dynamic is amazing. I mean, I'm still learning and I've been doing these workshops for more than a decade! And I don't think its just that "memory almost full" phenomenon!
4/4/08 Software Architecture Training
Ok, make that
Fittingly (given my metaphor that prompted the foothills and peak picture), I picked up Chip Conley's Peak today. I'm only chapters in, but wanted to note some key sentences and ideas that engaged my interest in reading further.
'...she read me a line
from a Mary Oliver poem, "Are you breathing just a little and
calling it a life?"' [p.5.]
Chip Conley, Peak, 2007.
Chip Conley, Peak, 2007.
This was the line that pre-empted Conley's re-invigoration during the gloomy dot-com bust years that spelled doom for the Bay Area-focused hotel company, in a travel industry already hit by 9/11. If you were reading along in March, that might strike you as a companion to my circle of excellence piece.
The following anecdote resonated with lessons I'd learned from Evo (then Agile):
'Kay noticed that his workers were more productive at the end of the assembly line, where finality of the assembly provided a sense of accomplishment. Kay dismantled the assembly lines, created small production teams that were self-managed, offered stock options, and created a post called the "vice president of innovation." These teams were even allowed to choose the decor of their private workrooms—a pretty revolutionary approach... more than thirty years before the first dot-coms sprouted.' [p.11.]
Chip Conley, Peak, 2007.
From early experiences with Evo (from Gilb's evolutionary development, now popularized as agile development), I saw that weekly cycles created a fast pulse that in part had to do with the "rush" of accomplishment, and in part the rush of getting the job done and meeting team goals in short timeframes. It was a motivator; the team depended on every member to make those weekly integrations. The two faces of this rush, though, created a situation that was easily mismanaged, letting quality issues build, in order to meet the next week's deadline, and the next.
What I learned was the role of the architect has to be still stronger, not weaker, in these cycles. There had to be someone who would call the team to an accounting, who could call a stop to the feature clock, if the quality, if the structure, was being compromised. The project manager, who has hiring and firing authority, who controls formal rewards like bonuses and raises, manages to the release clock. The architect is in a tough position, for generally the architect reports to a line manager who feels the pain if a project is delayed or, worse, stopped. But the strong architect will call time out to recover from a quality slide, because she knows that the alternative is to face ever-increasing cycle unpredictability (meaning integrations become harder and cycle acceptance criteria are less likely to be met), and even longer delays before release. Code issues that are architecturally significant because the scope of impact is broad and/or strategic (make-or-break), must be nipped in the bud. It is a generalization to say that project managers tend to be optimists, but with one eye on the release clock, it can be hard to pay the price of quality upfront.
We have learned a lot since those early days. With pair programming we go a long way towards building quality in (if I'm in a fishbowl being observed, I'm going to do better to preserve my self-respect; and I have a second mind helping me do better, and helping me catch my blind spots, assumptions and errors early). This is far superior to testing to find quality problems, where removing the defect means rework which, if treated as waste, is waste indeed, for quality issues have a tendency to mount. We hope that reviews and various levels of tests will catch any quality issues that do slip through, but quality at the source is the most effective approach to quality in the hands of the customer. So agile teams that hit their "flow," who work together like an effective rowing crew, tend to be those that have superior quality habits, each wearing an "architect" hat in addition to each keeping an eye on the feature clock.
Which does not do away with the need to have a lead architect, or a project manager, when the system size is beyond what a single small team can build in competitive timeframes. When a project uses multiple teams working concurrently to speed development, we need to have a team lead on the architecture side (accountable for right subsystem built right) and a team lead on the project management side (with schedule and resource accountability), with an overall architect and overall manager. If the architect reports to this project manager, we have given schedule the upper hand. If the lead architect and project manager report to the manager's manager, schedule still has weight in this transactional/short-term-results focused world. But it is a bit better. For strategic systems, though, the lead architect should ideally report to a strategic manager—one who is accountable for long-term results and business viability.
Yes, this calls to mind Coplien's "recursive binary star structure" (Organizational Patterns of Agile Development), and I really need to read that book, since I've only "dipped" into it.
The following also struck a chord:
'...Malcom Gladwell ... told the New York Times ... "People are experience-rich and theory-poor... people who are busy doing things don't have opportunities to collect and organize their experiences and make sense of them." [p.13]
Chip Conley, Peak, 2007.
Why? Well, if you have a sense of déjà vu when I talk about VAP, it is because you've been doing (some or perhaps even most of) VAP without formalizing the process structure, the pieces and how they relate, which also means that it is quite likely that either you were missing critical pieces or didn't realize their significance. So the value of VAP is that it provides an organizing model, which helps identify and prioritize steps, fill in gaps, or even just explain what you're doing to others.
Moreover, this is part of what architects do. It is what we do when we create patterns. It what we do when we extract and formalize a lesson as an architectural principle. It part, it can just be the common sense that isn't commonly practiced because it is obscured by the day-to-day morass of detailed issues and decisions.
4/5/08-4/6/08 Architectural Style versus Architectural Patterns
Paul Clements pinged Dana Bredemeyer, among a set of architecture pundits, asking for clarification on the difference between architectural style and architectural pattern. I wasn't included, but, being a brash sort (ha! ha!), I decided to gate-crash the party.
Here is my take:
And here is the expansive and wandering thought trail that led me to the above beautifully pithy statement (grin; it may be all wrong, but it is pithy; which is in considerable contrast to what follows):
Learning from Style in Building Architecture
When I need to distinguish between architectural patterns and styles, I like to draw on the building architecture metaphor because it highlights an important general property of styles that I think is useful. Let's start with wikipedia:
"Architectural style is a way of classifying architecture that gives emphasis to characteristic features of design." wikipedia
I'd push it further: First, architectural style is a collection of design elements from architectural to design to details such as trim, that are common across buildings of that style. This becomes clear if we think of Victorian, contemporary, Cape Cod, Eichler, etc.
Take Victorian. Though eclectic, one can still ask: What design elements are consistent with a Victorian home, and what design elements are clearly ruled out/jar/inconsistent? Complex roof lines, wrap-around porches, octagonal rooms, bay windows, down to gingerbread trim, are all in line with the style. There is an over-arching design philosophy, a unifying aesthetic, or perhaps, sometimes just fashion or fad, that makes some thematic design elements congruent with the style, and others incongruent. Thus, sliding glass doors and plate glass windows and open floorplans are inconsistent with traditional/period Victorian styled homes. Yes, some have to do with the technologies of the day, and some have to do with taste, but more broadly, with context—social, environmental, and technological context.
Given admittedly limited experience with friends' Eichler homes in the Bay Area, I would express the Eichler style as follows: the overall unifying vision that gives Eichler homes their integrity is an "affordable California lifestyle home." By California-lifestyle, I mean it takes the California context into account—the great weather, the light, easy living, etc. Then there are the characteristic thematic elements that deliver this vision: open floorplan, simple roof line with post and beam construction, and "bring the outdoors in." You may notice how succinctly these characteristic elements of the style can be expressed, even though each element is not necessarily related to any other element except by the overarching, unifying, integrating vision. One may argue that they can be expressed succinctly because each thematic element (e.g. open floorplan) is itself associated with a well-understood family of design elements. "Well-understood" is a relative term. Looking back, it seems to have emerged; to be a name given after repeated examples are found. But for repeated examples to exist, they are either independently (re-)invented or they are promulgated designs. "Bring the outdoors in" may now be readily understood, but at the time, Eichler had to create the expression of that design theme: skylights and floor-to-ceiling windows and sliding glass doors looking onto private garden areas, etc.
You may also notice how fit-to-context is a shaping influence. The context in the Northeast, for example, is quite different, with much colder, longer winters with shorter days, all making for a more harsh outside that you don't particularly want to bring in during the winter months. So energy efficiency becomes a dominant driver, leading to multi-story homes that are open to the outside only on south-facing aspects. It is this fit-to-context that my intuition tells me is the reason why a dominant design can emerge across quite disparate fields, even where there is relatively little cross-over influence—even though the contexts appear dissimilar (e.g. different industries, product development versus IT, etc.) the dominant drivers in the contexts are the same.
In Gothic architecture, the overarching architectural goal was to glorify God by creating places of worship that were lofty and huge in dimension. Man's aspiration to Heaven was reflected through buildings of extraordinary verticality and light--extraordinary, for the first example cited, the Abbey of Saint-Denis, was finished in 1144. The design elements (or architectural features) used to achieve the theme of verticality included pointed arches, the ribbed vault and the flying buttress. Together, these technological elements allowed an engineered structural solution that was in itself aesthetically pleasing. Further, the verticality was emphasized by architectural details all the way to trim, such as spires. The height itself added to the feeling of light. Moreover, with the ribbed vault and flying buttresses, walls did not have to be so weighty, and windows could be taller and wider, adding dramatically to the theme of light.
Architectural Patterns in Software Systems
A "design pattern" is "a formal way of documenting a solution to a design problem in a particular field of expertise." wikipedia
An architectural pattern (as in Christopher Alexander’s patterns and in the software field including the work of Buschman et al. and follow-on work) is a solution to a recurring specific (contextualized) architectural challenge. We used to say: encountered once: can't tell; twice: co-incidence?; thrice: maybe a pattern is emerging. One class of architectural challenge is high-level organizing structure, addressed by patterns like layers and pipe-and-filters. Another example would be patterns that address the architectural challenge of decoupling chunks of the system, like facade. Then there are architectural mechanisms, like resource managers. Are these last architectural patterns because they are part of an architecture/address an architectural challenge? Or are architectural patterns restricted to the set that have to do with the overall organizing structure?
In common use, a pattern is a stylized solution to a recurring design problem. In other fields, "pattern" is used sometimes more formally, but often less formally. But in our field, we have a conventionalized pattern for patterns, in which we identify the "problem" or design challenge, a proven solution design and the context in which the solution is a good fit, and we give examples, implementation guidance and variations.
We could say if the design problem of interest is the overall architecture of a set of systems, the pattern at that level of abstraction is a collection of patterns and other thematic elements (principles, idioms, specific decisions like technology choices) that apply across the set of systems (descriptively if we're looking back, and prescriptively going forward). Then we don't need a concept of architectural style in much the same way that some argue we don't need the concept of architecture given that we have the concept of design (proponents of that approach argue: it's all design, the boundaries are fuzzy, so why try to distinguish). So, we could argue: a system is a system of problems and the system of patterns that addresses these problems is a just higher level architectural pattern. Is architectural style just an informal (not stylized in the pattern for patterns sense) higher level pattern, consisting of (families of) patterns?
I believe there is both precedence and a prevalent preference for reserving "pattern" for tighter design challenge/design solution pairing, and architectural pattern is a refinement that directs attention at the architectural nature of the design challenge. It pays due to the fact that what is architectural in one context may not be in another, but an architectural pattern identifies a solution approach to a challenge that in its target application is architectural.
Architectural Styles in Software Systems
Returning to architectural styles in software, we could say that style is not specific to one system, but rather is what is common (in a design sense) across the set of systems that have that architectural style. Moreover, the design elements that express congruency with the style may be at different levels of abstraction, scope or granularity. For example, we could say that most organizations using Thomas Erl's SOA books have a flavor of SOA-Erl-styled architecture with a tailored layering (4 or 5 layers), principles (a la Erl), and other design elements. Most any great architect working within the SOA space these days, will have their own flavor of SOA style, much like Eichler is recognized within the broader "California Modern" style of homes. I'm not saying SOA is a style, but that great architects working across multiple SOA systems, will likely create one—they will carry their design philosophy and thematic design elements from one system to another. Obviously this is true for, say, embedded systems architects too, where they may carry event- or time-driven rather than service-oriented (or integration or large-chunk modularity) as the central organizing concern.
Now, I have to say that the concept of architectural style would be much more useful if we had clear examples of styles to point to. But architectures are proprietary, so can we expect much more than SOA-Erl? Quite possibly. It is becoming more accepted as an approach to building brand identity and employer desirability, and developing community relationships and loyalty, to send tech stars out to talk about their (organization's) architectures—at least at the style level of over-arching design philosophy and vision, along with elements including architectural pattern choices, principles and design guidelines. See, for example, Werner Vogels (Amazon CTO) and Randy Shoup (architect, eBay) on InfoQ, and other architects at QCon and IASA regional conferences. And then, of course, there's the promise of Grady Booch's Handbook.
When I ask myself what thematic design elements I see coming up in software, one obvious one is organized around the intent to build more modular systems, by which I mean an organization- or architect/architecture team-specific flavor of modularity is a central organizing concern around which a set of specific concepts (what do we mean by "modular"), principles and guidelines (how do we intend to build and evolve our modular systems), patterns, and so forth, hang—forming a thematic thread through the architecture decision set.
Still, I wouldn't see modular architectures, or service-oriented architectures, or highly distributed architectures, or any such very general characterization as being, in of itself, a style; perhaps these are genres? At any rate, the mere notion of service, or distribution, isn't what creates a style. There is enough spread in the interpretation and implementation of SOA, for example, that I would hesitate to say all systems falling under the SOA rubric have the same service-oriented style. Erl brings a unifying interpretation, and set of guidelines, and I see SOA-Erl as having promise in terms of creating a style that exhibits common characteristics beyond the notion of services. Still, we don't have to push on SOA too far before we get to thematic elements that are as concrete as the pointed arch, the ribbed vault, and flying buttresses of the Gothic style--just add principles around service design and granularity, key patterns and/or an ESB (which instantiates key patterns), and presto stylo.
Other examples holding promise for styles include: subsumption architecture (for robots: see, e.g., Luca Bogoni, and Rosenblatt); event-driven architecture (e.g., EDA and EDA and SOA); ... What other architecture genres do you see holding promise as maturing into styles (having a clear set of design elements that characterize the style, such as central concepts and philosophies, principles, patterns governing structural organization and mechanism design, guidelines, etc.)?
More Terminology Soup: Style versus Reference Architecture
The question then, is: What is the difference between architectural style and reference architecture? Style may follow an architect from one company to another, but the reference architecture may not. That is, reference architectures are proprietary, and the decisions and guidance they embody may be considered to be a highly leveraged source of competitive advantage. [As long as they remain minimalist, for bloated reference architectures tend to be treated, at best, as merely a reference to look to for ideas.] The style, on the other hand, is more a matter of insight, experience and talent that is going to leave in the head of the architect, if the company mismanages the architect's prospects. In other words, on her next assignment, the architect is very likely to bring with her the style elements from her last assignment that are part of her design philosophy harvested from her accrued experience, even though she is not permitted to bring the specific decisions reflected in the reference architecture she had to leave behind. Essentially, a reference architecture, if successfully implemented in more than one system, will likely have the effect that these systems will have a shared style. And a style may strongly influence a reference architecture. Or something like that. [And adding further terminology to the soup we've created here, there's product line architecture, and I've seen groups call their product line architecture a reference architecture; likewise for domain and portfolio. Would we want to standardize on these terms? We've seen the organic ferment of our field coming to life, and I think we can expect a natural culling to occur if the landscape can't support the diversity.]
Thus, architectural style is generally thought to be descriptive (expressing common characteristics of a set of exemplars). But can it be prescriptive (creating the style, going forward)? On the other hand, reference architectures are generally meant to be prescriptive. A reference architecture may refine a style (if, for example, SOA-Erl defines a style), and it may define a style. I've been tempted to say that a reference architecture creates the division/company-name-style or the lead-architect-name-style, though the latter would provoke push-back in "leveling" engineering cultures.
This is already over-worked, but again, that is how I think: tease it out. Develop the understanding out of which minimalism may be wrought. But getting to a pithy expression takes working towards a deeper understanding. There is so much overlap among the concepts, which to me doesn't obviate the need for these concepts, but it does make it harder to draw crisp distinctions!
So terms on the table include:
So far, where I seem to be at is:
I said "stylized" solution and can't get away from it! It means to represent or design according to a style or stylistic pattern rather than according to nature, or using a conventionalized pattern—and the pattern for patterns is that. So I'm stuck, not being able to find a word I like better, yet it has an unfortunate overlap with style.
These design elements may be at different levels—for example, they may include architectural patterns and principles, approaches, decisions, design patterns, and even specific code idioms and implementation guidelines, but they are ideally a minimalist set of decisions made to give expression to the key thematic design elements.
I'm alluding to the way reference architecture is commonly used in industry, at least among the broad set of companies we work with.
We didn't suggest that reference architecture should be added to the lexicon of our field. But we did add meta architecture, by which we meant decisions that guided the creation of the architecture, but is not the architecture itself; or, alternately put, the architecture strategy identifying the architectural goals, challenges that could impede achievement of the goals, and the high-level approach to reaching the goals and dealing with the challenges.
A dominant design may emerge after a technological innovation and subsequent era of ferment in an industry. For example, the internal combustion engine has been the dominant design in automobiles for decades, though now it is being challenged.
Testing the Concepts
Thinking empirically about my experience across a broad set of software architecture efforts, and analogically about the publicly accessible architectural styles in the building space, I conclude that style is not just a matter of architectural patterns (so not synonymous with pattern), but may include design patterns (at various levels of scope), principles, and may even include specific technology choices, and has a component that is the stamp of the period, whether this is fit-to-context, or fashion, or personal taste, or the idiosyncratic genius of the inspiring architect who promulgated the style, or some combination of these.
We do a dance between concrete instances and abstractions. We may posit an abstraction and test it against concrete instances, or we may look at concrete instances and find the abstraction. Is one approach preferable to the other? I very often see architects positing abstractions and forgetting to test them—because they were able to build these abstractions in the first place based on their experience. However we come up with our thesis, we need to test it. But I'm a pragmatist. I don't discount experience. I especially don't discount the experience of talented architect practitioners. So while I want (them) to test the abstractions they posit, I don't deny the validity of an intuitive, experience-based segue into the process.
Here, we have terms that are in common use, even if people mean different things by them. So we want to make sense out of the ways in which they are being used, and see if there is a preferred use we wish to promulgate in the community. An alternative is to say: what are the concerns architecture needs to address, and what are the approaches and decisions that address those concerns, and how do these cluster, and what should we name these clusters? Again, I think it is a dance between instances and abstractions and whether you start with instances or start with abstractions, the key thing is to start, and then begin to test the robustness and utility of the abstractions.
Just What Are We Talking About?
Ok, so we were going hiking and Dana and I were discussing this whole thing and the kids were bored and wanted to change the subject. I suggested we debate whether grey is a color or not. Dana is so onto my dry humor—he guffawed. The kids were perplexed. I said: well, is it just a lighter shade of black, or a darker shade of white? They still didn't get it. So I explained that to most people this whole discussion is just about shades of grey, and there are some people who'd wonder, with perfect reasonableness, if (or better, why) we're even talking about grey here.
Well, what do you think? Since I'm not one of the sanctified architecture pundits, you can feel more free to disabuse me of my misplaced notions.
4/6/08: To this question, Daniel Stroe responded: "To me style is a kind of fashionable approach, and pattern is more a reason-driven choice." I do agree that there seems to be an element of taste associated with style, and this may shade into fashion. But here, again, Eichler provides a reference point, for Eichler was not fashionable in his time. His modern ideas have since been embraced, but they were treated with skeptical resistance that didn't exactly make him a success in his day. We could say that SOA-Erl is fashionable, or we could say that SOA-Erl is accessible, or we could say that SOA-Erl pulls together and organizes experiences into a framework that practitioners would themselves create, if they weren't so busy practicing, in the way Gladwell talks about. It doesn't matter; what matters is that I see the same 'black book" (and subsequent Erl books) principles showing up in various architectures, across industries, and it dresses these architectures with these same elements—the same style?
[4/8/08 There may be a temptation to think that style will thwart creativity and innovation; that perhaps epigons [thanks for the word, Daniel] will adopt the style of luminaries like senior Amazon or Ebay architects (sharing their approach on InfoQ /QCon and blogs) without considering the specific architectural challenges (pre-eminently enormous scale, in their case) that those architects have to accommodate. Still, we do need to watch innovation for innovation's sake. If you've used the new Glad trash bags you'll know what I mean! I very seldom had the old Glad kitchen trash bags split on me, but these new stretchy bags split every time! Ugh. (Now, if Glad really wants a good idea, why not fly-repellant impregnated bags? Perhaps not environmentally friendly. Next!) Sorry, I had an axe to grind... But seriously, on balance as an industry, we probably err more on the side of (re)invention than on the side of leveraging extant best practice. But this does serve to surface the point that style is only going to be evidenced once several systems express the unifying design philosophy/vision and key thematic elements. Builders who build a series of one-offs don't create the recognizable style-thing that Eichler created by applying his vision and its characteristic design elements to multiple homes. Then the question is, how many systems does it take before we call it a style?]
Well, so much for what I think. Perhaps we should just have asked Sam Malek: "Effective Realization of Software Architectural Styles with Aspects." Another $19 download; I guess I'm going to have to take advantage of the IU library!
[4/11/08: There is a great piece on architectural style in Animals are Beautiful People. The architectural styles snippet ends sadly, but the movie is delightful and funny (if you "get" South African humor) and there is a great "I have a hammer, so this must be a nail piece" that has to do with a meerkat and an egg!]
4/8/08: Refactoring—or Rework?
Refactoring may sound better than rework, but shouldn't we think of it as architectural and design rework? The phrase "design debt" is also used here, to sensitize us to the fact that we are borrowing easy development speed early, against painful slowdowns later. The further along we are when we discover the need to rework the architecture, the higher the cost of (and barrier to) change.
In other words, if we could have gotten it right earlier, shouldn't we? That's where modeling, and actively testing our models, comes in. Yes, we'll learn. And yes, not everything can be learned through models, though we can learn where our biggest risks and uncertainties are, figure out where to focus prototyping and early development cycles. But every improvement in design that we make in modeling saves us rework at the code level, and every improvement in early code cycles avoids mounting quality/structural issues that are harder to fix, and more likely to be swept under the covers, downstream.
Of course we have to Pareto the work, move on when our rate of learning and improvement taps out. And of course we want to use a lightweight approach while we're in high learn/improve gear; I've mentioned 3M and Bienfang along with Mr. Sketch, as tool makers of choice here, but whiteboards are good too—you just need walls of them. And a digital camera is essential. Johnnie Chung Lee's interactive whiteboard might be just the thing! Or, possibly, Logitech will bring out a digital marker along the lines of the Logitech io digital pen (though I don't like the stationary prices)? [Are you listening IBM, Microsoft, Sparx, others? We have speech recognition, handwriting recognition, image recognition... How about model recognition?]
In many industries, the agent or counter person is the point of integration between different business systems. Take for example the insurance agent, who integrates across personal and business insurance offerings for the customer who happens to be a small business and car and home owner. In shipping, it is the counter person (or the customer!) who integrates across priority shipping versus ground shipping. Our businesses are letting often rather poorly qualified people be the point of integration. And even when they are well-qualified, they could be better supported by our systems. The architect is the person (the role, the team, the function) who has the unique vantage point of seeing across the system; and the portfolio, domain, product family, chief or enterprise architect sees across systems. The architect, as system (of systems) designer has a unique value proposition to the business, in that the architect can offer an integration at the point of customer interaction that the business units, in their silos, aren't seeing the need for, but which is only a sleeper, waiting for competitors to take advantage of the opportunity first.
Btw, a point along these lines is very eloquently made by Rawl Whittlesey of Delta Airlines in an IASA presentation—the video was on the web, but I couldn't find it again. If you know the link, please do tell me!
"Bauhaus: A German school of applied arts of the early twentieth century. Its aim was to bring people working in architecture, modern technology, and the decorative arts together to learn from one another. The school developed a style that was spare, functional, and geometric. Bauhaus designs for buildings, chairs, teapots, and many other objects are highly prized today, but when the school was active, it was generally unpopular."
Unifying/shaping philosophy: multidisciplinary influence
Defining/characteristic style elements: spare, functional, and geometric
4/11/08 Care and Feeding of your Architect Tree
This is another big week for architect jobs—I just posted 2 architect job listings, with another 2 backed up to post (I need some details back from the hiring company first).
It reminds me that it is useful to be explicit about nurturing the architect tree. Don't get me wrong, there is value to reaping architects from another company's architect tree too, for perpetual "in-breeding" weakens the crop. Still, as this field matures, we have to become more self-conscious about the fact that we have quite distinct pools of competencies that we need to develop, and that from these pools, we need to draw the talent that seeds the next higher layer (in terms of breadth of scope and strategic importance).
[The content of the figure on the left is obviously not new news from me, but I did want say that the chart derives from a much better visual created by the Embedded Systems Institute in The Netherlands. I've mentioned before that The Netherlands is a hotbed of architecture culture and attention, and the Embedded Systems Institute is blazing a trail for our architect world. If you've been following my journal, you already know about Gerrit Muller and the Gaudi project, but if you're just tuning in, I recommend visiting Gerrit's site]
All the personal visioning bits and pieces I did journaling last month has thrown an insight into relief, and it is this: when I'm a service/subsystem/component owner or tech lead, I need to have my ultimate path somewhat in mind. Do I want to be a technical specialist? an architect? or a manager? Do I want to be a first level architect? Or do I want to set my sights on the top tier where my scope of influence is broad, my strategic impact is enormous, and my remuneration is in line with taking on this level of risk, responsibility and degree of impact?
For if I am a component owner and I have aspirations of becoming a first level architect (as my ultimate goal, or as a step on path to broader impact), then I need to start exhibiting the propensities that will make me a good architect. If I am an architect, and I have my sights set on becoming the product family architect, I need to develop in myself what it will take to succeed in that role.
I say this, because what I often face is "that may be all very well for -finger points at architect x- but it is not relevant to me." It is relevant in these ways: it sets the terms of engagement between you and architect x (so you can lead by following well), it sets your expectations about what it means to be in the role of architect x (so you can decide whether you want those responsibilities that come at a cost of losing some responsibilities and focus you have now and probably like), and it helps you see what you need to develop in yourself, so that you can be seen as a suitable candidate for that role and be prepared to excel in it. In other words, if you aren't ready for the role, your manager will probably look to another architect tree to fill their opening—you have to demonstrate the propensity and readiness in advance. Yes, you will grow in the role. But you have to show you have what it takes to make a go of it from the start.
The critical insight here, is that there is a significant shift from tech lead to architect, and again from architect to product line/family architect and again to solution/portfolio architect, and chief architect and enterprise architect.
You need to realize this for yourself, so you carve out some bandwidth for preparing for and demonstrating propensity for the next level of scope. If you show no interest in product strategy, no insight into and taste for dealing with issues around visual modeling or creating alignment among people with diverse perspectives, and so on, you paint yourself as a poor candidate for a role that will make those demands.
And your organization, your management team and senior architects, need to realize this. It takes investment to create pools of talent from which to draw the next higher level (in terms of broader scope and strategic contribution) architects. And you have make some of this investment ahead of the need, or you find yourself looking to other architect trees to harvest already grown architects for your higher level positions. Succession planning has become popularized for senior positions and we have to apply this to our technical specialist and architect trees, not just the management tree. And we have to recognize that succession planning can't jump suddenly into focus one level down from the top. We need to create pools of talent from which the next level of scope and impact can draw, as well as accelerated development tracks to nurture and speed the most promising talent so that our innovation leadership pipe is always ready to meet our growing need.
[Well, if nothing else, I'm a master of mixed metaphor! What, you don't think that takes any particular skill? Hmmpf!]
[4/13/08: Daniel reminded me that the architect's path is not always "up" the architect tree, but sometimes moving around in it, subject to the vicissitudes of opportunity and circumstance (acquisitions, projects get cancelled, etc.).]
4/12/08 Analogical Reasoning and the Building Architecture Analogy
From time to time, we get quite intense push-back against the word architecture being used in the software space. At least some of this frustration has been directed at us, because for many practitioners we are identified with architecture. So, I take that as a compliment even though the terms in which the message is couched are generally distinctly not complimentary! And just to be clear, the use of the word architecture in software, and for that matter architecting, predates us by decades, going all the way back to my infancy, and perhaps before!
The push-back has two threads. One is that the building architecture metaphor breaks down because software is not nails and studs, and stuff. And the other goes along the lines that architecture is design and the supposed line between the two is hard to make tangible so why bother trying. So let's just let design be design. Period. While the rest of ask, shouldn't that be a colon?
Let's look at a candidate position on one extreme: We create intensely complex systems out of code, using terse to the point of a kind of nerdy-snobbism (the more humanly impenetrable I make something, the more kick I get) languages to transfer engineered ideas into digital actions. Moreover, things change so fast that not only can we not learn from our own experience, we can't learn rules and only advisedly break them; indeed, we have to create rules on the fly as we go.
Extreme positions are valid in extreme cases. And only then. (grin)
I take a moderated view. We can use analogical reasoning to good effect as long as we are conscious that we are using analogy and not the thing itself—that is, we use it to the extent that we can extract utility, and we use other tools for pushing our problem finding-problem solving process. If we're using XP and we have an organizing metaphor, we don't let the metaphor bound our system in damaging ways—that is, unless we don't understand the purpose and utility of metaphors.
We use names that make sense, that convey meaning both by reference to the historical precedence with which that word/term has been used, and that make a specific kind of sense that we carefully define. We do that when we name patterns (broker, layers, pipes and filters, bridges, on and on), we do that when we name principles (the most colorfully poetic I've encountered is "tie your horse to a post, not another horse" — this is about moving dependencies and the metaphorical allusion to the cowboy culture of that organization is just delightful), and when we name architectural elements (components, services, subsystems). We create an architectural lexicon that has huge communicative power, in good part because the names we give have analogical meaning that we borrow and refine in our architecture. These we refine in multiple dimensions—in terms of intent, meaning and context of application.
Engineers are engineers. Architects are a sub-pool who are both engineers and artists. An architect has to visualize and communicate the visualization, leverage and create meaning, even be a performance artist to move the intent, meaning and system visualization into not just the heads but the hearts of the team (of teams) that will build the system. This, and just a little bit more (grin), is what we demand of software architects because the number and variety of complex systems our world demands today can't be created by one or two or three of the world's most talented software creators.
Of course, we can look to Hofstadter to be more eloquent on the subject of analogy than mere moi.
As for the line between "design that is architecture" and "design that is not architecture," we go after it by saying architecture addresses the architecturally significant decisions and then we dance on what makes for architecturally significant! In particular, we say the architect decides. The architect. Not the manager. Not the developers. The architect (or team of architects, or those who are wearing the architect hat). Because the context (use context, business context, and system context) plays a role. And further, no set of architecture pundits, no matter how much profound wisdom they have amassed, can sit in isolation from specific systems and draw this boundary. Some decisions are clearly, and generally, architectural, like decisions around system decomposition. And some decisions are generally not.
It may sound gloriously, excitingly simple to say that:
'"architecture" serves to address those structural issues that would guarantee certain system properties, independent of the direct functionalities to be realized'
"architecture" addresses whole classes of systems, rather than individual systems.
Recognizing that architecting takes place at different levels, Dana Bredemeyer started drawing an "umbrella diagram" and it has become something of a signature model for us. For example, solution architecture provides the overarching set of architectural decisions that set context for, constrain and enable, the architecture decision set at the product family level, and that in turn for each product architecture, and that in turn for components (meaning architectural elements). [This is simply a schematic that we use to help convey important insights. I had one architect (?) tell me the arcs should be of different size...]
The surprise in Ian Sharp's NATO (p.24) address is not in the content but in the date: 1969! It was not the first use of architecture in the software field, but an early one, and Sharp makes this case for architecture: software lumps that have no overarching integrity and which are kludged together make for a lousy design. That is, important architecting work takes place at the system level, and has to do with creating a resonant design that fits all its contexts (use, business and system/infrastructure).
At the system level, we have to architect within a messy set of interacting, even conflicting, system property goals across a space of functionality with loads of permutations across user goals, user actions, and system context. The structure has to support the functionality of the system; structure serves behavior. That is, it is incumbent upon us as architects to decide not just how we will achieve the system properties, but which architectural elements will be responsible for which aspects of system behavior and how these elements will collaborate to deliver the behavior that serves system/user goals.
To create this structure, we abstract and generalize across functionality, but we also have to pay attention to corner cases. That is to say, we play some of the same abstracting and conceptualizing game across the space of functionality as we do across the space of structure. And every time we do, we have to test our abstractions against instances that are both central to the conceptualization and those that are peripheral to it, to test and shape the boundaries. To make this worse, there is all the "blooming buzzing confusion" (which I'd associated with John Dewey, but should be ascribed to William James) of the real world as it is and as it is becoming—our clean and simple structures have to support much anticipated and unanticipated variance.
One could argue that an architectural pattern addresses a specific structural issue that arises in a generalized functional context and defines an approach that delivers certain system properties. The architect's job is, in part, to adapt a set of architectural patterns to her specific system context, but it is also to add other enabling and constraining decisions as she sees fit, to deliver on the strategic goals of that system (or set of systems, in a product line/family or portfolio/solution approach).
Returning to the "umbrella" diagram," one crucial point we like to convey is that a person's "center of gravity" (as Dana Bredemeyer puts it) shifts as she moves from component owner to product (or application or system) architect. As a developer and as a component owner, the person can happily focus on technical concerns—on getting the component right in a technical sense. But the architect is responsible for good (technically sound), right (meets stakeholder needs) and successful (actually delivers value). That is, the architect's center of gravity has shifted from purely technical to strategic-technical; from pursuing technical goals to pursuing business goals through technology, determining the technical goals. And the architect can't shrug off the socio-technical concerns that are the package deal of good, right and successful! That distinction, in that little nutshell, has helped some technical people realize they do not want to be architects, and saved them 10 years of discovering it the hard way!
4/13/08: Piazzolla's Lesson: The Hard Way, After 10 Years
Daniel Stroe pointed me to this wonderful story:
At Ginastera's urging, in 1953 Piazzolla entered his Buenos Aires Symphony in a composition contest, and won a grant from the French government to study in Paris with the legendary French composition teacher Nadia Boulanger. The insightful Boulanger turned his life around in a day, as Piazzolla related in his own words:
When I met her, I showed her my kilos of symphonies and sonatas. She started to read them and suddenly came out with a horrible sentence: “It's very well written.” And stopped, with a big period, round like a soccer ball. After a long while, she said: “Here you are like Stravinsky, like Bartók, like Ravel, but you know what happens? I can't find Piazzolla in this.” And she began to investigate my private life: what I did, what I did and did not play, if I was single, married, or living with someone, she was like an FBI agent! And I was very ashamed to tell her that I was a tango musician. Finally I said, “I play in a night club.” I didn't want to say cabaret. And she answered, “Night club, mais oui, but that is a cabaret, isn't it?” “Yes,” I answered, and thought, “I'll hit this woman in the head with a radio....” It wasn't easy to lie to her. She kept asking: “You say that you are not pianist. What instrument do you play, then?” And I didn't want to tell her that I was a bandoneon player, because I thought, “Then she will throw me from the fourth floor.” Finally, I confessed and she asked me to play some bars of a tango of my own. She suddenly opened her eyes, took my hand and told me: “You idiot, that's Piazzolla!” And I took all the music I composed, ten years of my life, and sent it to hell in two seconds.
We use stories to work revelations in ourselves; to learn from someone else's experience. What do we learn from Piazzolla's story? That we need a Boulanger?
As a consultant you're asked to play that role, which is relevant to me, but it is also relevant to you, as an architect who coaches and mentors developers or other architects.
Too many times, exactly the scenario above plays out, where I have to say, 'this architecture is "well written" but I can't find your product/business's unique and differentiating strategy anywhere in it,' and it points to a larger problem that euphemistically is called "development/IT doesn't align with the business" but really means the business leadership, the strategy setters and brokers of responsibility and relationships in the company, provide no grounds for that alignment...
At other times the contribution is less transformative, but still pivotal. A "black hole" in the architecture that everyone is dancing around, sucking energy from the team because they cannot explain to me or themselves how and why it should work, so I tell them to isolate the mechanism in question and go prototype it and the relief is tangible. When there is no precedent, no experience to look to, we simply have to figure out and demonstrate how this cornerstone of the architectural platform is going to work. It doesn't matter that the project plan didn't have a space right then that said "create prototype here."
One chief architect that we've worked with over the years, sees one of his paramount roles as being the person who cancels a project if it has worked itself into a dead end. Maybe the concept as initially conceived, on elaboration proves not to be so compelling, or maybe too much was unknown and the structure wasn't right or just degenerated too quickly to be sustainable, but a lot has been learned. That point is a turning point if, like Boulanger, you don't demolish the spirit, but rather provide the opportunity to rebuild from the foundation of having discovered what really matters. But pushing his humility aside, I know that what this really means, is that most of the time his attention is what keeps teams on track--both because he helps them pay the right kind of attention, and because he holds teams to a high standard and, generally speaking, we high-achievers like that! I've never seen a team so demoralized as a team that knows it is being held to the schedule drum-roll when quality is slip-slip-slipping, or a team that has churned through 5 or 6 years of false starts (with acquisitions, cut-backs and other turmoil). Making sure that teams never get even close to that, making sure teams fail fast and fail safe, is indeed a critical role of the talented architect.
I've made this point before: sometimes we are so busy with the day-to-day foot-following-foot approach to our lives and our jobs that we don't see what a Boulanger sees through a little reading and a few targeted questions.
So yes, I've played that role, though less skillfully I'm sure—still, I suppose at least sometimes I do so effectively or I wouldn't be invited back! And sometimes I fail, in that press of the day-to-day, and yes, I've certainly had cause to kick myself. I once worked with this really promising developer. Smart—no brilliant. By himself, he could have created what his project needed, but it would have taken him twice/three times as long as the business could afford to wait. He absolutely knew what needed to be built, and how, but when he couldn't by sheer force of his intellect get his team on board, he shut down. Gave up on them. Wrote them off. I pulled an architect into his team, and he led the team to a team solution. The engineer didn't think it very good, not nearly so good as his solution. We need brilliant architectures—simple, elegant, evolvable. But they are nothing when they are in one person's head. Our promising developer thought he had nothing to learn from me, that what I brought to him was obvious. And yet he just couldn't see that he, his ego, was the barrier that no-one, himself first and foremost, could get past. I always wondered if I could have done something to help him see that, without breaking something in him but recognizing too that he'll shatter some part of himself on the sharp edges of life if he doesn't become more self-aware. If he doesn't turn around for himself the thought that "it's their problem if they don't get it" to "it's my problem if they don't get it," he can never be an effective architect. There really are engineers out there who think "management should just tell everyone to do what the architect says"—until the architect's decision impacts them, and then they think "management should just tell the architect to do it my way." Or "I need to be on the architecture team" but "I hate meetings where 30 people try to come to consensus because we never come to a resolution and keep rehashing the same issues." Hmmm. The idea that "he takes home a salary, he should just do his job" is seditious and pervasive even when we "know better" if we stop to think about it. For example, as architects we may think, "we did our job, we made the decisions and even wrote them down; now they need to just do their job and read them." It's a nice idea... even if it quickly breaks down if you want human creativity and talent applied to your problem.
So, I return to my question: is the lesson that we need a Boulanger? To the extent that circumstance and our own lack of self-assessment allows limiting blindspots to develop, yes. And we could go hang out on a cliff-face, and let life's fragility goad us into reflective self-assessment (à la Yvon Chouinard)—instead of the Bezos stratagem of imagining we're 80 and looking back at what we did or did not do and accomplish, we put ourselves in that moment of peril so our aspirations and regrets are in high relief. Or we could call time-out on ourselves, and on our teams, to face our aspirations and minimize our regrets on some rhythm. Weinberg suggests leaders keep a journal, and this is a technique I've certainly found valuable. Team "retrospectives" (a success factor in agile cycles) are another, but I'd want to change the name so that we put more of a forward-looking spin on it—I really like that "regret minimization" term (which is also used in economics, but I like the Bezos story).
4/16/08 Piazzolla and Personal Style
Another key lesson from the Piazzolla story and the architectural style thread, is that it is important for the great architect to find his (or her) own distinctive style that is fit to his unique context (business, technology, use contexts,...) and his distinctive aesthetic and design philosophy. As important as this is, though, I expect that the ten years of becoming intimate with the styles of other great composers, gave Piazzolla something important too. Studying and emulating the work of the great masters of one's field is important. As our discipline becomes more self-conscious about the need to document our decisions, our design elements and our reasoning, our discipline will also become more sophisticated, because we will be able to create great derivative works where derivative is the most economical and effective approach, as well as greater, more inspired unique architectures that are fit to a distinctive competitive strategy.
4/19/08 Cowboys and Cats
James Hooper has really found his blogging voice and it is funny and insightful! His "Don't Fence Me In" post is a superb example of weaving stories, humor, allusion, and insight to make a compelling case. I'm indebted to this post for pointing me to the "herding cats" video from EDS on youtube!
Returning from the open enrollment Software Architecture Workshop last night, I unabashedly listened in on the conversation two faculty members were having as they waited next to me for their flight. They were returning from a conference and talking about technology in modern expression, and how that changes what can and should be done in university classes.
Of course, it has been on my radar that every year we are graduating a batch of students who have more technology experience than those who have been in the workforce for a decade or more—our new graduates have been integrating technology (including coding) into their day-to-day lives since they were in elementary school. They've set up and been sys admins for their neighborhood wireless clouds since their tween years, they've programmed games and robots, they blog, twitter and text, create movies to express their ideas, and so on and on.
What I hadn't been thinking about was where this leaves faculty—in the dust, for the most part! There is a cloud that still has to settle around how and what to teach this new generation of techno-wizards. James, as you'll see from his blog, is an Enterprise Architect at Saint Louis University. Very interesting times for universities!
4/19/08 Blog Voice
Speaking of distinctive and insightful voices, Rodney Willis has created a blog and his first blog post does a really nice job of illustrating the importance of minimalism in enterprise architecture, using a vivid, evocative analogy to do so.
4/19/08 Workshop Reflections
In Rodney's blog post just referenced, reflecting on the workshop this past week, he says:
"Perhaps the real goal of any workshop such as this is to stir the imagination and awaken the mind."
Yes! But I do want to at least waive a hand at the process as the crucible for the outcome—doing the work we did, in the order we did it, created "flow" both for the smaller teams, and in the larger workshop group. In a very short space of time, a bakers dozen very smart, very experienced architects with very different backgrounds were getting a lot out of working together and making amazing progress from that "green line on a blank page" to walls full of architecture alternatives and ideas that are the cornerstone for iterating, refining and elaborating to reach a compelling system concept and robust architecture. Intellect and experience are critical. But divergence is an all too common outcome of that assemblage of attributes.
Of course, I don't discount attitude as a key ingredient here. The workshop was so full of wonderful interaction, and I learned so much, that I sheer forgot to mention the "enthusiasm persuades" lesson. It was demonstrated admirably by the workshop participants but I forgot to put a spotlight on it, to point out how key that is to the success of any endeavor we undertake. But it is striking to me that the technical outcome we seek is so shaped by attitude, and enthusiasm and positive expectation is such a powerful predictor of the outcome we get because it is enabling, while dispassion, and worse, griping, is disabling, miring attention in problems.
Thanking others in the workshop, Brian said
"I wish every educational experience could be that full."
To have someone as experienced and talented as Brian get value out of the workshop says a lot about Brian—he makes value happen—and it is rewarding to have been a part of enabling that experience. That said, I'm very happy to be in a position where I get paid to get that kind of rich educational experience myself! Thanks guys! (Yes, once again, I was the only woman...)
Aside: I just responded to Sara with "How do you know what I'm thinking; do you see inside my head?" and in a snap she said, "Yes! Yuck!" Dana popped up from his coding hole and said "Amen!" and laughed for minutes. Hmmmf! I get no respect.
4/21/08 Self-Actualizing Awe-Struck Seekers
Peak peaked my interest and Rishi cemented it:
I have to read Maslow at the source, so I'm putting
Management on my stack. Anyway, I've been reading "applied
Maslow," namely Peak, and to be honest my interest waned
the further in I got; perhaps there was just too much competition
for my attention, so I still want to jump ahead and read around to
see if there's more I like. At any rate, you can give Maslow credit
but no blame for the inferences I draw here:
There are many who fear that we are creating a culture of compliment
junkies (at least, I've heard this said in various contexts), but if
Maslow's hierarchy is right, then one only needs so much of that;
like food and other items of basic subsistence, external
gratification only takes us so far on the motivation scales, because
we reach sufficiency. To "peak," we have to move on to the internal
gratification of self-actualizing experience. So, we need
periodic sustenance in recognition terms, and I'm not nearly so
worried about compliment overdose or junkies as some people seem to
be. On the contrary, I think people are generally very chary with
compliments and recognition, for not only are they busy, busy, busy
but it seems like giving up something on the dominance hierarchy to
give recognition--like, some worry that they'll give the impression
they've made less of a
contribution if they give someone else recognition for their
contribution. But that is the marking behavior of a territorial
animal who seeks to lead through domination, rather than leading by
appealing to the aspirations, hopes, dreams, desires of others.
Give recognition; give that buzz of pleasure. Frankly, as much as
you might intend to, you're not going to overdo the compliments and
recognition bit--you just have too much on your plate. So you have
to make time to pay attention to find meaningful words of
recognition, and there is a reward--architects often worry about not
having "positional authority" but you do, for you have the power to
make people feel good about themselves; recognition from you carries
more weight. Leaders motivate and align. Recognition is a
motivational platform. And give yourself and your team
opportunities to feed that positive cycle of seeking and discovery
that creates the "flow" of high-performance teams. This doesn't have
to be in the large, like creating the next market-storming
innovation; indeed, I've had this experience in teams across the
spectrum from "toy" university projects to "maintenance"
(more appropriately, evolution) projects to
product development work in ground-breaking areas.
There are many who fear that we are creating a culture of compliment junkies (at least, I've heard this said in various contexts), but if Maslow's hierarchy is right, then one only needs so much of that; like food and other items of basic subsistence, external gratification only takes us so far on the motivation scales, because we reach sufficiency. To "peak," we have to move on to the internal gratification of self-actualizing experience. So, we need periodic sustenance in recognition terms, and I'm not nearly so worried about compliment overdose or junkies as some people seem to be. On the contrary, I think people are generally very chary with compliments and recognition, for not only are they busy, busy, busy but it seems like giving up something on the dominance hierarchy to give recognition--like, some worry that they'll give the impression they've made less of a contribution if they give someone else recognition for their contribution. But that is the marking behavior of a territorial animal who seeks to lead through domination, rather than leading by appealing to the aspirations, hopes, dreams, desires of others.
Give recognition; give that buzz of pleasure. Frankly, as much as you might intend to, you're not going to overdo the compliments and recognition bit--you just have too much on your plate. So you have to make time to pay attention to find meaningful words of recognition, and there is a reward--architects often worry about not having "positional authority" but you do, for you have the power to make people feel good about themselves; recognition from you carries more weight. Leaders motivate and align. Recognition is a motivational platform. And give yourself and your team opportunities to feed that positive cycle of seeking and discovery that creates the "flow" of high-performance teams. This doesn't have to be in the large, like creating the next market-storming innovation; indeed, I've had this experience in teams across the spectrum from "toy" university projects to "maintenance" (more appropriately, evolution) projects to product development work in ground-breaking areas.
Grady Booch characterizes himself (3/18) as an awe-struck seeker, and I sense that this is a key characteristic of Maslow's "peakers." At least for me, "awe" is a buoyantly positive stance that is energizing. Those who actively, perpetually, strive, seek, investigate, challenge--mostly themselves--have to create energy. External recognition provides fleeting satisfaction; we desire recognition, and it gives some succor to the spirit. But it is the intrinsic compulsion to do what we are good at, to seek, discover and bring ourselves to the point of little and big epiphanies, that generates self-actualizing. We seek to be in awe, which becomes a self-fulfilling cycle of awe-struck seeking.
Scott Berkun makes the point that what appears to be an epiphany, isn't; it is not a moment's worth of amazing, unprecedented discovery. The message from Scott is that we should not seek those illusive moments, but rather focus on the hard work that precedes any moment of "revelation" when the pieces fall into place and all the discoveries add up to something.
I see it differently. I think those moments of epiphany--for example, that moment when the product concept suddenly jumps into compelling, heart-pounding, exciting focus--are the kind of "peak" experiences we strive for. The hard work is the preparation, but the epiphany is the reward. And the joy of epiphany should not be discounted. Awe, to me, is as much internally as externally focused. That is, the ability to be surprised by oneself, and appreciate that, is as important an attitude as the attitude of being in awe of the discoveries, the writing, the beauty in others and in nature. Self-actualizing is in part about self-appreciating--the reward we give ourselves for doing something that works. Only in part, but it is an important part, because it is what enables us to create energy without relying on others to feed our ego to fuel our energy.
The other key part is appreciating others. Being in awe of them. For little is accomplished, little is discovered, by one person alone. Great minds bounce ideas off one another, furthering the discovery, fueling the joy of discovery. This kind of collaboration, asynchronously through reading and writing, but also, very importantly, in teams working together, quickens the pace and the pulse of discovery, produces the joy of man's desiring.
Joy of Man's Desiring is the title of the novel, and what struck me when Dana read it to me (romantic that he is), is the joy in nature that is so vibrant. I seek those awestruck moments in nature because they put me outside myself, produce a feeling of such sheer joy that I am diminished; my ever-present processing, analyzing, seeking is stunned into humble quiet. In those moments, losing myself in the blue of a forget-me-not, feeling my self fade with the sun from a mountain top, what is important has more clarity. So, in all, balance is key. And awe-struck seeking is a very balancing orientation.
"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." moi, 10/5/06
To that I'd add, architects are an unusual bunch. We started out as developers, where, for the most part, our greatest mental intimacy was with the computer we poured thoughts into and which readily gave us performance feedback. Yet we were attracted to the complex of challenges and rewards of creating great systems with and through other people. To me, both sides of that are compelling--the opportunity we have to shape great systems, and the opportunity we have to work with and lead bright people, people who inspire and move us, change what we are capable of being, and what we are capable of accomplishing together. If we revel in that, enjoy the creative foment of collaboration, we seek and foster it, and make the team richer and more likely to succeed. This is a unique time in the history of the world where many orders of magnitude more people around the globe get to participate in highly creative, highly engineered works that push the frontiers of what is possible every moment, 24x7!
"We act as though
comfort and luxury were the chief requirements of life, when all
that we need to make us happy is something to be enthusiastic
about." - Einstein
4/22/08 A Muse to Me
Looking at the experiences of many of the greats in art and music, we see the role of a muse, a mentor, a disciplinarian who holds a vision of the artist, and inspires him. Daniel, my scout, my muse, wrote:
A side note about Nadia Boulanger, she was Philip Glass' teacher. There was a classical music radio show and it showed how she was demanding Philip to compose a la maistre, like Mozart, Beethoven; she was the disciplinarian.
This is related to the self-actualizing thread. A muse is important to the self-actualizer. My role can be important to architects I encounter, architects I see--some insight I have shines a life-changing light on some area for the architect. These are the architects who in turn most lead me, for they explore places that are exciting also to me, and they are most open to me. They are the never-complacent seekers, happy in exploration and discovery, always yearning for the next accomplishment, the next epiphany, extracting joy from the work of creation.
4/22/08 Soda Pop Thinking
Ugh! Those last two entries are, I fear, the "soda pop" of thought--all sugar and fizz. As for beverages, a workshop participant said last week 'In Russia, we say "caffeine in, code out."' I joked: "In the US, we believe it's pizza in, code out." And segued to Amazon's "2 Pizza Principle" for right-sizing services and the teams that build them.
4/22/08 Happy Earth Day!
We enjoyed a splendid evening outside
and planted a shrub; it was as close to a tree as we had at hand and
the kids wanted to do something to mark Earth Day.
Copyright © 2004 Bredemeyer Consulting
Joe Ficko drew these pictures for me for a workshop slide on "the software problem," but they seem to fit well with the theme of the weight of global warming that came up journaling in February and March.
Rodney Willis has brought insight to the patterns conversation. Rodney is proving adept at using stories and analogies to inspire and lead. But I don't want to be a spoiler; do visit Rodney at his new home in the blogosphere.
4/24/08 Microsoft Architecture Journal Issue on Architect Role
I am subscribed to the MS Architecture Journal, but didn't get my (hard) copy yet... So it's thank you Charlie for pointing me to the current issue which focuses on the Role of the Architect. The previous issue focused on mobile device architecture, and was also very interesting.
I'm so happy architects like Charlie are watching out for me! Daniel too.
Inspired by Brian in the last workshop, I had this idea for a HelpMatch (still need a new name) business strategy principle that has the catchy name of "Pay it forward." (Well, I suppose it's catchy--Rodney thought it sounded like a movie title... Oh yes, it is a movie title, and a movement! ☺) This would leverage the "pay it forward" (based on "what comes around, goes around") ethic in that people who "paid forward" would have a bank of goodwill to draw on in the future, should they ever need help. Those without any balance of goodwill when they go to draw help, could make a commitment to "pay it forward" by committing to give help. It wouldn't have any specific timeframe, necessarily, and could be as simple as helping to get the word out about HelpMatch, but it would allow the receivers of help to do so with dignity, knowing they were going to put something back into the system as soon as they could.
I don't know how that relates to Charlie's pointer. But wait... I suppose if you found it helpful, you could return the favor and point me to something Charlie, myself, and other Bredemeyer or Trace readers would find valuable. Grin.
4/24/08 Frank Gehry On Customer Interaction and Innovation
"I spend a lot more time with clients than people could guess. Because I think that is the way we move forward and they get what they want and they feel comfortable about it. It is a process that lets them know you're listening to what their problems are. But it also is a process that creates the opportunities for invention, because it is that interaction that makes it exciting and rich. And I love the process most of all, the people process better than the final building actually."
Frank Gehry, quoted on Architecture Sketches Blog, 9/30/05
4/24/08 Jørn Utzon On Delight!
"On the road from the first idea - the first sketch - to the final building, a host of possibilities arise for the architect and the team of engineers, contractors and artisans. Only when the foundation for the choice between the various solutions derives from the awareness that the building must provide the people who are to live in it with delight and inspiration do the correct solutions to the problems fall like ripe fruits."
Jørn Utzon, quoted on Architecture Sketches Blog, 9/26/05
4/25/08 Event-Driven Architecture
4/25/08 Business-IT Alignment
4/25/08 Architecture Strategies
Strategies and principles for availability and scalability:
If you want to rave about my journal, I can be reached using the
obvious traceinthesand.com handle. If you want to rant, its
email@example.com. Just kidding,
welcome input, discussion and feedback on any of the topics in this
Trace in The Sand Journal,
my blog, and
the Resources for Architects
website, or, for that matter, anything relevant to
architects, architecting and architecture! I commit to using what you
teach me, to convey it as best I can, help your lessons reach as far as
I can spread them. I try to do this ethically, giving you credit
whenever I can, but protecting confidentiality as a first priority.
Feedback: If you want to rave about my journal, I can be reached using the obvious traceinthesand.com handle. If you want to rant, its firstname.lastname@example.org. Just kidding, I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I commit to using what you teach me, to convey it as best I can, help your lessons reach as far as I can spread them. I try to do this ethically, giving you credit whenever I can, but protecting confidentiality as a first priority.