 These gentlemen are going to talk about a real-life case study of jumpstarting a digital business for a leading fast-food giant. So over to you, Manish and Joss. Welcome. Thank you. That was a very good introduction. Good evening, everybody. This is Joss. We're coming live from Mumbai. And as I just mentioned, we are from Capgemini. A brief introduction. So I've been in the IT industry for over 20 years and along the way I've executed multiple successful cloud migrations and cloud native projects. Over to Manish. Hello everyone. Very good morning. Good afternoon and good evening. Myself Manish Parvekar, I am director at Capgemini and currently performing a role of an enterprise architect with focus on developing point of views and innovative strategies to transform the businesses digitally. And along with that, I am also responsible for developing enterprise solutions, platforms, leveraging emerging technologies, which are primarily centered around industry. So today we are going to talk one of our such implementation for making digital business. We're going to talk about a recent client experience where we designed and built an elastic platform to be able to accommodate increasing volumes. And we use a lot of emerging technologies used cloud obviously to modernize and operate efficiently from an architecture scope. This includes microservices, automation containers and end to end APIs with DevOps. Before I get into that, I would like to talk about a few examples of how we can do digital business with successful outcomes. What does digital business really look like? A telecom wireless operator has built a platform for billing and promotions, and they were able to launch new subscriber services for Netflix just within days. Literally, Monday's idea from the business was a reality on Friday, delivered with real quick time to market. And as part of that promotion, they were able to gain 1 million new subscribers. Another example, a global beverage giant has very engaging touchscreen dispensers. These have been built over an API driven foundational platform. These APIs are actually used to connect to the suppliers and the vendors and they collect all the data and can even predict consumer behaviors. The last example, who doesn't love beer, right? A global restaurant chain. So they have enabled IoT sensors in their beer tab, and this keeps a track on the wastage so that reduces the shrinkage. And they're also able to procure the craft beer dynamically based on the regional demands. So the world has shifted to digital and legacy IT is not keeping up. Across every industry, we are now seeing new leaders who are able to make use of those digital technologies, and those are leaving the others behind. So despite the benefits, many companies struggle to shift to digital business models. Studies estimate that over 70% of IT budgets are spent on business as usual systems. These are the challenges through legacy systems, governance models that just can't keep up with the pace of innovation. The CIOs of large enterprises face a fundamental dilemma. They must both optimize as well as innovate. By optimize, I mean increasing the operational excellence, reducing costs and making existing systems faster. But on the transform side, they need to move the company to a digital business model. They need to enhance customer experiences, enable always on innovation and become more agile. Those of you who were in the session this morning earlier, we had Miles who spoke about being digital is more about making money and not just about reducing expenses. You can see the goals and the outcomes that are on screen are different when you're trying to optimize versus you're trying to innovate. So in our point of view, CIOs will still need to encourage these transformational bits. You need to invest in the relevant technologies and you also need to promote digital thought leadership within the organization. There is an urgency to transform, more so as we now see in the current situation, but this requires a holistic approach. You need to bring together the technology, the people and the processes. And I've heard multiple sessions across yesterday and today talking about the same thing. So what we're going to do explaining in our case study is how we could deliver a business value for one of our clients with speed and stability, but at the same time also offering them future proofing. Our case study is on a global restaurant chain. In order to transform to a digital business, you need to rethink your approach to the core apps of your business because you need to respond quickly to your customer needs. And you really need to deliver faster as soon as your idea is in your mind. Priority business modules were user profile, menu management, product management, order management, delivery services and loyalty services. So this was the business first approach. They had a key set of deliverables which had to be built out in a prioritized manner. The second objective was to build a platform that could support multi brand and multi region because this is a global chain that we're talking about and you would have different internationalization requirements and regulatory requirements across the globe. The third imperative, given that we are now in the experience economy, there was a high customer focus to build a differentiating customer experience that allows personalization. And eventually drive revenue through loyalty. So in order for them to actually have an engaging customer experience and a return of the customer, they wanted to have a very active loyalty program. And that was only going to be built if the customer found the overall experience across all devices engaging. The idea was also to build a platform with capabilities that would allow for future integrations with upcoming technologies. And there is a need to convert all of this data that you're going to be collecting into meaningful insights. Lastly, essential to boost platform capacity whenever a new geography or a new brand is added. And this made it a natural fit for having a cloud based and a cloud native architecture. What are the technology drivers to support these business capabilities? So the very first decision was to build out the solution as products families with several products. So we planned certain foundational services and on top of that we would build vertical functionalities. And each of these were delivered as agile with small independent pod teams. This was not entirely a green field implementation as it involved a few legacy systems of record as well. And those legacy systems were going to be exposed via APIs. So these APIs are able to unlock the unique functionalities that are residing in very old enterprise systems within the organization, mostly legacy on premise environments. So the implementation required us to make changes to the legacy systems as well. Each product was to be built with an API first approach and all accesses between each product was also meant to be via APIs. So we had to build microservices with a domain driven design. And each of these deployments were containerized and they could be hosted on multiple cloud vendors in case we ran into any regulatory compliance issues across geographies. A foundation element over here is what we call continuous everything. So you have DevOps, you have infrastructure as code and you have automated and repeatable testing. A closer look at the pillars of our solution. The most important aspect of the business is that the cost consumers would have a satisfying experience. So the UX was designed to bring to life those user stories. And the idea was to be engaging and build a differentiating online order experience. As I already mentioned, the architectural approach was microservices deployed in containers. There was an end to end tech DevOps cycle, which Manish is going to describe in detail. API based products and these products had both internal and external consumers. And finally, the reporting with all the data that was being collected and all the consumer personalization and loyalty programs that needed to be rolled out. We needed to build a separate operational and reporting data stored separate from the transactional database. Additionally, having a microservice based architecture, there was a traceability of each transaction and each event across distributed services, which needed to be a foundational capability. So for most folks who do microservices, you're well familiar with domain driven design. We started with plenty of workshops. So we had the prioritization of the domains and then those were broken up into sub domains as well as supporting capabilities. These were iterative and they involved many workshops to define what the external API was going to look like, as well as for us to agree on the internal bounded context for each service. As an example, the customer domain was broken up into sub domains, which were profile loyalty and preferences. And these were supported by the organizational capabilities such as your IDM and your contact center, which were existing functionalities that would either consume or provide data for your microservices. We took a conscious decision on whether to go for a database per service or whether there would be even in some cases shared data stores. And these would make use and actually we've made use of polyglot data stores to a mixture of relational and no SQL databases as required. As the slide is showing right now, we are there to some of the best practices for defining the boundaries for each services. And I'm going to now hand over to Manish to talk more about the DevSecos. So as companies look to transform their businesses digitally, they need to embrace agility and deliver value to the end customers faster. And in order to do that, the organization need to add a strong DevOps mechanism. As you can see on this slide, this has a key ingredients that go into creation or carving out of the successful enterprise DevOps strategy. Over the past few years, DevOps has rapidly evolved from an enabler of development efficiency to a driver of business agility for enterprises. And today, DevOps is a de facto standard for any digital transformation. And we are turning it as a digital foundation for improving time to market and also launching innovation initiatives in order to respond to dynamic and disruptive market scenarios. So let's see what are those key ingredients which can help to organize organization to adopt a strong DevOps mechanism. So first is about having a strong governance model which can be adopted across all the teams, including the internal stakeholders as well as the external stakeholders for fostering collaboration and focus on providing business value all the time. And the organization should have an ability to run agile teams at scale across the entire business and technology portfolio. The second ingredient is having a standardized process in form of multi-technology DevOps pipeline catering to unique needs of different stakeholders, domains and platforms. The third one is mimicking a development environment similar to production, including the production like data volume. And fourth is about automation of the creation of the environment. So these are some of the key ingredients that are needed for creating a strong DevOps model. Now, how do we really go about setting up this tech DevOps model? So we are proposing or we had followed a four-strip approach for carving a roadmap and implementation strategy for the client. Firstly, we assess the DevOps and agile maturity of the client organization. Then we identified the gaps and defined the roadmap with the maturity level that we wanted to achieve with a concrete implementation plan. And then we kind of try to prioritize the functional modules that need to be developed in terms of criticality of whether they are customer-facing or their internal functions. And we accordingly prioritize an onboarding map onto the DevOps framework. And last, not but the least, we assembled a DevOps pipeline to support multiple technologies such as microservice, UI integration using a reusable framework. And the overall effort for setting up this entire pipeline right from maturity assessment to around two weeks time. And it was followed by a quick pilot to ensure that the pipeline is operating successfully. So here is a quick simulation of the pipeline that we implemented for the client. This release management flow includes JIRA as a requirement management tool. Service now for release management and incident management. And Jenkins was leveraged as a backbone for orchestrating DevOps pipeline and beat bucket as a code repository. So typically whenever the user stories were created in JIRA, the teams used to pick up those tasks. And after development activities were implemented, as soon as the developer committed the code into the code repository, JIRA notification was triggered automatically and it invoked all the CI CD pipeline through Jenkins. And Jenkins was kind of building and packaging the entire code into a Dockerized version, which was getting deployed onto the running environment for execution. And this process was repeated for integration and moving through the stages through QAV, UAT performance and production. Now, there was some manual intervention in terms of approvals while the code was promoted from the development and integration stage to a stage environment or to the QA environment. And this was primarily to have a kind of an architect report review and post the necessary approvals in ServiceNow release management platform. The application was promoted or the package, the Dockerized version was promoted through the Ansible onto the subsequent environment. So as you can see, it is a combination of few manual steps followed by an entire suit of automation operations. So this process was replicated until the application was into production and there were followed by a lot of health tips to ensure that any alerts are refuted in time to make sure that the application incidents are resorted in a timely manner. So what are the benefits of having this approach? The first one is we gain a faster time to market. This can be demonstrated through the rapid environment creation at a single click-off button through which automated trips were triggered, which we term as infrastructure as code. And we were able to create environments using technologies like Ceraform in the background. Then the business concepts can be delivered and tested in hours with help of microservice implementation. So business wanted to prototype certain recommendations and offers based on the customer proximity to the restaurant. This particular feature was developed in couple of days time and made live the prototype which could have probably taken several weeks or reduced to a couple of days time line with the help of the microservice implementation and the reusable API. Secondly, we were able to see a significant reduction in cycle time by leveraging a containerized approach which allows the platform to be upgraded separately from application with almost zero downtime. It allowed to improve our delivery cycles and release the features to production faster compared to what we could do earlier. And last, we were able to improve the productivity with environment automation and focus was completely shifted from infra management to managing the off time of microservices. Also the pretext in terms of the validation in terms of the code quality checks or the test coverage or even running the regression test through the DevOps pipeline and continuation of application helps to expedite the overall timeline and release velocity. And also it helps in reducing the incidents when the application went live on to the production. So in summary, taking a modern approach to development across people, processes and technology, leveraging tech devops and embracing cloud native development including microservice containerization and integration are key to making digital business a reality. So with that, we are concluding our session, I would like to convey a big thanks to the open group for organizing this wonderful event and providing us an opportunity and platform to present our case study. And thank you both, gentlemen. Thank you, Manish. Thank you, Joe. Great, great case study and great to hear about about the approach and some clear benefits coming out of that for everyone to take away a few questions for you are coming in. One is something that all organizations are struggling with right now. The question is how do you advise your clients. Given the business pressures and constant changes from the market and the pressure to operate efficiently. How have you handled the balance between optimizing the business as usual and being able to get the focus needed on innovation to deliver faster and transform. Yeah, so some of the levers that we would talk about and which I also presented in the slide on the optimize and innovate approach. We would try to advise if there are common foundational elements that are applicable across both towers. So for example, when you talk about agile and divorce, I know everybody's been talking about this and doing this, but we have certain accelerators as well so though this project began became initially an innovation and a growth driver to increase revenue. Some of these foundational things we spoke about went back into even the legacy or the projects that were not part of the scope to say if you've got a release times that can be faster. What are the processes that we would follow and how do we release how do we get proactive monitoring, for example, on production. Can we reduce the number of production incidents. So all of that helps the optimized part of your current estate, but the principles that you have followed are born out of the innovation investment. If you've invested on enterprise monitoring if you've invested on enterprise DevOps security and all of those tools, it will help you in both parts. Right. Okay, thank you. Next question, how do you how do you identify and measure microservices that have a sub optimal agility. Yeah, that's that that's come from experience. I'll tell you, we've been doing these for this is a long project we've been doing it for a while. There have been cases where we have redesigned. As I mentioned on the bounded context, we have redesigned the API is once it's gone into a higher level environment. So what we thought initially on the design board is not the way it's gone into production. Because the time that we have measured for each response time or the set of data that needs to come back. There are multiple microservice design patterns out there that you realize when you're getting back a data from a legacy system and you're massaging it or you're taking in data from your supply chain or your ERP. It's not really reflecting the kind of data that you want to display to the end user, you need to do certain things on it. And if that involves too many hops. So for example, we shifted one of our services from an rdbms to a no sequel, just for that to ensure that we could plug in and make that service faster. So we have an elastic search as an elastic look up a key value based thing just to have a faster query on our massive reports. So those are changes that come in at a later stage you really will not always get it right at design time. Right. Thank you so talking of design the question come in domain driven design how does that help in the microservices world. Okay, so I think there are plenty of articles on this as well literature out there so the fundamental concept that we have for a microservice is to have a boundary on our scope. So, as I said, this is a typical question that we always says as a challenge how micro is a microservice. So what is the elements that you would have am I just going to do a simple current based operation, or would I even have some aggregation on top of that as part of the same service. And as a result, the domain driven design is that specific approach where you start breaking it down and you think you've got it right. One massive domain can be broken into five subdomains, each of them doing their own current operations. And then you realize that I actually need two elements from service be and three elements from service see, and that's going to be an aggregated response. So, some of the features that I spoke about as best practices right we start with domain driven design, and then it's you you ensure that you don't want too much chatting us between the services. And that's where we modify it to ensure that the consumers get the right amount of data in a minimal call rather than making three hops or three calls across the network. Okay, so in a similar, similar line and how do you identify subdomains and link them with capabilities. Okay, I think I would have covered that in general what I just spoke about, but yes, you're breaking them down. Yeah. And I really, I think what works over here is always workshops so we think we've got an idea the business architects on the client side have certain ideas. There are times where you you try and map what each service will do to each business capability, but in the end, the services have to be designed for the consuming applications as well. So if there are changes that are required, we will modify those and you need to be ready to modify them that really you go in with a fail fast approach, you make a change and you ensure you test it out and and that's where having that automation right having repeatable tests having repeatable performance tests that really is the foundational element that allows you to do this. Okay, thank you. And one last question. What considerations are given for static and runtime security and undersec DevOps. Yeah, so in terms of static security, we are so there are both open source platforms and there are some commercial platform like static security. We are using platforms like yes, or no, even where a code, they provide kind of no portable can and we are we have integrated this with our pipeline so whenever there is the application goes through a security scan, this is getting triggered automatically through Jenkins. And apart from that, we have no the tools like 45 or no IBM scan. So this particular platform can help you to do the, the, what it was, you know, dynamic security scanning right so both of these platforms, we have integrated in across our various implementations into the pipeline, and Jenkins allows you to run those through the plugins you can trigger those tests and then you can also integrate back the reports that get generated. Gentlemen, you're right up right on time and thank you very much for your insights and answering the questions so big virtual round of applause for Manish and Joe's thank you. Thank you.