I confess, I’m a sceptic when it comes to architects, for two main reasons.

1. What qualifies someone to be an architect in the first place?

If you meet an architect in the construction world, you know they’ll have studied the minutiae of building design for many years. But if you meet a user experience architect, an information architect, a system architect, or indeed an enterprise architect, what qualifies them for that role? How do you know if they’re any good?

There are some recognised models for “enterprise architecture”, provided by the Zachman Instititute for Framework Advancement or The Open Group Architecture Framework, but these don’t actually tell you whether your architect is sufficiently clued up about your CMS publishing model that s/he can get it to work with a proprietary HR system.

2. What use is someone who designs your project then walks away from it when you actually start implementation?

I think I’d like to be a project architect. I could come up with all the tasks, dependencies and deliverables to design a project, then hand it over to someone else and say “deliver that”. I’d know what all the tasks are likely to be, identify risks, assumptions and approach, but someone else could own delivery post initiation / inception. Anything goes wrong, it’s not my fault: I told you how to do it, so if the project goes wrong then it must be your fault.

It’s just the same for development. How many projects have you seen where the technical architect needs to be called in to resolve an issue because the development team couldn’t apply the technical design?

These days, Service Orientation is the order of the day, which makes having an architect a prerequisite for any web CMS project. So how do I overcome my scepticism and define what an architect should do and if they’re any good or not?

Pranshu Jain provides some insights into what you should expect from your architect: fundamentally the role is about picking the technologies that enable the business to meet its objectives. But this approach has led to some organisations having less technical architects who understand what various software packages do, but who don’t understand the in depth technical details of how the architectural components relate. This spells project disaster.

So my message to architects out there is get your hands dirty. Get involved in the project development and take ownership if things start to go wrong. It will help you to design better systems in future.

And my message to project sponsors and managers is that if you’re recruiting an architect and they don’t know what a reverse proxy is, they’re not going to be much use to you.