A Trace in the Sand
Online Architecture Journal
by Ruth Malan

I also write at:

- Resources for Architects

- Architecture Action Guide

- Trace In the Sand Blog
 

HelpMatch:

- HelpMatch Wiki

- HelpMatch Google Group

Trace in the Sand
Architecture Journal

2011

- January

- July

- August

- September

- October

- November

- Current

2010

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

2009

- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

2008
- January
- February
- March
- April

- May
- June
- July
-
August
-
September
- October
-
November
- December

2007
-
January

- February
- March
- April
- May
- June
- July
- August

- September
- October
- November

- December

2006
-
February
- March

- April
- May
- June
- July
- August
- September

- October
- November
- December

 

 

 

 


 

November 2007

11/1/07 Architects Architecting Architecture Notes

My architects architecting architecture-related notes from past months in 2007 are at: October, September, August, July, June, May, April, March, February, January. And for 2006: December, November, October, September, August, July, June, May, April, March, February.

 

11/1/07 EA Blog Links

There was a call for blog links on Shared Insights EA community, and I've harvested some of those links:

11/13/07 Decomposition and Composition

Much of what we have been pursuing in the software development technology space has to do with the problem of composition—making parts more plug-and-play, addressing implementation language independence, remote invocation and location independence, and so forth. We've seen technology waves, each doing more to address the challenge of composition of systems from larger grained, (potentially) distributed elements: components and CORBA/COM; services and ESBs.

Architecture is about system design, about decomposition taking a system perspective to address cross-cutting concerns, so that when we come to compose the system, it will indeed have the properties we, and our stakeholders, intend. 

Software engineers often come at this from a parts perspective—that is, they want to know how to create better parts. My orientation is that "better" has to be judged in terms of the context. Yes, there are the universals—crisp abstractions with clear separation of concerns, cohesive responsibilities, balanced distribution of responsibilities, isolation of external dependencies, areas of complexity or areas that change with greater frequency than the rest of the system (e.g. hardware dependencies, where hardware innovation is fast paced), and so forth. We can look at a part, to see if it has a cohesive set of responsibilities. Still, to see if responsibilities are balanced, we need to look across the set of parts. To see if (similar) responsibilities are replicated across parts, we need to look across the parts. So "goodness" of a part is not just a local (to the part) consideration.

Moreover, the functionality and the properties of the system arise from the interaction of the parts. Intentional design is the attempt to make system capabilities (including properties) a matter of conscious decisions and choices. Too often, properties are emergent, that is they are merely a matter of happenstance; they are just ambient to the system. It is true that our systems are complex enough that we can't prevent all surprises and fully control the system properties through intentional design. But we certainly won't do better if we don't try!

This is why we need SOA, not just services and ESBs. Intentional system design is not just about designing independent services that can be strung, post-hoc, together by a workflow/BPM engine.

11/14/07 Why Bother With Models?

I watched part I of Eric Evans presentation on Domain Driven Design on InfoQ (DDD: putting the model to work). In addressing "Why bother with models?," Eric made the point "Critical complexity is in the business domain itself ... although there may be technical hurdles to be overcome, these are not the main hurdles."

He demonstrated how cheap and easy it is to throw up ideas on a white board... often people go until they get to the first decent idea and stop there... but if we go further, we end up with a lot of ideas and at some point we have to decide which ideas we go with.  Eric notes that there isn't a correct model, there are many models (even an unlimited number of models) and we need to choose one that is useful for our particular need.

I like Eric's point that it is cheap to explore through models—while they are rough sketches on a white board and the cost is terms of the discipline of driving out ideas, of letting go of the first idea and looking for other ideas, and sifting across the ideas for relevance to the problem at hand.

In part I, Eric is essentially creating a domain concept model, reifying this model into a system concept model, and then contrasting it with the concepts in the algorithmic space of route optimization. I like the way he positions models, and found his talk a good demonstration of his message—because I was coming up with different models on the fly as he talked. The pace is slow for anyone who is conversant with domain modeling, but I'm sure Eric was pacing himself given the introductory nature of a positioning pitch.

Of course, I have my own gavel (visual modeling, strategy and value discovery before tactical design, iteration, writing down decisions and their justification and explanation, etc.) that I pound mercilessly. I appreciate others pounding out some of the same tune.

11/16/07 State Management

Holger gave me some constructive criticism on my website (navigation). I curbed my instinctual reaction to defend myself, and got good feedback that is most valuable to me. But even more importantly, it gave me a personal example of the power of framing—and reframing. As soon as I reminded myself that he was giving me feedback because he cares enough to want to save me from making a bad impression, I saw his feedback in a quite different light, and it became more useful to me.

I keep trying to get my kids to understand that, yes, environmental context matters, but they play a powerful role in determining their internal state and shaping the environmental context. We choose how to interpret what we encounter. And even if we can't choose every encounter, we can influence how they unfold.

Being positive, and interpreting actions and intentions in a positive way, is a powerful shaper of our own, and others, experience. There are those who fear we are creating "compliment junkies," but I think that there are already so many people out there wielding baseball bats on other people's egos that we don't have to worry that our bit of positive force will do harm! Quite the contrary! For example, everyone I've worked with who grew up in California has been extremely positive, and they have literally squirmed at the least bit of negativism or pessimism; and California is a hot-bed of innovation. The two are not at odds. I'm not saying everyone has to be positive and optimistic, but that a positive culture is a ready host for innovation.

Being positive, and managing our own interpretation of our encounters and experience so we stay positive, builds a self-reinforcing positive environment. This doesn't mean empty rah-rah cheerleader stuff to pump up the team. It doesn't mean hand-waiving away risks and threats. It does mean looking for the positive outcome, and working to remove barriers so we reach it. It does mean working with ourselves if at first we feel a negative knee-jerk reaction, to find the good in the situation.

As engineers we tend to think that the state of the team is simply ambient, and we forget that we can raise and lower the "temperature" of the team by first managing our own state and setting an example of being positive. And, yes, it can be hard to keep rev'ing up our own energy so we can stay positive in the face of those self-appointed to wield baseball bats to keep expectations and egos downsized. I've been in this software game long enough to have my share of bruises, but I've also been around long enough to know that generally the person on the offense is shielding a point of vulnerability.

11/16/07 Seeds

I was working with a group and I kept feeling like the world had turned monochromatic, like I'd stepped into someone's nightmare, rather than their life. There was so little joy in the work being done, no sense of meaning, of value. Being a leader in that space is hard, because strong antibodies have been developed to keep the culture amorphously even. But lack of leadership means lack of direction, and resets when a direction is tentatively sought.

A culture that is hard, arrogant, is, I've learned, quite brittle. It perpetuates a blinkered view, and is prone to being blind-sided, and with these surprises, reset after reset produces a malaise and a self-defeating erosion of expectation and enthusiasm. Failure does not remedy arrogance, for the finger of blame always points elsewhere, and management is an easy target when strategic direction is not clear. The blame game lends itself to a self-reinforcing, implosive cycle. To break free of it, we have to take ownership for our own state, and discounting the importance of enthusiasm, of passion, simply doesn't cut the mustard for me. 

Robert Louis Stevenson once said,

"Don't judge each day by the harvest you reap, but by the seeds you plant."

Working in software, you learn there are people who understand this, and those who would take umbrage at it. We have our share of curmudgeons. Still, if a bleak perspective dominates, the organization becomes an inhospitable place. We can plant the seeds of hope, a vision of delivering compelling value, of competing through systems that make our customers' lives better. Even curmudgeons can get behind that, when they can see tangible steps to get there—a way to harvest (working code) each day, or at least each week.

Creating collaborative work products, including software systems, takes good leaders and good followers. Seeds need to be planted and harvests need to be reaped, that is true. Even so, if you are a leader, seeds must come first. Inspiration and action. "Ready, aim, fire!" not "fire, aim, ready?"

Mixed metaphors... But while we're spinning metaphorical dinnerware, if you perpetually see the glass as (more than) half empty ... reading this journal must be like... having teeth pulled???

11/17/07 Unconscious Incompetence to Unconscious Competence

Sara is an angel in IU's Nutcracker production, and rehearsals together with all the usual lessons is a logistics monster. The upside is that I actually had to sit through Sara's piano lesson yesterday. Sara was a little tense having me there—she likes to play for me, but I don't usually hear her lesson, which involves corrective feedback and that is hard for her. Given her bit of fluster, her piano teacher talked about the unconscious incompetence to unconscious competence cycle (yes, Sara is 8, but she has a conceptual grasp well beyond her years). Her teacher talked about toddlers learning to walk, and how at first that takes concentration and conscious effort, but becomes something so unconscious we take our competence for granted; until we try something new, like skiing, and we quickly find ourselves back at the conscious incompetence phase of the learning cycle.

We had a slide on this learning cycle at the beginning of some of our workshops and I moved it down into the notes. I think I'm going to emphasize it again, at least in groups with a mix in experience levels. It provides a way to talk about the difference between being exposed to modeling and using models in architecting to support decision making (and to explain and defend the architecture). When we begin modeling we don't know what we don't know, and don't know how to value those who do it well. On the other hand, when we are comfortably competent, we tend to forget what was hard for us when we were starting out because it has just become as natural to us as walking.

Note: For those (whose daughters and wives, or sons and husbands) are interested in ballet, Indiana University's 4 performances of The Nutcracker will be streamed live at http://music.indiana.edu/iumusiclive on Friday, November 30, at 8:00 pm, December 1 at 3pm and 8pm, and December 2 at 3pm.

11/30/07 Getting Inspired

Here's a quote I think we should embrace as leaders and shapers in product development:

"One of our core philosophies," explains Anthropologie president Glen Senk, "is that we spend the money that other companies spend on marketing to create a store experience that exceeds people's expectations."

from Fast Company, Sophisticated Sell, November 2002

Interpreting that in our architect frame of reference, it goes something like this "we (will) spend cycles developing products that exceed people's expectations." Yes, this is the delight theme. It means finding the dimensions along which we should excel to surprise and delight customers. It does not mean we have to surpass the market on every dimension. It means we have to figure out what is exciting to our (would-be) customers—what makes our customers lives the way they want them to be.

This "circle of excellence" notion is exciting, because it brings to the foreground the fact that for customers, and for development engineers, excellence is compelling, and we need to pick the dimensions along which we will strive to excel—that is, what capabilities are within the circle, and what are the properties that define excellence for our product. This is very much about scoping, and being clear where good enough is just that. This is not just about high-end products with design sizzle; it is also about a low-end product where ease-of-use, core features, and robustness may be within our circle of excellence—where beating customers expectations has to do with lowering the usability barrier, not just the price.

People want to work on something set to succeed, something that will create a (positive) buzz in the marketplace. Our vision for the product, for the distinguishing contribution it will make, is as important to changing the terms of the game from a focus on selling to a focus on market pull, as it is to creating the kinds of great teams, super-stars in innovation, that we want to have in product development.

Across a broad spectrum of industries, insight into what customers need, together with insight into what we can make possible with technology, are the shapers of innovation. This partnership between customer understanding and technology understanding is vital to innovation. It gets lost in our organizational divides between marketing (or "the business" in IT terms) and R&D (or IT). We have to recognize that these are artifices we have constructed to try to manage organizational complexity, but they become fiefdoms that misshape the opportunity to collaborate effectively on market-determining innovations.

For architects to play a more effective early role in creating the product definition that bounds the innovation opportunity, the architect has to be inspired and inspiring. The architect has to be there with a personal mission—to understand how technology can be used to create an experience that exceeds the customers expectations, brings them closer to what they envision for themselves. Gives them time back. Creates an image they want to live by. Whatever it is that makes our product or service powerfully compelling to the customer; sets tipping points tipping because our customers are excited advocates who transmit energy and excitement about our product.

 

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 ruth@traceinthesand.ru.cz. Just kidding, I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I commit to using what you teach me, to convey it as best I can, help your lessons reach as far as I can spread them. I try to do this ethically, giving you credit whenever I can, but protecting confidentiality as a first priority.

Referencing journal entries: I figure at some point, someone, somewhere, is going to find something I've written worth linking to. I know, it's a long shot. But hey, it's a world full of different people, and if I write long enough, someone is going to stumbleUpon this Trace in the Sand and be delighted enough to want to tell someone else about it. 

So, here's how: To link to a particular entry, I bookmark and link to section titles from the sidebar, so you can copy the shortcut (from the sidebar).

Restrictions on Use: All original material (writing, photos, sketches) created by Ruth Malan on this page is copyrighted by Ruth Malan. All other material is clearly quoted and ascribed to its source. If you wish to quote or paraphrase fragments of material copyrighted by Ruth Malan in another publication or web site, please properly acknowledge Ruth Malan as the source, with appropriate reference to this web page. If you wish to republish any of Ruth Malan's or Bredemeyer Consulting's work, in any medium, you must get written permission from the lead author. Also, any commercial use must be authorized in writing by Ruth Malan or Bredemeyer Consulting. Thank you.

Copyright © 2007 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: October 21, 2007
Last Modified: December 01, 2011