Comments on: Conversation about an Agile Architect http://blog.xebia.com/2008/01/04/conversation-about-an-agile-architect/ Software development done right! Wed, 08 Feb 2012 14:41:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Quirijn Slings http://blog.xebia.com/2008/01/04/conversation-about-an-agile-architect/#comment-31063 Quirijn Slings Sun, 20 Jan 2008 18:12:51 +0000 http://blog.xebia.com/2008/01/04/conversation-about-an-agile-architect/#comment-31063 In my opinion, an architect is simply an experienced developer who has been involved in so many projects (good and bad) that the business finally decides to listen to him/her BEFORE the project starts.. And since I don't think a business should ever start a project without listening to an IT-person first, I believe that an architect should be involved in any project that might be IT-related. In my opinion, an architect is simply an experienced developer who has been involved in so many projects (good and bad) that the business finally decides to listen to him/her BEFORE the project starts..
And since I don’t think a business should ever start a project without listening to an IT-person first, I believe that an architect should be involved in any project that might be IT-related.

]]> By: Mary http://blog.xebia.com/2008/01/04/conversation-about-an-agile-architect/#comment-29726 Mary Sat, 05 Jan 2008 21:27:22 +0000 http://blog.xebia.com/2008/01/04/conversation-about-an-agile-architect/#comment-29726 Hi all, First of all i would like to wish you and your beloved a very happy 2008. At work (large governement organisation) i am writing about the strategic (business) goals in relation to SOA and v.v. Helping to formulate advantages and trying to let them see how we can go about aligning business and IT and why we should. In fact trying to educate my fellow workers (most of them are architects of the digital kind). You know, the ones that give a lot of developers a headache. There is a lot of missionwork to do in realtion to SOA. Both on their side as well as on the business side. Although they say i am, i am not an architect. I am more an advisor on strategic business matters or what you can call a policy consultant. BTW: The latter can give developers a headache too ;) Architects come in all sorts. You don't need the apparatsjiks; you need the one(s) with the big picture. Perhaps you should check this out: martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf Our philosophy teacher told us that he uses the following rules (and adviced us to use them too): tolerate ambiquity, beware of understanding, think for yourself, make your own effort to acquire knowledge and bravely give your own opinion. I see we do and i like that. Mary Hi all,
First of all i would like to wish you and your beloved a very happy 2008.

At work (large governement organisation) i am writing about the strategic (business) goals in relation to SOA and v.v. Helping to formulate advantages and trying to let them see how we can go about aligning business and IT and why we should. In fact trying to educate my fellow workers (most of them are architects of the digital kind). You know, the ones that give a lot of developers a headache. There is a lot of missionwork to do in realtion to SOA.
Both on their side as well as on the business side.
Although they say i am, i am not an architect.
I am more an advisor on strategic business matters or what you can call a policy consultant. BTW: The latter can give developers a headache too ;)
Architects come in all sorts. You don’t need the apparatsjiks; you need the one(s) with the big picture.
Perhaps you should check this out: martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Our philosophy teacher told us that he uses the following rules (and adviced us to use them too):
tolerate ambiquity, beware of understanding, think for yourself, make your own effort to acquire knowledge and bravely give your own opinion.
I see we do and i like that.
Mary

]]> By: Peter http://blog.xebia.com/2008/01/04/conversation-about-an-agile-architect/#comment-29631 Peter Fri, 04 Jan 2008 18:36:29 +0000 http://blog.xebia.com/2008/01/04/conversation-about-an-agile-architect/#comment-29631 >> An architect is a "waste" and has no direct business value. A very dangerous principle I really dislike. >> P1: Why do we need architect for this? The team could do this too... It depends on the definition of an architect. If you define a (software) architect as a senior senior developer, I would expect him to be responsible for the architecture of the application. Even Jeff Sutherland has an architect on each of his teams 'a single wringabe neck'. >>P1: But if you trust the team to take care of the architecture and you accept that architecture emerges, then it can be also done by the team and scrum >> master? It depends partly on the amount of knowledge on your team. But often there are some architectural patterns you can use to provide a lot of value. So someone who is aware of such big bangs for the buck, could save a lot of time. And by not having someone responsible for the quality of the software, the quality is going to suffer from different styles, dry problems, tight coupling/low cohesion and this is going to lead to spaghetti code (I have seen my share of spaghetti code caused by dogmatic usage of scrum). So I think people should get over their 'we don't need an architect'. I think ivory tower architects are dangerous, but a hands on architect with more than average experience (technical lead) should be mandatory on every large project. >> An architect is a “waste” and has no direct business value.

A very dangerous principle I really dislike.

>> P1: Why do we need architect for this? The team could do this too…

It depends on the definition of an architect. If you define a (software) architect as a senior senior developer, I would expect him to be responsible for the architecture of the application.

Even Jeff Sutherland has an architect on each of his teams ‘a single wringabe neck’.

>>P1: But if you trust the team to take care of the architecture and you accept that architecture emerges, then it can be also done by the team and scrum >> master?

It depends partly on the amount of knowledge on your team. But often there are some architectural patterns you can use to provide a lot of value. So someone who is aware of such big bangs for the buck, could save a lot of time. And by not having someone responsible for the quality of the software, the quality is going to suffer from different styles, dry problems, tight coupling/low cohesion and this is going to lead to spaghetti code (I have seen my share of spaghetti code caused by dogmatic usage of scrum).

So I think people should get over their ‘we don’t need an architect’. I think ivory tower architects are dangerous, but a hands on architect with more than average experience (technical lead) should be mandatory on every large project.

]]>