 of beautiful sessions. I can see that, you know, I have gathered a lot of information over the last two days and it has been an information overload. So, what I am going to try to do now is keep it light. I have designed the slides in such a way that I keep it light. So, my session subject today is bringing order to innovation. So, what is innovation? Tesla Tesla was a young scientist who traveled after his education in Serbia. He traveled to New York to work a career in science and he is known to have invented the alternating current and he has done some amazing work in magnetism and he has also done some initial designs in the radar technology that we use today. He was a geek and a genius and a lot of respect for him and he was an amazing scientist basically. From a salva Edison on the other hand was a businessman. If you look him up on Wikipedia it says an inventor and a businessman. He is known to have invented the incandescent bulb and he has got a lot of patents in his name. The reality is he did not invent the incandescent bulb on multiple levels really. So, he was the owner of a company called Thomas A. Edison Inc. and he had about 75 to 85 scientists working for him who used to do all his inventions and he used to patent them. Now that sounds a little bad saying that somebody else is doing the inventions and he is keeping the patents, but you cannot really take the credit away from him because he put a process around innovation. The innovations or the inventions that were happening were happening on a deadline. He had a fixed number of inventions that he expected from all the scientists that were working for him. They used to work 20 hours in a day, sleeping only 4 hours in a day, working really hard at inventing new things. While Nikola Tesla had about 271 patents in his name, I do not know the exact number, Thomas A. Edison had over 1000 patents in his name. Now, if you do a little bit of research, you find that Thomas A. Edison looks like a villain because he used to electrocute animals showing that alternating current is not a good thing. It is a dangerous thing and DC or direct current is a better option. Nikola Tesla was a genius. He actually changed how we electrocute the entire world. The way we electrocute our buildings today is alternating current, but he was just an inventor. There is another thing that Thomas A. Edison was really good at. He did not just invent things. He used to make them marketable, practical and viable in the market. That is really the subject of my session today. My name is Nelot Paldas. He will call me Neil. I am trying to build a career in the small space between these three circles, engineering excellence, process excellence and business IT alignment. Someday, I wish to push this space big enough so that these three circles converge into one. I work with Novartis as a lead solution architect. The mission of Novartis is to care and to cure. We want to discover, develop, and I am going to read it out. We want to discover, develop and successfully market innovative products and to prevent cure diseases, ease suffering and enhance the quality of life. That is our mission. There are disadvantages and advantages of having your slot allotted on the second day so late in the conference. The one disadvantage is that your thunder is stolen. You have had so many amazing speeches, almost everything that I wanted to say has already been said. The advantage though is that I could never have said the context so well as all the previous speeches have. All I wanted to say has been so beautifully elaborated by effort. It is reduced. The agenda today is the New World Order. I will try to describe what the New World Order is very quickly. We will look at agility, enterprise architecture and its relationship with innovation. Then I will talk a little bit about how we bring order to innovation. We used to depend on the bolt from the blue or any new genius ideas for innovation but that is not going to fly anymore. We need innovation on a deadline like Thomas Edison started it. Then we will conclude with an open discussion. I am not going to talk about anything that I know and you do not know. I am here because I know that there is a lot that you know and I do not know. My conclusion is going to be about a discussion. I want a good healthy discussion happening here so that I can learn out of this whole exercise. Do you remember your first phone? How many people remember your first phone? Raise your hands please. What can you go one by one there? Motorola. What about you? Nokia. Who else? You. How about you? Fingers. Which one? See you stole my thunder. This was the first phone that all of us used for more than 15-20 years at least. I remember I was 5 years old when I saw this phone for the first time. I had gone to my father's office and he had this phone there a few days later. A few months later we had a phone like this in our house and things did not change much for the next 15-20 years or so. We used to pick up the receiver and call somebody up and talk and that is what it was. The dial must have been replaced by a few but it was more or less the same. It was not until I reached college I believe that the first cell phone came around. In the old days if I had to take down somebody's number I would put the receiver under my shoulder like this and write it down in the address book. But then the first cell phone came around with the basic features of address book and what have you. Today we are here. This is my phone now. The Nokia Lumia 920 not to advertise it too much but any phone that you look at these days is extremely advanced and we do not really just call people with this. In fact calling people is the minimum thing that we do. I mean we rarely do it. There is so many other things that we do with this phone and it is not just the phone. There are so many other smart devices that we see these days. There is the tablets, there is the phones, there is the desktops and laptops and all that and all this enables us to do so many things. There is social and I am not going to talk about all that. Social, mobility, analytics and cloud. We have been talking about it all the last two days about it and we are completely, constantly connected and we have come a really, really long way all the way from the black dial phone to the beautiful ecosystem that we have created where we have access to information. I remember when I was studying in my early days, I used to buy these books of computer engineering, Oracle Architecture, Win32 Programming, DC++, MSC and so on. These books used to be very expensive and I was on a budget so I could only buy one book. I used to go to this bookstore and all morning, all the way till the afternoon, I used to keep reading various options of books that I had so that I could finalize one book that I am going to buy. This ecosystem today has given us the opportunity to access information on our phones, on our tablets, whenever we want, whenever we want and it's a new world. So it looks like we have come a really, really long way, haven't we? Yeah? Think about it. We haven't. Ten years back, we had 5 million internet connected devices. Today, we have 8 billion internet connected devices and this is the statistics that I picked up from a book called Digital Enterprises. It's a beautiful book. You guys should read it if you haven't already. And by 2020, we will have 50 billion devices which are internet connected because of the internet of things and then it's going to drastically rise to a trillion by 2025. So it looks like we barely scratched the surface. We only have mobile devices and gadgets right now. Very soon, our refrigerators, like somebody said, is going to start talking to our door knobs so that they can open the door as the droid brings the milk packets that the refrigerators has automatically ordered and so on. It's a new world order. And what you see in the picture is Christopher Scholl's typewriter. It was invented in 1870s, early 1870s. But this was not the first typewriter ever. This typewriter was invented in 1870s and we were not really focusing on business, innovation, and what have you. But that's my whole point. The times are changing and we have to adapt accordingly. Let's talk a little bit about organic growth and complexity. Now I wanted to bring, if this would have been an relevant slide, I would have been doing the session early yesterday morning, but this has been talked about a lot. So quickly, a couple of years back, a couple of my friends started a small business. The business was they were building a product for a niche market and they were already doing their jobs and they wanted to do something on the side and probably if it works out then they would leave the job and go full time into the business. Now it was just four or five people working on a product for a niche market segment. Do you think they had an enterprise architecture in the organization? How many people think there's an enterprise architecture in the organization at that time? How many people think there is no enterprise architecture in the organization? Nobody's raising their hands. Come on. You can't be neutral. You've got to take a stand. All right. There was no formal enterprise architecture in their organization, but the enterprise architecture did exist. In the heads of the owners, they knew what their applications are. They knew what their business is, what their market segment is, who their customers are. They knew what information they're working with. They knew what technologies they're going to work with. They knew their roadmap. They knew what they have today. They knew what they're going with, where they're going. But it was simple. It was so simple that they didn't even have to write things down on a piece of paper. They could all remember everything. But then slowly it started growing. The business started growing. They had bigger market segments. So they had to break it down. They hired people. They hired head of marketing for Chennai and Mumbai and then they started taking tactical decisions how to run their business. And soon these tactical decisions started becoming inefficient because redundancies were created. Because they were taking tactical decisions without considering or consulting each other, which causes inefficiencies and interoperability challenges. Because since the systems that they're using in silos are not designed to talk to each other, very soon they would start realizing that okay, we need to do something. Then to just make the systems talk to each other, they would have to spend a lot of money. And that is what is happening these days in the industry. You're spending a lot of money just so that systems can talk to each other. We do not have strategic insight about the various systems that we have. So are you ready? The business landscape is changing every day. Opportunities come up every passing day. I've worked for a financial services organization just a couple of years back and I'm now working for a pharma company. And I've seen so many opportunities that come up every other day. I went through a merger that in my previous organization, which I encountered myself. And we've recently done something here at Novartis. And you know, the competition leaves the market. New geographies open up all the time. Sorry. All the time. There are opportunities for cost savings. Like India opened up about 1991, if I'm not wrong, under PV Nerfimaro when globalization happened. New geographies opened up. New opportunities for cost savings based on foreign exchange differences. So when these things happen, when you want to start a new line of business because you've recently acquired a company that has a new business capability or maybe you want to start a new product or a business or a line of service, these are new opportunities that come up. Suppose the competition leaves the market. It's a green field for the rest of the competitors. Who's going to go and capture the market? Is your IT ready to support you to take these opportunities? It's very important. Now there is a lot of people who say that enterprise architecture is architecture of the enterprise and it's not about IT. But I say that information in the enterprises these days are managing, are being managed using IT. IT plays a very, very critical role in the enterprise these days. And somebody just said that we are now on the strategy table. And it is high time that we are. If we are not, very soon organizations are going to start to realize that if they do not take IT into consideration, they are going to die. They don't have an option. They are spending so much money on just keeping their IT systems alive because they do not have a strategic inside, which all this money could have been used much better in doing this, in capturing markets, in increasing turnover. The truth will set you free. The more you know about the enterprise, the quicker you can investigate the impact of change. Whenever there is a business landscape change. Whenever there is a new opportunity that comes up that you would like to leverage. Whenever you would like to look at cost savings or going into a new business or going into a new country or a geography, you would have to look at the impact that it causes. Impact on your business, impact on your systems, on your applications. When you want to integrate two companies when there is a merger, you would have to study the impact of that change. The more you know about yourself, the better you can study the impact. The more you understand the impact, the quicker you can respond. Each cycle of investigation takes you closer to your final goal of near perfect adaptability. And that, so there was this social scientist, social psychologist named Frederick Hussberg, who created a two-factor theory, hygiene factor and delighter. This was all about employee engagement and satisfaction. I'll quickly talk about it. He came up with two factors. One is the hygiene factor that used to talk about an employee would leave the organization if you do not have these things for him. A decent salary, a healthy working environment, an air conditioner for that matter. Without these things, you won't really work for an organization anymore. But these things do not motivate you to do an excellent job at your work. So hygiene factors are necessary, but they do not motivate or inspire you. On the other hand, there are delighters. Without the delighters, you would continue to work in the organization that you're working. But if you have the delighters, you feel like doing a good job. So I usually use this theory everywhere. So enterprise architecture is absolutely necessary for survival of every organization. And that is a hygiene factor without enterprise architecture. Without some form of architecture, in fact, IT architecture I'm talking about. The organization will not be able to face the competition that is coming out these days. Then the delighter is that enterprise architecture harnesses innovation. That is hercules. We all love heroes, don't we? We like listening to stories where heroes go and, you know, kill 700 hydras and what have you. But can we afford a hero? We like to listen to stories and imagine that Nicola Tesla invented the AC current, for example, or Thomas Edison invented the incandescent bug, or Bill Gates created the huge behemoth called Microsoft single-handedly. But truth is not as interesting. Actually, truth is quite boring. Nicola Tesla studied the AC current in his college days. He did not invent it. Does that mean that he did not contribute to a short hit? It was his designs that changed the entire way we look at AC current. I always thought that Thomas A. Edison was a geek, a thin guy, I don't know, I mean, in a dark laboratory, you know, and there's a small bulb that is lighting up in front of him. That was the image that I had about Thomas Edison. But that's not the right image. Thomas Edison was a businessman wearing a three-piece suit. He was not the geek that we think he is. And Bill Gates did not single-handedly create Microsoft. There was a lot more to it. So the point that I'm trying to prove here is that you can't depend on one person or group of people, group of people, I would agree, but one person for innovation. You don't want Hercules working for your organization. What if you leave? You're left with nothing. What you really need is a process around innovation. Whether somebody stays or goes, innovation should continue. There are innovations and there's ideation. And we've heard some people talk about the difference between innovation and ideation. And so I'll cover that a little bit for you. There's ideation here. So ideation is coming up with ideas, but that itself is not innovation. Like Thomas A. Edison put a process around ideation. Innovation requires the process. Secondly, innovation requires the ideas to become practical, marketable and viable. So there are a lot of ways that you can do ideation in your organization. Okay, there was this manager that I used to work with some time back, a long time back really. And sorry about that. He had come up with the formula to inculcate innovation in everyday life. This is the formula of appraisals that he used to do, performance appraisals. So this is D multiplied by E plus I plus X. D stands for delivery. So if delivery is zero, everything else is zero. Nothing, I mean, everything else doesn't have any value at all. If delivery is two, then the value of everything else doubles. So he used to give prime importance to delivery. Then I, sorry, E stands for engineering excellence. He keeps engineering excellence before innovation on purpose. Last year's innovation, if you execute last year's innovation this year, it's engineering excellence. So you get brownie points for that. So that innovations don't die out. You innovate something this year, you forget about it next year, doesn't make sense. So last year's innovation is this year's engineering excellence. And this year's engineering excellence is next year's delivery. So you have to deliver that next year. And then I stands for innovation. There are two types of innovation that you used to call it, although I don't think that is innovation. I think that is ideation. But still, there are two types of innovation in his view. There's business or customer focus innovation and then there's technology innovation. This is from Microsoft. I have to work at Microsoft back then. And they put a lot of value to technology innovation. And then X was a manager's prerogative. So if your behavior and everything is very nice, he would give you extra brownie points. So one system of ideation. Another is there's a lot of ideation frameworks that are available in the market these days. So we had an ideation framework in my previous organization we had come up with. It's basically a system of putting a group of people into a room and giving them a business problem and then discussing the various ideas that they can come up with. They would have three or four tables so that the group is not really big and it doesn't create a commotion. And then you rate these ideas and the lower ideas are filtered out. And then you start bringing the groups together with a smaller set of ideas and compare them with each other and finally come up with two or three ideas. So that's another way of coming up with new ideas. The third one is crowdsourcing. We have this here in our organization of artists as well. There's something called an idea farm. And we farm ideas from all the employees and then two or three ideas that are give away iPads or what have you every year. So these ideas, the two or three ideas are selected and then they are executed and they are basically tested on various levels. And then finally there are ideation workshops. So we used to do quarterly ideation workshops in my previous organization where we didn't specifically have any business problem that we are trying to solve. And that is the difference between ideation frameworks and ideation workshops. Right. In ideation frameworks, you have a business problem that you're trying to solve using generating ideas. In ideation workshops, what you used to do is we didn't specifically have any business problem. We would go and sit down in a room and start talking about the pain points that the senior management is facing at the moment. And then first come up with a pain point that we would like to solve. We would like to take care of. And then based on that, we would do the ideation framework. So and if you do this on a regular basis, there's putting a little bit of process around ideation. Right. The next thing that I'm going to do is we'll look at the Togav ADM as an innovation framework. I do this again and again. Sorry. So I'm going to present a case study. Not a real case study though. Maybe not so unreal either because you see this in so many organizations these days. This is an application communication diagram, which is so very common across so many enterprises that I've seen in my life. These are various applications talking to each other. And what this creates is vendor dependency. So these are course applications and commercially of the shelter applications. And the problem is if you would like to eliminate or replace one application with some new application, it's a nightmare because now you'll have to study so many interfaces, so many other applications that are talking to that. You don't even know what are the other applications that are talking to this if they're not properly documented. And usually these things happen organically. Right. You have a couple of applications and then these applications are willing to increase the number of features that they have. So suppose you have a portfolio management application and it says it starts doing something which is not portfolio management related. Because just because it wants to increase its footprint to the organization. And then slowly what happens is you're doing way too many things with just one application and it happens organically across various teams. So you don't have a very clear idea about what each application is doing and what are the other applications that it is talking to, which basically creates a vendor dependency. Because now you can't get rid of that vendor because you don't know what's the impact. So in one of the ideation workshops let's say they come up with this pain problem, pain point for the senior management. That we have vendor dependency or we have application dependency and we don't have a very clear idea about what's the impact of stuff. Right. So vision. Everybody knows this diagram. It's what is it? What is this diagram? Can somebody tell me? Pardon me? No, not the right one. I'm not that one. This one. Pardon me? Yes, hub and spoke. You can call that but there's more. Look at it closely. Can you read what's written? And yeah, so what is it? Data no, it's not data warehousing. This is service oriented architecture. You've got a service layer in middle, which is the data transport layer. It's not, doesn't have to be a service layer. It could be an orchestration engine for you. So for all you know. So it's basically simplifying the entire diagram that you saw here into this. You have a data transport layer based on universal standards and all the applications talk to that layer and now if you want to eliminate one application and replace it with another, all you have to do is take care of one interface. Now this is one of the business problems that came up. Is this an innovation? It's not really because this is just an idea. We haven't really studied this idea whether it's practical, whether it's viable, whether it's marketable, we don't know. Right? So the first thing that you would have to look at is the business impact of this idea. Right? So do the business goals and drivers change because the organization has annual business goals? Are they going to change if we implement this idea? What is the impact that it's going to have on the business processes? What's the impact that it's going to have the people? The people who are accessing the applications today, are they going to change some? Is this going to change something there? Right? The people who are going to implement this idea, is their life going to change at all? And the most important thing, what is the business value that this idea adds? What is the return of investment? Because this idea you can't execute it free of cost. Right? It's going to take some investment, some money, some time, some resources. So what is the return of investment on this idea? And then applications. So it's still not innovation. You still have to look at what are the changes in the application interfaces that are going to happen. Okay? What are the new applications that we are going to introduce? Are we going to use the same applications? Now that we are changing things, why not take a look at if we can replace some old applications with the new ones. Right? What are the, what is the impact on the information flow? Upstream systems, downstream systems, how is the information going to change in format? Or what have you? Are we going to upgrade those? This is still not an innovation because we still haven't looked at the technology. There are going to be technology changes. Upgrades. We've been using old technology for so many years, simply because we don't know what's the impact it's going to have if we upgrade it. We are so afraid. And life, these days I see, I was having a conversation with a very good friend of mine here in Bangalore. I have met him after many years. He's a good friend, a childhood friend. And we were talking about this. We are led with fear, led by fear so often these days. Every part of our life is led by fear. It's the same thing in the organization. We are afraid to touch our applications and our technology simply because we don't know what the impact is. And enterprise architecture relieves you from that fear because you have information about your system. So are there going to be any upgrades? Are we going to decommission something? And then we won't be, this is a big change by the way. It's not a small change. Even if you don't do the whole enterprise, because there will be let's say two and, I don't know, two thousand applications depending upon the size of the organization. This is just a very small picture. But changing two thousand applications and converting the whole thing into service oriented architecture is a big thing. Let's say even if you don't do the whole thing. Let's say you take a very small subsystem of let's say 15 applications or 10 applications for that matter. It's still a really big change. It could be a five year plan for all you know. So you can't do everything right away. You'll have to plan it. You'll have to prioritize it. You'll have to see what are the various applications that are dependent on each other and based on that you'll prioritize. You'll have to align with the PMO. That is important because you are not going to execute the project and they are not sitting there twiddling their thumbs all day long thinking about what's the enterprise architecture team going to give me next. They have their line of business plans. They have worked with the CDA management in coming up with what they are going to do and the business and this all brings us back to the reporting structure. How is the reporting structure? Now there are many various organizations in this world and there are different types of reporting structures that you have. The project management team sometimes reported to the business directly. Not always do the report into the CIO. Sometimes they have dotted line reporting into the CIO. Sometimes they have direct reporting into the CIO. So based on depending upon what kind of alignment you have you'll have to start prioritizing your service oriented architecture project with them. They don't report into you. They've got other things to do in life. Again I did it. And then there is the ivory tower problem. So people say that enterprise architects are sitting there in the ivory tower. They don't know what's happening in this world. They don't know how we execute our project. We hear this all the time. The project teams always say this. There is a big disconnect between the enterprise architects and the project teams. Governance is what brings us down, brings the enterprise architects down from their ivory tower. When they govern the application, when they come and see how enterprise architecture is being executed. They will realize what are the problems that the project teams are facing on a day to day basis. They will realize that whether the plans that they are giving, the architecture they are building are the relevant to the enterprise, to the project teams or not. It is this governance that makes enterprise architecture relevant. And then change. The business landscape is not, the world has not stood still after you started designing your application. If there are any changes you'll have to take a look at it. Back to innovation. What is innovation? Innovation is not coming up with ideas. Innovation is looking at idea, coming up with ideas and looking at it from the business standpoint, from the application standpoint, from the technology standpoint. Innovation is coming up with ideas and making them marketable, practical and viable. With that I'll open it up for discussion. Let's talk. Yeah, go for it. Sorry. Mike here can be behind you, behind you. There is a quote there. I don't know who has quoted it. They say research is a person who sees what others have seen. But it thinks what others have not thought. Thank you very much. Excellent quote. Anybody else? Yeah. How do you welcome like, when you see that there is a very interesting question. So governance, right? Reviews. Now in many organizations what happens is the reviews happen only once. Once the project has done the project charter. When they submit their project charter, the architecture team reviews it and sees whether everything is in order or not, whether it's meeting the future state road map or not, whether the technology blueprint is being adhered to or not and so on. They'll review it and then they'll say okay, approved and then they forget about it. Now the project teams go and start executing these and that's when they start realizing the pain points of what's the, I mean, with the technology blueprint or whatever has been the principles and the guidelines. So they start taking deviations but the architecture team doesn't know and when the project comes back, there's a big variance. The only way that this can happen is when a primary architect is assigned to every single project. Now there are various types of projects in an organization. There are development projects, there are operations projects or what have you. But wherever required, I mean I would say that enterprise architecture is the art and assigns. So I leave this to the good judgment of the architects but every project that requires regular reviews, they should be assigned a primary architect and that primary architect should run with the project throughout the entire life cycle of the project all the way it will close up. When that happens, enterprise architecture stays relevant because then at regular milestones whether it's quarterly or half yearly, the enterprise architects is down with the project manager and talks about the project. It will be at a high level obviously and then I think there should be technical architects and you know, I don't know how, what they call it, there are various designations, tactical architects or what have you who will work with their day-to-day tactical problems. But milestone reviews are the only way that an enterprise, I mean, a good way, there are other ways as well that an enterprise architecture team can stay relevant. Does that answer your question? Sure, sure, please. There is something called as the technical design authority. Yes. As part of the enterprise architecture, you have a technical design authority and you have technical design architects in part of the team. So how it drives is a chief architect and a chief enterprise architect. We have a team of technical design authorities who will be designated for all these projects. So once suppose it is a maintenance project and the CR comes in, this person will try to see what is the business requirement, then the system impact, the functional impact, application impact, then the operational impact, okay, then there is a risk, what is called a raid, RAID, risk and what is the dependency, what is the impact and then these aspects will be covered as part of the TDA documentation. So once this go, it will be going to the next person who is the specialist. He will be coming back to the TDA to come up with, okay, this is the design I am going to do. There is an impact on this particular database and then that is approved, the TDA says, okay, this is approved. Then it goes to the developer but TDA is still working with the developers. You see that, okay, till this goes through production, it is the responsibility of the TDA for the, that it aligns with the business requirement as well as to the conformal story enterprise architecture. There are a couple of, there are a couple of comments I want to add. In our organization, like we have a delivery architect's role, probably if we have a multi-million projects, whatever the model that you propose, probably will work. But one other reason when we execute a project which is in a continuous improvement or legacy mode or find some new technology, probably these delivery architects whose on ground along with the developers who has a collaboration with the EA would certainly help and that helps us in terms of two hazards to the standards. Yeah, it does help to solve the tactical problems but then how will you align it with the enterprise architecture and the solution architecture at the high level. So that is where it is important that the enterprise architect remains aligned. So at Novartis, at one more point, similar to what he said, technical design authority, we have something called architecture handbook. So it is called a handbook because you hold it in your hand, it is not really a book, it is a word document, really large word document but that document is filled out not up front in the project. As we go along and cross each and every milestone as new information is revealed that document needs to be filled out as a part of one of the regulatory norms. So the enterprise architect, the solution architect and the project team stay aligned using that architecture handbook as a tool. Any other questions or just a comment? Discussions, ideas, yeah? Just a comment or? For example, there may be some innovation like open source ring framers. They have not written any monetary value but since they have, there are innovations. Why we have to see innovation only from business and monetary aspect? Because everything that we do in our organization is around business. Now the point is sometimes you give back to the society like I am here speaking, it is well this is a give and take to be honest. I am learning as much as I can, I am very selfish when it comes to this. But the point is that it is when I speak there is something that I will give back to the community and there is a lot that the community will give back to me and this is a give and take. So once in a while doing something, even if you do do something such as this which does not have a direct business impact in the long term it does and I will tell you why. It is very simple. At this point in time like Steve gave his presentation about branding, it is very important that we brand ourselves because organizations do not think that you can impact them. And I think that it is a social cause almost that the enterprises know the impact that enterprise architecture can do. So if you contribute to the community as a whole without the direct business impact that you have it still has a long term business impact. So to be very honest I think it is all about the business. Whether it is short term or long term that is a different story. I think my comment was around the same thing. Just wanted to share one more equation similar to D. Multiplied by E plus I plus X? Yeah. So this is from a colleague of mine like invention plus application equal to innovation. Right. Yes. Thank you very much.