PowerPoint architecture goes hand in hand with those that think architecture is all about generating reams of UML diagrams before handing them off to a bemused development team. Actually, this is one of the reasons that I don't get model-driven architecture but I'll save that for another day.

On the basis that an application/system architect will remain hands-on, we've often discussed what percentage of their time should be allocated and somewhere around 40%-60% seems to feel right. You do need *some* time to do the QA stuff, mentoring, etc but you also do need to keep your hands dirty. This is what I ideally like to do on projects.

Interesting point about having a big break from development activities and it raises an interesting question. For whatever reason (e.g. had enough of coding, want to do more strategic consulting work, etc), there must be a time in an architect's career when they give up coding for good. Be really interesting to hear from anybody that has taken this route and transitioned away from the techie stuff.

• Techie architects – good coders, designers, mentors, trouble shooters, delivers etc. but are best practice zealots who follow all that has gone before them.
• Project management / hand waving architects – they no longer code but are very good at facilitating technical decisions and delivery. When you go down this route your natural progression is Enterprise Architect/CTO where you influence the decisions made at the board level.
• Visionary architects – excellent coders who are good at seeing the even bigger picture (Frameworks) and are not afraid of doing things completely differently based on experience. They prove things in code but are very poor at final delivery and will often take shortcuts to prove their point. These are the rarest of architects and are very hard to pigeon hole into a job title in a lot of organisations. Their effort feeds back to both of the above. Techie architects make it really work and project mangement architects sell it to the business.

I think you need all 3 types and sometimes you need to be all 3 types. Your own personal preference comes from what you enjoy and what you are good at. In most organisations the structure is Technical Architect, Enterprise Architect and CTO. Rather rigid but all are important. The structure comes from the need to scale the business and the higher you raise up the tree more you need to base decisions on the wider business and economic situation.

I would classify myself as 20% visionary, 20% techie, 20% Project management architect and the remainder would be classic coder because I still enjoy solving a hard core calculation/business problem. More importantly I find this feeds the other 3 architecture disciplines. I go through periods where I gravitate towards one more than the others. Most importantly I am still hands on! I have only had one job where I fore filled all of the above in the right measures. The reward is amazing when you influence decision at the board level, through the whole development lifecycle and are at the end “flicking” the go live switch and seeing the impact on the business literally minutes later! Shame the money ran out on the development side! We always delivered scaleable working complex software but I am not sure which architectural area I didn’t exercise properly! However, the client was often seduced by the latest “brain fart” ideas without calculating their return on their investment!

Let's take a new look at what architecture could mean. In building, the architect does not install windows, wiring etc. but at an abstract level he specifies the various tasks so completely that the workmen ought not to be able to take design decisions.

In England half a century ago the Leo computer company arranged something like this, in business applications, where the coders were obliged to follow a fully detailed set of instructions, without exercising any discretion. This approach has been lost. It should have been retained, and the coding of course automated when that became possible.

Now software is immaterial, and weightless, so why not automate the task of the worker completely and eliminate the coding?  Or a lot of it, anyway. This would imply the software architect would need the ability to produce a totally complete specification, not the vague stuff that UML can provide.

It is possible and has been done, by a small group of un-financed experts. Sorry to seem to push a commercial product here, but my aim is in fact to inform the community about possibilities and also achievements. Buy the book ISBN 0-8493-8086-3 for an account of the technology I am speaking about, or read a couple of ECBS'03 and '04 papers - see www.stateworks.com for details.

Our idea is in fact to totally specify the software behavior in detail, and then execute that specification, in an environment separated from the data handling. The coded modules which all projects would also need are then easily attached to a read-made framework, and the system never goes crazy by losing track of its precise state.This works very well, producing bug-free systems, applied mainly in the embedded control system area or telecommunications to date, but the concepts are quite general, and scale up to handle big projects, unlike most solutions proposed in this field.

The architects would not need to code, but would need to understand coding well enough to farm out the various coding tasks, easily specified and tested, to other staff.