 I'm Tassos, we're gonna be talking today about technical decision making and ways of making this. So, just before I started, I wanted to ask, who has been a developer 10 years ago? Can you just keep your hands up? All right, so, a lot of the things that I'm gonna say are relevant to you guys. You would have seen the same journey as me. For newer people, you will understand a little bit how we got here, right? And what is important is to understand that once upon a time, life for a Drupal developer was much easier than it is now. And over the last few years, the average technical project has, and Drupal project has changed significantly, right? So, we always had sizeable builds in the Drupal world, comparing to other platforms, but we moved from that, from having sizeable builds into multimillion-dollar engagements, right? And those projects are usually, you know, coming with the decoupled front-ends. They have elaborate system architectures. They have a lot of third-party integrations. And also, as the complexity of the projects changed, the complexity of the infrastructure changed as well. And, you know, back in the day, a few servers were enough to host your solution. And we had very simple go-to-market mechanisms, you know, perhaps a sales script that was executing remote SSH commands. But now we have containerized public clouds. We have distributed file systems. We have high availability databases. And we have complex integrations and deployment pipelines to get our code its production. And actually, our ways of working have shifted also. So what used to be like a team of a couple of developers who were handed over a few Photoshop files, everything before, you know, the actual development started is now, you know, multidisciplinary teams, agile teams, you know, we do iterative component design systems. We have JavaScript front-end frameworks. We have third-party component libraries. And we are talking about omni-channel deployments and apps and websites. So essentially, we moved from this to this, right? So, and what's more important is that digital doesn't have an end date. You know, everything now is in product mode. And we talk about products, not projects. And what that means is that our work often is not governed by beginning and end-to-end, like a project, right? We are working on platforms, on services. We have fluid scope. We have flexible timelines. We have adjustable budgets. And what that means is that our work often does not end. It needs refinement. We need to refactor it. We need to adapt it, right? And that means that we are in a constant state of flux in a dynamic environment. And that, you know, as you all know, comes with a whole other set of challenges. And some of those are, how would you make the best technical decisions when you have a dynamic environment? And how would you know when you make a decision, whether that's good enough for now or for a given context and that you can move on and manage the scope of the project? How would you know that a specific decision is introducing some kind of technical debt and that you need to go back and address it at some point? And how do you document those decisions? Especially in a complex project, you would have many of those. How do you do it? And how would you make sure that everybody who's participating in the project and has something to contribute has a voice and that voice can be heard and can be factored in into the decision? And finally, how do you create consensus within your team? You know, technical people sometimes are very passionate about specific things and tools, but they may not be the relevant ones for a specific context. How would you get those people on board on decisions? So today, I will present a methodology we have defined, we developed at FFW for driving key technical decisions, and especially in the context of implementing digital experience platforms or digital products. So who am I? I'm WTVP of Digital Solutions Europe at FFW. I consider myself an expert on digital agile tech and data. I've been many years in the field. I have been architecting complex digital solutions for over 15 years now. I've worked in enterprises, in private sector, public sector, with the third sector, NGOs. I've worked with clients in EMEA in Europe, in North America and in Asia. And fun fact about me is that at some point in my life I did a PhD on AI. Back then it wasn't sexy, we were just like in windowless rooms with not very fast computers. But yeah, and here I am, I'm Tassos. So let's take a deep breath and let's get to the agenda today. I'm going to talk about, is a KTD, a key technical decision. I'm going to slice it up, see how we were making those in FFW and we help our clients and consult with them, making them. I'll show you what are the different workflows in the context of having a KTD. I'll show you a real example. We had to run a KTD for a project. And then I'll share with you some observations and lessons learned and finally we'll have some time to discuss it and ask questions. So first of all, what's a KTD, a key technical decision? So key technical decisions are decisions that have profound strategic and architectural implications for the organization, right? And that means that they either enable or inhibit strategic goals and that has to do with the evolution of an organization, not necessarily a platform, the growth of the organization and the value creation of that organization. And why do we talk about organizational level? And that's because right now technology is the medium where organizations see growth, evolution, and value creation. And with that central part of technology, we understand that the projects that are coming out and the work that is coming out and commission is more complex and requires technical decision-making processes. So one obvious observation is that the KTD is not a user story, right? So user stories are about technical implementation details, they're about functionality, right? They still may require discussion over the details, specific approach, but the main thing is that the approach has already been given at the point of a user story and that is the role of the KTD. That's the strategic that has the profound effect and then the user story is the implementation detail. And user stories obviously carry a lot of weight, they influence the project delivery, but not necessarily the strategy of the organization, right? Just to give a schematic view of this, there's a decision to be taken here, there's a decision here, there's decisions over there, decisions, decisions and decisions. And that's a lot of decisions basically. So you need a way to make those decisions. And most of the times in projects, we know that the distinction between an architectural decision, a strategic decision and an implementation detail decision are pretty clear. There are other times that those boundaries not be as clear as in other projects and the teams themselves would need to define what those boundaries are, what is a strategic decision and what is an implementation detail decision to keep the balance. So essentially a KTD is a document, right? You see on the left-hand side the whole conference document, right? I'll go through section by section just to let you know what it is. And then I'll show you a real one. We have it in Confluence because we would like to address business people as well and have them contribute. So let's start. First thing, first, is you have the header section. The header section contains control information about the KTD, you know, what's its status, what's its impact, any other related KTDs, any user stories that are related to the specific decisions that need to be taken. Who's the business owner of this challenge? Who's the driver of this KTD? Someone is responsible of actually filling in and coming up with the solutions. We'll see in a minute. Who approves this? Which means who's the decision maker? Who contributes to the KTD? And a lot of the times because we are talking about strategic decisions, there might be proof of concepts that need to be made in the context of a KTD for a specific approach to be ruled in or ruled out to find advantages and disadvantages. And those are being noted over there as KTD tasks. And those are tasks that need to be done before the KTD can finish. The KTD finishes by taking a decision. Then you have the background section. You have to define the challenge. Any background information that provides context to this particular challenge. Key requirements that are coming to the business and then you have clarification questions. You'll see later on how we run it, but essentially it's a two-step process. One is a conversation around defining what the right problem is and then there's a second conversation around the solutions and the recommendation from us to the client and a second discussion around this. So clarification questions are being captured here. This is to the person who would be driving this KTD. They may need to ask questions and source answers from the client sometimes. And this is being there, captured over there. The next is the solution section. So essentially what we are doing is creating solutions and approaches. So this is where you sort of like capture this. It can be three, it can be two, it can be more than three. Essentially you expand this as necessary and this comes into three sections really. You have your solution where you describe it in a sentence, then you have some pros and cons and then you call what we call the traffic light. So pro tip, use your business project APIs to create this section over there because that would give you a very easy way to relate the decisions back to the business owners and you'll see through the traffic light system, sometimes it's very visible which solution is the best for a given context. So what that does is relates it back to business needs and it's much easier to bring the technical solution and the business people together to understand why a specific decision is being made. And finally you have the discussion and decision section. Any follow up questions after that's on the second step when you are presenting the solutions, the ones that you have ruled out and the ones you are recommending to the client, then you may have the follow up questions from the client that you may need to answer. You're capturing the answers there. You list the assumptions, main assumptions for the given decision, the key points of it and then the record of the decision, right? So what you end up doing, sorry, what you end up having is a record of a specific decision which approaches have been considered. What is exactly the context and what is the challenge? You go from the way back up. So essentially as you accumulate records of those, you have all your key decisions on a project documented for further use. I'll show you a real example later on. So I want to quickly touch upon the workflows just before. So the process from a process perspective is not that difficult. It's quite simple, right? So it's been designed to actually be a lightweight process. The main question is whether there is a strategic or an architectural decision that's to be made, right? And if not, usually then there's only one solution. You just consider it. It's an implementation detail goes. You evaluate it, it goes into your backlog and then you move on. But if it is a strategic decision, usually there might be more than one approach is and it's not really clear which approach serves best the organization and the business needs that they have. So essentially that's how you then go into preparing all the solutions and all the approaches. Outlining the solutions in pros and cons and then having that evaluation step before making the decision. And I want to emphasize that evaluating the need, creating like the first bits of the KTD that challenge the context, the real requirements behind and the motivations behind a few things is essentially defining 99% of the solution, right? Like defining the right problem makes, is sort of like guiding you to the solution most of the times, right? The second bit that I would like to outline in this process is that when you're considering or you're forcing yourself to consider multiple solutions, essentially you really hone down on understanding the benefits of the solution and you do that in the context of the problem. And the problem is the burning issue for the client. The problem they have. So it certainly helps you consult in a higher level to the client in a more constructive way. And finally, it's important to assume the role of a technical partner and a partial technical partner, especially at this level or a consultative level. Because at this point and during the KTD you're talking about the technical capabilities, you're talking about business needs, not necessarily about the commercial aspects. Although the commercial aspects, certainly if it is a business need and it comes through the traffic like system usually because that's a KPI. Implementation costs or operational costs need to be low and it comes through as a KPI. So you can run it in both also how you can run it in agile springs and run it through waterfall. Agile springs is the most complex and the reason is you have an ongoing process and you need to somehow factor the fact that you don't really know some of the approaches before you actually start reaching, discussing the implementation details. So what we said is usually it's a two-step process. What we run it is a few days apart. So there's time for someone, for the driver, to organize their thoughts around the solutions and what's the pros and cons, understand the KPIs and how that works. So you see we have a few days apart per session, per KTD. And what essentially this schema shows is that a KTD may be informed by a spring planning meeting that you don't really know exactly how to approach a specific issue. And then it just informs a backlog refinement meeting or another spring planning meeting. And by informing means that makes clear what the requirements for specific user stories are and makes it clear whether those user stories need further discussion in the context of those meetings to understand the implementation details of those. In the context of a waterfall project, it's much easier. You just run technical discovery period with the KTDs and one after the other. You document it, you have this corpus of KTDs within your confluence space or any other medium you may choose to run this. And then you just inform the tech delivery around this really. So let me show you a real example, but it looks like. So I'll let you into a problem we run for a client. So around a third of the way into the delivery of the project, there were new requirements that came to light and they challenged completely what we had pitched as the hosting platform for the project. And that meant that we had to accommodate the new requirements, understand what we should have, what we should do as a hosting solution for the client. And, but we shouldn't put in jeopardy the stability of the platform as it was at that point, nor the stability of the project, meaning we would still need to hit the deadlines and the budget, which was the very tricky part. So what do you do when you have like a strategy, a profound strategic decision to make? You run a KTD, right? So I'll just go through, you see, our people driving this, contributing myself over there who's informed and the impact it had, it's pretty high. Essentially, that's how a background information looks like, some relevant information, use cases that we may have, edit diagrams, anything that would give context to the person driving this, right? And then the high level requirements, what are the boundaries of these solutions are coming over there? You see how we sort of like came up with the solutions? Essentially solution number one was out of the question, we knew that straight away. And through the traffic light system, you already see that like the third solution seems to have like more green, right? So that gives you like a good indication already what the recommendation might be to the client. In this particular, we had multiple rounds because then there were open questions that we had to go one by one source it because it was hosting and we were going for a cloud native serverless application, sorry, infrastructure instead of a platform as a service that we initially thought then we had to go through rounds of estimation for now, like implementation costs but also operational costs. We had to go uptime and support and proposal of infrastructure. You see like this KTD sort of like started incorporating other things that are really important for this particular problem, that's fine to do, right? And then finally, we summarized what the key points are and we made the decision. And through this process, we were able to actually honor both the timeline and the original budget requirements and we just changed part of the engines with flight and that then created new user stories that we had to adjust our deployment pipelines. That was work that we were not dissipating that we would have, but it's work that came out from this KTD that needs to happen for this extra, sorry, this extra step to happen. Just to show you what it looks like in Azure DevOps which is like a horrendous platform. So this is like a corpus of KTDs. What would you run KTDs on? Anything that has strategic effect, like the backend content model for an organization that wants to move its content forward and they may have ideas about reusing components is a profound strategic decision, right? So you can decide on those things running the KTD. In this particular situation, this is a decoupled Gatsby application. A lot of questions around Gatsby came into being. Obviously, choosing that technology and choosing which features of the technology have profound effects on the longevity of the platform and the maintainability and scalability of the platform. So again, to address all these issues and have several approaches, we run KTDs. What the KTD does really well is allow also a lot of people to come together and discuss several things, right? To contribute to what is a pro, what is an advantage, what is a disadvantage, you know, what is, which decision is better, sorry, which approach is better on a specific API. So through this system, we managed to also get consultants, external consultants from the technologies involved and everybody to actually come down to a common decision. I'm just showing you, essentially, what you see here is the same, like you see on the conference template. It just doesn't look as good, but it's exactly the same type of information and exactly the same type of decision-making happening, right? So moving on, I quickly want to touch upon some of the lessons learned. First, allow me to share some observations, right? So it's a, KTD process is a transformative way of consulting with a client. Help them, but also us as an agency, co-create the solution, define what needs to be delivered and create consensus, which is really important, you know, going forward, especially in complex projects. It's generally very well accepted from client side and from teams, but be aware if you want to implement it within your teams. The collaborative nature of the process, sometimes it's not easy for everyone to follow, right? And especially at the beginning. So there might need a little bit of hand-helding, helping like the team members being open and sharing and being open to expressing an opinion and someone else having another opinion and it's okay to have a conversation about it and it's not gonna be the end of the world if we choose, you know, Next.js over Gatsby because that is the context of this project, right? So as of lessons, right? So trust is a really important currency, right? It makes decision-making much, much easier. So if you lose trust with a client or amongst team members, the decision-making process is going to be way harder despite, you know, the best efforts of all methodologies used. Also teams that are defining things together. They deliver better. They understand, they take the extra step basically sometimes that's needed to make things easier. Once you make a decision, it's best to follow through that decision, implement it, you know, go through the user stories, get the implementation details, deliver those user stories and then evaluate, you know, what that decision was about. If you keep changing the decision as your, you know, it's like changing the parachute while you're flying, but changing parachutes. Basically at some point, you need to open the parachute and land, right? Be aware, sometimes you'll see, you know, decisions being dependent on other decisions and sometimes, you know, there's going to be situations where you would think that you can tackle a couple of decisions within a single KTD. Keep them single-minded, like one KTD per decision per thing. And that is, I think like a big lesson is don't cram the decisions. Sometimes getting the approach clear and getting like what the user stories implementing that approach are is a long way. So what that means is that for specific KTDs it may be straightforward, but the user stories are. For other KTDs, you might need to follow up with extra conversation at the technical details level and the implementation details level and allow those conversations to happen, even though you may have exhausting conversations at the KTD level, but they are working at different levels. So there might be that this is like such an important issue that you really need to hone down on the details to be able for someone to deliver this technically, right? So good KTDs don't guarantee good delivery. That's probably because of the previous point. You know, the delivery is dependent on the user story, the level of detail, how well defined they are, you know, how actionable they are and all of this invest kind of thing, right? So there's still a KTD doesn't relieve you of the responsibilities at the backlog level, right? What he does is it gives you like a very clear map of what your architectural situation is. So decisions also need to be scoped and you need to scope for context, you need to scope for timeframe and you need scope for budget. And that's really important not to forget that. And finally, that's, you know, the term analysis paralysis, right? Some people may use the KTD process to just overanalyze stuff and keep analyzing and analyzing. It's good to know when something is good enough, right? And I think that's the previous point, essentially scope what the KTD is for context, timeline and budget. There was a talk earlier today about the architectural decisions records. It's an interesting concept. I watched it and I've seen the work that Lollabot has done around this. To me, it seems like the ADRs are a documentation medium, right? The KTD is more of a discussion medium and coming up with the solution. And they, I mean, from what I've seen, they can work in tandem, right? There's another, ARK 42 is used in Germany, apparently. So some of our clients asked about this. We presented the KTD back to them. They liked it better, but. And, you know, we've been trying this actually with real clients, Haiko, Achilles, also, you know. So that's it. So thanks for listening. And I'll be more than happy to take questions or discuss this. By the way, my app has just stopped working on me. I can't connect to the server, so I don't know. Yeah, is it? Okay. But do you have, it needs me to log on again. Can you, yes, can you, I'm not sure. Can you just, all right, thanks. There's one question. So what are the profiles, architect-lead product owner that contribute on KTD? All right, so that's a good question. Essentially, it's, the way we have been running it is in a distributed way. We want, you know, front-end KTDs, for instance, you know, there's no, it doesn't make sense for someone who's not from a front-end background to run, right? There are DevOps oriented KTDs. There may be architectural oriented KTDs, you know, whether you're gonna be using a content syndication system or just straight on the API, right? So depending on the context, you have a different driver and that's precisely the reason this is a collaborative approach because you spread out the responsibility of who's coming up with the solutions and it's not those persons that are also taking the decisions, these are the people who have the knowledge and they are documenting the approaches, right? The decision then is taken as a group and approved by the approver and in that sense then also allows everybody not to fear or, you know, in a blame game situation, you know, not pointing fingers but essentially allows everybody to contribute their knowledge and their expertise and skills and then have this medium, the KTD to sort of like bring that all together and help them make the decision. So there's no other question on the QA. Is there anybody else who would like to ask something? Which kind of projects do you use it mostly? Eja, what would you say or what would you like? Yeah, yeah. Well, actually in fact, the, you may have like a hybrid kind of situation where you would run a technical discovery for a few weeks prior to starting a project and you have like the really big KTDs taking care back at that point, you know, just like what is going to be the front end framework, right? And then you have also other KTDs that may run parallel to the project delivery, right? I haven't had it as a lesson learned because I haven't decided myself whether it is a lesson or not but sometimes it might be beneficial for the project not to leave too many really, really strategic decisions to when the project actually starts being delivered, right? So, yeah, certainly, certainly. And that's the theory of it, right? But if you have like clients who want agile but they don't want any of the downfalls of agile which is the refactoring aspect of running a project then, you know, you're better off especially like the real strategic stuff, the ones that they have real architectural impact to make those decisions beforehand because you know where you are going, right? Yeah, yeah, that's the reality of it. It might be very different if you are in an internal project setting or a product. So if you are an internal team, not like us commissioned on a project, it might be different, right? But if you're working for someone, it's sometimes it's really hard to have the argument of, oh, yes, now we need to refactor this because, you know. So, yeah, that's the judgment call and it's not at the technical level, the judgment. It's more of a business level, right? So I think there's a mic over here so if someone wants to ask a question, can you just stand up so I... Can you grab the mic? Thanks. So, yeah, basically if KTD involves another decision to be made, do you open another KTD and create some kind of dependency between both or how does it work? So let me just go back to show you exactly how it works. That's quite fast, but... So you see this related KTDs and then related user stories. Essentially, you know, a KTD might spark other KTDs and those decisions need to be made prior for a decision that you started running the KTD, you just link them and that way you have a trail as to why specific, you know, which decision influence other decisions. Okay, so everything related needs to be resolved prior to continuing with the current KTD, right? If there is, if one influence is the other, yes. So to give you an actual example, you need to decide on, you know, your front end, if you have a decoupled solution, you need to decide on your front end framework before deciding how you're gonna implement your design system, right? So if it's a React-based framework, then you would know that in Figma or in Storybook, you can write your components in React, but unless you have decided that, like if your decision is to go with Angular, then, you know, that decision impacts the other decision. Nice. Thank you. No worries. Anyone else? No? Can someone check if it's on the live QA, no one? Okay, so if there aren't any other questions, thank you very much for being here. Thank you.