In House Frontend Architects Pt. 2

0:00 - intro

0:00:43 - What kind of organizations would benefit most from having an in-house frontend architect?

0:02:10 - What problems would be solved by this ROLE in place?

0:04:07 - Specialized skills vs. hiring more engineers.

0:06:16 - The role as a Frontend architect or a Consultant

0:07:50 - Acquisition of F-a-a-S companies and integration to larger companies.

0:09:18 - Advice for business stakeholders and digital leaders.

#frontend

#javascript

#programming

#developer

#coding

#html

#css

#webdevelopment

#ux

#ui
#frontenddeveloper

#frontendmentor

#frontendconf

#frontenddesign

#frontendux

#frontendjs

#frontendcss

#frontendhtml

Welcome back to the Goodfrontend podcast. My name is Karl, and today I'm with Kane, the
founder of Goodfrontend. Today we'll continue to talk about the organizations that would benefit most from having an in-house frontend architect. Let's cut to the chase. What kind of
organizations would benefit most from having an in-house frontend architect?

What I would say is any brand or retailer thinking about moving to a new platform or thinking
about doing a big project today would probably benefit from, a frontend architect. So anyone
between Shopify and all the way to the large enterprises like SAP commerce, Salesforce would really benefit from, a frontend architect. So if you think of the word headless automatically, you should associate that with the word frontend. If you think of the word composable, you should always associate that with the word frontend, because when we say headless, we are talking about those SaaS companies that are offering headless solutions.

Those solutions require a head or frontend. In the same way when we are talking composable, you automatically think of a composer, someone needs to compose those software together, and more often than not, that happens on the frontend side of things.

And what problems would be solved by having this role in place? Let me perhaps describe the problem, and I'm sure many brands and retailer who would have decided to go headless or composable in the past few years would've experienced this problem.

And that problem is when you start with your project and you are shocked at the number of
frontend engineers you need to accomplish that project successfully. And a lot of these projects that have started two years ago or a year ago, they find themselves in a position where their projects are delayed. And that's because they are lacking a lot of the architecture that should have happened in the beginning of that project. And so the tendency is they get to a midpoint in their project and they solve it by adding more people. They try to add more frontend engineers into the project to try to solve this problem, and they keep getting delayed and more delays because they can't go live. And so having a frontend architect would really help address that problem because this architect person should create a roadmap that will allow you to achieve certain milestones at certain times and to create that framework for your process and for your people and your technology to ensure that everything is done properly.

So it's more to do with that specialized skill of architecture that these companies would be
needing as opposed to having or hiring like, multiple number of engineers, right?.

Yeah. Absolutely. I think it's a common mistake that people make. They get to panic mode and they think adding more people will solve the problem, but more often than not, it won't solve the problem. What that does is that it just looks like you're solving the problem, but you still finish at the same time.

So it's more important to have the right types of people in place.

And can you think of any examples of project that failed to, to lack of frontend architecture And can you describe the situation and what happened when you were brought on board?

Well, I won't name any names, of course. As you know, a big part of what we do here at
Goodfrontend is frontend architecture. It's frontend consulting, and we work with many brands and retailers to help them with that problem. And what I would say as a common scenario when I see projects is that I come in a lot later as a frontend architect. I come in a lot later when the problem is already there. And for the most part, what I see are clients who are doing their best, they are really wanting to push forward, they want to be successful, they want to deliver this project, and they're working 110%. And then you also have delivery teams who feel the same. They're doing their best, but for some reason they just keep spinning around in circles and they can't quite put their finger on what the issue is. That's the common situation. And so I come in as a consultant, as a frontend architect consultant, and my role really is just to guide the team, guide the business, and try to help people see the gap. I think if architecture was in place in the very beginning, those problems would not exist. And so, yeah, that, that's a very common scenario.

And I'm sure again, that many organizations who would've replatformed in the last two, three
years to composable commerce and headless commerce would've experienced the same.
Do you think this is a widespread problem? How are people solving this problem currently? I'm just thinking this is why we're seeing so many Frontend-as-a-Service company center, the market, and I've noticed that ElasticPath, Commercetools and Shopify have all acquired Frontend-as-a- Service companies recently. And what do you think about, these changes

Yeah, it's definitely a widespread problem. As you mentioned, we see a lot of people looking at this problem and working towards a solution from a vendor perspective. They're doing their best to create technologies to try to chip away at that problem. So they would buy Frontend-as-a- Service companies and integrate it into their products to try and support their clients. And I think that is proof of how widespread this problem is. The fact that all of these commerce providers are buying Frontend-as-a-Service companies and integrating it into their products shows how widespread this problem is. But the issue is that having Frontend-as-a-Service only chips away at the problem if you like, it makes the problem smaller, but doesn't actually completely solve it. The real issue is that we don't have proper roles in place to enable these projects to be successful. And I do think you're right that the reason why there is such growth of demand in this market is because yeah, the problem is so widespread and that's why we exist as well. For the same reason we just solve this problem in a different way from a vendor perspective. It makes sense for them to solve it from a technology perspective, but for us, we want to go to the heart of the problem and fix it through putting the right people in place and ensuring that these projects are
delivered successfully.

Finally, what would be your advice for business stakeholders and digital leaders who are unable to fill the frontend architectural role? Is buying a Frontend-as-a-Service product sufficient? I definitely welcome Frontend-as-a-Service organizations for sure. I think they are in the right place to solve the right problems, but I don't think it's sufficient. And let me tell you why. Everybody thought that having certain frameworks in place would solve our problems. You know, a little bit of history, we thought that, oh, if we had something that would allow us to solve cross browsers compatibility, it would make our lives easier. So jQuery came along, but it didn't really solve the problem. Well, it solved the problem, but new problems arose because people needed to differentiate. And so we ended up with more libraries like React, Vue, Angular to enable organizations to differentiate, but that created a new problem. That's the same thing for frameworks. People needed to differentiate it from libraries. So frameworks were created like Next.js, Nuxt.js, Astro and all these frameworks. But that again, created a new problem, which is now we have Frontend-as-a-Service, which is the layer above the libraries and the frameworks. And now it's more like a, A-as-a-Service, but that is really not sufficient. You need a person in place to solve this problem. And my advice for organizations who are struggling to find the right person is perhaps to hire a consultant with the goal of training someone in-house. If you don't want to be a technical organization because you want to focus on commerce, then yeah, work with partners. There are, there are companies nowadays like GFED and other organizations similar to us that
are more than willing to support organizations to ensure that their commerce projects are
successful.