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

- February

- March

- April

- May

- June

- 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

 

 

 

 


 

December 2007

12/2/07 Architects Architecting Architecture Notes

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

 

12/3/07 YAGNI, YAGNI Not

Working with a team recently, I simply had to push back against the YAGNI principle being invoked unquestioned in architecture. We have this (like the mythical lemming) tendency to overcorrect. Yeah, yeah, generally speaking we've had something of a problem with "push innovation," rather than innovation that fits the demand ecosystem. And requirements change, or at least our understanding of what is required changes or something in the physical environment or business or use context changes, and impacts requirements. One response to this uncertainty is to build our system piecemeal doing system value discovery, system definition, system design and construction as we go, and invoking YAGNI at every point where we could have taken other use contexts into account. This means we gather requirements as late as possible, and minimize our losses when we do have to cut them. It sounds pretty good, especially if we've been scarred by cancelled projects. It's all very well, if we're Alice:

'Would you tell me, please, which way I ought to go from here?'
'That depends a good deal on where you want to get to,' said the Cat.
'I don't much care where --' said Alice.
'Then it doesn't matter which way you go,' said the Cat.
'--so long as I get somewhere,' Alice added as an explanation.
Lewis Carroll, Alice's Adventures in Wonderland

One may push back against that and say, "Oh, but the customer holds the vision, and we rely on the customer to guide us to what they need." The customer? Would that it were so easy. But, yes, we need to have a vision and a strategic plan for reaching it. We can let "the customer" hold the vision. But surely we'd rather we created the strategy that determines our competitive position? With input from the customer, yes, but also with input from other stakeholders too.

We need to strike a balance. An agile approach to system definition and architecture, allows us to face uncertainty, do value discovery and system definition and design, scope, and re-scope, factor and re-factor, but to do so with lower cost, more mutable constructs than code, especially for larger systems. (If the average developer delivers 6,200 LOC/year, we have to get real about how mutable code really is.)

As architects, we're responsible for structural integrity as well as the strategic objectives of the system. Strategic objectives focus on how we will compete over the strategic horizon, which is longer than one release cycle. Architecture is where we address cross-cutting concerns and concerns that arise when we take the long-view into account. In a piecemeal growth approach, we reactively respond to cross-cutting concerns as they emerge; refactoring is then our primary tool, but that becomes expensive, error-prone and risky in large, complex systems.

In Visual Architecting, we apply the agile principles of stakeholder involvement and iteration to refine our system concept, definition and architecture. We use models and abstractions to work with the whole system, making tradeoffs inherent in addressing cross-cutting concerns. As we do so, we can't dismiss every opportunity and every threat with YAGNI, or we will be hamstrung when we come to addressing cross-cutting concerns and risk, and lowering the cost of change. We open the box enough to do a good job of building a system that is robust to likely changes and threats, and resilient to lower probability but high consequence risks, but not so much that we get paralyzed by the unknown and unknowable in our complex and changing world.

With a (business, product and technical) strategy in place, we can set about incrementally building out our vision, adjusting our strategy if what we learn changes something significant. You could object that this is just waterfall, or cascades, or whatever. But it is crucially different to typical waterfall approaches in that the strategy and architecture are built applying key agile principles (stakeholder involvement and iteration), though loosening up on certain of the agile principles (code delivery and YAGNI) during strategy and up-front iterations on the architecture.

We think that code is the holy grail, but value is the holy grail and code is necessary but not sufficient to reach the holy grail. Forsooth, we can write a whole lot of code that fails to deliver the value we seek, so code isn't the be-all and end-all of value delivery.

12/8/07 Simplify, Simplify, Simplify (Eb Rechtin)

I'll leave you with these quotes I found reading let my people go surfing: the education of a reluctant businessman by Yvon Chouinard (founder and owner of patagonia):

"Simplify, simplify."

        H. D. Thoreau

'One "simplify" would have sufficed.'

        Ralph Waldo Emerson, in response

 

12/25/07 Seasonal Tidings, from South Africa

    Just visiting...

 

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 written 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: December 2, 2007
Last Modified: December 01, 2011