Agility and architecture koan
“Self-organizing teams can decide everything by themselves. So they don’t need an architect.” writes Samudra Kanankearachchi on the Software Architecture group of LinkedIn.
This feels to me like one of these strange agile koans. If you repeat it often and long enough, it will gradually become the truth.
Self-organizing teams have very little to do with the architecture of your system. Self-organizing teams are about: task allocation, collaboration, communication, accountability, … it may have to do with time-boxing and therefore what gets accomplished in a certain time-frame. Architecture is about making decisions (choices) about the structure, composition, organization of the software system. It also feels like “architect” is necessarily not a member of the team. Not my personal experience or recommendation. Architect is a role, not necessarily a person (whose only role is to be an architect, though these exist in large organizations.)
Most systems tackled by small agile teams have a pre-defined stable architecture. So yes, they do not need to have anyone playing the role of architect. For novel complex systems, where architectural decisions need to be made, if they are made “by the team”, it means that the team plays the role of architect, and hopefully they have the knowledge and experience to do so. Like some teams have a scrummaster and a product owner, such teams should have an architecture owner, who drives the discovery of architectural issues and their resolution. Because an architecture is not going to gradually emerge out of weekly refactorings (another agile koan), unless this emergence is guided somehow.
There was a whole issue of IEEE Software magazine last year dedicated to the interplay agility-architecture. Start here: http://www.computer.org/portal/web/computingnow/archive/april2010 . Some of my own prose to be found there.
Philippe Kruchten 
I completely agree with you but I think the context in which Samudra has made that statement is perhaps something to think about. I think what she meant by a “self managed team” is a cross functional self managed team where people with varied skill set would be involved in the development of an application. If that is the case then perhaps there is no need for an architect in the team who has the overall picture of the system and would design accordingly. People within the team who are experienced enough can make those “decisions”.
So you are right when you said that architect is not necessarily a person but actually role which the entire team can play. But just on the basis of what Samudra has said, an architect is really not necessary if the team is indeed cross-functional and self-managed. A solutions architect can be assisting the team as a consultant rather than being part of the team.