Developers need to wake up and start seeing what they do as part of an industry, not just a hobby for which they're paid (often extremely well). Accountability, responsibility and transparency are not just tenets of agile methodologies but are the hallmarks of any professional.

Another interesting question is when do you know a project is failing? I think one of the problems we have in the software world is that it's not obvious.

If you're building a bridge and the struts don't fit in the foundations, you know you've done something wrong and have to correct it properly. But with software you just hack a bit of code in and continue.

It's also easy to scrap a project you don't like (politics has killed more projects I've worked on than bad code). After all, you don't leave behind a half finished structure spanning a river for people to ask about. If you can't finish a project in the lifespan of the sponsor (CTOs last about three years) you might be doomed. ;-)

I'm not sure a "real architect" would specify every element of a system. They ought to ensure that every element is specified and reviewed but they probably won't try to do it all themselves (depending on the size, scope and duration of the project)! Perhaps a minor semantic point, but marshalling experienced specialists is often also required in my experience. This is particularly true when using bleeding-edge technologies - you simply won't be the best person to make these decisions. The point is excellent, though: if projects aren't sufficiently specified they are more likely to fail.

I agree that there are lots of so-called "architects" around but this is possibly more a reflection of how weakly defined the role is rather than delusions of grandeur. Simon's role profile is a useful yardstick here.

I also have to agree with Rob about "architects" only thinking in terms of software design. Many projects aren't just about code but in my experience this still makes up the bulk of my work. This is possibly because the people charged with other aspects of the system (such as the network infrastructure) are more like engineers and are working with more established processes. Perhaps that's a separate post, though!

No argument here - technical authority has to be based on something more than just vacuous claims! Sometimes experience will suffice. Sometimes exhaustive testing is needed. Sometimes neither is possible so someone else's experience or testing has to be relied upon.

Architects can be bad at what they do just like everyone else. That doesn't necessarily define what an architect is, more how they do it.

This title-related discussion is becoming really boring. When can you start referring to yourself as an architect or not? What is an architect vs. application designer vs. anything else? Who cares?! I mean, what really matters is not who you are, it's what you can do. The architect who drew my house and the one who designed the Millau Viaduct are both architects in that they don't build themselves. They just know enough about materials and structures and so on to actually design things, think of it before they exist.

The main problem I see in many projects is that they tend to start with an architect that is not cut for the job (like a house-drawer for the Millau Viaduct). But what's even worse is when they start with an "overkiller", making things more complex than necessary, overbudgetting everything. My point is: we need pragmatism. We should stop worrying about titles and big unrealistic architectures. Let's focus on getting back to the ground. I think that's the whole point of the philosophy behind Agile Methodologies. But apparently we are still entangled in big discussions about "whose one is bigger?"

I think that one of the key aspects to re-educate all the actors is to show them the article from the Times, and others like it. IT project failures seem to be easier to hide, so the more we dig up those failures, the more we draw lessons from them, the more lucid we are and the saner the market will be. But then again we're facing some business and political issues here.

So another approach would be to convince all the actors to try out a different, more pragmatic approach, and show them how it's more efficient and less error-prone. And yes, we will lose money on the short-term because the contracts we sign will involve less money. But it's a long-term shot. Even in IT projects, less is more.