 infrastructure, and IT management at Rabobank. I've had some insight into this, or some preview of this presentation, I'm looking forward to it. Twan is a broadly skilled IT manager known for a pragmatic approach and getting the job done. In his career, he's held positions as lead operations architect, project manager, product manager, department manager, and ITIL process manager. Twan is active as the chairman of Inter Experience Netherlands, and is a member of the Global Customer Advisory Council for HP Enterprises. And this morning, Twan will explain how IT for IT helps his organization navigate the DevOps journey. So a warm welcome please for Twan. Hi, just got my water out of the way. After last night, maybe I needed that we did some singing in the lobby with a few people. So, the clicker. I'm going to tell you the story about what we're doing at Rabobank. Why, well, when we started roughly, what we did, where we're going, and based on the business strategy. So how business strategy and IT strategy tried to align it. We see, as we have all very happy customers, everyone is very happy with banking at the moment, so in the Netherlands, it's the same thing. We see, we don't have any security attacks or that kind of stuff, so. In the end, we don't have problems. But still, actually, in the Netherlands, we created the title wave last week by announcing that 25% of our people have to go. We have to cut 25% of our cost. So, this is strongly related to how, from IT perspective, we are going to do that. First of all, and I will click on. First of all, I will introduce our bank. We have a global presence coming from our agriculture background. We are founded by farmers. We are actually still in the agricultural food business, and we try to be a player across the world in agricultural food and a retail player in the Netherlands for mortgages and loans. To get an idea of our IT, we have roughly in our business, we have 45,000 to 50,000 people in our IT, so roughly 10% of our staff. To get an idea of 3000 IT, we have IBM mainframes, we have HP nonstop, we have Windows, we have Linux, a bit of AIX, so we are highly virtualized to get an idea. So, you saw that Microsoft presentation and my presentation from a strategic point of view in trends isn't different. We see the customers are getting digital. They demand everything fast. Not now, but earlier than now. They want to be helped. They want to be, they don't even want to ask questions. They want to be helped before they know they have a problem. You see a lot of fintechs aiming at our customers which is a big issue for us as banks. We see it as a big competition. We have still a weak economy. The banks are under pressure by regulators. Costs lots of money to present all the right figures to be compliant in that space. And we see a lot of criminal attacks. Our strategy is to have customers in the first place. If we want, in the Netherlands, it's a nine plus customer experience would be related to an A minus customer experience. We are aiming high. It needs to be personalized and it needs to be omnichannel. We saw it yesterday in the presentations. Rapebank isn't different. We want to have our products seamlessly available across all platforms. And actually, we are quite ahead in that, I guess. While lowering cost, gaining in volume because the business letting go of 25,000 people has to be solved for part of the problem by more IT in the end. More straight through processes. I'm losing my, okay. And so IT has to step up there. Volumes are getting higher and also we get a target of losing people. I think it will not be 25%. It's been figured out at this moment. But we expect between 15 and 20% losing people, gaining volume and adding more IT to the business. While having more rapid change, not everywhere. We are not doing agile and DevOps across the line. We have what the gardeners and IBMs call bi-model IT of tour to speed IT and that kind of stuff. I will come back to it later. Actually, within RayWank, we call it 50 Shades of DevOps. So what's the key message? To have a customer experience that's A-minus, we need to be always available. So continuity is high. We need an improved time to market. So yes, we are going to do continuous releasing. Yes, development and delivery of processes needs to be highly automated. We have bringing automated testing and test analysis. And we need loosely coupled modular IT. What do we mean with that? Think about an API driven model where the API talks to another API. And that's the basic model of IT. What you do underneath that API isn't that important. But as long as the API is consistent and working. So a real service oriented architecture as we know it for years. While a culture has to be highly agile. The upper side of this model is our old IT value stream model. We use that RayWank. You see a demand coming in for a strategy moving through development into IT operations. Underneath, it's mapped to the IT for IT stuff. Which we are bringing in at this moment. We can overlap that straight away. In the end, it's the same model. Just written down, I think nicer today. It's a nicer model. And we can put our strategy across it. Also, at the left side, strategy to portfolio, you have to know what to build. Prioritize with business, business aligned. What does the business want to do? Actually, we are not so good at this. Then automate everything. And why aren't we so good at this? We had too much money in the end. We had never had any governance help in the Netherlands while our competition had. We always were in the black figures. And you see that changing now because there is a cost pressure today. Still making profit, but we suspect going into the future that we need to cut costs. And there is real pressure from the board on this issue. And that really helps to automate everything. We are moving fast in that direction. And I think it will help to put pressure on strategy to portfolio as well. Monitor everything run seamlessly based on a fundamental majority. Our upside is very mature, I might say, very, very mature. We are looking at the next thing of analytics to really prevent outages. Not by looking for events we already know because that's already automated at Rabelbank. Whole incident processes are automated. Detectives are correct in the end. It's automated at Rabelbank. We are beyond that. So the big focus now in this day and age at Rabelbank is in death. Automate death as much as possible. What needs to be done? Cross Rabelbank, a common understanding of loosely coupled IT. How does the model, what is the model, what does it look like, and everybody has to work with the same model? Move away from silos. And saying that always is difficult because moving away from one silo creates a new silo. We move away from infrastructure based silos, testing silos, monitoring silos into business value chain silos. But in the end, they are silos. New silos, more business driven. So that's good, but still silos. And you have to overarch those silos because there isn't, if you have a group responsible for all mobile banking, they have in the end to bring payments into that mobile banking side. And payments is a different part of the organization. We need an agile culture. Not everybody working agile, sorry, way. So waterfall is still good. If you have a mainframe, which is updated every year, and you've been doing that for 25 years, it's not really feasible or needed to go into an agile approach there. But the culture has to be agile. You have to be customer aware, lean and agile. Customer aware, you have to move fast. You can, the automations you develop are also good in a waterfall method. It will show value. It leaves us in a maturity model. And I know within the group there is a lot of debate to create one for IT for IT. I love to see one, but in between we did this because we couldn't wait. In the end, the aim is loosely coupled IT, DevOps, seamless automation, everything automated, everything agile, and preventive analysis. In the end, we want to have seamless IT, fully automated, across the board. To get there, you have a few streams who will help you there, with certain steps in between. I think you will get the slide, so I think I will not go into every detail here, but you can look it up. What we see as in-between steps that show value in itself, we actually look for steps that in itself already show value. So why a value stream-based approach? We want the ability to track cost, performance, business value, and risk as a base of investment and improvement decisions from requirement to retirement. IT isn't ops. IT isn't dev. IT is the support, in our case, of doing a payment on a mobile telephone. That's our business, to do a loan to help the advice of our local branches. That's our IT. That's what it needs to support. So we have to be able to track the cost of that kind of transactions, so that we can make a decision where the forever bank is good to stay in a certain country doing direct banking or something like that, that type of cost. Today, that's not possible. And I will challenge every bank that says they can, because we can't. And I think the competition in the Netherlands, we have great talks with them. They all can't have. Yes, they make a price per transaction, but it's this way. So you have to understand the value chain in IT. So everybody understands it. Architects, management. So we can make same decisions where to invest. Why? Because in the end, IT is not different from any other industry, only less mature than a few of us. So our approach is governance by principle. Our architecture is a principle-based architecture. I have slides with a lot of data on it. You will see it, but it's based on just principle-based architecture. Why? We trust our people, and we want to trust our people that they will do the right thing in the end. So less control, we are diminishing controls. Yes, we need to be compliant. So those are critical controls. But in the end, all in between steps we brought in with ITIL. And we are still an ITIL-based company that won't change. Incident is still an incident. Problem is still a problem. A change is still a change. But how you look at it and how you manage those processes, because it's not about counting incidents. In the end, it's about availability of a business server to a customer. And we have to understand that. And that's the value. And again, that's the value stream. So we want to trust our people to making the right choices. So we set some boundaries. We set some guidelines. And that's our principle-based architecture. You will see things there as reused before, by, before built, a single source, because you need one truth, simplicity. I heard it with Microsoft as well. It's roughly the same thing. In terminology, everybody can understand. And they are starting to live with them. So if you already have a solution for something, everybody knows that they have to explain something if they want something else. They really start to understand that. Here, agile way of working, the operational principles derived from the business principles as well. Avoid handoff, create everything from self-service, loosely couple, sizes challenge. So you need structure. Yes, there needs to be structure. Everything needs to be automated, that kind of principle so that everybody really can understand. And actually, that helps. So what have we implemented? The 50 Shades of DevOps? Again, the same model. That's what we have in place. It's been there. The upper side of this model has been there now, I think, 10 years. We're using it for 10 years. The only thing I added, I think, five years ago, were the orange arrows coming back. That's when we started to introduce Lean and Agile. And, yeah, that the loop back became more interesting. But in the end, everybody, there's great discussion and everybody who wants to debate that with me. I have a lot of debate that Agile and architecture, that's a big change. In my opinion, nothing changes, only the speed of things. You still need your PSAs, your architecture for your projects. You still need same things, but you create them in a different timeline. So maybe good for debate. Later on, whether Agile or Lean changes the way we do architecture. Again, the same, changing it to the IT for IT model. We actually implemented version 1.1. That at that time wasn't on the market, we would say. But still, it helps us. Why does it help us? We map, like Microsoft also suggested, we map our solutions against it. With one idea, the essence is one function, one tool at Rebel Bank. Do we actually implement one function, one tool? No, we do a stack-based approach. We have a big Java environment, a big Microsoft environment, Microsoft.NET environment is managed by Microsoft stuff, the Java, with the Java community stuff, SAP with the SAP stuff, Oracle with the Oracle stuff. HP with the HP. And the overarching part we do with HP. So required to deploy, again, the same tools, same basic approach. And it really helps you. You get an insight straight away, whether it's too much or too little or whatever. You get the slide, so if I'm too fast and the picture isn't taken yet, you can look it up in the slides. And then one part that I a bit miss in today's IT, for IT framework. Documentation, task execution, like batch and that kind of stuff. Where do you position it in today's architecture? That are things I think that can be debated out and still is ops. The reporting layer, test data management, config, you can argue that it, that you can place test data management, but you also can argue that it's not really finding a place. Config management, sort of, in the end I miss a fundamental layer of real fundamentals, models, objects, that kind of stuff. What are the results we find today? We are consolidating tools fast because we have insight in which tools we use. And actually we started off roughly around the mid-nineties with automating the incident process, automating service management processes as well. And for that we needed to consolidate our, at that time, aid service management solutions into the one we have today. The idea is to get one tool for every function in the end. The industry has to be standardized as well to do so because today you really need community-based approach. Microsoft still has trouble managing Java and Java environments, still has troubles managing. Microsoft platform, and in the end I really want one solution for every function. So for the people from the industry here, build those solutions. But in the end you also need one common data model. That's a question, again, to the open group. Come up with one common IT data model. Give it to me, I need to say, and then defector you create the market standard. One common service model, cross all industry, I love it, give it. So what we have also today is multidisciplinary scrum teams in Dev and Ops still experimenting whether we do it with leadership only across Dev Ops, all people in one Dev Ops team are still a Dev and an Ops team and all kinds of in-betweens there. Still separation of concern because it's needed in a bank, but changing fast because if you have automated Dev to Ops procedures, you have straight-through compliance as well. If there is no people involved, you don't have separation of concern, you don't need separation of concern. You just give the Ops guy the key. VP level management still Dev and Ops, but experimenting, as I said it, deliberately not everything agile. Why? I addressed it earlier because a mainframe is a total different thing than our portals or our mobiles. Automated fast, instant process, fully automated, event management, fully automated, delivery of a normal Linux or Microsoft server fully automated. Actually, automating middleware as well, like MQ, which is a hazard, but automating their deployment of software, automating. So it's really adopting fast. And yes, I hear what the Microsoft team was telling earlier that the people have to really feel the change. We started this journey I think 10 years ago and only to have the last two years really increase in speed in automating. People have to be under pressure to start automating. They see everything happening at the bank. They see their colleagues gone because today it's 25% of our people, but last year we also had, in IT, had to lose 20% of our people. So it's counting and counting and then there's pressure on the people and you see then everything gets fluid and we automate really fast because then the people get a motivation to automate. Value we got, a value-based approach gives me the opportunity to tell my leadership where to invest. I can now pinpoint, for instance, our DetectorCorrect site is very mature, so please go into Dev and invest there to automate more there because it's feasible and then you get a total maturity level of your IT organization pushed up. The real discussion now is we started to automate IT functions like DetectorCorrect, like delivery of a required to deploy, that kind of stuff, but now the question's come up. If I need a new mobile payment, I want to automate along those lines. So a new portal, a new, so business-wise, so we have the models in place, have to have the models in place there and automation, we actually really see our time to market, stepping up fast, less cost to deploy, actually also more change, so we are getting there with continuous delivery. The challenges, still the business finds it hard that IT demands time and money for itself to implement the change to automate because it's a cost that goes before the benefit. So you have to fight for your priorities. The common architecture is also today, it's still silo-based. Yes, we have service-oriented architecture, but it's not mature enough to really automate across those lines. Impact on operations is high, when work is automated, Microsoft also stated this and it really is, we need different people. In the end, yes, we are going to lose a few people, but in the end it's about changing the way we work and our suspicion is that we will have to lose roughly 20 to 30% of the people who can't move into a more solution-based approach, scripting, understanding the process of the way they work and starting to be able to help automate those processes and still trying to go into the systems and that kind of stuff. Those people won't keep up. Our culture today is not yet agile and not yet risk-aware enough, so if you give the responsible to the people, then you have to be sure that they know what they're doing and we have a leadership issue because we have now organized across business domains so who in the end is boss of IT? We have infrastructure, we have one boss, we have payments and loans and finance and organization, that kind of stuff in different domains, so who is going to determine where the bug for operations will go? That's a big challenge actually because in the end it will help you be efficient because in certain areas they will implement their own solutions and then because I'm an architect for all of it, for all IT management, across this platform, I will have a debate with those VPs who actually then have to report to me why they chose different solutions, but in the end they can because they have the money. What is, the current tool set is not sufficient, the sprawl of tools continuity, it's closely related to a remark I made earlier, if we don't have clear integrations between steps in the process, clear APIs, you will have vendors not integrating automatically and I think we all can recognize that, a Microsoft tool set doesn't automatically integrate with an HP tool set or an IBM tool set. I think if the industry will, it would be my position that if the industry will mature and wants to mature, this needs to change. So we have to have some common ground rules about service model within maybe really, and I think this is a good start to have this as a basis to move ahead on this. And so I hope the industry also will recognize that and will work with Open Group to develop this further. And it gives me time for questions. Before we do questions, if we can just say, are there any questions from the audience? I think there's some coming around here. So we're gonna do it, if I can invite you to have a seat, pick up much where you sit, and we'll sit, but we do have a few questions from the audience, and obviously we're gonna have more questions for the panel, but people won't get to ask you those questions, so yeah, Dave, sure, thank you. So while we get going on those, just one of the things that struck me about what you said, you said a lot about people having to, loosening controls on people, giving them certain boundaries and guidelines, but trusting them to do the right thing and make the right decisions. Give an example of the kind of area that happens and where it's worked and where it hasn't, or is it too early to say? No, it's not too early to say. We give, based on the agile approach, we give the teams to all freedom within their teams to choose which every method they want to choose amongst the team, every tool they want to use, as long as it's not related to Rabobank standards in the end. So we have a cross-team approach, for instance, your source control and that kind of stuff. That's where we demand to use certain solutions. So that's where we gave more freedom. Also, looking to give me more freedom in change control, for instance. It's a very rigorous process today at Rabobank costing a lot of time. So why not trust people that they really will do the testing? They really will understand the impact that the change will have on multiple environments. So that kind of areas. And are they responding well? It's kind of difficult because they always were used in a bank with high compliance here. They get freedom, the dev side already always took that freedom, but the upside is culture shock. Yeah, I bet, I bet. Okay, we've got some questions from the audience which open group CTO Dave Lounsbury will start asking. Over to you, Dave. Yeah, thank you, Steve. You mentioned your incidents were fully automated and how do you do it and what does that mean in practice for your IT and operational staff? How do we do this? It's a big, it's a long story. I can go about it, I think, for another two hours. In the end, it's event management really doing, knowing what's being put in your logs, as well as measuring the infrastructure, correlating it very, very well and very rigorously and creating incidents from that and automate workflows as well to assign incidents, to mitigate incidents and. Okay, great. So another question. You know, what do you mean by two speeds of IT? You know, how does that, how do you map that out? Or your 50 shades of Dev Ops? Yeah, it's everything between a fully agile, highly free, all degrees of freedom to a fully waterfall-based approach and everything in between with a real separation of concerns to total teams of Dev and Ops doing, for instance, and we try that with Dev having in the standby cycles, so they understand what hazard they put on Ops, that kind of stuff. And in the end, also, leaving nothing, leaving everything the way it is, only adding automation, for instance, in the mainframe area. Great, thank you. You know, there are a lot of existing standards for IT service management out there, a lot of frameworks. What areas have you found there to be gaps in those, and where do you see IT for IT filling some of those in? I think IT for IT gives the architectural framework where we always have been using ITIL as one of the first, actually, in Europe. We adopted that and you heard in my bio, I have big history in ITIL and I always found we were over-italized at Rebel Bank. Because actually, the real examples that I mentioned, it's not about counting incidents, and as I still say at Rebel Bank, it's not about counting incidents, it's about availability of business service. So, thank you. Steve, we got two more, how are we doing on time? We're okay for, yeah, we maybe can't, they're completely different. Take two more, Dave. Okay, great. So, you mentioned needing to avoid money in the business, and does that result, do you feel that it results in short-term decision-making or a trade-off between short-term and long-term? How do I explain the question? Well, I might have to invite the person who submitted it. Yeah? Eric? Yeah, I'll walk him around. Oh, great. In the past, can you hear me? Yeah. Okay. In the past, money in the business means local decisions and mess in the near future. See what I mean? No, no. If everybody is choosing, if the business is choosing what they expect the best for the business, it may mean that in the near future, you have to manage a messy situation. So, do you consider it can manage that? Yeah, yeah, that's true. In the end, you have a lot of debates always in the industry about IT being the business. In my opinion, IT still isn't a neighbor of business and still isn't business. We are doing payments and loans in the end. And if we can do it cheaper tomorrow by using paper, we will go back to paper and not IT. So, but the business really understands the value of IT in the business process of a bank and actually, they demand more IT at Rabelbank. All business processes are much as possible automated as well. So, the strategy of having automation in IT is not only in IT, it's also having automation in business. Okay, thank you. And that for a bank, for traditional old bank, that's also a cultural shock. So, just one last one, which I'll turn into a statement, you know, you called for the interoperability of the development of a common model for information sharing across all those phases and interoperability tools to do that. That's something where I think the open group would love to step up to that challenge, but we always like to have both the buyer and the supplier represented. So, if Rabelbank wants to get involved in leading that, please come and see us. Maybe show of hands, who wants that kind of model? Okay. So, there's a group as much as I expected. So, thank you. Thank you. But anyway, big round of applause for Twan. Thank you very much, Twan. Thank you.