The Time is Now for Front-End Architects

This article works for me on several levels. I looked at your list and the vast majority of those skills I have developed over the past 10 years of making sites and interactive media.

But this article is also a wake-up call for me to never rest on my laurels. Time to take my skillset to the next level and start checking out things like Ajax, Rails, CSS3, and more.

Thanks! Good stuff!

One of the things that I’ve always strived for, ever since becoming interested in the web in ‘96, was the knowledge of both the front and the back ends, so that I knew how best to merge the two in a cohesive manner. I guess in that respect I have always tried to be a front-end architect.

I think that one of the reasons that there are so few people trying to attain the knowledge is the fact that there was never an expressed need for it. People felt that it was better to have a focused knowledge of one aspect of the technology… almost like having the difference between a Neurosurgeon and a Cardiologist. You wouldn’t want a Neurosurgeon working on your heart, just as you wouldn’t want a Cardiologist working on your brain, but you would be comfortable having either one of them just give you a general checkup, because they have to have the broader knowledge before they can focus on one area… and that’s truly what our profession is lacking.

Once we have a school setup that actually groups both the front-end and back-end developers together, for at least a good portion of the beginning of their learning, we’ll have a new breed of designer/developers that are even more integrated with both sides than that proposed by the idea of a Front-end Architect.

I think front-end architects are the future of the web too. I’ve long felt that burdening a designer with things like CSS, Javascript and XHTML is quite a stretch. Just as it would be for somebody with a programming background to be performing graphic design (without proper training/education).

Whenver I see a job requirement where there is not a clear separation between backend coding, frontend coding and graphic design I just cringe.

Sadly, in the corporate world of timelines and budget constraints web standards and CSS still are shrugged off as if it was 1999. In walking around a typical IT department in a corporate environment, one would be hardpressed to see anyone writing markup by hand. That in itself is a pretty good indicator that people just don’t care about what their IDE does behind the scenes, just as long as it looks good in the browser.

Really good article, Garrett. When you wrote about it last year, I didn’t entirely agree. However, I think there are merits to what you’ve discussed in this article.

The hard part, for me, is deciding how deep the front-end architect needs to be in each respective skillset. I consider myself an expert level CSS/XHTML/DOM accessibility minded developer, with good working knowledge of MVC frameworks (having worked both in enterprise level Struts, and Rails projects). I’ve also found myself focusing a lot more these days on I/A and usability, as I find that the more I abstract the technology, separate layers, and develop patterns, the easier technology becomes and allows me to work on user needs.

I wholeheartedly support the idea of an FEA. However, I would also add as the most important skills an FEA would need are communication, leadership, teamwork, and project management. I would think it unrealistic to ask the FEA to do everything (though, I think I could swing it 9 times out of 10 ;-) ), and the FEA needs to be able to debate usability/IA changes, visual design, etc. to people who can be quite stubborn in their design decisions.

I tend to prefer T shaped individuals. Perhaps the usability/IA, and business logic, are the branches. My one nitpick is visual design. It could be my lack of experience, but I just don’t think having graphic designers doing usability/interaction design is the best method. I think as the web becomes more dynamic, you’ll see front-end developers moving more towards improving their interaction design/usability/IA chops, and working closer with the I/A, rather than strict graphic designers doing HTML/CSS and hacking together JS.

agree strongly on your point that these people must be real programmers. that means the “crayon crowd” need not apply. unless you understand why/what/how is going on underneath the abstract layer of elements and javascript, you are doomed.

A few weeks of PHP does not make one a programmer, and a few weeks of XHTML does not make one a serious client-side developer.

Can’t agree here. If one really has the skills, it doesn’t have to take longer to become a ‘serious developer’. This isn’t self-defence or anything, I have been programming for four years now (both in PHP, Perl and Python) and designing for three, but I think the ‘diagnosis’ of a developer is someone who knows his stuff. If one can learn it in a short period of time, that one has learned it. It doesn’t matter whether it has taken him three weeks or three years.

I consider it natural progression. An industry growing up the same way the movie and video game industries have done. What you’ve described sounds similar to a director for a movie in the sense that they answer the questions about how things should go and have the overall vision someone working on only certain aspects of a projects would not have.

Web design and graphic design are not 2 unique disciplines. They both are means by which an artist communicates information – no matter if you’re looking at a printed poster or a corporate website. Please, lose the “no crayon crowd” attitude – these types of comments make people who use them appear uninformed and under-experienced.

Great article Garrett. This niche is what I was aiming for anyway.

While many might consider themselves front-end architects, I’d argue that true programming knowledge is the one requirement where most fall short.

Just like the back-end needs to be properly separated into a database access layer, business logic, presentation logic, etc., front-end development is now sufficiently complex to justify its own architect.

Can’t agree here. If one really has the skills, it doesn’t have to take longer to become a ‘serious developer’.

Having a programmer hat may allow you to pick up a new language and run with it, but it certainly doesn’t automatically mean that you are advanced in that language.

Garrett, you’re exactly right. In fact, it’s something I am dealing with right now (trying to extend a poorly written application, while staying within a tight budget). How do you extend code that looks like this?

Garett,

I’ve been writing about much the same space that you’ve covered here for some time, and agree wholeheartedly with what you’re covering here. However, I think it extends well beyond the browser pane and increasingly into other XML-oriented frameworks (such as Mozilla’s XUL) which again have the potential to be far more dynamic than they are, but that are usually crippled because developers fail to think about what they are doing in the larger context of application – they become component developers, and not architects.

An architect is not a programmer, though should have a thorough grounding in programming. As rich client applications become increasingly the norm, such an architect needs to have at least a working knowledge of content delivery, of web services and SOA, of XSLT transformations, of asynchronous development, ACID transactions and so forth. These are not necessarily “front-end” technologies, rather they are distributed technologies which have a much greater dependence on a highly stateful client capable of maintaining that state over the course of many client/server transactions (i.e., AJAX, etc.).

A timely article, and one that I hope gets a lot of people thinking.

I think the industry is starting to realise the same thing, but most of the time they don’t know what they are looking for. Your article sums it up pretty nicely. I’m still waiting for the day when I get hired as the front-end architect and not recognised as ‘just the’ front-end developer. Most backend developers, don’t quite embrace the complexity of front-end technologies and its importance to usability. And because in most projects there’ll be 1 front-end developer vs 3-4 server side developers with the project manager also coming from server side, I’ll often be ‘just the’ front-end developer. I think most project budgets just aren’t enough to sustain a front-end architect.

Garrett,

Good article. It really caught my attention, because I hope it brings light to the fact that you need someone serious to do this type of work, and that it’s not just for any jamoke that can use WYSIWYG mode in Dreamweaver. I linked to you from my blog as well.

As a “traditional” back end developer and architect I find this article refreshing. The need for a solid front end architecture is certainly present in most web apps being developed today. I’m in whole hearted agreement with the op’s sentiments regarding a strong programming background.

But this is an extension of an age old debate regarding the importance of architecture, design, and implementation. They ALL matter, at ALL layers. The leader, visionary, architect, guru, whatever, better know enough about them all to make the most educated decisions possible when it’s tradeoff time.

P.S. I’d like to humbly apologize for my past trangsressions in not recognizing the value a solid team of “front end developers”. But I have consumed the red juice from the talking pitcher and would argue that I’d take a front end architect over just about any other position on my team.

Very good write-up Garrett. I may add one point though. A front-end developer working solo sometimes finds himself doing a bit of coding. And back-end developer doing likewise. Neither is an expert in both areas but they have to get their hands wet to get something done.

I suppose what I am saying is that although front-end and back-end technologies are separate in their own ways, one may cross the borderline either way.

Garrett, great article—definitely a must read. However, I think your definition of the “Front-End Architectâ€? is slightly off. It is poor business practice to spread yourself too thin; know your core business (talent) and strive to be the best at that. By suggesting that designers become proficient with backend programming and programmers become more proficient with front-end programming could prove detrimental. How many
of us (front-end designers) are already struggling to keep up with the huge, almost daily, advancements in action script, XHTML, CSS, XML, XSLT, DOM, JavaScript (AJAX) and not to mention visual design programs/trends/styles.

You state, “A few weeks of PHP does not make one a programmer, and a few weeks of XHTML does not make one a serious client-side developer.� I believe the best front-end visual talents should know the technology – its possibilities and limitations; vice-versa for programmers. However, we shouldn’t pressure front-end developers to become proficient with PHP and vice-versa. Know and understand the technology; don’t waste your time at becoming a master of everything.

Has team work died? Are we truly becoming an “every man for himself� individualized design entity. In my experience, the best web teams are made up of those individuals who excel in their area of expertise – and can communicate that in a manner that properly compliments their colleague who excels in another area.

My comments are strictly from a management perspective – build teams that compliment each other. From a personal perspective – yes, being proficient at it all will most likely get you more money, a promotion or an interview into that impossible company you’ve been struggling to get into.

Raise your hand if you think that’s an acceptable practice in 2006.

Hands firmly secured in my pockets!

In addition to the proper players to really play ball I think we also have a need to address the numerous frameworks that propagate deprecated thinking and limited client-side logic. Unless you’re building from nothing, most tools sold to large corporations completely ignore the position you described. And even if the corporate world catches on and starts hiring FEA’s (assuming they can even manage to get the right person hired for the job duties) the frameworks only allow minor fiddling, and mostly from a strait jacket. In others words, a major issue that I see is the contradictions that appear with most enterprise frameworks and the position you’re defining. Don’t get me wrong, as a FEA I’m totally onboard with what you saying. However, an FEA is not much use to anyone when a majority of the functions required of an FEA are already locked into place by most enterprise frameworks.

For example the one we work with, BEA is just pitiful. It assumes that a java developer is the be all developer for a portal. BEA in trying to help a java developer has only held those who use it in a mind numbing time portal that dates back as far as 10 years ago. That is as it pertains to modern day client side practices. Of course this won’t change until the people with the money, start understating the ramification of their decisions.

I have to agree with Martin, although I like the article and the idea – it’s essentially what I do in fact. But your very example on the “programmer” side of the coin is really making the FEA into an engineer. Why in the world should I be telling a .Net programmer the best way to do something in .Net? If I am in fact schooling him on best practices, then either I ought to be doing his job or he needs to be out of one, and we need to get better engineers.

I fully agree we need to be able to have programmer conversations on a more than superficial level, but the engineer needs to be the expert on engineering. I need to be the expert on the front end.

I don’t say this because I lack programming skills. I have 10 years experience, and can code in various server side languages and even understand (and write some) Java or Ruby code. But I agree that you’ve spread yourself way too thin if you are going that far.

Other than that – great article. I think it’s a natural offshoot of the bubble bursting and people taking on more (being less specialized since those days) and the medium maturing in the last 5 years. I may have to change my business card… ;)

I think I understand your point better then, if you are saying you really need to know what the outcome for the markup is going to be – makes sense and I’d agree.

It’s amazing how our field never slows down. There is always a new technology, browser, or coding technique/hack that shows up every week, forcing us to constantly learn more to keep up. I still remember back when cross-browser compatibility between Netscape 3 and 4 was a prized skill set. Now I need to jump on the AJAX bandwagon just-in-case a client comes asking for it.

A front-end architect/producer, seems to fit well as the “liaison” role between the graphic designers and back-end developers. Interface design and IA skills help give the designers some direction. And having a computer science background definitely lets us meet the developers on their terms—as often they don’t have a clue about how to output web standards. As long as their copy of IE shows stuff correctly, back-end developers (and many in the business-side too) don’t seem to care about anything under the hood like accessibility, page weight, or usability.

I hope Justin is right about our role being the future. It seems to be getting diminished lately, especially with Dreamweaver and similar “create your site” tools becoming good enough for many businesses to not hire consultants or skilled employees.

Garrett,

Thx for this great post. I just have one suggestion, could you mass-email it to recruiters ?, because I’ve been asking/kicking and screaming for such a position for over a year now, and no one seems to get what a Front-end-architect is Grrrr !

I think you’re spot on. I can’t tell you how many times I can’t communicate with the guys building the back end. I mean it’s not just my fault, I have no experience with Ruby, but they don’t have any experience with xhtml. It’s hard, but I’m trying to learn Ruby and the other languages, someday it’ll be ok.

Garrett,

Where do we get an education like this? How did you get it?

That makes sense Garrett. I’ve been designing for a while and the more I learn, the more I realize I don’t know. Somehow I missed the whole web standards revolution until a few months ago. I’m very excited to learn new things but where to start? I’ve got some good books on accessibility & designing with standards. Any book you’d recommend on information architecture and usability?

Your post reveals so much ignorance about WWW development that it is truly difficult to know where to start. Only a few points:

There can be only one architect. And unlike the situation for a building architect, the “front-end” is not the software architect’s appropriate viewpoint. In fact, “front-end architect” is an oxymoron.

Garrett – Great post.

G Roper – I disagree. There are two kinds of software: the kind that serves systems and the kind that serves users. For the rare but important segment of the software market that has no users, software architects are free to reign supreme.

For the segment of the software market that serves users, user interaction needs to be the driving force of project. Obviously, there are crucial backend considerations in all software, but they should influence and constrain the design of a user-facing product, not drive it. For user-facing apps, the software architect’s role is to support and enable the required user interaction. That means someone else should be telling them what that required interaction is.

Read Garrett’s post again.

Think about the last enterprise software you used (portal, CMS, payroll, HR, accounting) and how badly its interaction sucked. Ever look at the front-end code from one of those things? Crap. I mean, just embarassing. And the interaction: absymal. Then think about who led the design process for that very expensive software. I bet you a nickel it was a software architect. I’m not saying these folks aren’t important. I’m just saying they shouldn’t necessarily drive the design or implementation of the front-end.

Know this is a late post and while I admire the direction I disagree with the naming!
When you build a house, you employee the services of joiners, carpenters, tilers, bricklayers, plasterers, plumbers, and, if you have the cash, may recourse to an architect. With the web, we have technical architects, application architects, system architects, brand architects, information architects, and now a front-end architect…...
Can’t we just have honest to god people who know what they are about and not afraid to call themselves by the service they offer? By all means develop rigors and skill areas that bring creedence to the work, but please loose the architect bit. An architect is the one who learns a little about more and more until he knows nothing about everything – surely?

# emphasis # strong # citation # deleted text # inserted text # ^superscript # @code@ # bq. blockquote # link text

I am just curious about this regexps hoho~