 So let's deeply into the topic. I just have five minutes, so I'll just be rushing it. So breaking the mold, unveiling the anti-actical patterns as platformer of product. So I know many of you have been running platforms here. There are some anti-actical patterns that we need to recognize them. The first thing to get started, you see the bridge, right? So whenever you land in Paris, I thought, what would I just start with? So this is one of the marvelous bridge. It's a Milau viaduct bridge. It's the longest bridge in France. That's for its structural height and deck. So this is one of the longest bridges and it's for its architectural supremacy. So let's see what we are covering today. So we'll understand what is the anti-actical pattern, what are the patterns, an example, and some common anti-actical patterns in a product, what are the negative impacts of it, what are the best practices to avoid them, some successful case studies that we generally And there are tools and resources to implement in your architectural patterns and conclusions and key takeaways. So let's understand what is an anti-actical pattern. So any pattern that are detrimental practices that hinder your system performance, scalability, and that are leading to inefficience and complexities, those are called anti-architectural patterns in your platform. So how does your platform needs to be designed? It should be like a design that is crucial, that acts as a foundation, that between stakeholders, that it may be users, apps, teams, or business, that should give an outcome of value, growth, and innovation. So that's how a crucial platform should play a role. What are anti-architectural patterns? We understand what is an anti-architectural. For example, a monolithic architecture. So if you're implementing a platform, you don't want to deploy something bringing monolithic architectures into your platform. So that will lead to a lack of cohesion, but also this is like brittle design that is more susceptible to widespread failures when the changes are introduced into the system. So let's see what are some common anti-architectural patterns that we know of. So over-centralization. Concentrating too much control or functionality within a single component, that can lead to single point of failures. Tight coupling. When you want too much of control, you do have much independent resources that can lead to an anti-architectural pattern. Inadequate scalability planning. When you don't estimate the growth of the platform, that is one of the pattern that you need to move away from, vendor lock-in. Insufficient security measures. When you're building the platform, you need to make sure what are all the security things that we need to bake to into. Lack of monitoring and observability. Lack of monitoring and logging. And this also leads to the siloed observabilities. So when you're building a platform, you should not be across multiple observability and logging tools, rather than concentrate on one centralized tool and having features into that tool and giving that customer needs. Inconsistent documentation. So that's what we heard in the previous panel talk also. So we need to document the APIs, the configuration, the things that we are building out of the platform. So if the documentation is not proper, inflexible data management, inefficient resource utilization. So whether it may be overutilized or underutilized, you should be able to know what kind of resources are utilized in the platform. Complex configuration management. Limited interoperability. When you have too much tight controls or tight coupling, this is one of the leading effects of limited interoperability. Depends on the differences between the systems. There's less flexibility that happens. Poor governance and complaints. And ineffective change management. And last but not the least, ignoring user experience. This is one of the best. We should not be ignoring the user experience on the front end when we are building the platforms, right? So there are a lot of talks on developer platforms that we are building on the front end. But we should have a feedback loop developed into a platform to understand how we are on the front end, how the users are experiencing it. And we need to work on those. But there are three main things out of those which we have shown that we need to definitely tap into legacy system dependencies and the tight coupling. As I said, there are two different corners of it. Loose coupling and a tight coupling. So when the loose coupling, that gives a lot of chaos inside the platform. But when there's on the other side, tight coupling will give you more control. But again, when there is a system, there are dependencies a lot that tight control will also affect the system. So there should be a balance between those. When you're building those platforms, the scalability bottlenecks, as I said, there are, like, in the scalability bottlenecks, you need to plan for the platform growth ahead of time. So at American, what we do is every quarter, we do a big room planning. We understand what are the platforms, because each platform is a product. And the product owner comes with the estimation growth of each platform and what are the practices that needs to be included as part of backlog for that quarter. So centralized control pitfalls. Then there's too much of centralization. What happens? There's a single point of failure. So you should avoid those kind of point of failure so that there's much flexibility inside it. When you don't care about these anti-axial patterns, what happens? There's an A2 impact on the patterns, on the platforms itself as a product when you're developing it. So you can see a small picture that is in the back, and you can see the bridge that's not built properly. So that's what happens. So it's a reduced maintainability, impaired scalability, and elevated technical depth. These are the main things that has a negative impact on the product. What we are doing to avoid these? Either the best practices, best practices need to be identified to avoid these patterns. So through code reviews, I don't know how many of you practice architectural patterns through code. So we need to incorporate architectural designs and principles also through code so that when there's a drift in the deviation, or then there's a drift in the architectural patterns, we should be able to observe them, and we should be able to detect them, and we should be able to give it to the platform teams that yes, there's a deviation in what we have thought and what we have built out. Idea to design principles. So how many of you know about well-architected framework principles? So if not, just tap into well-architected framework principles. There are four pillars. Every platform that it's building on should be adhering to those four principles of well-architected framework. Continuous refactoring. So we should promote a culture of continuous refactoring, eliminate existing, eliminating these anti-architectural patterns. So there are three successful case studies which I can think of. But again, there are other than these cloud platforms, which we think AWS, GCP, and Azure. So when I think about robust architectural design and which enable seamless scalability and innovation, I think about Google Cloud. And there's a clean and modular architecture, supported rapid feature development and adaptability. Then that is like Azure and well-structured architecture, sustainable growth, and easier maintenance. So that is AWS. So it's like the three different platforms which we can think of. So there's always tools, that, and resources which we can adopt to. We should always think, we should always adopt microservices architecture. And the continuation technologies we should tap into, rather than the monolithic architectures, and the continuous CI CD. We heard in the previous panel too, right? So we should be using Argo CD or Flux whenever we have to. We have to incorporate those kind of tools. So the key takeaways are the early detection in your platforms, proactive refactoring, and always continuous education about the principles and everything that you need to refactor into your principles and patterns, so that these ways you can avoid the patterns that we have seen. That's it. Thank you. I think, yeah, this is a lightning talk, so I don't know what's the question and answer, but yeah, thank you. Thanks a lot. Thanks a lot for the opportunity.