When I think about the role of a frontend architect, I always think about the characteristics that it shares with that of a traditional architect.
An architect is defined as someone who designs, plans, and oversees the construction of buildings. This is exactly what a frontend architect does, except that the end product is a website.
And just as an architect spends more time drafting up schematics than pouring concrete, the frontend architect is more concerned with building tools and processes than writing production code.
Let’s dive into this definition and explore what our role would be as frontend architects.
Design
Think about a building with no clear architecture. The important decisions were all left up to the builders doing the work. One wall built was with stone, another with brick, a third with wood, and the fourth omitted because it was trendy.
The overall look and feel of the website is still squarely in the hands of skilled designers, but the frontend architect crafts the frontend approach and design system philosophy. By designing a system all frontend developers are going to work within, the architect sets a clear vision of what the end product, the code, will look like.
Once a frontend architect sets the vision, the project has a standard against which to test code. Without a design for the finished product, how could we determine whether or not our code actually has met that standard? A carefully designed system will have checks and balances ensuring that all code contributed to that system adds perceivable value, rather than just adding lines of bloat.
Planning
With a clear design in mind, the planning stage involves mapping out the development workflow. What steps will a developer take to write a line of code and see that code through to production?
In the simplest case, this plan involves FTPing into a server, editing a file, and hitting Save. For most projects, it will involve some combination of version control, task runners, CSS processors, documentation tools, test suites, and server automation.
The goal of the frontend architect is to design a well-oiled machine that provides quick and painless setup; offers useful feedback in the form of linting, tests, and documentation; and reduces much of the human error that occurs when we perform repetitive tasks.
Oversight
Frontend architecture is never a “set it and forget it” proposition. No design or plan is ever perfect or complete. Clients’ needs (as well as the needs of developers) will change and evolve over time, and a process that was working well in one phase of the project might need to be revisited later to improve efficiency or reduce errors.
A key talent of a frontend architect is the ability to continually make those adjustments. Modern build tools make it very easy to change workflows and distribute those changes out to each team member.
Some people have asked if becoming a frontend architect means a role in management, and never writing a line of code again. I can personally attest that not only do I write more code as an architect, but I get to write in a greater variety of languages, and for a larger number of tools. It’s not that I write less code, but simply that the audience of my code has changed.
A frontend developer’s audience is the end user, whereas a frontend architect’s audience is the developers themselves.
Adopting an Architectural Process
Just like other disciplines before it, frontend architecture has had to fight a battle of priorities. While we can’t imagine why anyone would start building a skyscraper without first consulting an architect, that is in fact how most large web projects start.
The excuses are numerous:
- We don’t have the budget.
- We don’t have the time.
- We’ll make those decisions after all of the designs are done.
Or worse, there is no excuse; you are just placed on the project months after the design was finalized and development is already in full swing. You now have just a few months to make a pile of HTML magically look like a stack of PSDs tossed over the wall to you.
This is not the way to successfully develop a scalable and sustainable website.
As frontend architects, we believe that there are a number of key frontend decisions that need to be made at the beginning of a project.
These decisions are either too difficult to implement later on in development, or the cost of making the wrong decision is way too great. Once those decisions are made, our task is to help shape the visual design, platform development, and infrastructure set up to best meet the needs of our envisioned architecture.
Without the early input of a frontend architect, projects run the risk of having to choose between reworking designs, platforms, or infrastructure and telling the frontend developers to make do. I can tell you from experience, betting on the former is always a bad gamble.
Conclusion
I know this isn’t going to be an easy task. The changes I am suggesting have a tangible cost, and anyone in a position to make these decisions will always need to weigh the risks and the possible benefits. For anyone who hasn’t had the experience of working with a frontend architect, this can be a difficult risk to take.
Read more: Frontend Architect: How To Distribute CSS Classes in HTML
The chicken-or-egg dilemma is that to overcome the objections of spending time and money on a proper frontend architecture, many stakeholders will require examples of how this approach has helped projects succeed in the past. This obviously requires you to have worked on a project like this in the past.
How do you get the opportunity to work on a project like this, if you are always required to prove that the approach works?
