Next 20 minutes, I'm going to speak about platformless, a new concept and how platformless is affecting enterprise software engineering. I would like to start this story with greek myth that in the ancient days we used to think that Atlas is holding the world. So everybody thought about this before they realized the truth. Similarly, inside an enterprise, Atlas is the platform. Because any IT expenditure or any IT related work that we do as a developer, architect, project manager, CIO, all these activities are related to providing some kind of digital experience to our end users. We need a platform, and if you talk to most of the technical teams inside enterprises, they are building platforms. Platform is a necessity. But there's a problem. The problem is application development teams are focusing on building a platform rather than delivering applications. So I am in bunch of CTO clubs in the Bay Area, and whenever we get together, most of the CTOs and CIOs, even architects are discussing about the teams are mainly focusing on Kubernetes, how you can run a service mesh, how you can have resiliency on microservices, things like that. Related to, and unfortunately with that trend, these development teams are not focusing on application development. As a result, business is not benefiting what the technical team should deliver to the business. So that's where there should be a change happen in the industry. And we think it as a focus shift from platforms, CTO, application development. So how you can do that, to do that, the platform should be there, but it should disappear from the focus. So that's where this concept or analogy like dark matter and dark energy will come and play a role, because even dark matter is not visible, but it is supporting to have the universe, these galaxies and all the different components that we can find in the space. I'm not going to talk about this too much. We are going to tell more about this concept during a conference that we are running that's called WSO two con and it's posting on May 7, CTO 9th in Florida. So if you are interested to get to know more about how dark matter and platformless connected, please come to the conference and we will tell you this story. So, moving back to the platforms, let's dig in deep into what exactly that two layers I highlighted earlier on digital experiences and then platform looks like. So if you look at the platform, there are two main layers. One is a business platform and the second one we call it as an internal developer platform. So recently this term internal developer portal also came to the picture that some of the analyst firms are referring the internal developer platform as an internal developer portal. So there are bunch of different stakeholders inside the enterprise responsible for these different layers. If you look at the digital experiences layer, the product owners are responsible to deliver that. And if you look at the business platform that I have highlighted here, the chief architect and application architects are responsible to deliver that. And then the internal developer platform has become the main focus of this new role called platform engineering. And platform engineering teams are mainly focusing on delivering that internal developer platform. So the platform is consist with these two things, business platform and internal developer platform. So why the focus should shift from the building platforms into application development? It's basically the business advantage or the competitive advantages an enterprise can get coming from the digital experiences and the business platform that they are building, not from the internal developer platform. Because internal developer platform is a technical platform and those capabilities are common for any enterprise. So there won't be a big business advantage the organization will get by mainly focusing on that, kind of elaborate more on the internal developer platform. We can even divide it into two sections, an enterprise software engineering platform and an infrastructure level platform. Those two are connecting and creating this internal developer platform mainly. Today, most of the platform teams are mainly focusing on the delivery platform, not the enterprise software engineering platform. So that's an issue because the delivery should contain the enterprise software engineering capabilities as well. Otherwise application developers will be not that productive in the platform. And if the application developers are not productive on the platform, we might go back to these shadow it type of approaches and application developers will build applications outside the platform. So this internal developer platform is facilitating the enterprise software engineering. As I highlighted in this diagram, it is addressing the development time as well as it is addressing the runtime. And then to have more collaboration you need a marketplace. So that way you design APIs, services and then it will be available for discovery and consumption for the application developers. And application developers can use these concepts like domain driven design to group these workloads and at the runtime the same concept should appear as well. So I introduced a concept called Cell based architecture. So that's where the runtime is contained with the cells, that cell A, cell B as I have highlighted, and the components inside the cell connected with a mesh. And then you can secure this environment by bringing various security principles, authorization, authentication, entitlement, so on and so forth. And that way you can build a zero trust environment and there should be a synergy in between the development time and runtime. If you are interested about the Sylvester architecture you can read more. So if you Google from my name and Sylves architecture, you will get the paper and you can go through that in detail. So then going back to this platformless concept, it contains four fundamental things. API first, cloud native middleware, developer experience and then obviously the platform engineering. So the API first approach is basically in everywhere in the organization. You should be able to expose APIs, secure them, and then you should have internal access as well as external access to these APIs. And it has to be facilitated by the platform that the technical team shouldn't be worried too much about creating these APIs. The platform should enable the developers to create APIs and then publish it in the marketplace and let the consumers to consume the APIs. And it can happen at various levels, data APIs, domain APIs and then at the edge you will get the experience of edge APIs as well. Then cloud native middleware is really important. Middleware is a bit of outdated term, but still middleware is important, but it has to mainly model into cloud native architecture. So I wrote an article some time back by describing middleware as disappearing into code and infrastructure. It's already happening. But having this middleware either in the code or infrastructure is pretty important. That's where the platform should provide these middleware capabilities. As example, the security components that we discussed and various other runtimes like service measures, message brokers and way to secure the APIs through API gateways. All these type of supportive things that you need to build an application should come in the cloud native middle and then the developers are the craftments of digital experiences. So developer experience is really important. So having a rich developer experience in the platform is key. So it has CTO be self service and pipeline tune. That means like when developer starts doing this application development, it should automatically connect to the organization approved pipeline and then they should be able to collaborate these different type of workloads and consume them. And sharing should be there and high agility should be there for the developers. And developers should be able to use their favorite tools and connect to the platform. As an example, if developers are preferred to use vs code as an IDE, they should be able to use that and if they are willing to use command prompt to do CLI to do a lot of development, the platform should support a CLI and platform itself should have some set of system APIs that the developers can use it to extend some of these capabilities. Then the platform engineering is the foundation and the result should be platformless. So it should provide all these capabilities and provide that application development environment for the developers at the development time and then CI CD during the development phase two production and then how you can monitor and manage this development runtime and have a proper application lifecycle. So you create, you run and you manage and you deprecate these runtimes based on the application needs. And you should be able to find the dependencies and all the related observability as well as debugging capabilities as well. So platform engineering is not only about DevOps, it's about site reliability engineering as well as the platform engineering should have a fair understanding about the application development because they have to provide this rich developer experience by understanding the developer needs. So that's where a platform team will really important consist with platform engineers as well as people who got some knowledge about application development. So to have another analogy about platformless, earlier days when it comes to an enterprise, to have emails like we used to set up these email servers and then we used to set up chat servers, all these work related systems we used to run. But today any enterprise that will leverage capabilities provided by Google Workspace or Microsoft 365 or similar solutions instead of running these servers. So it's basically not about focusing on running these servers, mainly focusing on the consumption and the experience that you get. So basically it's about the collaboration, not about how you run this workload. So similarly, on the platform less environment, just focus on the application development and you will just add developers to the platform for them to focusing on business problems and deliver applications for the enterprise. So how you can achieve it, there can be two parts. First part is you build it. So that's where you have CTO, have a dedicated platform engineering team, treat the platform as a product and look at the technology advancements happening and keep an eye on the future technology changes, understand the developer needs and build that. You can start it from scratch, or you can use a framework and build your platform on top of that. So main thing is it has to be a dedicated team and it has to treat as a product and you have to keep on maintaining it. Just building it and handovering it to the application developers will not work. The platform engineering team should mainly focus on that and build it. WSO it's bigger investment because it takes time, specific skill set as well as you have to maintain this, as I explained earlier, and then as a technology provider, we are helping people who's building that. That's where we provide API management integration and identity and access management products. If somebody is building a platform, they can use all this cloud native middleware runtimes and build the platform. So the other part is you buy off the shelf internal developer platform when you're choosing an internal developer platform, you have to take a look at whether it's providing a platformless experience and the four key features that I explained. API efforts, cloud native, middleware, developer experience and platform engineering should deliver from this platform. There are many choices in the market, so you can go through them and then see whether it is meeting your requirements as well as whether it's addressing platformless capabilities. So as a technology provider, we have a solution built that we call it as choreo. Choreo stands for choreography and how you can choreograph different type of workloads at the development time, at the runtime, and not only that at the people level or the development teams level, how you can collaborate with each other. So if you are interested then you can go to wsru.com slash courier and take a look how this internal developer platform looks like and whether it is fit into your requirements. It's a SaaS experience WSo you can just sign up and try it out. So in summary, the digital experiences are the key when it comes to an enterprise. So you have to focus on delivering these digital experiences. That's where you can create a differentiator in the market and then the digital experiences should be modern and it has to leverage cloud native concepts because we are in a cloud native era. So how you can use those different type of cloud native skills and how you can use this platform is very important. So platform less is the concept that you can mainly focus on the application development and then have less focus on the technical platforms that you are building. And I think with the requirements coming from the business, expectations coming from the end users or the consumers, it's really important to look at this concept and it's time to go platformless. So we wrote a paper about this concept. It's called the platformless manifesto and it is available under this URL and it is released using creative comments by phototo. So feel free to send a PR with some improvements or any suggestions that you think. It's currently under zero eight version and we are in the process of bringing it to 10 with your feedback as well. So read the paper and if you have any suggestions, please send this information. So that's about it. And if you like to have productive conversations and a detailed conversation about these concepts, these are my contact details. I blog in my personal blog blog architectoarchitect.com and you can read all my readings from much rank URL I have provided and you can email me on my email address and you can connect with me in LinkedIn as well as x platform. These are my contact details, and if you have any question, you can post it in the channel. And I am happy to answer those questions as well. So till we meet in another conference, thank you very much. Hope this is useful for.