@olivierthereaux – Teh Artsy Techie

For almost all of the past decade I have spent working in Tech, IT, and the Web, I never really had a Job title. My roles and responsibilities varied from project to project, and I never felt like a single title would do my work justice. So it is with a certain feeling of excitement that I recently signed for a job with a clear title: “Web Architect”.

There does not seem to be a lot of existing resources or information on the Web about this role. “Web developer”, “Project manager” or “Software architect” all have their wikipedia entry. Search for “Web architect” in wikipedia and you will currently be redirected to a page on Web design. Wrong, wrong, wrong… There is indeed a page for Website architecture, but it still needs work.

In the Web industry, the “architect” title has long been hogged by Information Architects, and the Web Architect is generally called “Tech Lead”. That name is problematic, however, because it implies that the lead has evident authority on the development team, when the reality is often one of much responsibility, little authority: the tech lead seldom has authority by virtue of being a manager, but gains authority through the building of trust and effective mentoring.

The good news is that the Info Arch world is reinventing itself as “User Experience”. This is an opportunity for web architects to reclaim a title that makes more sense: architecture is about knowledge of complex systems, design and technology, and nurturing a project from beginning to end.

Still, the fact is there aren’t a lot of good resources yet on the Web explaining the work we do. I decided to collect a list of resources for Web Architects, mostly for my own consumption, but if it benefits others, even better!

Know the Job

In a nutshell, my understanding of the job goes:

• Provide technical vision at every stage of the project, from feasibility to delivery.
• Build specifications and/or prototypes. Do it with a team, not alone.
• Participate in development and own responsibility of architectural consistency, quality, documentation, code reviews, testing.
• Know the methodologies and development processes and frameworks. Get teams to use the right ones for the right projects.
• Develop and maintain expertise in the team through research, exchange
• Communicate, communicate, communicate. Be a bridge between people who don’t speak the same language but need to work together.

One of the fairly good resources giving generic advice on being a Web architect / Tech lead is a tutorial by Daniel Pietraru called 36 steps to success as technical lead.

I don’t fully agree with all of them, but they all carry some wisdom if understood and applied well. Number 27 (Be sure you have authority along with responsibility) is a good summary of the Architect’s odd position, of responsibility but not always authority – the latter is earned, not given.

Number 7, too (Get your hands dirty and code) can be a great way to keep one’s skills sharp, earn some respect from other developers and help deliver projects on time, but they can also drag and confine you in a role that isn’t yours. An architect is not a developer – and there are responsibilities in the architect’s job that require a creative mindset.

There must be quite a few experienced tech leads/architects out there with worthy experience to share. Jeremy Miller has a good article on the Classic Technical Lead Blunder. I’m on the lookout for more.

Learn the Tech

Regardless of how much hands-on the architect role has on a given project, the need to know the stuff can not be underestimated. This doesn’t mean you have to know everything – it’s healthy to not know, even healthier to know when to ask, and know when to do your homework.

1. Spend time on the W3C’s Web site. No, really. Keep an eye on “best practices” on Accessibility, Internationalisation, mobile Web and of course Web Architecture.
2. Can one be an expert in every possible programming language? Probably not, but worth a try. On the Web today, you probably won’t be able to survive without php. Do keep an eye on python (the Python: Visual QuickStart and Beginning Python from APress come highly recommended, and I love Doug Hellmann’s python module of the week), django, Ruby on Rails…

Learn to think like your team mates

One of the most exciting parts of the job is that the architect works with almost everyone involved in a web project. This means we need to speak their language. We need to speak marketing and strategy when assessing the project, we need to speak project management with the PMs, we need to speak design with designers, UX with UX, speak code with developers, speak test with QA. Here are a few books and resources that help become polyglot in no time:

1. Read Boxes and Arrows on a regular basis, and infuse the vocabulary and mindset of User Experience. I also like infosthetics and GUUUI. Read Jakob Nielsen too – if you must.
2. A good architect needs to know about the different frameworks and methodologies for web project management. I found Mike Cohn’s Agile Estimating and Planning to be the best book on agile project management, period. Real Web Project Management is not bad, either, although obviously made for a more novice audience.

Know the process. Know when not to follow the process

One risk, as an architect, is to be dogmatic about architectural or process changes. We all have a favorite way of running a project or building an architecture, but not all projects would be better off as scrum, and not all development benefits from test-driven development. That said, one first has to know the tools, know them well, before knowing when not to use them.

Specifications: joelonsoftware has a piece on “Why bother with Functional Specifications”?

Tech specs, however, I remain conflicted about. Most of the time, the technical specification is a long, painful document that nobody will bother reading. Several agree, calling for the death of the web technical spec, but others still see value in it.

In my first weeks on the new job the most important problem I identified was that the team created specs that nobody could really use. We’re in the process of improving our specs with the help of User Stories. User stories are often seen only as a tool for agile teams to evaluate work, but even in non-agile environments, they provide a clear checklist that can be used by everyone: the client can validate a real list of scenarios, the project manager can keep track of work done and remaining, developers can reuse the User Stories within a test-driven or behavior-driven development method.

Test early, test often. A good way to release software with fewer bugs and a quicker path to fix issues is to apply some level of Test-Driven development (and unit testing), or more recently Behavior-Driven development. For the architect the work of bringing TDD/BDD to a team will be as much technical as human, so you may want to read articles like this one and learn how to sell, and how not to sell, TDD to your team.

Tool-wise, look into rspec for ruby, junit for java and unittest for python. For php I quite liked the SimpleTest library.

Productive Tools

Doing this job well implies being good at managing people, knowledge, code and time. Patience and soft skills are the tool of choice for managing people. For the rest, a quick selection would include:

tracking ongoing work and todo lists – Things remains to this day my favourite in this area, though others will swear by iGTD or OmniFocus. If you’re hesitating, know that others have gone through this too, and see which choice they made, and why.

QuickSilver (or other similar launchers if you are not on Mac) can save tons of time on a daily basis. The real time-saver however, is to learn one’s text editor inside and out. I still love TextMate to bits and want to learn more tricks with it… even if my daily routines sees me use spreadsheets and text processors more.

For more suggestions of tools and methods, The Productive Programmer is a very decent read. It did not teach me anything I had no clue about, but it was a good validation of some simple, solid principles every developer, or anyone working closely with developers, should be reminded of on a regular basis.

Keep a sense of humour

Because it won’t be easy every day.

This list of resources will grow over time. If you have any suggestions, or disagreement, the comment box is right here ☟.