ThoughtFactory.CreateThought() A random collection of thoughts from an easily bored developer

Which Type of Architect Are You?

This article is part of a series of posts that originated in a talk I did at the 2011 Perth SharePoint Saturday event.

Around 10 years ago, when the IT industry needed to pinch another fancy title for itself after engineers got sick of us using their professional title, the term "architect" started popping up in job ads and an entirely new career path for developers was born. Sure, we annoyed real architects, but who cares about that? We had something to look forward to after being promoted to Senior Developer! Skip forward to today and we now have a bunch of job titles that sound posh but have no solid definition. Some of the generic, non-product specific "architect" roles include:

• Information Architect
• Business Process Architect
• Solution Architect
• Application Architect
• Systems Architect
• Software Architect
• Enterprise Architect
• Computer Architect
• Technical Architect
• Infrastructure Architect
• Technology Architect

Then comes the product-specific architect titles:

• SharePoint Architect
• Oracle Architect
• Cisco Architect
• SAP Architect
• Citrix Architect
• Active Directory Architect
• .Net Architect
• Java Architect
• COBOL Architect
• World of WarCraft Architect

OK, so I made the last two up, but my point still stands. There's a lot of different positions out there and a lot confusion about what these roles are actually responsible for.

As someone with the title "Solution Architect" on their employment contract I have a vested interest in clearing up the confusion around this issue. In a recent presentation I even went so far as giving "rough definitions" to some of the more common types of architect that you'll find in the wild just so I could have a common vocabulary with the audience. Here's a slightly augmented version of the list I used with a few other terms thrown in:

In an ideal world I would love to see the general architecture titles standarise on something like the list above and the product-specific architect roles go away. When I saw "go away", I mean that I'd love for people to stop calling themselves things like "SharePoint Architects". Each one of the general architecture roles I mention above has a core set of skills associated with it that apply regardless of the product space being worked in. "SharePoint Architect" tells me nothing; do you build specific applications, set up infrastructure, define taxonomy? It's much more useful to define the skillset and say that someone has a specialisation in a particular product

Using the non-product specific roles would also solve the problem of having no standard set of expectations to compare different architects. A new product being released shouldn't be a trigger for a bunch of unqualified people to start calling themselves architects just because they want to hit a certain pay grade. It would also stop Application Architects who know how to build an application on a certain platform (e.g. .Net or SharePoint) from calling themselves Solution Architects or Enterprise Architects when they don't know the first thing about orchestrating a process between different systems in an organisation (i.e. Solution Architecture) or waving their hands and spouting buzz words at the CIO (i.e. Enterprise Architecture).

I honestly think that our professional vocabulary needs to be updated to include common definitions of what we think these roles involve, and there needs to be some control over the tasks that a person has to be capable of before they can call themselves an architect. This is especially true given that we are stealing the term from a rather well organised profession that does have standards and guilds and all that other funky stuff that legitimises an industry. We don't necessarily have to go so far as having guild fees and written exams, but it would be nice if people stopped calling themselves "Enterprise Architects" because they "know a lot about Lotus Notes".