Why don't you introduce yourself? Yeah, sure. My name is Tai Lange. I work in the credit bank IT team. I am responsible for software architecture, cloud and middleware, database and storage and the DevOps teams. You've got a big stable of things. How do you structure that organization? Before my current role, I was the director of the software infrastructure and architecture. And there we started working with cloud and also the software part, the new architecture, software architecture. So I believe that today with the DevOps and that kind of methodologies, infrastructure, middleware and also the software part come together. There are too many common goals and objects to work on. After I worked in this position more than three years, but after that, the infrastructure part also came under my responsibility so that the team, we have now a bigger team and also we work more closely and we are going to the same direction. It is not a common organization, I can say, because in the enterprises, generally, the software part and the infrastructure part are separated. But in order to work more efficiently, we structured like this and we are working in this organization around one and a half year now. It is so far so good, I can say. I agree with you completely that most large organizations and particularly banks, most large organizations, there's no particularly, but definitely banks that I talk with, they all of those functions are, am I exaggerating, are very separate. Some of them are like a little less separate, but definitely infrastructure and applications and development tend to be very separate. The question they often have is a little bit that you're alluding to is we know we shouldn't be operating this way, but like we can't figure out changing. And since you're saying like, you know, you recently moved over to consolidating all this, what was that like? How did you kick that off and get across any barriers that, how did you pull that off?
2:00It's a rare feat. It's a good question because when there's something happen, there are some changes. Everyone, especially the teams, when you assign to a team, there's a fear, I can say. And also some reflections to change. Maybe it is not so easy, I can say. We are, by the way, we are doing it not for just my underlying responsibility. We are also changing the organization for the delivery teams as well. We are switching to product teams. We say it's product teams. Right. Under these product teams, before this organization, the analyst teams, business analyst teams, and the software development teams were separate. And also there was a central testing team, for example. But now, today, we are switching to product teams, which all of these functionalities are consolidated in one team. And there is a product manager at the head of that team. This is the delivery side. And the other side, the infrastructure part is this. In this kind of an organization, the most challenging part is, especially, you have to give new responsibilities and also new abilities to people. And basically, when they are in their comfort zone, it is not so easy for everyone. Of course, we are a young company. There are too many volunteers for new technologies, responsibilities, etc. But there is also some people who don't want to change. So, that kind of cases we had, I can say. But how do we figure out it? First of all, as a leader, we always said that we are always together with them. We will educate it. We will give time to them. And we will give what they need. And they will be part of this change. So, there is nothing to fear. It will be all good. And now, we are doing it. For these, for example, we set up different education programs, internal education programs, external education programs. And we are making lots of sessions, especially with the COVID. We can make sessions very easily with huge audience. So far, so good.
4:00But it is not so easy, I can say. One of the things you touched on that I think is, that I've been interested in sorting out recently is, one way of putting it is, you gave people psychological safety. Like, they felt safe and changing and going through learning things. And so, I'm curious, like, how do you, how do you make people trust you? That you actually, we're going to provide you this training and we will support you in doing this. Like, how do you win that trust over? Or, maybe I shouldn't be so cynical. How do you maintain that trust to make people feel comfortable that you actually will be supporting them and you mean what you're saying? Correct. Good question. I think we are lucky at this, at that point. Because in Waikibi, people trust each other, I can say. There's a good culture here. So, I am lucky at that point. So, when I came to this organization, first, I also adopted this. In my previous organizations, I am always very transparent to my team. I, we always talk everything. And not only for the business, but also for their personal life. I don't separate the personal life and the business life. So, in order to give trust, you have to be transparent. I think it's so important. And also, you have to do what you say. If you say something, but you don't do it, it will crush trust. I can say, we always do what we say. So, after you work with people and they observe this, it is the rest of the thing. This is the result, I can say. So, I am here in this organization almost in five years. So, people know me. It is not the first time I, something I promised. It is my part. But the most important part is, as an organization, people trust each other. Commonly, we don't have any issue there. So, people are used to it. Also, our top management behaves like that. So, it was a good point, but it was not so difficult for us. The idea of transparency comes up a lot in this kind of realm. And I think the part that you added that I think was all effective, common sense things sound ridiculously simple once you figure out what they are.
6:00It's figuring out what they are and actually doing them. That is the problem, I find. But as you were saying, to put it another way, being reliable in doing what you know, doing what you say you're going to do seems valuable to maintaining that trust. And it reminds me of, there's a lot of people who, there's a lot of theorizing about habits and creating new habits and maintaining them nowadays. There's one little thing in habit folklore, which is, it's okay to not do a habit for one day. But once you skip two days, it's not going to be good. And in thinking about people I've trusted in organizations, like, it's not so much that they're perfect all the time. They might skip a day, so to speak, but they never skip two days. There's a certain consistency and reliability. It's hard to do anything perfectly all the time, but it really is, it's extremely important to maintain that trust and be mindful of it. Instead of just, I think the problem a lot of people fall into is they rely on policy and governance instead of, like you're saying, just like person-to-person interactions to make things happen. I sort of skipped us just right into the center of things. I should have started, like, you know, with these product teams, like, what are the actual products and services that you and the infrastructure area are supporting, but also the product teams? There is two sides of these products, I can say, as a bank. One of them is our digital channels. I mean, we have different digital channels. For example, we have a mobile app. We have a wallet app. We have our ATM channels, call center channels, etc. These are all standalone products which maintain by different teams. This is the one thing. But the other thing, and I think the most important part for the banking, as a bank, now, for example, we have different teams under domains. But what I mean by domain? For example, credits is a domain. Credit cards is another domain, etc., etc. Campaign management is a domain. Document management is a domain. So under these domains, we have different product teams. What do I mean by product? For example, if there is a domain which is responsible for document management and also the workflow management, and under this, there is a document product, document product team, and workflow product team.
8:08Even the granularity of these products may be more. Last year, we had, how can I say, blueprint study. It took almost four or five months. So now, we have a blueprint of the core banking. We have almost more than 300 products under these domain teams. And each of these domain teams are responsible for more than one product, of course. But each of these teams are responsible to make this product great. This is our aim. Under YKB, there are small startups. If you have a startup, how would you behave? You will try to make it perfect. And now, each of these teams are responsible, are trying to make their products better and better. Of course, we have a legacy. We are a big bank, and we have a legacy code base and systems, etc. But we also start the transformation journey. There is a very good, these product teams are very lucky, because each of them may start from scratch. And design their products with architectural studies, basically like that. So you started off figuring out, let's see, the actual architecture of the business, so to speak, right? This is the business as is. And what all of the... I always struggle with words, with phrases for this stuff that don't sound, I don't know, like jargon and a bunch of business talk. But you figured out the business-facing thing or the customer-facing thing. And then you took the step of like, all right, that's how we should organize IT, right? To very directly deliver that. And hence, I think you walked through a good example of what it means to think in a product versus a project way. How would you contrast to, before you did the blueprinting and shifted over, like how were you operating in like more of a classic project way? Or like, how were things arranged and how did those apps get worked on and the infrastructure managed and everything? Yeah, exactly. As you said, based on the projects, mainly. Of course, there were some domains, of course. But each of these domains, the roles and the responsibilities are separated.
10:09Especially based on the functions they do. You are a business analyst domain, so you just write the business analyst. You are a software development domain, you just make the software. The product was not the main issue there. Each of these domains were doing projects internally. And of course, there are some issues, as you can guess. But at that point, we were also working mostly with Waterfall. During this time, during these organization changes, of course, we started switching to agile methodologies, etc. It is not a new methodology. For example, Amazon, Netflix, etc. They are working like that for Spotify for a long time. It is very similar for us for the banking part. Also, in these product teams, we are aiming to have the business side as well into these teams. What I mean, when we do that. All of the parties of this product team will be completed. It is another part of the story. But it is not so easy for the big banks, as you can guess. Very legacy institutions. You'll see. But as an IT, we are ready for this, I can say. Another issue is that the main issue is not the technology. Technology is important, of course. We are adopting the best technologies and the latest ones. But the main issue is the business. For this, we also set up another team under architecture team, which is a business architecture team. We also set up this team. They are now closely working with our business teams and also analyst teams together and making the designs, the product designs together. It is also important for us because otherwise it is just a technical conversion. But now it is a business conversion at the same time. Yeah, that's interesting. That would be interesting, that topic to talk more on. Because I think what I've noticed in recent years is there's some bottlenecking in that area you were just talking about. And essentially, we've made our IT organization agile and product centric. And now we need the business side to talk with us more. And it sounds like you all are getting past and in some cases have gotten past.
12:10But what was the initial sort of work to go to the business side and say, we're ready to do stuff for you? To be honest, I think we have still too many gaps there. There is still a road to go. But we started, for example, it is also interesting story because generally requests come from the business to IT. But today we have also the request comes from IT to business side as well. For example, there is a project that we did with our new architecture and cloud environment. It's a very important project for us, which is we renewed our personal loans from scratch. But at that point, especially our IT team was very, how can I say, active to make this project and make it make a better loan system. They were very patient about it. And they also worked very closely and pursued most of the things to the business. As you said, at some point, it is surprising. It seems surprising. But with this new mindset, I think a business side will also get used to it. And I think there is still some things to do there. But at least we started. And for a bank, a personal loan is a very critical project. So if any problem there, we have really a problem, we can say. So it was also good for us. The operating model, we proved the operation model and also the technologies. We will see how it will go. But it is not so easy. But so far, so good. Yeah, arguably, loans are the core of banking, right? If you're not doing loans, you can't really generate most of the capital that you need to do everything else. Like it's core to it. So another thing, it's interesting going over this because you all are either in the middle of or you've gotten to a lot of the change that people are always striving for. And another thing, as you were going over examples that you're reminding me of is there's some people at large organizations I've been talking about recently, and they struggle with taking on more of a product mindset or figuring out the infrastructure that they should provide for more of a DevOps-y way of doing things.
14:18To put it in more boring language, having developers be able to use self-service to set up their infrastructure instead of having to file tickets and not to minimize all the DevOps stuff to that. But it's been occurring to me recently that one of the struggles that these people I'm talking with have is if you were to say who owns the end-to-end process of everything, I don't know if they would know who that was. Each little unit, like the storage people, the networking, the database people, the app people, they just do their own job and hope that somehow magically it all fits together. You have a lot of things underneath you, like a bunch of functions. And did you have any struggles or any, how did you get people to say, we want to have someone owning this end-to-end thing, right? Because that seems very non-traditional to have someone say, we need to pay attention to the whole process, not just these little parts, because otherwise we won't be able to do very much. In fact, our organization, in fact, this role is under my responsibility, checking each of these small units are working together, is the process okay, et cetera, et cetera. Yes, but the more important is there are too many people who came to me and said that, okay, I am doing storage, I am doing middleware, I am doing application, doesn't matter. But I want to learn the other side as well, not maybe not very deeply, but at least I want to see the whole process. So I want to see the big picture. And of course, at that point, I will be some part of it, I will be doing some part of it. But when I see this big picture, I feel I will be more excited and also I will also feel more trusted. So people are also, what I see, my experience is people want to change themselves as well, want to gain new abilities, new technologies maybe. They also see it as a chance, that is what I see. So when I collect this information, we started internal sessions, especially for this next generation project, next generation banking, we call it.
16:25We have a group of people from different teams. In this team, we are weekly, we are doing these discussions. Everyone is coming to this session and sharing their experiences, what they have done this week. And maybe another thing, it doesn't matter. Maybe they can share new technologies, it doesn't matter. We are trying to make transparent and, how can I say, removing these borders between teams. It is, until now, I get very good feedback from my team because they say that now there are some black boxes in the environment, but now it is all clear. There are two sides of it. I mean, the team wants it and also I agree with them and now we are running it like that. Yeah, it's interesting. One connection that occurs to me is you did what you said in the sense that sort of what you're saying at one point is we care about things from a product standpoint, which means we care about an end-to-end view of things. We don't want to have silos set up. And one of the ways of demonstrating that maybe someone like yourself or someone in a leadership position can do is to say, and I've done the work to figure out what the end-to-end process is. Like, I'm not going to go to all of the different silos and tell them to figure it out, right, to map out what this is. Instead, I'm going to try to figure out what this process is and then show it to them and get their input about it and their participation. So it's almost like, it's interesting, like, that a lot of the problems I talk with people about is we can't work together because we're still in silos. And it almost points to like, then you need management to do that first, right? Like, you need management to maybe do some of that work that they're expecting you to do instead, and then show you what that complete process is instead of relying on other people to do it. Yeah, I'm totally agree. Management, okay, it is important, but the thing is we are all part of a team. My role is the management and some other stuff. Some of my teams are more technical. It doesn't matter. But if we are going to do something, we will be doing it on hands.
18:30I think I am very serious about it. So I am trying to still be staying hands-on. So we are a team. It doesn't matter. But yes, it is also important when you are at the management, you decide. But we are all part of a team. It is so important. And having this experience together hands-on is very important. It also affects the people, I think. When they see the management is also doing it with them, it also affects. I think it encourages them as well. Yeah, it helps win that trust over ongoing, that you are all in it together. And you share the success and you share overall responsibility, good and bad, that things are happening as things are going. So another topic that comes up all the time in banking, but as I found in every organization, is worrying about compliance and security and following those sort of things. And in this discussion of doing things in a more product-driven, agile way, that's always one of the first questions. If we have, like, if we're pushing down a lot of decision-making and we're making it faster for developers to do things, like, that sounds bonkers. That sounds like it's going to be problems for enforcing security and compliance. Like, what have you all done in that area? Because it's not, it's, there's not an option to not be secure and compliant. You're right, regulations and security is the core of the banking. You cannot have any mistake there. What we have done in this new journey, I can say, we have legacy systems and all of these regulations and security issues are mapped in this legacy system. So it's okay. But when you set up a system from scratch with our new architecture, we change our infrastructure part, software part, middleware, cloud, and everything. So what, you have to figure out all of these issues from scratch with the new technologies, with the new mindsets, maybe. If it is necessary, you go to regulatory, and you also discuss with them.
20:30I mean, it takes time, it takes effort, but at the end, it makes sense. In this journey, what we have done, due to regulations, we cannot use public cloud providers outside Turkey. So we set up our private cloud in our data center, but private cloud technology, all of the technologies are different, containerization, et cetera, et cetera. So with our security team, we set up a project group. And with this project group, we studied all the new technologies around security. But we are very careful at that point, because everything must be secure, but also it doesn't have to affect the general working environment. We are lucky that, I can say, we have a very good, I mean, they are all open to new technologies, new ideas, our security team. So we work very closely with the good for us, and also regulations. We are also talking with our regulatory teams, and we are also checking these new technologies. But I can say it takes time, because as a bank, you have to, as I said, rethink all of these technologies, processes, not only the technologies, but also the processes from scratch. It is our journey until now. Now we are all compliant and secure, I can say. Even more secure, maybe, with the new technologies and elements. So far, so good. But also we are now, today, we are also talking with regulatory government, how can I say, for the public cloud issue. Right. Now, currently, we are working on this area as well. It takes time, but we are almost aligned with the rest of the world, I can say. What is the kind of timeline for that? How long did it take from thinking, we need to go talk with the security people and the auditors and regulator people, to like, all right, we got it. It is not so easy to say how long did it take. We are working on this project since 2016, I can say. But we see it as a journey, what I say. We started with some processes and technologies. But during this journey, now in the world, especially the software world, is changing so fast.
22:33New technologies, new opportunities. It is an endless journey. We see it like that. It is not completed. It will continue. And there is no deadline for this. The most important principle in our new world, I can say, architecture and technology, it will be adaptable. It is our first main strategy. All of our software components and infrastructure components, virtualization components, we always keep abstraction layers. So when there is a new technology, I don't know, or a better option, we can change it. So it is so important for us. So we started this journey. We are very good point there, but it will also continue, I can say. But how long did it take? Until now, it took almost four years. Yeah, that sounds about right. When I talk about this with people, I somewhat flippantly tell them, when they ask about security and compliance and what do we do about that, my first flippant answer is basically, yeah, that's a problem. It takes a lot of work. And I think your experience is what everyone else who's figured it out says is like, yeah, you need to go talk with the security people and the auditors and just start talking with them. And you even touched upon, there's that bidirectional thing, right? In the same way that, like you were saying earlier, like traditionally the business asks IT for things. And now every now and then you're getting IT asking the business for things, suggesting things. And I think what in more mature organizations that are getting closer to a product way of doing things, it's also a bidirectional thing, as you're alluding to, that the technical staff starts to say, this is, I understand the requirements for security and compliance stuff. And here's something new we could try out, right? There's actually some new functionality that might make what you're doing better rather than just waiting to be told what they can't do by, by people. But yeah, it's a major component. I think it's, I think it's part of what makes so-called enterprise stuff different than just like regular old tech companies. I like the way you put it a while back.
24:33You're like, technology is of course important because a lot of people like to say it's to misappropriate the old phrase, culture each technology for breakfast, to say it some other way. What is the technology? Like, how do you evaluate it? What do you look for? What are y'all using that helps out with all of this? It is a very important part for us because when you decided to change almost everything in banking, you build up from secret, you have to be very careful about the technologies that you choose. Especially for our new framework, we choose all new technologies. I can say we use open source and we are all open. We also contribute to open source. We are a fan of open source today. But also the underlying, underlayer part, the infrastructure part is much more important. Because today we have more than 8 million digital customers, very, very high number of transaction numbers. So when you set up something from scratch, you have to be sure that it will be rock solid. So otherwise you cannot take that risk. And also you will do some investments at that point. And it is not so easy. For the special cloud part, we had almost one year, how can I say, POCs with different vendors. And at that point, we chose Pivotal at that point, but today Tanzu. And now we are using Tanzu. Especially why we chose Tanzu, there are so many reasons. But two main reasons I can explain. One is it was a very mature product. And also the other part is it is easy to use. For the developers, when you say DevOps, you say that you will give new responsibilities to developers. So it must be user-friendly. So we see that developers can use Tanzu products very easily. It was so important for the developers part. But also for the operations part, for the infrastructure teams, most of the things can be automated easily with pipelines technologies. We saw that we have that kind of features in Tanzu.
26:33In the cloud part, we are using Tanzu. And also we are using different technologies in different layers. For the logging part, for the monitoring part, and also the networking part. For example, we are using NSX. Why? Because we can make, for example, micro-segmentation with NSX. We can put walls between products. Each team has their own area in the Tanzu. Their own products in this area. Especially in banking, authorization and authentication is so important. So we are at this tech now for the technology. And just as one minor thing, because people ask me this a lot. You said you also, in the cluster of things you worry about, you work on. You have databases as well. So what's been the, what have you done in that area? What do you do with databases? And I don't know, what's the data story that y'all have? Database is a huge part of the story. We are basically Oracle customers. Mainly we are using Oracle. But we have also a huge farm for the SQL server as well. This is the legacy part. Also for the big data part, we are adopting new technologies. We have Hadoop environment, for example. And also we are adopting new technologies such as MongoDB. We are also using these technologies as well in the database part. And it is evolving because what we see, especially different big players are attacking this area. Especially Amazon and Microsoft. They are providing today context-aware databases. We will see what will be our main strategy for future. But we are watching all of these changes very closely. Especially our migration transformation project is also very important for this. Because with our new transformation project, each of these products, as I said, will be running their own databases. So there will be no common database, maybe. So maybe we will be using context-aware databases in near future. I don't know. But the thing is, our software will be ready for this in the near future.
28:37Because there are too many homeworks to do. The first one is, as I said, creating this product. The main principle at that point is the domain-driven design, I can say. We are applying these principles today. And with this domain-driven design, we are making products. And each of these products will have their own databases. Today, it is like that. So we don't need to make a big bank. Today, if, for example, let's say, change our database, it's not so easy. Because it will be a big bank. Probably no one will take this risk. But in the near future, we will be in another position. Yeah. And also by doing your domain-driven design and figuring out all the different products that you have. Tell me if this seems true. But it seems like you're making it a lot easier to connect directly, like, the business value, like, the business that you have to the decisions you're making in your architecture. And so when it comes to something as difficult as database choices, you can say, we're going to, people might have different databases per product instead of one centralized database because it's invaluable for the outcome that we want, which we can now understand, right? Like, you can start to evaluate the risks of things versus the benefits of them and the difficulty of changing technology based on, is it going to be useful for the business versus just, like, other criteria, which is a nice side effect of all that analysis. At the end of the day, we are a bank. Each of these technology changes must affect your business. It must be, there must be some value added on your current business. For example, before, I don't exactly remember the number, but I think it was around 30 to 45 seconds when you give your credit as a bank to our customers. But with our new architecture, it is now almost eight seconds. And we are trying to make it six seconds because mobility, a customer cannot wait so much. We are making these changes in our technology and it also affects our business. It is so important and it will also get the support from the business as well.
30:40Yeah, I guess, as you say, that's the other thing that's important is it makes budget discussions a little easier. They're probably still difficult, but they could always be a little easier. So, well, this has been great. I appreciate you letting me ask questions here and there and fill in details. If people wanted to, like, check out more or follow up on things, do you have anything you'd point them to that you're interested in having people look at? Do you have any accounts like, hey, if you want to follow what I'm doing or do you have any job postings you want to direct people to? Sure, sure. Thailand, Gunayet, Twitter, you can find me and also LinkedIn. Basically, I am using Twitter. I am doing postings there. Very good. All right. Well, thanks again. I really appreciate it. Yeah, me too. It was my pleasure. Thank you. As always, this has been Tanzu Talk. If you want to get the archives for this show, you can go to TanzuTalk.com. And with that, we'll see everyone next time. Bye-bye. Thank you.