Fathi Bellahcene - L’architecture n’appartient pas aux architectes ! @Veepee

[00:00:05] Hello, let me introduce myself, my name is Faty Bellahssene. I am a principal architect at Vente Privée, at Veepee, excuse me. And before I start, I'd just like to tell you how I ended up on this stage. So I don't know if Samuel is in the room. No? So a few months ago, we were discussing with Samuel, Samuel Reutier, who organizes the conference, about the architecture practices between Vente Privée and and and Sdisount, and so we exchanged several times, and at the end he told me, Ah, it would be cool if you came to pitch a bit what you told me and what you do at Vente Privée. Ah, so I told him, no, I don't think it's that interesting, and I think there are more interesting things to talk about than what we do at Vente Privée, he told me, yes, yes, it's good, it's good. So you know, like when you tell kids, yes, yes, we'll see. And here I am. So I found myself in trouble. So if Sam offers to talk to him,
[00:01:05] don't talk to him. And thank you for the sauce. So we're going to start, uh, the presentation will follow the following plan. I'm going to start by presenting a bit of the context in which we work, explain what Vente Privée is, the context of e-commerce, and our definition of architecture. Then, what it implies, and how we practice it, and how the architects, the architects in our organization, position themselves.
[00:01:34] So to start, a few figures. So it's not to show that we are big and that we are important, but it's just to give you an idea of the size of what the Vipi information system represents.
[00:01:46] because there are a lot of people when we meet them and we talk to them about Vipi, they think it's just an application. So it's 650 employees.
[00:01:54] Uh, an information system that is very, very big, so it's 1200 applications, but hundreds of databases, thousands of services, uh, 7000 deployments in production since the beginning of the year. And functionally, we don't just expose, we're not just an e-commerce site where we expose catalogs. We do logistics, we do supply, we do production, so we do shooting, so there's a real functional density. And the system is really large. So when we talk about architecture in this presentation, you have to keep in mind that it's a system that is really very big, uh, that has a real functional complexity, and uh, the architecture will go from application architecture to an exercise that is more about urban planning.
[00:02:42] The context of e-commerce. That's one of the first things I was told at Vente Privée and uh I think it's the most important thing to share and understand when you work in in e-commerce. Uh, unlike all other industries, this is my first experience in e-commerce. I've done a lot of banking, insurance, automotive, some classic industries. Uh, what struck me in e-commerce compared to other industries, is the importance of going fast. Uh, if you take banks, the automotive industry, the size of the company is important. Uh, take automotive, Toyota, even if new companies are arriving, before Toyota is dethroned or put in difficulty, or Ford, a lot of time will pass. Same for banks, these are industries where the size of the company, its valuation has a real, a real importance, uh, in its weight, in its weight in the ecosystem. E-commerce, and I'd like to say more about all the businesses that are online today, it's very different. What will matter is really speed. Vente Privée is a relatively young company, early 2000s, and between 2000, when Vente Privée started, and Amazon, Amazon arrived and became the giant we know. Today there are many players. In our field, you can have a player who starts today, who in two, three years, can become major, even very important in in our ecosystem. So, there's a real importance in going fast. What's important is not to be big and to grow, the important thing is really to go fast and accelerate.
[00:04:21] Uh, it's really something that has an impact on our way of working day by day. As an architect, we will have three interlocutors and again when I made my presentation, he told me, but who will be the brute and who will be the truant? between the business, the product people and the tech people. So as an architect, you have three main families of interlocutors.
[00:04:45] The business people. When they interact with you, uh, it will mainly be about alignment. They will expose their business vision, their concerns, and the initiatives they want to do. I want to develop travel, I want to open a new business, new functionalities, etc. Uh, you have to very quickly, again, speed is important, tell them if it's feasible, uh, in how much time and at what price. So what they will try to understand is
[00:05:15] to be reassured that you have understood their business vision, that you are aligned with it, and bring them answers.
[00:05:25] The POs or the product family, the BPOs, well, what I call the product family,
[00:05:32] their interaction is that once the topics are on the table, they have to build roadmaps and uh one of the main difficulties is the interdependencies between the products. So we have a product organization and often the big functionalities are cross-product. And a PO, what interests him is,
[00:05:48] okay, I have to do this, I master my roadmap, I master my team, but I need to have visibility on what's going to happen in the other teams, uh, etc. So having visibility on the interdependencies,
[00:06:03] uh, what this functionality and this development implies for the other teams of the organization. And it's the same there, it's we must be able to give them visibility, explain to them how to develop things, and especially visibility on the interdependencies. The tech family, so the developers, the lead developers, the infra people, etc.
[00:06:26] They will also be interested in the vision, they need to know where they are going and what is asked of them, to give meaning to their work, it's very important. But in addition to that, they will ask you in what framework they evolve. So to be able to define for them a bit the rules of the game, where they work, and also to have visibility on
[00:06:49] the global solution, the global development, and not just say, well, I'm here, I have functionalities, I have to develop them, but they need to have the global vision and give meaning. And we'll see in this presentation what that implies.
[00:07:00] So if we summarize our work as an architect, vis-à-vis our main interlocutors, it's to be able to respond quickly and give solutions. If the business asks me if it's possible to do this new thing, yes, no, and how we're going to do it for the POs, and technically how it transforms into development for the technical part.
[00:07:24] So that's really our, our, our main mission and our main task at Vente Privée.
[00:07:34] So the definition of architecture. Uh, in 2005, Martin Fowler wrote an article called 'Who Needs an Architect?'. At the time, I was a developer and I was looking for arguments to
[00:07:45] criticize the architects that I thought, I thought they were fictitious employees, useless people who didn't serve much because they came to see us every six months with rules and constraints.
[00:07:58] And it was a bit of a question, we subjected ourselves to the question. So I told myself, wow, someone I respect enormously, who creates a somewhat flashy article where I'm going to find arguments to prove that architects are useless. Uh, in this article, it, there are two, there are three parts, but the two parts are interesting. The first thing is he asks the question of, well, what exactly is the practice of architecture, and uh, he separates the practice from the role. So he talks in the first part about the practice of architecture, what it is to do architecture in an IT company, of course. And what is the role of the architect to precisely apply this thing. And in the various exchanges, well in the article, he finishes with this definition which may seem a bit generic,
[00:08:46] but which for me is really, in any case, it's the best and it's the one that I carry. Architecture is about important things, whatever it may be. And he defines importance by things that have a systemic impact on the information system or the application you are working on, or an irreversible impact.
[00:09:10] It can be an algorithm choice that can have an impact on your performance or the performance of your company, for example, the search for an e-commerce company. It can be a database choice, it's very well known for developers that changing a database once it's in production with a lot of history is extremely complicated. It can be a design, a flow, a process, when you work at the scale of an information system and you do urban planning. So for him, it's really what is irreversible, which can have impacts over time, or difficult to reverse, and which can have a systemic impact. That's what's important. And we realize that in fact, uh, it covers both the decisions that developers can make, and enterprise architects. The scope is really broad,
[00:09:59] and it touches a lot of things. And here we find the classic architecture professions with software architects, urban planners, enterprise architects, etc.
[00:10:12] We have adapted this a bit to our context at Vente Privée by taking the two elements that are specific to us, namely decision-making and speed. So for us at Vente Privée, and that's what we do every day, is to make decisions. We try to make good decisions.
[00:10:30] I hope they are good, otherwise, I think if I made bad decisions, I wouldn't be here. On important things, as quickly as possible. So that's our definition of architecture and what is important, it can be an algorithm choice, a database choice, uh, a database model, uh, or a flow, uh, a solution choice on uh a software, etc.
[00:10:58] So the consequences of that. Uh, here we have an organizational problem, we are 650, we have about sixty products, there are a lot of decisions. We are a team of 10 architects or a dozen architects at Vente Privée. Uh, if it's the architects who have to make all the decisions about what works, it doesn't fit, it doesn't fit. You will slow down and you will become very, you are a bottleneck. So you cannot delegate the responsibility of architecture as we defined it to the architects alone. There is a real problem if you do it. Uh, you will go against the first principle which is to go fast and accelerate, and you are a real blocker for the organization. So you have no choice but to delegate this responsibility to other people in the organization.
[00:11:44] Now, delegating is a big word, it's easy to say, well, I delegate you the responsibility of making decisions, but you have to put in place the right context. And that's what we're going to explain a bit. It's how to set up a delegation context on architectural decisions in the organization.
[00:12:03] The first thing is to whom do we delegate? Uh, so our information system, but also our organization, it's cut into parts. So we have the global part which is the information system, which we divide into three domains, which are three sub-functional sets of the information system, which we re-divide into sub-functional sets which are the tribes.
[00:12:26] which we re-divide into products, and within the products, we have the applications, the databases, really what we call the software system.
[00:12:38] Today, the idea is, uh, when we have a decision to make, And we also find this in in many books, in the accelerate book, and also in the The Program. If you want to make the best decision, you must turn to the experts, those who have the best knowledge. If you need to go fast, you must maximize your knowledge on the subject. So you have to select the person who concentrates the most knowledge. Then there are two things. Either you ask that person to explain everything they know to you and then you make the decision. Or you trust them and you ask them to make the decision. That's the choice we made.
[00:13:19] Uh, in this organization, the product level is high, so we are a product organization where each product has a product team with a lead dev and developers and a PO.
[00:13:31] If a decision concerns a product or an application of a product, the decision is automatically delegated to the lead developer of that product. That is, as an architect, principal architect at Vente Privée, I can't go to a product and say, well, you're going to develop this like that, or you're going to do that like that, you're going to use such technology, etc. That's not how delegation works.
[00:13:55] For us, the product is master on board, he is the master of his product and he is the one who makes his choices, after he assumes them, of course, but in terms of delegation,
[00:14:04] if the decision is made on a product or an application, it is uh, it's the lead developer of that product who makes the decisions. Of course, he can ask for our opinion, he will consult people, collaborate, but he is the sole owner of the decision. Then, if it affects several products within a tribe, at the domain level, we have architect teams. So we have three domains, three architect teams, and in the tribes, in the domains, we will also talk about the organization of architects in the different domains. We will have architects who are, uh, who can be specialized on a tribe, for example, in operation, in one of the tribes, sales preparation, where we will find the negotiation part.
[00:14:45] So all that is commercial and the production part of sales, so generation of the catalog, technical data sheets, images, everything that is banners. And uh, we have architects who are specialized on all that will be production. So we will ask them. If it touches a subject, uh, that concerns the production tribe, we will ask them. The idea behind all that is to say that
[00:15:08] at the tribe level and at the domain level, we have architects who are the most extensive knowledge on the subject, so we will give them the delegation. And if it concerns the system in its globality, well, it will be, it will be for Bibi, it will be for me.
[00:15:24] Uh, once again, the philosophy behind this is to try to go fast in the decision, and to go fast, we delegate to the most competent person in our organization. So if it's product, the lead dev, if it's cross-product in a tribe, an architect, if it's in a domain, the person from the domain who has the most knowledge, and if it's transversal, it's for me.
[00:15:46] The second element, well, for me, it's the most important element. And yesterday Arnaud talked about it in his presentation in the three pillars of measurement, he said that one of the things that was really important was to put people in
[00:15:58] in a context that is really, uh, I don't know how to say, but in a healthy context where we will perpetuate productivity. You, you can't delegate responsibility to someone, having a lead dev and saying, well, now you're responsible and you'll assume your responsibilities, if you don't create a relationship of trust with them. Uh, what I learned at Vente Privée after 8 years, is that the most important thing for an architect is his proximity with the people he works with. If there is no proximity, there is no trust. If there is no trust, if you go to see them, it's like an elastic band. If you go to see people just for problems or to check accounts, you stretch the elastic band. Uh, we do an architecture review, so it's a kind of question. Uh, why are you late on your developments? Uh, why did you use such technology? You stretch your relationship and at some point the elastic breaks.
[00:16:57] And when it breaks, the relationship is completely broken, there is no more trust. And when you put a lead developer whom you ask to take responsibility in a tense or non-trust context, he won't make a decision. Because he won't be in a, he won't be in a context where he will feel at ease. He will say, well, if I make decisions, then I will have to justify myself, so he will want to cover himself, he will not seek to go fast.
[00:17:26] Uh, it's really important to develop this proximity. We, for example, at Vente Privée,
[00:17:33] the architect teams are really in the domains and we are mixed in the same open spaces. We don't have a place of our own where we meet, we are really in the teams and distributed.
[00:17:42] A tip I also give to architects is to spend time with your teams. Go have lunch with them, go have a coffee, go eat. There is no better way to understand an information system. You can read the doc, you can read the code, but the best way to get the best information is to talk to people. By talking to people, you will build a relationship, build trust, improve your knowledge. The person, when they make choices, will talk to you about it. So you will be in anticipation and not in the reaction of an architecture committee. where you discover things that have been done and, well, you're going to say, why did you do that? And you have to start over, but it's too late, we have already engaged in developments, we have already chosen the database. There are only benefits to going to see. It may seem insignificant, but having lunch, taking time, being interested in people, listening to what they do,
[00:18:31] uh, for me, it's really the most important thing in our work as an architect. There are enormous benefits at all levels. way to get the best information is to talk to people. By talking to people, you will build a relationship, build trust, improve your knowledge. The person, when they make choices, will talk to you about them, so you will be in anticipation and not in the reaction of an architecture committee where you discover things that have been done and well, you're going to say, 'Why did you do that? We need to start over,' but it's too late, we've already started developments, we've already chosen the database. There are only benefits to go see. It might seem trivial, but having lunch, taking time, being interested in people, listening to what they do. For me, that's really the most important thing in our work as architects.
[00:18:36] There are enormous benefits at all levels.
[00:18:40] The next thing is to really trust. Now that's really difficult, we've had a lot of trouble doing that until today. If you take rugby or any team sport, we're going to tell you how to win, so winning means scoring more goals than the opponent. We're going to define the rules for you.
[00:18:59] What's an offside? What's a scrum? a lineout and so on and so forth.
[00:19:05] And the same for all sports. But in the rules, you find nothing about strategy, it doesn't tell you that, for example, in soccer you have to play in a 4-4-2 formation and be defensive. Or in rugby to send balls into the air. We have to do the same. If we trust, we must not confuse the objective and the means. If you look, for example, at the technical guidelines, which are a bit like the rules of the game, often, you will have rules that relate to the means of achieving an objective rather than the objective itself. A simple example is on tests. So very often in many companies I've been to, in the guidelines, they'll tell you, 'Well, I want 90% test coverage or I want you to do TDD.' Well, I'm okay with that, but when you work on a proprietary software like Aix, which is a proprietary language, doing TDD or a very, very old legacy software that has no coverage. When you go to the team and tell them that their goal is to achieve 80-70% coverage, they'll laugh. That will never happen.
[00:20:14] Is there any point in doing that? I'm asking myself the question. The time it takes to cover all their code and, moreover, the time it takes for them to implement these codes, it's going to take ages on code that's been in production for years and is running, otherwise there will be other problems. There's no point in making that rule. On the other hand, for an application starting from scratch, which is an application that is just starting, imposing unit tests on them can make sense. But this rule makes no sense, what is the real objective of unit testing or coverage or TDD? It's about having a stable system in production with no bugs, with good performance. It's the concept of SLA. So rather than imposing means on performance like doing TDD, doing BDD, doing trunk-based development, doing a mono repo, ask yourself what really matters, what is the desired outcome of all this, and give people the freedom.
[00:21:13] Really trust them with the choices and the means they will implement. Uh, if you tell people to calculate their SLA, implement technical means to measure this SLA and ensure that this SLA is respected. And the means are your problem. There, you show respect. But if you go to the person and tell them, 'Okay, you have to do TDD, you need 70% coverage, you have to use such and such a database, and you have to do trunk-based development,' where is the responsibility, where is the choice, where is the delegation? It's like going to a soccer coach and saying, 'Okay, these are your players, I'm imposing your starting eleven on you, you'll play in a 4-3-3 because I want to, and you'll play defensively.' But you're the coach.
[00:22:02] There's no delegation and no respect, I'd even say. So when we trust,
[00:22:09] you must focus and really leave a field of, well, you must leave the choice to the person you delegate to, whether it's an architect, a lead dev, or even a developer, to do things as they wish. That's really important, and read your guidelines, you'll see that very often we make this amalgamation, and very often, it doesn't work.
[00:22:33] The timing. So, we talked about it, we put people at ease, we respect them by giving them the choice, really the choice to do what they want, now they need to move fast. Uh, in chess, there are different time controls in games, it can be classic games of 2 hours plus increments, a game can last more than 6 hours. And then you have games, what we call rapid games, which will last 15, 10, or even 5 minutes. Uh, we asked, well, I read an interview with Maxime Vachier-Lagrave, who is one of the very, very, well, the best French player in recent years, but at least in the last 10 years, even the greatest French player ever, on game precision. So precision, in chess, when you play a move, you have a precision score. If you have 100%, it means the move you played is the best. And the lower your score, the more it goes down, it means you might have played the second best move, the third, and so on. And a game will have an overall precision that will indicate the quality of the decisions you made with each move. So if you play a game with 100% precision, and it happens for grandmasters, it means that with every move, every time, you made the best possible decision. And the more it drops, it means that you were, there were times when you made moves that were not the best, not optimized. We asked him to compare the precision between a classic game of 3-6 hours, more than 6 hours. with a game, with a game the precision of a rapid game of 5 minutes or 10 minutes. And his answer had quite troubled me. He said the quality and the precision are the same.
[00:24:17] On average, the precision of a long game of 6, we have 3 hours of thinking time, and a game, we have 10 minutes of thinking. It's the same. The only difference between these two games is that you will have epiphenomena, there will be an error from time to time in rapid games. But on average, the precision is identical.
[00:24:38] A grandmaster, when he plays for 2 or 3 hours, always makes the right decisions, sometimes he makes mistakes. You have epiphenomena which are errors.
[00:24:47] Uh, and he justifies it extremely clearly, he says when you play, you immediately have the feeling
[00:24:56] you immediately get the feeling and you immediately know that there aren't, you don't look at all the moves, there are three or four of them, you know they are the best. So already, you have an intuition about the three best moves. And for the three best moves, intuitively, you know which one is truly the best. So already, when you're in a rapid game, you have three moves, one of them you tell yourself is probably the best, you do your calculations quickly, and very often you follow your intuition. He says, well, the long game. We have the same impressions, except that we secure ourselves by looking at the 4th, 5th, 6th. But in the majority of cases, for very grandmasters, for people who are quite gifted, the best move, the intuitive move, is very, very often the best. And do the experiment and do the test around you. When you go to a lead developer and present a problem to them, they immediately answer you, they immediately tell you, 'Well, to do this, you have to do this or that, but I think it's this,' and in 99% of cases, what they tell you is the right thing to do. He has the intuition for the right move because he masters his subject, he has the knowledge. And if you put him, if you have a good relationship, if he's confident and feels secure talking to you, telling you, 'Well, if I answer him, I'm not risking my life or they won't blame me for things,' he'll answer you right away. A concrete example is when we did the convergence, so vente-privee, 5 years ago, we were three companies. We, vente-privee, bought two companies, Privalia and vente-exclusive. And we were asked to converge these platforms. To have one platform that links the three businesses and no longer have three different platforms. I remember, we met with Arnaud in Amsterdam at the time, he was with us. Uh, in one week, we defined, so we had imposed the vision of having a single platform, very quickly, we knew, we had three options, and very quickly we positioned ourselves, we knew which one we should do. Afterwards, we backed up, we backed up our intuition with reflections and verifications, but in one week, two weeks, we knew which approach we should take, what our convergence strategy was. Because we were between, we trusted each other, we didn't want to evaluate all options. We really had three on the table: create a new platform, hybridize platforms to get the best out of them by ensuring interoperability, or take the one with the best functional coverage and develop the missing parts. That's the one we chose. Because the other two, developing a new platform in one year was impossible, hybridizing platforms was too complex, and the human context was not suitable for it. And there were pieces that weren't capable of handling the overall business load. The third was the only plausible one, and among the three platforms we had, we chose the one that maximized functional coverage and gave us security guarantees in terms of coverage and ability to manage and support the overall load. So it didn't take us a huge amount of time, and it was the biggest project I've done in my life, and after that, we were right to do it, and it went very well.
[00:28:16] Errors. Uh, it's also something important. Uh, if you ask people, as I said in chess, the difference between a long game and a rapid game is the epiphenomena of errors. So if you ask people to go fast, there will inevitably be times when they make mistakes, and that's okay. When you are in a mindset and you are truly in a philosophy of accelerating, of going very fast, uh, you must at some point collectively take responsibility for errors and accept them. We are not in an industry where error can be critical and fatal, like in human transportation industries, excuse me, or uh. We can afford to make mistakes if the sum of our successes and the ROI, the impact of our successes, covers our errors.
[00:29:08] We made mistakes on many projects, one of the biggest, well, one of the biggest projects we made mistakes on was the transformation of the production chain. Similarly, we started with an approach, we had a strategy to develop the thing, after a while, we realized we had made a mistake. We admitted the error and we changed. And we continued.
[00:29:29] Error is truly a part of, uh, you cannot judge a person by their errors, but you must judge them by what they contributed to the company. Of course, if she did big things, I mean, if she was in good faith in her mistakes and didn't do anything serious, then it's another matter. But you can't, if you're in an organization where you show errors, you, in all humility, take responsibility for your errors, and it's not serious, and we see that you continue to be there and that we trust you, it's also a way to show that you are in a fairly healthy ecosystem and environment where you, as a lead dev, could have hidden things that aren't working or aren't going well.
[00:30:09] And you'll feel reassured by the fact that, well, he messed up a very big project for the company, if I made a mistake there, it should be fine. So the relationship with error is really important.
[00:30:23] And you must ensure that people who make decisions, especially when people join the company or when they get a promotion to certain positions, reassure them that, firstly, It's certain they will make mistakes at some point, it's certain they will make mistakes. Zero error does not exist. Two, it's not serious. We will all take responsibility together. If the responsibility is delegated, it will be my fault.
[00:30:51] It's my fault, I will bear the consequences. Three, errors are also an opportunity to learn. The project I told you about, which lasted a year and impacted about ten teams, so it was a very, very big project, we made a mistake. We decided to start over, we didn't start from scratch.
[00:31:13] We learned a lot, we kept the fundamentals that we considered good, and we changed what wasn't working. So we didn't start from scratch, but we started with better knowledge, foundations, we started with certainties about what worked and what didn't. And we were able to succeed, and in 6 months, we did more than what we had done in 1 year. It's important to communicate about these errors within the organization.
[00:31:40] Vision and strategy, that's something I really understood late, and after the convergence project, which is also important. Uh, especially when you delegate to lead devs and on very, very big projects that will impact many people in the organization, you must communicate your vision and strategy. If we take the convergence project, the vision was One platform One brand. To have a single brand, VP, originally, we had three brands, vente exclusive, Privalia and VP, and other e-shops. So it was about merging all of that into a single brand and having a single platform to do it. So we made decisions on the strategy to adopt, and behind that, we had a plan. If you take a GPS, the teams are like the GPS. Your GPS, you're going to tell it, 'I want to go to a place,' that's your vision, and your strategy will be the constraints. You're going to tell it, 'Well, I want to go to Lille, I'm going by car, but I don't want to pay tolls and I want it to be the shortest route.' Or I'm going by train, and so on, so your constraints will be your strategy. And your GPS, your team, will define the optimized path to access it, it will define its roadmap in complete autonomy. And if something happens on the way, so you're in your car, there's a traffic jam, an accident, your team, knowing the vision and strategy, is able to adjust
[00:33:05] to choose another route and to continue its journey without coming back to you and saying, 'There's a traffic jam.'
[00:33:13] There's a problem, what do we do?
[00:33:17] You give autonomy and you allow to avoid the team stopping, asking you a question, you answer and it leaves, so you also contribute to the team's velocity and to having real continuity in its work. What happened with convergence is that after 6 months, uh, the board came to us and said, 'Okay, we've changed, we no longer want to go to Lille, we want to go to Valenciennes,' so they changed their vision, telling us, 'Well, in fact,'
[00:33:45] we're going to keep the Privalia brand, we're not going to make VP one platform, we're going to make VP Privalia one platform.
[00:33:54] And uh so it's a real change of vision and they told us well what are the impacts? Already, there are real impacts on the front end where it was completely transparent for them to have one platform and a platform for one brand because you had a single website to deploy, there you found yourself in Spain with two websites. So we had to develop the brand website and Privalia. You would also have to manage multi-tenancy, a member can have two accounts on these two brands. With different orders and so on, on the finance side, it was also necessary to divide and manage sales figures separately, so it had technical impacts at all levels, logistics.
[00:34:36] Uh, financial, accounting, on the front, on sales production, and so on and so forth.
[00:34:44] Having it, and we did it, not on purpose, but it was our way of communicating, we had communicated the vision and strategy. When we communicated the fact that the vision had changed to the teams in 2 or 3 weeks, in 2 weeks, 2-3 weeks, we had an estimate of what the impacts were, the teams reported the impacts to us in terms of cost and in terms of deadline.
[00:35:10] In 2 weeks, in 3 weeks, we updated the costs, the deadlines, so there were back and forths because there were questions and points of clarification, and the team had shifted to the new vision in complete autonomy, there were no hitches, no blockages, no delays. Because people had the vision and strategy in mind, and again, we didn't do it on purpose, but in hindsight, when we analyze, that's what it really was. People knew what the strategy was, our vision was One platform One brand.
[00:35:35] Our strategy was 'When in Rome, do as the Romans do.' At the time, that's what I was saying: we develop on VP everything that is functionally like VP, you do it; if there's a functional gap that's not covered, we develop it; and if, tactically, there's a way to do better within the deadlines and constraints imposed by the business, we do it. People had the strategy, understood that the strategy hadn't shifted, and that we had a deadline and that we had to 'When in Rome, do as the Romans do,' so use the VP platform's functionality to the maximum and not deviate from it. They very quickly understood what the new adjustment was to move towards this new vision, what it meant in terms of cost, and when we told them to go, they were completely autonomous to shift and go for it. So communicating the vision and strategy helps avoid these sudden changes because on large projects, at some point, there will certainly be an unforeseen event, there will be a change. Here, it was a real, a real change of vision, but you can also have changes. And by communicating this to them, you truly give them autonomy, like a GPS; when there's an accident on the road or a traffic jam, it recalculates its route, it recalculates its roadmap.
[00:36:42] The architects in all of this. So the first thing is that we are responsible for implementing delegation and not acting in, well, for truly delegating without substituting ourselves in decisions. It's very hard, we have a lot of trouble, especially when people arrive, getting into this posture of the leader, the lead dev in their product, they are the one who decides, they are the one in charge. He's the one who does it, so he's the one who knows, and he's the one who will assume responsibilities every day in his developments, he's the one who does his production, he's the one who manages his support, he's the one who manages his bugs, so it's up to him to take responsibilities. So one of the difficulties is really to instill this mindset in the minds of architects, including myself, and to ensure that it works that way. Because you're going to have a lot of people who will want to, voluntarily or involuntarily, make decisions instead, say, 'Well, I think it's always the case of the business coming to you with the solution and not the problem,' or sometimes it will be the PO who will impose a solution on you or not. We are a bit the guardians, we are a bit the guarantors of, no, the one who must make the decision on a technical subject is this person, so we must ensure that they are in good conditions and protect them from interference. Then, the attitude of architects. So, one of the difficulties is really to get this mindset into the heads of the architects, including myself, and to make sure it works like that. Because you're going to have a lot of people who are going to want, voluntarily or involuntarily, to make decisions in your place, to say, "Well, you know." I think we all know the case of the business that comes to see you with the solution and not the problem, or sometimes it will be the PO who will impose a solution on you or not. We are a bit the guardians, we are a bit the guarantors of, no, the one who must make the decision on a technical subject is this person, so we must ensure that he is in good conditions and protected from interference. Then the attitude of the architects, uh, the example that I often give is Belgium in 2010-2011, uh, for 18 months, they lived without a government. So there was a political problem where they didn't agree, and for 18 months, there was no government. So people were saying, "My God, they're going to die, Belgium, it's going to be a carnage." And in fact, what happened is that they had very, very good performance, the country was doing very well economically, on all administrative levels, etc. The country functioned very well without politicians. What I mean by that is that the architect is not indispensable. If you remove all the architects from Vente-privée, Vente-privée will work. Vipi will work. Those who produce value are not the architects.
[00:38:56] They are the developers and the lead developers. They are the ones who produce the value and the wealth of the company. We are here to help them maximize their productivity in the best context and in the best possible environment. We are really a support function. It's not up to them to do things for us, but it's up to us to do things for them, to ensure that they are in the best context and in the best conditions. The first question that every architect must ask a lead developer or a team is: how should I help you, how can I help you? That's really it. And if you look, I hesitated between this image and images of Cherpa, but I like the attitude of the orchestra conductor, it's that he is facing the orchestra and not facing the crowd, so he is not there to take the spotlight, and it's not him who produces the music. It's the musicians. If there is no conductor, if there is no orchestra conductor, there will be music. They will produce music, maybe not as good, but they will produce it. If there are no musicians, there is no music. There will be a guy who is agitated.
[00:40:05] It can be fun. Uh, really, that's really, that's really it. Our attention must be completely turned towards the people who produce and ensure that they are in good conditions and that if they have a support need on choices, if they need help. If they have questions, if they have questions, we are there to help them and provide them with answers. We are really a support function and it's, it's, it's, for us it's non-negotiable. It's really important. And when you put yourself in this attitude, when you put yourself in this posture, your relationship will be better, your relationship and people will question you. They will ask you questions, they will share their choices. You delegate the choice, but you participate in the decision because you have a good relationship with them. They know you're there to help them, not to control them. You're not Moscow's eye. And that in any case, you'll be by their side. The attitude is really important, and we are a support function. Uh, I shouldn't say that, I might have problems for my job, but that's what I think. We're not, we're much less important than the developers.
[00:41:14] Our organization, as an architect in the three domains. So there, if you look at this image, uh, functionally, these people change tires. So it's not the same, whether on a Formula 1 pit stop or struggling on the side of the road, but these people functionally change tires. Uh, it's Vente-privée, if you take our three domains. So we have the sourcing part, which will be sales production, negotiation, operations, logistics, supply, finance, and the front.
[00:41:47] These are extremely different contexts. If you take, for example, the entire distribution channel part, which is the front, the mobile apps. Functionally, it's not very dense. There's no extraordinary functional richness and no real complexity. However, technically, it's extremely specific. We have a business where we have a sales opening where during the first two or three minutes, we are, we have a peak load that is really very, very strong. Working on the front end, the constraints are rather technical and extremely specific.
[00:42:20] So the architects we're going to have on the front end don't have, can't have the same profile as architects on the sourcing side, where there's more functional and business complexity. Or on the operations side, where we need people who really master the flows and the regulations. All this to tell you that in terms of organization,
[00:42:43] for me it's laziness to want to have a symmetrical organization everywhere in your, in your organization. Because if you're looking for speed and performance, you have to adjust to your contexts. And in your organization, the different parts of your organization have different contexts. The front end has a context extremely different from operations, which is very different from sourcing. An architect at our front end, well, I wouldn't hire him as an architect on the operations side. Because they don't have the same profiles, they don't have the same aptitudes, and even he would be unhappy. On the front, architects develop, have responsibilities on certain components, have a dedicated team of developers. On the sourcing side, they don't develop, they do urban planning. It's more of an urban planning team that performs an enterprise architecture exercise. So these are really different profiles, they have different sizes and different organizations to best respond to the problems and contexts of each of the domains. And for me, that's really, really important. We're not looking to have a symmetrical organization, but we give freedom, in the same way that we give freedom in decision-making, we give freedom in how to organize and work to the architects in each of the domains. What I told you about delegation at the very beginning, how we delegate. For example, on the operations side, logistics, supply. The architects are specialized by flow. Order placement, procurement, accounting. So if we have a functionality or a feature or something to do on order descent, we're going to orient ourselves towards these architects. On the front side, they will have more responsibility for the critical common elements throughout the front. Uh, the catalog, the exhibition of the catalog, the exhibition of the stock, etcetera, etcetera. So it's going to be more an organization where they will have responsibility and development on common components. On the sales prep side, negotiation, production, they are rather organized by tribe.
[00:44:50] You will have people who are specialized in the negotiation part and people who are more specialized in the production part. So we don't have a symmetrical organization, uh, the architects don't have the same role throughout the organization, and the goal is to best respond to the questions of the different contexts in which they are involved.
[00:45:13] Pragmatism. Ah, that's my favorite subject. Uh, we are an industry that likes controversy and sterile discussions about, uh, "Ah, you do enterprise architecture, you do 60s IT, I do agility, or I do safe." It's super trendy, it's the best method, you have to do that. Uh, we don't care. We don't care about knowing where a practice comes from and where it originated, as long as it has a utility or answers a problem, we take it. My conviction is that there is no framework today. A framework is a set of solutions, of processes, etc. There is no one that responds coherently to the problems you will encounter. However, in each of the frameworks, whether they are agile frameworks or old-fashioned frameworks, you will find things that are extremely relevant and useful. And the choice we made at Vente-privée is to say, well, we start from the problem, what problem do we have, and what exists that solves this problem? So if it's old-fashioned stuff, we take it, we don't care. If it's very recent stuff, we take it, we don't care. For example, the product organization of VP, and I think it's one of the things I'm most proud of at Vente-privée.
[00:46:35] which is to have participated and contributed to the product organization. The basis of this organization is a land use plan. So it's old-fashioned architecture. And it's one of the most important assets at Vente-privée. Our organization, our domain-tribe breakdown, is nothing more than an urban planning and enterprise architecture exercise. Uh, we use Wardley maps to discuss with the business and highlight the dependencies. They are interested in the upper part of the Wardley map. And what we want to show them is, okay, you want to do that, but don't forget that it has impacts on these products and on that, and that it requires this workload. So the Wardley map is extremely useful for defining, for working on dependencies.
[00:47:19] Uh, we also use Event Storming on the production side to see and identify flows and see how we can optimize these things. We will also use BPMN on the dynamic view of the information system with swimlanes, pools. Sorry, to see how, to visualize the processes. Uh, We use what and sometimes, uh, same, uh, sometimes there's nothing and we invent our own, we have our own support, like our map, which we use and which are not industry things and which meet a need. So, instead of asking the question, is it old, is it new, and applying a framework completely? And we also use C4 for system modeling, etc. It's what is my problem? What existing solution is there, and we apply it. If it's practical, if it's effective, we keep it, whatever its origin. And that's really important.
[00:48:23] Now, to conclude, uh, we talked about context, we talked about architecture and architects. One thing to also take into account in the context is the maturity of people and the level. You have to remain humble about your level. And often you're going to see people who are going to read books and who are going to come and see you and say, "Well, we're going to deploy this or this method, it's great." without taking into account the maturity of the team or the maturity of the information system, when you have a lot of legacy, uh, there are methodologies, practices that cannot work. And the level of people, you have to know yourself and be really very humble about your level, that's part of the context. Don't apply, don't put in place things that you can't assume. Uh, I've read a lot of books where you read practices and you say it's great, it would be good, but when you look, you say, do I have the capacity to put it in place? Do I have the level of understanding of experience? Is it the right timing to put it in? That's also part of it. So,
[00:49:27] it's important when we talk about context, to also take into account our level and the overall level of the company and the ability of the company to follow you. There's nothing worse than doing something we're not capable of assuming. If you're not capable of assuming it, don't do it. And the last point is, it worked for us, it's in complete transformation, there are things we put in place 5-6 years ago, we removed, we put back, it's something that evolves over time, uh, in our approach, there are also many errors, we make a lot of mistakes. And in any case, we, that's how we try to move forward and how we try to work. And I thank you for your patience. I thank you for your patience.
[00:50:13] Okay.
[00:50:25] Thank you very much. Yeah, great. Uh, I really thank you for your presentation, which was super clear. I'll just react to Belgium.
[00:50:37] I'm sorry, but in fact, it went badly, in fact, because what happened is that notably the cultural associations, uh, the budgets were renewed as they were. They weren't allowed to change the budgets. So notably, the associations found themselves in some complicated situations where they couldn't create anything anymore, and it was those who already had money who continued to have it. So it's not at all to criticize your image, it's precisely to extend it, and I wonder if the role of the architect isn't also that, at times, to prevent it from being, it's not because we did it well that we're going to keep doing the same. And that, well, when there is no architect, we will continue, but this idea of putting the light where it doesn't work, or where it works well, precisely, turning off in the rooms where, well, it doesn't work anymore, isn't that also one of the roles of the architect in a company like VP?
[00:51:23] Yes, yes. So, uh, so thank you for the remark, and uh, I'll take it into account for the next presentations, I'll delve deeper into my example. Uh, it's, it's exactly that, it's, we are factors of optimization and acceleration. And when in the example of Belgium, what I wanted to say was, the country didn't fall apart, well, the country, it wasn't a catastrophe. It was more to say, the architect, he has importance.
[00:51:50] The conductor, he's the one who sets the rhythm, he's the one who synchronizes people, who brings people back when they do something wrong, he has a role. With the conductor, we optimize something. So there's an impact, an interest. A government also has an impact, it's the one that gives the vision and sets the rhythm. That's what I was trying to say, and I said it badly, and I thank you for the question to be able to clarify my point. It's to say that, we still have music. We still have a country that works. It's not the end of the world, you see what I mean. Yes, I agree with you, there were surely things that went wrong, that could have been improved. And the role of governments was to make decisions, to allocate budgets to the right places, and they have that importance. But the example I'm trying to take is to say, well, if they're not there, of course we don't improve, of course we don't go, but it's not a catastrophe. Where if tomorrow there's no, there's no administration.
[00:52:48] that's really the catastrophe.
[00:52:51] One or two more questions? There's one in front. Oh, sorry.
[00:52:56] Well then I didn't see who.
[00:53:04] Hello, thank you very much for this presentation, it was very interesting. I have a question about the trust between architects and lead developers, regarding what happened, among other things, with COVID, in the sense that we have a lot more telecommuting, it's a lot less easy to create relationships of trust. And also sometimes there are people who have let go a bit, let's not lie, people who are much more difficult to get on board. How have you resolved this problem within VP? So, uh, we talked about it internally and, at least for me, it's my conviction that if we had done convergence during COVID, we wouldn't have succeeded.
[00:53:33] Uh, we, I believe in human relationships and human contact. I'm not saying that teleworking is a bad thing, I'm very happy to be at home teleworking. Uh, I believe in human relationships and human contact. I'm not saying that teleworking is a bad thing, I'm very happy to be at home teleworking. But at some point, this human contact, this proximity, also has an importance. When we did, when we started convergence, it was from a human point of view, very complicated. You have to imagine three teams, well, the Belgians and the Spanish, we were the invader for them. Uh, the fact of moving around, of going to see them, of eating with them, of discussing with them, of really showing who we are, the person we are, of showing them that we are there for the good of the company and not to invade them and recover things, that the choice we made, which a priori was, we are going to take the VP platform and not that of Privalia, it was a reasoned and objective choice. Uh, it had an importance. COVID was very hard. We had a lot of human damage, there were a lot of people who were recruited with whom there is not the same level of trust. And it's very hard, it's very, very hard. We have our morning coffee, we have presentations, we have Slack channels where we exchange jokes and we'll laugh, but in any case, my conviction is that it doesn't replace lunch. And it's very hard, it's very, very hard. We have our morning coffee, we have presentations, we have Slack channels where we exchange jokes and we'll laugh, but in any case, my conviction is that it doesn't replace lunch or going for a drink after work or going for a coffee, discussing it's different. A meeting is programmed, having a coffee is, it's, well, it's, I'm here, I have a headache or I see the other person who just left a meeting where they got angry, well, let's go for a coffee, let's talk.
[00:55:23] Human contact for me is really essential.
[00:55:26] And COVID, we were lucky to have done all this work a bit before. I don't know if that answers the question.
[00:55:34] Thank you.
[00:55:37] Thank you for this very interesting presentation. Uh, I just wanted to come back to the delegation and, uh, do you have any ways to, maybe, bring up the information afterwards? Because I imagine there are practices that are adopted at the team level that can benefit, perhaps. Do you have feedback on how to propagate without, without forcing, ultimately, you yourselves to make the decision?
[00:55:57] In fact, uh, that's super interesting.
[00:56:03] Uh, yes, uh, it's, it's part of the things I wanted to talk about, and I thank you for the question. It's that the fact of delegating and being in the team allows precisely to have a fluidity in the decision and to participate in the decision and not to control it after the fact. The second thing that is also useful is that we have a community of architects who discuss among ourselves. So, when we identify something that works well in a team, an approach, a technique, etc., we'll discuss it and we'll make sure that this practice, this thing, we'll disseminate it. So we're not going to say, now you're all going to do that, because we're going back to the first bias, which is to impose an approach, but we're going to communicate on this approach, on this methodology. So we have internally what we call the experts' corner, every week we have technical presentations where people come, we push them, we help them to present what they do and how they do it. After that, we also have internal tools that allow us to visualize who uses what technology and so on.
[00:57:00] So, we are also agents, promoters in the exchanges between the different lead developers. If someone does something in a team and I work with another team that has a similar problem, I will put them in touch. So we also have this role of knowledge sharing and dissemination of good practices.
[00:57:22] Well, I guess it's time to conclude and go have a coffee. Thank you again.

Transcript (Translated)