Foundations of a Frontend Platform - Standardization & Best Practices

Architecture guidelines

Too often, Frontend Architecture happens in relatively small siloes. If team autonomy is your goal, then keeping things in your own silo may seem like a good idea. But we all know plans can change, reorganizations happen, ownership of code can get moved to another team, and people may move from one team to another.

In Enterprise environments, you usually have Enterprise Architects and Solution Architects or some similar roles that make sure the entire IT landscape of an organization is a consistent whole. You want to be able to rearrange the landscape, replace parts and combine things into new and innovative ways. With a modern, cloud based Platform, these people usually reason about (groups of) microservices and Platform capabilities, and APIs to stitch it all together.

Because of the lack of involvement of these Architects in Frontend Development, this helicopter-view on Frontend is usually not there. If you look at all of the Frontends, and as an Architect you would know and understand how eventually these Frontend Features are delivered as one experience to the end-user and therefore need to be integrated at some point as a more or less monolithic, single-threaded application on unknown hardware, you would understand that it makes sense to define exactly how a single team's Frontend should be built, in order to fit into the Enterprise Frontend system and to have a generic way to expose new capabilities for Product teams to consume.

Your mileage may vary, but setting some Architectural guidelines is unavoidable, or you'll lose your ability to move fast as an organization.

Boilerplate code

Every Frontend Framework these days has its own way of providing a quick start for projects: scripts that generate some boilerplate code to get you started on the right foot, implementing best practices.

But for your organization specifically, you may have different needs for every project to start, every component or service to create, or whatever it is you are building. You have your own ideal, curated set of libraries you want people to use on which you perform Lifecycle Management. You have your own Architectural guidelines. You may need to register new applications in your Software Catalog or something similar that you need to automate when setting up a new project.

In other words, in order to get your developers quick start the right way, you want to offer them your own boilerplate code that adheres to your standards. This speeds up development, reduces their cognitive load and can greatly enhance the Developer Experience (DX)