If Architect doesnt run code then there is a problem.
Architecture doesnt live in documents
Architecture embodies the critecal design that typify a system
- Good Architecture is a light weight upfront one that enables you to take decisions in the future.
- It helps to see the big picture
- It is Stable but NOT static!
- Dont play dumb, if you know something and sure about it then take a decision…
- Documentation is not a skill that developers have or like.
- Architecture of seperation of concerns not a divorce!
- Defering decisions to the last RESPONSIVE moment!
- TDD is not about design shape, it is about getting code right!
- Architect is not a verb, the verb is Design, and one of its productions is Architecture
- TDD works well when you have a right upfront architecture that shapes out the system. Otherwise it will turn the system into procedures wrapped in objects!
- we need a balance of details in an agile architecture, just enough details to help us taking decisions…
- Architecture deffinition (not a finished one, not done but done right!) in a scrum process can be the first sprint, but you deliver code!structure classes that build. We call it Inception
 
- Without it , softwares fail in advanced sprints because of lack of it, after being maybe released in the market!Â
- Think of time software decomposition as well as the classical one.
“Inception”?? sounds very much like RUP to me…
To be honest, I don’t see what the big deal is with their inception phase. Clearly it seems very short (less than 2 weeks if I compare with the iterations). Why not make it part of the first iteration?
As for the sentence “second and third to market are often more successful”, who says so? Besides, the reasons might be numerous, and not necessarily related to architecture.
Comment by Eric — March 16, 2007 @ 9:55 am
Yes it can be a part of the first sprint, they even mentioned that it can be the first sprint.
The idea is just not to be too naieve that the architecture will draw itself, like in TDD where the last “D” is Design, which leads to a procedural style wraped in objects, and a disconnected procedure from user requirements and user needs!
2-3 weeks is quite short, and thats what is good about it. You cant go far with your architecture, choosing the programming language is a kind of decision that you dont want to differ till later i guess. And the result of such a sprint would be code NOT only documentation…
Comment by sadek — March 18, 2007 @ 12:49 am
Yes, “inception” is a word that RUP uses. It is also an ordinary English word that means “the establishment or starting point of an activity”. Therefore, by definition, inception is what happens first. RUP uses this term correctly, as did we. So, making inception part of the first iteration automatically makes it happen first. There is no contradiction here, but what you will find is that the initial iteration is qualitatively different to later iterations. There are many ways that this can be addressed within the lifecycle model. One approach is to introduce a “sprint 0″, thereby preserving the regularity of iteration terminology. Another approach is to recognise this as a phase difference, and mark it as such. In the all-day QCon workshop I ran, I used the “sprint 0″ approach because it fitted with the rhythm of the day (four parts to the day, which mapped to spring 0 to 3). In the talk described in this blog Cope and I used the term “inception” to acknowledge the qualitative difference. We also mentioned that this can be structured in terms of being an initial sprint. Historically, Scrum also used to make a distinction, dividing the lifecycle into the planning phase, the sprint phase and the closure phase. There is no getting away from: whatever you do at the beginning of something will be its inception, regardless of how you want to brand it!
Comment by Kevlin Henney — March 22, 2007 @ 1:48 pm