 And then please welcome Ben Norte, thanks. Before we just had a discussion before, Rob and I have met four years ago for actually we met 20 years ago for systems management. So it has been an interesting journey, an interesting period, also with ABMMO actually. I wasn't working there, Rob wasn't working there, but we did that the same. The slide deck is such a journey, we're not there yet. And I think for IT and for IT for IT, we'll never be at the end of that journey. But the journey itself is very interesting. This is my Meet the Author slide, you can all read it afterwards. What I think is important that it's, I like white areas. I like areas where a lot of things are happening and that are interacting with all kinds of other parts. That means that you can do a lot, even within a bank. We have had our share of integrations and other things, so really a nice place to work. Doing both IT for IT and systems and service management, which are interesting related. And I'd like to have discussion with some people about ITIL, but let's not do that now. Maybe have some counter-opinion on that. My presentation is in three parts. One is, okay, what did we do in the beginning? How did we get to IT for IT? How did we start with it and what did we do to use and to implement that? Or to define our route forward? Second part, what did we do to, not to really define the capability, but to communicate? Because we noticed that communication, and it has been stressed this morning as well, that communication is one of the very important things about any change. And also the change to IT for IT. And I'll show you some of the things that we produced. And the last part is about, okay, what did we gain? How did IT for IT help us? And what would we like to see as additional parts in IT for IT? Now, let's keep ourselves operational and active. So, let's start with the first introduction, ABNM route. Obviously not as big a bank as the State Bank of India. Let's be very clear. I think about one-tenth of the size. But in the Netherlands it's one of the three major banks. And the three major banks together have about 95% of the market. About 8 million customers, 13 million accounts, both retail, private, and commercial, and a lot of other things. Primary focus, Netherlands. And we are active in more than 30 countries, but we do that very specific. As always with any bank, a wide range of products. A lot of omni-channel, multi-channels. But if you look at it now, I think 90%, 90% is internet and mobile. We ourselves are already, and we have been very challenged by the intake and the upcoming floor of internet. There's hardly any people anymore in the branches, which poses another problem, actually. So that's what we are. And we have grown over the last few years, primarily my mergers. Forced or not forced, that's another discussion. But these mergers have a large influence on our IT. We have 50 years of IT. Yesterday I heard someone mention we have an application that has been running for 47 years. I think we win there. We have one application that has been running for 48 years. But okay, it's about, and it's one of the most stable, of course. But it hasn't stopped then. It hasn't stopped 40 years ago. We have changed and changed, and we have had multiple applications, lots of middleware, and all the things and all the new hypes have always been part of our development. And it poses an interesting challenge for maintenance. But you all know that. So we have many standards, and we still have a lot of products, a lot of duplicate products, because people like their own thing. And especially in IT itself. So what we noticed is that the speed of change has deteriorated over time. It gets harder and harder to keep up with the requirements of the business. So we need to speed up development, delivery, and we need to do a lot more on alignment with business in IT. And actually what you see now is that, because business is also getting more and more IT savvy, that alignment is getting into another pace. We get some interesting discussions with business. And actually I like that, because they know, and they have feeling about what IT is and what IT could do. Alas, they also have an idea about how fast that should go without thinking about support, run time, stability, et cetera, et cetera. So that's the squeeze we're in. And I think multiple of you will be in there as well. To structure our thinking for IT for IT, we created a future state architecture, the FSA that is mentioned here. And we saw, and we still see, eight external trends that really drive what we want to do. One is the border between IT and business and business and IT is disappearing. There's a gray area now in the middle. What I said, the business knows more about IT, but the second point I mentioned at the beginning, our internet and mobile channels are 90% of the interactions with our customers, so we need to be far more integrated. What we also see is that cloud is coming up, as we mentioned before, and it's no news for anyone. And we personally think, or as an organization, we think that the end of the journey will be a lot of SaaS solutions. And you see more and more things coming up. Not at this moment in time, software as a service is not there for all aspects, but you see the market rapidly growing, very rapidly. And I think the cloud evolution is getting there. We have some issues with cloud. Of course, the problems that you have mentioned before, security, availability, et cetera, but you see the increase of possibilities and stability and quality of software as a service is increasing. So in the end, we will end there. The next point is that, look at Google's, look at the larger parts and know we are not Google. Winner takes all. We have to be at the forefront of the changes. Otherwise, if you are left behind, people will overtake you. There's a lot of change, and that's also what in the left-hand corner, the upcoming API economy, a lot of change, external third parties that will gladly take the profitable part of our business. And that's not the bookings and not getting money from A to B, but the real profitable part. The third parties we'd really like to get. And we need to be sure that we are progressing in this race and that we are part of that race to prevent us from being, in the end, only the payment processor. For, as a payment processor, you are far too expensive as a bank. Speed of change increases, we don't have to explain that. But what is an interesting thing is the rise of artificial intelligence. You see that not only as a research thing, but now you see that coming into AI for the operations side. You see a lot of artificial intelligence in the running of the business and also in the business itself. For instance, rating credits, et cetera, et cetera. A lot of AI comes into help there. So these are the drivers that we saw. And the other two, okay, let's skip these for now. And we have internal drivers and most of that is fighting complexity. We have that discussion and also within the State Bank of India. There's a lot of things that need to be, can be said about that. We're not going to deny that. We have to take care of that. And it's actually very hard to get rid of that. It's very hard to get rid of complexity. And it's on all levels. It's not only, this is the IT part, but also the business side. There's a lot of complexity also in the business products and that may be the required complexity. Okay, I can give a guest lecture on complexity, but I won't do that. Let's continue. So these are the drivers and the changes that come to us and that we have to address. And this is the first deliverable on that. We created a picture on, okay, what is coming towards us? Because awareness, awareness within IT as well, but also within the business about the changes and the impact of all the external changes is very important. So people know we have to address them. And you can make, I can't make these pictures, but people can and they're very nice. They show you one go, okay, this is what's happening. I like these things. But this is purely focusing on the run environment. But of course, we have the same in our development part. And that's where IT for IT as a whole addresses the whole range. And we also, you see that we need to change there as well. Now, I'll come to this later. What is very important is... Oh, wait a second. Sorry. I tried to do some things, but I shouldn't. We are really aiming for the automation of IT. And that is where both IT for IT, but also the generic thing like CICD, they are helping there. We have now the first development streets where you really have the automation up to the testing and get that running automatically. And that is very important because agile and CICD, they are important, but most of the importance and most of the benefit can be reaped if you automate all the repetitive actions. And we do that to the business. We have done that to the business a long time. Getting automation in to do the repetitive actions. Now it's IT itself which has to be done. Okay. Now the question becomes, okay, what did IT for IT help us with? Now, the first part is the capability model that is part of IT for IT. This is our definition of it. IT for IT itself is a reference architecture. So you have to align that with your own organization. And this is the model that we came up with with the capability model of IT for IT combined with some other capability models. Actually, we structured it in the same way that we have structured our business capability model. As a bank, we also have a business capability model within the center in core capabilities, things like bookings, et cetera, et cetera, and credits and whatever. But if you look at IT for IT, actually the structure is completely the same. We are a business. IT is a business. And that's where IT for IT reference architecture helps you to identify that and to help you support that in the discussions. So, yeah, and what you see also for IT for IT and IT organization itself, the supporting capabilities, the management and control, they're the same. They're the same kind of functions, the capabilities that you need there are the same. It's only the core capabilities, and here you directly see the value streams of IT for IT that are different. And we have partners at the left-hand side. There's a lot of outsourcing going on with ABNM row, within ABNM row. We have the API providers, the third parties, and we have a lot of customer interactions, but most of the customers actually are the employees or the direct channels outside to our end customers. In the end, the people that provide the money for us to run. But looking at the previous page, that is very hard to understand and to read for non-technical savvy persons. So what we did is we did a lot of, and what I also already said, we did a lot of communication. We put a lot of effort in our communication. I think Rob has shown this in his previous presentation just before lunch as well. The value chain as being a chain, looking at and describing the steps and the value stream of IT for IT and what's in it and what's there in the end comes up. And most people are very well known with the part that they provide, but it's very good to have them see that there's more to it than just the development or the run. The request to fulfill that has been a very neglected part within ABNM row, but we're picking it up now, and I think the IT for IT has helped there. And set the portfolio, that's an interesting part, but that's also where Agile comes in as a game changer, so we need to see how we combine that in a good way. Based on the previous and based on a lot of process discussions, we also came up with this picture, and this is far more complex than the previous one, that's clear, but the main reason for this picture is the BPM, the process management part of that whole IT for IT. We plot a lot of things, and the most important message from this picture is that there's a lot of feedback. There's a lot of feedback going on within IT for IT, and you see that at the bottom. Information coming back from the run side, the detector correct to the phases before that. The structuring that, of course, it's there now as well, but structuring that and being able to really identify, okay, what is that flow? How do we take care that if an issue is found in detector correct, that it is really fed back to requirement to deploy, even to the portfolio part, and that is a very important awareness that people tended to forget, and luckily we have here again a lot of communication, a lot of things about, okay, how do we do that? What is actually the feedback loop? What is the loop? What processes are there in those environments, in that value stream? And in the end, the end user at the top. And it's not about pictures, it's also about training. We provided training for the whole IT organization, not only the developers, not only the strategists, but for the whole organization, including the run, and there are two main messages that we wanted to give there. One is it's a chain, it's an end-to-end chain with its feedback loops, et cetera, et cetera. And to identify that detector correct or run is an integral part of the whole chain. I don't know in this audience, but I think in a lot of organizations that I know of, you create something in development and then throw it over to run and let them take care of it. It's very important also with your stories about feedback, shift left, et cetera, that you start stressing the run part or the detector correct part to be part of your whole IT for IT organization. It's also not only technique, it's also people and process. That has been stressed this morning as well. We need everything together. Data as the foundation layer. I think Mr. Rao will be very happy with that I set up. The tooling processes and the people. The data is one of the major parts that we have addressed from the beginning because it was not... It didn't have the quality that the rest of the things have. And what we started to do is stating, okay, we have a lot of data models. But actually, if you look at DMBoc, the data management body of knowledge, you have to identify multiple layers in that. So we started... Actually, we skipped the subject area model, but okay, that's very high. We started with the enterprise conceptual data model. And looking at our organization, which again took the reference architecture of IT for IT, and we saw there that the major data model that's there, the conceptual data model, looked very much like what we wanted to have. So we took some things out, of course. We are a bank. We don't take everything for granted. But it's very much in line. Then we have the logical data model. And that is something that is not in the IT for IT reference architecture and actually becomes organization-specific. And we base that on our demand. And we have a picture now, we have a data model, a logical data model of about 100 elements. And that's fully defined without coming back to that. And then in the end, you have the application models, et cetera. We are not going to go in that direction now. It is very interesting, actually. We are using, for instance, surface now, and you see that those application logic data models influence the rest. Okay, this is the conceptual data model. We explained, okay, what is it? How did we change it? Why did we change it? It has been accepted. People understand what's there. This is the ABNM row data model. And, obviously, it's not readable. But we have some explanations for that. So we have an explanation, okay, how do we get there? And the whole model has been described, including terminology, of course. I'm one of the people that stress semantics. That's a very important part. It's not about the syntax. It's more about the semantics. What does it mean? Because that really differs between organizations. You have to explain that over and over again. For, within the bank, and you may not want to believe it, but it's really true, we have 12 different definitions of a customer. Luckily, I didn't have to fix that here. But semantics, and okay, what did you really mean by a customer? What do you really mean by a test case? It's a very important thing. And we took some time, and a lot of time, to get that. And we are influenced not only by IT for IT, but also with other things, and also with some regulator requirements on the thing. Banking is a very regulated environment, so we have to take care of what our regulator thinks and wants to see, or needs to see. And the next picture that we made, and that's more for the IT people themselves, is looking at the capabilities. Or, yeah, it has to be changed, actually. Looking at the capabilities, and these are not the IT for IT capabilities. Looking at what's here, define, okay, which tooling are we using, and what actually are the interactions between the tooling. What you don't see on this picture, but is there, is a list of details about every interaction between, for instance, a service portfolio and a backlog management environment. And what you see also on this picture is that for a lot of capabilities, multiple tools are mentioned. And that is because we don't want to restrict the tooling. What we do is we stress the interactions. If people, as an example, in the Azure environment, VSTS is a very useful tool to use. And, okay, we grant it somewhat, but people are using that. What we say is, okay, you can use it as long as you keep all the interactions with your environment intact and automated. Actually, that puts a real, that makes the number of tools that are in use a lot lower because it's a lot of work to get everything done. Okay, conclusions. First part, we gained a lot from using the IT for IT reference architecture. There's a structure that helped us, there's a list of capabilities that really helped us linking to the business capability model. We use it a lot for heat mapping. We had a discussion yesterday on that. Planning, budgeting, using the IT for IT model, or at least our version of it, for those things as well. So not for the pure IT things, but also for the portfolio part. We used it, and I mentioned that already, we used that to stress the end-to-end chain and to make people aware that they are part of that whole chain and that when they deliver low-quality functionality to the next stage, that in the end, they will be bitten by it. At this moment in time, we use agile, but agile only in development. We are thinking about that. We have some groups already using DevOps, and you see that the awareness in the DevOps groups for that whole chain is far higher than in the more individual and smaller defined groups. Of course, because in the DevOps group, if your dev is low-quality, then your ops people, which are in the same group, or maybe it's the same person, will have to take care of all the issues. I think doing DevOps right will help us to get a better understanding for IT for IT, and also for the fact that it is an end-to-end thing. And, yeah, as last point, it's a very good basis for tailoring. It's a reference architecture. No single reference architecture can be complete, but looking at IT for IT, we noticed that it says 80%, but sometimes it's more, it's how you count. You can count in all kinds of directions. It's a very good basis, so you can just reuse it, and it helps you identify the spots that you may miss if you look at it yourself. And it's also integrating with business process, integrating with outsourcing for us. Yeah, we are trying to get that also done with our outsource parties. Just for, as a reminder, we have been using Tocav, Archimates, et cetera, already for a long time, so we're very happy with the open group. And we're not a member, but that's another discussion. Last part, of course, I really like IT for IT a lot. Thanks for that, all of us. But we see some gaps, and we are very willing to cooperate in there to do the next level in IT for IT, or to fix the wide spots. One is interoperability with third parties. There is a working group, has been started already, so I'm very happy with that. We are involved in it as well. We have a lot of outsourcing. And a formal interaction with the outsource parties will be very beneficial to us. Now, the formal communication is a lot of what they call Shriffle chair interaction. People retyping whatever has been done on the other side. Formalizing that and making it more automated really helps. Also to keep the speed in your hole and to end chain. Second point, dependency management. There is, as everyone in IT will know, dependencies between software, dependencies with outsource processes, et cetera, is a very important part. How do you manage that? Not how do you act on it, but how is there management? Can you dream up a good management structure to do that? And the last thing is knowledge management. It's not about using the known errors. There's known errors, et cetera, in IT for IT. But how do you get there? How do you get that information? How do you get from the data? Known errors are known errors. But how do you get from that error data to a real generic process to create that known error? And these are three things. Maybe there are more, but these are the three major things that I'd like to discuss with IT for IT. But Rob and I already had the discussion on most of those points. So let's try and use and cooperate to bring IT for IT to the next level. Yeah, thank you, Ben, for that. But it's nice how or is IT for IT integrated with enterprise architecture? Yes. I'm one of the enterprise architects, so yes. And we do have business architecture and data architecture, et cetera. So you see that for the IT part itself, it is very much integrated in there. But yeah, there are also all kinds of business applications and business architecture which sometimes even doesn't impact IT or has no relation with IT, and I've seen those cases. And also I thought it was an interesting approach that everybody in the IT organization is trained on this IT for IT value, or IT for IT and IT value chain. So was that a good experience that everybody now is aware in the IT function that how IT is organized and workflows through the entire organization? Yes. Is it a fundamental training that people should do internally like that? Yeah, and I think IT for IT was first the reason to do it, but actually you should have done it far before. People should be aware that the part that they're in, in that whole creation-run cycle is not the whole world. And people, if you don't stress it yearly or whatever, people tend to forget that their work is the center of the universe, which is okay, but as long as you know there's a black hole in the center of the universe, then you still have to know that. Okay, and the last question I got was who did you create an ABNMRO version of the IT for IT reference architecture? The difference is that. So how did you do that? Did you come up with that changes? Two faults. One is we went through the capabilities, and said, okay, we may need to combine those in another way than the reference architecture does. Most of it is a combination thing. And second, we do have what I said a lot of outsourcing, so that impacted, and so it's our given structures, and those given structures also impact the capability model. Okay, thank you very much, Ben. That was a good presentation, and it's good to learn from experience like that in the organization of using IT for IT. Thank you. Okay, welcome.