|Entry for hiranabe||Syndicate hiranabe's entries|
Context matters but listen to your elders.
Author: hiranabe (5:51 pm)
I attended a wonderful workshop "Architecture in an Agile World" led by Dennis Mancl, Bill Opdyke, and Steve Fraser at SPLASH2010 yesterday.
The final Report is here, and with the last year's one, I think we had explored a interesting field of Architecture and Agile world.
After the session, I again thought about architecture. I was not able to speak loud in the workshop, but I'll ramble a little about it here.
A question still sticking to my head is "can a sound architecture really 'emerge' as Agile people say ?" (I like the concept of Martin Folwer's "HarvestedFramework", but questioning it somehow.)
Agile believes that the context matters most, and the most effective(simple and working) architecture can be havested in the course of adding business values to the system and refactoring through iterations. Software development is a learning process, and the architecture will emerge as you learn the problom as well as the solution domain.
I'm a strong believer of the latter part, but the learned knowledge can be used beyond one project, can't it be ? The application you are working on is not the same as the last one, but the knowledge around that area is stored in your head through experiences.
Not every piece of knowledge can be written (as patterns like POSA or other way). But you can use human beings as a container and conveyer of knowledge.
Architects are such people.
Grady Booch used a word "tribe memory" for the knowledge storage I described above.
The code is the truth, but it's not the whole truth. And there is a loss of information from design to implementation such that a lot of interesting information is kept in tribal memory. And that tribal memory deteriorates over time.
So what I wanted to say is;
* Agile says context is the most important thing, but
* There is also usable knowledge outside.
* Some is described as patterns in POSA-like literiture, but not much.
* Most of the knowlege is in experienced people's heads in a tacit form.
* Architect is a human being who can carry the knowledge across rojects he experienced. Using that knowledge, he balances the current business needs and long-term stability of the architecture.
And the bottom line is;
"Context matters but listen to your elders."
In the above discussion, I used design and architecture (and maybe framework, too) not very distinguishablly, but my definition of architecture is as Booch's: "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. --Grady Booch"
By the way, In "Ise", Japan, there is a big shrine called "Ise-jingu". There the main shrine building is re-built every after 20 years. They actually break it into parts, exchange some to new ones, and move them to the new place, and re-assembl them again. Do you know why they do that ?
Building a shrine is a difficult work, needing special knowledge and skill. There is a blue print but no detailed description of how you build it.
So, every after 20 years, elder generatoin and younger generation of "builders" get together and make a team, and do the shrine rebuilding project. This is how they transfer tacit knowledge in the elder people to the younger people. They know that not the whole knowledge is documentable, and experience is the most effective way to convey the knowledge.
Getting back to the workshop, I really want to thank Dennis Mancl Steve Fraser for nice facilitation and final write-up, and especially Bill Opdyke, who invented the concept of "refactoring" and started the new world of design.
Trackback URL of this entry
Posted: 2010/11/1 10:53 Updated: 2010/11/1 10:53
Sharing knowledge that isn't explicit is very helpful. Missing this piece leads to trouble.