Architecture @ FARFETCH

Many times, I’ve seen people discuss what architecture is and, more often than not, it ends up being about the role of the architect while ignoring the essence and purpose of having architecture practices within a company. So in this article instead of writing about what means to be an architect at Farfetch, I’m going to focus on how I see architecture within a tech company, what it should aim to achieve, and how we go about it at Farfetch.

We want to change the way people shop for fashion. We are the global technology platform for luxury fashion, and we will continue to do it with technology as one of the drivers of innovation and development, and so we focus on building sustainable, consistent and scalable technology to support the future of Farfetch’s product suite. This is the mission we all share - though bestowed to the Architecture Group as its main focus - is to ensure everything we build solves today’s challenges and thinks about tomorrow’s innovations.

As I see it, Architecture is about the long-term while doing it in incremental steps. It is about supporting our business growth ensuring everything we build has a purpose, it is about what benefits our customers, and it does not derail into a tech-for-tech exercise. Yes, yawn away at the entire sentence… I understand. I know it looks very consultant-like and I still think all of that is important. However, what I believe makes the difference is how you go and walk the walk.

So what does it all mean?

Reflecting on the above this is our Architecture mission: "Champion the architectural integrity, consistency, scalability, performance and long-term future of Farfetch’s product suite.”

All we do reflects that in one way or the other, in a practical way.

It reflects on how we organise the Architecture Group.

Let’s start with the obvious; we have Architects at Farfetch. It’s a small group that keeps a global view of all efforts across multiple domains ensuring we take the right technical steps and avoid isolated, many-times reinvented, solutions. To ensure this, they work with everyone, contributing to planning, promotion of guidelines and best practices, monitoring global tech debt and helping guide the multiple teams on getting the right enterprise solutions in place. Also, whenever needed, do whatever’s necessary to solve the hardest technical challenges.

The Architect Group itself has five additional teams which I believe are key to the overall architecture’s mission.

The Core Engineering team, which work as an operating arm of architecture efforts, building and maintaining core systems that service all business areas indirectly, and are key to our platform strategy.

The API Champions, who coordinates the design of our Platform APIs, ensuring that although we have hundreds of developers building our platform and its public facing APIs, at the end of the day, such APIs will feel as being constructed by the same person.

The Frontend Champions, that similarly to API colleagues, help build frameworks and run activities to ensure consistency in how we develop our web, customer-facing applications.

The Technical Writers team, the natural partners of the Champions, which gives us the means to share and educate internal and external people on how to use our platform.

The Tech PR team that connects all we do with tech communities and events, ensuring we learn from everyone and we also share all our efforts consistently.

I deeply believe that the balance we get from these five teams within the group is key to a healthy architecture within a company, ensuring understanding of the business, consolidating designs, teaching and promoting our tech inside and outside the company.

Nevertheless, it doesn’t stop here; we have architecture within other groups that specialise in areas like infrastructure and big data while sharing the mission and keeping a healthy network of communication.

It reflects on how we organise the teams building our products.

It’s important to point out that Architecture Group is just a piece of a broader tech puzzle. It works very closely with Engineering, Infrastructure, Security, Product and multiple Business teams, making collaboration the most important enabler of architectural decisions, and while we all have specific missions, there is a natural, healthy overlap. All teams are vested in helping design and follow our global architecture and principles, and everyone is vested in ensuring we can build and support what we’re designing. When done right, this balance is magical. Done wrong, you get isolated islands. How to do it right? For me this is simple: participate, share your opinion, debate, respect each team responsibilities on decision-making and at the end-of-the-day work to make any decision a success (even if you don’t fully agree with it).

In my opinion, one key element of implementing our platform strategy is the fact we organise teams around how we design the Farfetch Platform and its multiple domains, and vice-versa we adjust our systems as we need to scale teams. Big fans of Conway’s law, we started organising our teams around business domains and organising our services accordingly, creating units that focus on growing and optimising specific areas. Architecture guidelines and activities ensure isolation doesn’t mean waste and work as "the glue” between domains as tech efforts scale up. As domains grow in complexity and teams in size, splits at a team and tech levels are planned and executed. Multiple companies follow similar models, we learned from some of them and did what was best for Farfetch ecosystem. Copy-pasting design blindly is not, in my opinion, a good exercise.

Tech-per-tech is not our goal, and as such, all our choices follow a simple rationale: "do we really need it?”.

I’m not a big fan of any specific language, and consequently not a real fan of specific language developers. I believe a true software engineer will learn whatever tools are needed to achieve given goals within domains, and not change tools guided solely by personal tastes – these are the people I like to work with.

Farfetch started as a set of code built in VB.NET. This was an initial choice that led to the success of the company. As a result, all our tech evolution comes from that base, and we slowly evolved it as it made sense to do so. We added new languages, databases and tools to our tech stack, but only when needed and not because someone was an expert on it. I called it, the SimpleStack. It will grow, evolve and change, but just enough to be useful.

It reflects on how we help to define our roadmaps and outcomes.

The theory is great and is the foundation to design and plan the best solutions. And a theory is only useful when putting into practice.

Creating the right solutions means we need to understand the customer needs and define how we aim to address it. Knowing what we need to offer our customers then sets the stage for what we need to build. This is where technology conversations need to start. 

We naturally define technology specific work but, even that is aligned with offering the best service to our customers. We need to prepare for the impacts generated from having more customers, offer a faster experience across a global landscape, process more data and be more resilient. And keeping up with those requirements must happen while adding more useful features across the multiple channels of our platform. As such, enabling architecture vision within our suite of products requires collaboration with all teams planning the delivery of such products. There isn’t a plan for tech evolution and a plan for product development. We aim to ensure all technical enablers are included within a single team’s plan. And we work, so everyone understands the best way to intertwine new features with technological enablers. So put simply, defining how tech evolution and new functionalities are executed should be a multi-disciplinary team effort where everyone contributes with their own skills.

In summary

At Farfetch we don’t see architecture as a position where some enlightened gurus sit on chairs laying out blueprints, saying what must be done and expecting others to build. Architecture at Farfetch is a balancing act, one that requires experience, a lot of learning, communication, planning and execution. It all starts by fully understanding our company and our challenges; then is about explaining what our technology achieves today, what it can become in the future and what changes are required. That enables conversations that go through multiple scenarios and trade-offs, and finally making the technical decisions we believe are the best for the company. So it requires listening, understanding, explaining, evaluating ideas and making decisions with the data available. It is not about foreseeing the future as if we owned a crystal ball that shows us the way. If you believe you can design anything by the power of foresight, then my bet is you are playing a roulette game.