Hello everyone, and welcome back once again to Front End Center!

For those of you listening along each week, sorry for the delay this past month or so! A cross-town house move and seasonal flu piled up in perfect tandem and derailed my best intentions to keep each episode on track. Now that both have run their course, we’ll be back to our weekly schedule!

We’re moving into the tail end of the December, and I always like to look forward to planning the year ahead. 2016, for me, was filled with interesting challenges and in-depth exposure to technology systems like SharePoint, Sitecore, and numerous, bespoke client sites. Like any good new experience, I navigated most of them while still learning on the fly!

As each project comes to a close, I set aside notes and ideas I’ve encountered that may be of use later. Sometimes they become lifesavers when I need them, sometimes I realize much later that I’d been barking up the wrong tree for weeks on end!

My collection of notes has grown substantially more than usual this year, prompting me to really dig into them and consider what I can refine out of their raw material. In doing so, I’ve found my major interest of research and action for next year: front-end architecture.

The topic is one I’ve been aware of and even referenced here on Front End Center before, in passing. For those not familiar, here’s a Cliff’s Notes on software architecture:

Software architects choose a standard method of pursuing development. This method is intended to unify the efforts of other team members, outside clients, and future work done on their software. Rather than have ten different developers working in ten different ways, the architect tries to plan the project in advance.

Software architecture has its roots in more traditional computer science. Algorithms, databases, and interconnected servers gave rise to the need for specialists who could plan and execute high level complexities. Projects can be completed more quickly and efficiently with a plan in place.

The difficulty in software architecture comes from the amount of abstraction necessary to architect well. It’s one thing to code a solution. It’s another to plan HOW to code a solution without actually doing so immediately.

A good architect needs both long term experience and up-to-date knowledge of the solutions available to them. It’s as important to know why you shouldn’t use one tool as why you should use another! A proper architecture will mean the efforts of everyone involved are efficient and focused, whether they’ve been on the project for months or just joined the team yesterday.

The role of software architect is one that’s established and respected. In many organizations, it’s the technical equivalent of a manager or even director. Even if an architect doesn’t have people reporting to them permanently, they’re essentially managing both technology and people for extended periods of time. They may even be responsible for managing multiple teams in overlapping projects!

Front end architecture is an emerging discipline in comparison to such backend roles. Like many things “front end”, the role is a hybrid combination of many disciplines. The title may also have different expectations in different places, based on existing team roles and capabilities.

A front end architect’s primary focus is often the actual process of a project. Like any other software architect, they want to ensure the proper time and tools are given to their team to complete a solid product. Architecting a front end process, though, can put you in touch with a lot of outside influences.

The original, defacto role of front end was to put together the back end code and Photoshop designs, to make the final website both look and act as expected. Often through whatever means necessary. This role, though, ultimately amounted to front end being a limited after thought. That doesn’t leave a lot of room to architect anything, and means good front end developers could contribute little more than meeting minimum expectations.

Instead, effective architecting gets involved early in the process. Let’s assume the strictest definition of a front end architect. We aren’t responsible for user experience research or graphic design, just the development of the site itself. Many times, this may not be the case, but that’s down to situation.

For now, we still want to be involved in those UX and branding processes! Not only will we be aware of the larger goals and ideas in the project, but we’ll be able to influence and potentially improve them based on our knowledge of the technology that will be used. No one likes having their heart set on one solution, only to be told later that it’s just not feasible.

Whether or not we can have a large impact on external factors on a project, we can always improve our own process through this knowledge.

There are specific elements inside of the overall process that an architect must plan out carefully. Those are the code itself, the testing of code (both as and after its fully written), and the documentation of the work done.

The technical decisions made for the code are all about picking the tools to use and what a correct finished product looks like. Most front end architects will leverage a combination of HTML, CSS, and JavaScript. Others may add in Ruby, or any number of additional languages. Within each of those languages, appropriate tools must be selected.

If every set of rotating images in a hundred page website looks similar but is coded differently each time, maintenance and expansion will be a nightmare. An architect needs to ensure that code methods and tools are consolidated and easy to access.

Test driven development can help ensure that once we have those tools and guidelines in place, they’re actually being followed. Proper testing of code can verify both that the end product looks and acts like it’s supposed to, and it was built in the appropriate manner. Like the coding itself, there are a large number of tools and methods available to achieve the same ends, and the architect is responsible for making the decisions that benefit the team most.

Finally, architects are responsible to ensure quality documentation is created, updated, and accessible. Even in the best of conditions, documentation can quickly seem like an unpleasant after thought. It’s a time honored tradition for documentation to be the last thing you do as you sprint out the door after years of working on a project.

Carefully architecting a project, however, means proper documentation is going to be much easier to do and less likely to be put off. With the proper tools, documentation can even be built into the very process of writing the actual code, as developers work. Task runners like Grunt and Gulp make it easy to use just a couple lines of extra comments to transform the site you’re already building into a well-organized and useful collection of styles and branding.

Going into the new year, I’m making plans to reshape my own process to better reflect proper front end architecting. On smaller client projects, some complications are unnecessary. On other, larger endeavors, there’s a limit to how much influence one team member can exert with an as-yet unproven process. In both cases, I want to maximize how much I can learn and grow anyway. I plan to report back with my ideas and changes in the near future, and then follow up with the impacts as they arrive in the coming months and years.

Look forward to plenty of abstract architecting in 2017! If you’ve had experience with this emerging field before, or just want to join in the experimenting, reach out to me at fec.fyi or on Twitter!

Thanks for listening, everyone. With my schedule back on track, I’ll look forward to once again seeing you all next week! As always, this has been Chris Landtiser, and Front End Center.