I’m not sure I believe in a common architectural process. As the author of a successful project management book, and articles on data architecture methods, I probably shouldn't say this, but to paraphrase a famous quote, "When I hear 'process', I reach for my gun!".

My focus is always on product not process, and technique not “methodology”. I produce architectural artefacts, and I don’t necessarily follow an architectural process. In my experience “processes” can often mean a lowest common denominator approach which is quite inefficient and doesn’t have any control over the actual quality and value of the product – I know that’s not always true, but it’s something we need to guard against.

I don’t know whether construction architects are hung up on process in anything like the same way IT architects often are. For example, is it possible to reverse the order in which you do static load and dynamic load analyses for a building? I bet it is, but many software processes would not admit the equivalent.

At heart, I’m in favour of agile development approaches, and in my own experience I have found them to be perfectly compatible with “good architecture”. One of my most successful development experiences was a few years ago, for a major British household name. We were faced with an almost impossible set of conflicting constraints: tight business timescales, a pre-Y2K change freeze, very limited physical resources and WAN bandwidth, and others. But we delivered the first working system in 8 weeks, and kept on delivering regularly for over two years, at a rate unheard of in the customer’s usual IT experience.

The approach had most of the characteristics of a very agile development: iterative and incremental delivery, dynamic planning, close association with the users, pair programming, enough modelling and documentation but no more. Most of the team, from the top business manager down, were known mavericks. But yet we managed to establish and maintain an extremely strong architecture, highly praised by expert external reviewers. The architecture was also well matched to the team structure, with a few key developers generating core code, and most generating “scripted” content.

There were two continuing battles: the customer’s central IT group, particularly the “architects”, didn’t like the project, because it didn’t follow the approved process, and was delivering far too quickly for their regimented delivery scheme. And the users were very demanding, so that the process of meeting user requirements usually consisted of an initial “absolutely not, over my dead body” followed half an hour later by “well maybe”, when we had managed to dis-entangle their true requirements from their proposed solution and found a solution which would not break the design.

Sometimes we suffered "ping ponging" requirements, where common sense suggested that a stated requirement was wrong, and would be reversed at a later date. We ended up with a policy that such requirements were only implemented if we could find a way to accommodate them so they could be quickly and easily reversed out later.

Our relationship with the IS Operations people can best be described as "love-hate". It started badly, but improved over time, as they realised that we really did care about both our users and our impact on the infrastructure, just maybe in a less formal way.

Our project certainly had a strong architecture. And that architecture was maintained because I spent a lot of time working to keep the design pure, and to balance the different forces on the solution. If I made a mistake, it was to neglect some of the needs and views of the enterprise IT architects. But we didn't need to follow their heavy processes to deliver a strong, durable, architecture.

So agile projects can have a strong architecture. But in my experience they also need a strong architect, someone, whatever his or her title, who "keeps things straight". Those agile methods which suggest you can "do away with the architects" are probably deluding themselves.