Initial question:

Are metaphors sufficient?
Is architecture just going to emerge gradually from a succession of refactorings?

Some issues with architecture-centric approach:
- the architecture coming from the sky syndrome
- the architect in some ivory tower taking ages to decide something stupid
- the architecture as a straight jacket killing all creativity and discouraging any refactoring
- architecture is synonymous to big-up-front-design (therefore bad)

Some issues with not paying enough attention to architecture:
- emergence of design hits a wall after a few iterations
- some non-functional requirements hard to retrofit late in a system
(examples: security, safety, performance, generalized "undo" mechanism)
- Conway's law (architecture = team structure)
- Driving planning only based on "value to customer", not looking at risk, in particular
technical risks, of which many are architectural.
- Not leveraging company's asset and know-how.

Some facts/ideas/issues/suggestions:
-Many systems (especially in MIS) have a pre-existing, implied, de facto, or inherited architecture
that does not require much effort to evolve. Example: language, major compoenents, platform are
already decided.
-Metaphors not used much in practice. Many team do not know how to use them effectively. Though they are great tools for communicating succinctly the few key ideas one need to know about how the system works.
-System partitioning: do you conquer and then divide (build first a small prototype, then break it), or first divide and then conquer.
-Anticipation: how early, how late? Too much anticipation may lead to solving problems we won't have.
-Architectural decisions must be taken at the "latest responsible moment"; team must be able to decide what they do not have to decide. ("If it is not important to make the decision, then it is important to not make the decision" Author unknown).
-Aspect-oriented programmming may help (organize concerns and non functional issues across whole system).

More ideas:
-Need to have a common shared architecture vision.
-For large organizations or projects, some guidelines across the board maybe a good thing. They help
moving people around, avoid reinventing the wheel.
-Architecture can emerge during the early iterations. Identify archtiecurral risks, and add approproiiate stories to tackle them in the next iteration (or spike).
-Architect is a role that must be in the team, not a separate corporate function.
-Architect = chief advisor/refactorer, working in pairs with more junior folks for mentoring them while doing the architectural design.

- "software reuse is a false god."
- It is sometimes faster and more cost effective to re-implement, or duplicate than to carefully generalize a piece of software.
- An architecture function (e.g., software review board) should not dictate an architecture but spread knowledge, do cross-pollinization.

(Notes taken by Philippe Kruchten)

---