What Does an Architect Do in an Agile Shop? An Agile Architect Explains(adtmag.com)
adtmag.com
What Does an Architect Do in an Agile Shop? An Agile Architect Explains
http://adtmag.com/articles/2011/08/12/role-of-an-architect-in-agile-dev-shop.aspx
17 comments
Someone who isn't hands on can't make decisions on behalf of those that are. What have they got to go on but hype and vendor white papers? Only if you are immersed every day can you see the forest for the trees.
Sure, but as the guy talks about in the article, he is hands on. He just spends a certain fraction of his time trying to maintain a global picture of the project and applying insights that come from that.
I haven't worked on a project with more than 4 people for ages, but I don't think I would mind this.
I haven't worked on a project with more than 4 people for ages, but I don't think I would mind this.
If 2 viable solutions have this kind of long term vs short term trade off, technical decision makers need to talk to business decision makers.
Often it's reasonable to incur some technical debt with the short term solution, and then switch to the long term solution later on.
Delaying work gets you to market faster, costs less, and means you understand the problem better for less effort.
Obviously, if it's not a feasible roadmap to go with option a first and migrate to option be later, it's the techie's job to make this abundantly clear to the pm / business.
Often it's reasonable to incur some technical debt with the short term solution, and then switch to the long term solution later on.
Delaying work gets you to market faster, costs less, and means you understand the problem better for less effort.
Obviously, if it's not a feasible roadmap to go with option a first and migrate to option be later, it's the techie's job to make this abundantly clear to the pm / business.
I give him points for being aware of the normal pitfalls of designated architects. But even in a good Agile shop I think it's incredibly dangerous to give somebody an "architect" title.
If architecture is one person's job, it means it's suddenly not anybody else's job. Software architecture is a pervasive concern, so everybody should be thinking about it. I think that's much more likely if anybody can notice an architectural issue and is encouraged to take the lead on sorting things out.
If architecture is one person's job, it means it's suddenly not anybody else's job. Software architecture is a pervasive concern, so everybody should be thinking about it. I think that's much more likely if anybody can notice an architectural issue and is encouraged to take the lead on sorting things out.
Agree completely.
You are simply not a well-rounded programmer if you can't architect an application / piece of functionality to do whatever it needs to do.
Designating someone to be the architect just causes strife / encourages 'normal developers' to shut up about architecture because there is no credit to be made.
You are simply not a well-rounded programmer if you can't architect an application / piece of functionality to do whatever it needs to do.
Designating someone to be the architect just causes strife / encourages 'normal developers' to shut up about architecture because there is no credit to be made.
Yep! And the "architect" is forced to strive for credit, because nobody is really in the position to evaluate their work results. At the best, it results in self-promotion like found in this article. At worst, it involves claiming credit for everything that goes well, while blaming "those developers" (and their failure to obey the architect's dictums) for any and all problems.
In my experience good developers act as architects no matter what their title is. But the purpose of a single formal 'architect' is more of a mediator between developers. Someone to find common ground when two viable technical solutions are presented, and be accountable for those decisions.
In my experience, when two viable technical solutions are presented, one is decided on by weighing the pros and cons.
The problem with 'appointing' a formal architect is as the parent said: the architecture becomes the sole responsibility of the architect.
There is plenty of room for a mediator without having to call him the architect.
The problem with 'appointing' a formal architect is as the parent said: the architecture becomes the sole responsibility of the architect.
There is plenty of room for a mediator without having to call him the architect.
The same thing they should do anywhere else, and this has not changed since the days of building cathedrals from stone:
1. Design.
2. Supporting the implementation effort of the design.
3. Governance, i.e. making sure that what was designed is what is delivered.
Of course there are many other tasks that a software architect in particular has to carry out, but in my day job I never stray too far from the three fundamentals above.
1. Design.
2. Supporting the implementation effort of the design.
3. Governance, i.e. making sure that what was designed is what is delivered.
Of course there are many other tasks that a software architect in particular has to carry out, but in my day job I never stray too far from the three fundamentals above.
He sounds more like a PM than an "architect." Is it because he codes and works in an agile shop that he suddenly becomes an Agile Architect?
That sounds like the foreman on the construction site and not an architect.
Hey look, my employer is getting some HN love..
Haha, hey guys, us Agile Ruby guys are so much cooler than those stupid people that don't use Apple MacBook Pros and chill at Starbucks.
Sure, they write code and get things done while we talk about how awesome our Ruby code is, but hey, All the cool kids use ruby[1].
-- Send from my iPad
[1] https://www.youtube.com/watch?v=5GpOfwbFRcs
Sure, they write code and get things done while we talk about how awesome our Ruby code is, but hey, All the cool kids use ruby[1].
-- Send from my iPad
[1] https://www.youtube.com/watch?v=5GpOfwbFRcs
Perhaps my biggest advantage is that, while I do spend some time coding, when I think about our software I am not constrained by the fear that I will have to implement my own ideas. It may seem crass, but as someone who has worked long years in the trenches I know that there is a subconscious tendency to discount ideas that may have huge long-term benefits if it means a lot of work in the short term.
Hate to admit it, but it's true. It's something you fight against.