 So please give a warm welcome to Dr. Upendra Rao. Thank you. Thank you, Linda, for introducing me. I am Upendra Rao. My designation is strategy, architecture, and planning. You might have noticed this is unique in the banking industry. According to me, I have never saw that designation in any other banks. That shows the importance of enterprise architecture. Our bank is taking. So before I explain what is meant by integrating IT with EA, this looks slightly observed statement. What is this IT integration with EA? EA itself is an IT. What is IT integration with EA? So I will explain what is state bank of India. Some of you may not be aware what state bank of India is. It's a public sector. Government-owned corporation, largest in India, one of the top 50 global banks with $50 million revenue, more than $50 billion, $500 billion assets, and 278,000 employees, 420 million customers, 24,000 branches, 59,000 ATMs, 198 offices in 37 countries. That's how big is that organization. So implementing enterprise architecture in such an organization is very complex. We started one and a half year back starting this journey of enterprise architecture. We also faced a lot of problems. Our experience leads us to some kind of framework how to implement an enterprise architecture in a large organization. The contents go like this. IT execution models, generally how the people follow, understanding integration disciplines, common mistakes. Generally, all of us do. IT and EA integration workflows. We have developed a new model called FDI, Approach to Implementing EA. Frameworks are all available. At the question of implementation comes, failures are happening. So we require a strong framework for implementing an enterprise architecture. That's what FDI model which we have developed. We are following that. Transform my home to innovate. Integrating IT HR, the least important aspect of IT HR, playing a role in nowadays organization. That is made stronger. Enterprise architecture happens successfully. This is what contents. So the execution models and their impact, most of the organization follow this model of execution. Run and collapse. Take the requirement. Find a solution. Operate it. We call it ad hoc model of implementation. Most organizations fall into this category. Now later on, the organization, another model, is jog and tide. Where they started doing some kind of foot full assessment, prioritization. Then this calls some kind of siloed approach, but some kind of formalism is brought into the system. The third way of doing execution is walk and relax. There you start looking at the architectural fitness of the solutions. When you start doing that, you have to spend more time. So in the fast world, people try to adopt the first model. Then the pressure comes, okay, try to do some foot full management. When enterprise architects are coming to the picture, the time which you need to spend, everybody is taking a one step back. So we are not giving a sufficient time to analyze the architectural fitness of the solution. Immediately jumping into the implementation and trying to fail, not achieving the integrated view of the organization. That's why when you want to do an enterprise architecture, the top executives first has to understand we have to spend some time. Quality is a time. So we are moving from the siloed approach to integrated approach. Generally, in enterprise architecture, traditional flow is this. Especially for a large organizations, this flow takes a lot of time. Where do we start, where do we implement? As is architecture, implementation itself takes a long time. Until the, when we document the as is architecture, same thing, a lot of things got changed. Then again we start reinventing the wheel of as is architecture. So for a large organization, if the traditional model of enterprise architecture flow constructively is good, but implementation need to be changed to some extent to fit into the large organization implementations. So we need to understand especially the enterprise architecture integration of disciplines, what we are going to integrate, not just only the systems. The major enterprise activities which we do under enterprise architecture, strategic planning, enterprise architecture, then enterprise information management. The planning part, previous speaker was also, and we generally neglect the strategy and planning. What we need, what a business needs, first we need to have a deliberate on that. Then what we are, that is an enterprise architecture. When you understand what they need and what we are, then how to deliver, these are the key tasks we need to integrate. These are the disciplines, how effectively integrate the process people, the systems. Now when you take up any implementation in the project, people always go in the IT management angle. So the different layers of approach in IT management, IT management, the lowest layer, everybody jumps into the solution and start implementing it. Then above that an IT portfolio management, now the new and phenomena of enterprise architecture has come into the picture now. Now you look at these differences in the IT management, solution development and implementation. Most of the project manager adopt. When you start doing that, the architectural view will be missing. That's why we don't be able to have an integrated view of the organization. No architectural view or limited architectural view. Then when you go to the portfolio management approach, application portfolio management, hardware asset management, HR management, least attention is paid to HR management, but this comes under project portfolio management. In this approach, we have a partial architectural view of the organization. Still we are not getting an integrated view. Now when you go to the enterprise architecture, we have business architecture, data architecture, application architecture and technology. That is enterprise architecture. There we are going to get a complete architectural view of the organization. So where we are going to place our organization, which model, how we are going to operate it. So when first we assess ourselves where we are, how we are operating it, especially the top management, understand then we will be able to implement the enterprise architecture very effectively. Now we see that same one, I have just elaborated the difference between the project management, portfolio management, enterprise architecture management, talks about the tasks to the architectural view, the orientation of the project management only the performance, then portfolio management investment model, the angle, then enterprise management agile angle. So the scope is a project specific, class specific, environment specific. The focus is qualitative, performance and delivery quantitative and relationship and dependencies, that's the enterprise architecture model. Methods, generally we have project management techniques and solution techniques, then the IT portfolio management, we have identification and evolution metrics, enterprise architecture management, modeling, how strong you are in modeling the organization, understanding the relationships. Then transformation impact is low in the IT management and very high in the enterprise architecture management. Framework, delivery framework, both are delivery framework, that is a design framework. So degree of realization is complete, partial and is developing. Architectural view is micro level, operational and micro business level that is an enterprise level, that's kind of differences. Once you know the top management know the actual differences of these, where how to implement the enterprise architecture in organization will be relatively become simple now. So at the same time, you have to see the maturity view of the management maturity. You look at the management maturity in these three layers. You require a high level of maturity when you start implementing enterprise architecture. Enterprise architecture, select the right things to do. We don't do the right things to, we don't select right things, we do the things generally. And the fourth one, do the things in the right order, then do things right. So the level of maturity from the down to bottom, very high level of maturity. What level of people which are positioning in these layers is very important. If the low level of maturity person, the capability person is at the, sitting at the top of an enterprise architecture, then you will not able to achieve the desired results. So this is also, organizations need to understand very effectively what is that now. So when you see the domains of enterprise architecture, these are the four domains, business architecture, application architecture, data architecture and technology architecture. You have specialized people in each area data architect, application architect, like that. Then the combining all these things when a solution is developed, the who is going to develop a solution architect. What is the capability of the solution architect come connecting to all the four domains? So for namesake solution architects are working in many of the IT areas, therefore it's failing it. So what level of capability a solution architect should have? That's a big question in many of the organizations. So there we have to pay a very important role in each domain as well as the solution architect role. Generally what kind of mistakes happen when we're doing an IT? IT for the sake of IT everybody does. Now today enterprise architecture came into the field then the first sake of enterprise architecture doing, people are all starting, okay we are also doing an enterprise architecture. So the both are going like a silos, how it happens there. Treating IT management and enterprise architecture management in silos. There is a department of enterprise architecture man where IT generally they start doing their own project. Selecting things to do in IT later on they will give you to enterprise architect assess whether it's proper or not. That's what is happening. That's why both are going as a kind of a parallel slightly little bit only overlapped manner. That's a major problem in the today's practice. Second one is enterprise architecture governance board. As soon as enterprise comes to the picture you have to form a board combining the business people and IT people. In the enterprise architecture board I have in my practice I find business stakeholders feel artifacts are not of their own advantage. And least interested in understanding IT. In the technology stakeholders in that board meeting they take a long time to understand the business unable to manage the business authority. So when the board meetings happens they are in their own domain of I want to be done I want that this is to be delivered fast but they don't try to give us empathy empathy or reward this IT people. IT people try to be in their own area of artifact that is not there this is not there. This is not the board actually enterprise architecture board effectiveness is not coming out. So in this process lack of role clarity in the solution architect enterprise architecture. Solution architect even you read about the Togoff architecture you find all the four domains where the solution architects fit into the entire domain is not much clear. There's the rule clarity is missing there and also in while implementing in enterprise architecture application rationalization is generally out of the scope. If you do the application rationalization out of the enterprise architecture you will not able to achieve the real benefits of an enterprise architecture. It has to be parallel to be done. It cannot be separated from the enterprise architecture. The another most important thing is master data management is a core of a data architecture and often neglected. Many organizations many people don't understand what is master data management? How does it need to be integrated with the enterprise architecture? In my knowledge all the enterprise architecture practices neglected the master data management portion and then try to do an enterprise architecture. They do only a data architecture point of component and a little bit in a siloed manner and then try to implement an enterprise. These are all the common mistakes generally happens now. So we need to integrate the IT which is happening in the organization and the enterprise architecture through a flows, workflows, common platform. So integrating IT practices without architectural view will result only process integration but left with the redundancies in technology components. Most of the people struggle with integration at the time of integration architectural view is completely missing. I need to integrate, I need to implement an IT at the same time bring the architectural view in the time of doing processing it. I cannot separate the architectural view at the time of implementation. What is the procedural interplay between the IT management and architectural landscape management? IT management is always going a procedural way. Architecture management is an architectural way. How do you do the interplay? How the both together go in hand to achieve the objectives? So what we need to do? We need to rediscover IT process with reference to the enterprise architecture. Whatever the existing IT process is not sufficient. Since the introduction of new actors, their business architect, application architect, data architect, technology architect, solution architect, enterprise architect, coming to the play, a crucial role in IT, IT process need to be redefined in the current practice. What are the processes? I'm giving an example of few process, hardware procurement process. You look at the existing process. How do you redefine with reference to these stakeholders? Software development procurement process, business requirement, identification, managing process, IT HR alignment process, inter-department workflow. Every process which is happening today in the organization to be really good in view of these current stakeholders, how the workflow will happen, develop a complete integrated information system. That's where the IT and enterprise architecture can be integrated. Integrating IT management with enterprise architecture should be a prescriptive treatment rather than a descriptive explanation. When I look at the framework, they're all descriptive. A lot of blocks are there. When you put in practice, how do I implement it? Different people implement it in different ways and may not lead to a correct result. So when you're dealing with IT management and enterprise architecture, you give a prescriptive description of doing an activity. That's what you need to redefine the processes in the organization. How do I do that? I'm giving an example here. In the business, the demand is raised in the business. It first goes through the business analyst or business architect to the business side. There's a specific role defined for them. Are they doing their job or not? How much of their business architecture job? How much business is doing? How is IT is doing? What is the importance of doing the business architecture by the business people rather than the IT people? If you look at many of the enterprise arts implementation, business architecture is drawn by the IT people rather than the business people. How do the business gain the capability of business architecture review? So ultimately, the enterprise architecture success will not come if the business doesn't have the capability of business architecture review. So once the business request is raised, analyzed, architecture review is taken with reference to the business architecture, then you should go to the development process. Application architecture, solution document. If it's a minor, it will directly go to the development. It's a major, it has to go to the architectural division. So enterprise architecture assessment is done by the technology architects, data architects and enterprise architecture with first level of assessment by the solution document prepared by the solution architect. Then goes to the quality assurance, quality and UVIT, and then security division before going to the production. So what are the divisions in the organizations? How they are fitting into the, while carrying out the enterprise architecture process into that. What they're doing their role effectively, this all to be done through an integrated work, automated workflow process, not in a paper document manner. Example I'm showing here, IT management enterprise architecture integration flow. Out of these many flows which you need to identify, each flow I need to define like this. Business request comes, put into the demand management portal. So that you'll be able to measure how many demands are coming with reference to what kind of business. Business will also understand how much demand I'm raising against the capacity of IT is having. So they will also able to see the capacity of the IT is this I have raised more demand. So I need to prioritize, I need to reduce, I need to eliminate such and the process they're able to do that. Demand request then it goes to the business analyst. He will analyze the request in a vertically, how the process flow. Document it using the standard BPM notation document. Then goes to the business architect. Then he will see the architectural fitness into the business architectural view. So he will analyze horizontally about the business only. No, you will not look at the IT component of it all. Then later on verify and validate the architectural fitness. Then go to the application architect. So application architect will design the application. Then give it to the solution architect. That means he will design these kinds of software. Where is the application architect, what does he does? So this is a function. Is it a part of the existing one of the application can it fit or can it be a separate software is required? So he will do the application fitment. Is it a part of an existing application or a separate application? Need to be developed, need to be procured. These kind of decisions are taken at the application architect level. He is supported by the application portfolio management software that's behind the system. Then we go to the solution architect. From solution architect, he will define the design, the solution, discuss the technology architect depending on the stack and all those things. And discuss the data architect with reference to how the information model, data attributes, where the sources, the destinations, how to map it and all those things. Those people, the data architect should have a knowledge about database trends. The technology architect will have a technology trends. These are all the knowledgeable people who is supporting the solution architect in designing the right solution. Then come to the enterprise architect's complete validation. Then go to the once the request gone to these processors in matured, yes, it can be accepted as a project, then only it's going to the demand management portal as a matured project. Then goes for an implementation. Project management happens there. So that's how we integrate enterprise architecture. So this technology architect will be accessing the application portfolio management. It'll update as soon as a complete application is developed and the project executed that contents to be upgraded into the application portfolio. Which application, what features, what factors, what are the impact, what are relations and all those. At the same time, master data management need to be updated. This is also important factor there. So this is a flow we need to integrate it. Most often I have mentioned it. Master data I mean out of the site while in enterprise architecture contribution. Many people don't understand clearly what is just my master data management, what role, who has to play, which role is also not clear. We need to integrate master data management with enterprise architecture. First understand master data. We have master data types, reference data, master data, application data. Reference architecture view of the reference and master data is centralized, application data is distributed. Characteristics is a global level, reference and master data, reference data. Master data is organizational level. The example is country codes, state codes. Master data is a product code, organization level, application level, loan codes, loan management system, or mission codes in a production system. So then when you know the categories, this data type, who has to play which role in the master data management? Where do you position the master data in the enterprise architecture integration that need to be done now? So what integrating data architecture with an enterprise architecture view? You have a business architecture one side, we have a technology architecture one side. There's a different stakeholders has to play a different role in each area. In the reference data, company master data, reference data and application master data view, each application based data view. Technical view is the transaction data, master data management, meta data management and operational data store and data warehouse for operational purpose. In this business architecture view, governance stakeholders, company corporate body, they have to play a major role in the governing the reference data. And the business owners have to take company master data, business owners. So that means the master data definition, unification is to be done by the business side, not the IT side. Most of the cases, the IT does the master data management. The single source of truth will be missing if the IT does it. Once they do that, if you assign that responsibility, if they take that responsibility, our master data management can be effectively integrated with the enterprise architecture management. So once we come to the transition, IT will be looking at only the operational data as well as data warehouse for the different purpose of business and CRM and business intelligence. So how we want you to integrate it now, take the business demand, have a business area architectural sessions with all those people, define a solution, let's set up group of people then, then define architectural application for full sessions with IT people, second group of people. So this group is first different, that group is different. I don't want to combine the two groups and discussing how the solution to be developed. Then technology implementation sessions by the project management people, then operations management about where to, how to do and all those things, service management, then integrated. That's what, in each and every area of activity, the inputs would come and be stored in the enterprise architecture meta data repository. So the measurement will automatically happen there. So considering all the aspects, we have designed a new approach of implementing enterprise architecture, federated dynamic architecture integration. So what we said is in a large organization, single enterprise architecture board is not working effectively. Your separated business architecture board, they will have a business integrated architecture view and the down in the technology architecture board. We need to conduit between the two. All the people sitting there discussing about is not giving an effective result. So business architecture board, the fundamental platform is a master data management system. Implement effectively, that is a business side. And the technology architecture side, these people will be fundamental platform, some is IT asset management, IT service management. So these are the fundamental platform between them. Then later on new applications will come, they will be fitting into one of the business. Based on each business vertical, we form a steering committee. There's a technical team. For that business team, there is an application portfolio management. Each business and application portfolio management. So that those applications later on, the across cross integration of the applications across the business is very rare. Therefore, we segregated the application portfolio management each business unit wise. However, it can be analyzed at a later stage. So in this framework, the chief data officer will sit at the master data management system level. He's responsible for the data and custodian codifications and all those things, you know. And the chief technology officer will sit at the down at ITM, ITSM level. And the chief information officer will be across the businesses. He's responsible to what information, who requires at what time, how to deliver. So this is the kind of framework. So what we say, why did we say it is a, the federated dynamic, why you call the federated? We are not implementing enterprise architects or taking the whole organization at a time. We are taking most critical important wherever I want. This is the most problematic business area. I will take that area, implement it as a standalone and build up the bottom board and the top board over a period of one year or two years time. I'm not building the first board and then start looking at everybody, looking at the whole holistic view. So whatever way I want to implement the enterprise architecture, it can be done through this model. That's why we call it as a FADAI. Generally, what happens to the current trend is innovation to transform. You bring a lot of innovation. But many organizations don't know how to innovate. Are you struggling to innovate? But our practice, our experience shows the way is transform to innovate. If you are innovative, you want to be innovative, first transform. Solution is implement enterprise architecture. Definitely enterprise architect will give some innovative idea to solve many of the unhidden mistake patterns in the organizations. So how do you ideate? What is the enterprise architecture approach? Will it give an idea to implement? New ideation? Yes, why not? Enterprise architecture knowledge repository you create. Analyze the relations. We got an experience. We have found some new solutions based on that. Market requirements, we know that. Consolidate and validate these master requirements. Then you combine these two, you get an ideation with taking some inputs from the technology changes. You do the proof of concept. If it is a file, go back and update it. If it's successful, then put it into a kind of a demand management. Definitely the enterprise architectural route will lead to new solutions for solving the new problems in the organization. This is the ideation to approach. So the last one is the most neglected discipline in the organization is ITHR with enterprise architecture. ITHR capability management, most neglected area. How do I do that? What kind of people to be placed in which positions? So in the enterprise architectural, we require these people, BA, DA, TA, EA. When you do project management, application architecture and solution architecture is important. When you're project management level, developer and project management level. So I need to skill the people to be positioned in each domain of enterprise architecture. For BPM skilled specialists, up to APM skilled specialists, APM we don't have today in the market new proper solution. We have developed our own solution of APM. Master data management specialist, most neglected area, ITAM and ITSM. Fundamentally we fix that ITAM, ITSM solution and the down, up at the master data management, you work on the enterprise architecture, you're able to implement the enterprise architecture more effectively than anybody else now. So the ITHR strategy you should have with reference to enterprise architecture. Not a general distinction. You should have a skill development and placement strategy, especially with reference to enterprise architecture. How do you do that? So basically whether domain or IT specialist, you assess the capability assessment and then map to the division. If the employees is useful through the formal inform, you assess them through the formal and formal feedback. If the skill is matching, assign it. The skill is not making, there is a gap and try to train them and feed them. This is not ad hocly to be done through a system, through a system flow, is one of the flow like previously I mentioned the development flow, the skill management capability flow, all through be done through a workflows automated systems. Then you can do the IT capability. If you are able to pay much attention to the IT capability management, enterprise architecture implementation will be much simpler. Without paying much attention, we're trying to do anything about that, then it is only for the namesake we are implementing enterprise architecture. The takeaway is we must strongly integrate BPM, MDM, APM, ITAM, ITSM with HR through a workflow system. Otherwise, EA remains as a siloed knowledge repository. That's thank you. Thank you so much, Dr. Rao. You have a smorgasbord of questions queued up and ready for you, so why don't you take a seat and we'll walk through some of these together. So I can see from a few of the questions that it would be helpful to have a level set about the state bank of India and the open group. So you are a brand new member with us and recently joined the IT for IT forum. Some of the questions are around, are you currently using Togaf in state bank of India and are you using, what is your intentions with IT for IT? No, Togaf, we are framework is Togaf only, but implementation methodology is slightly, we are changing to meet our complex situations. Framework is Togaf. Very good, okay. Let's get into some... That's what I mentioned, Togaf is a descriptive. We are converting into a prescriptive model by the time of implementation. Okay, thank you for clarifying. We have several questions around Agile, so I'll give you an example of some of those. Is this framework applicable to Agile projects and let's see if I can get the other one up here at the same time so you can think about that one. How are agile practices affecting the way EA should work and changing the role of an architect, for example, continuous delivery? See, Agile, according to me, which is applicable to Agile projects, but people don't understand in a true sense what is Agile. Agile, while the time of implementation, ad hoc way of doing things is agile. So previously, without the agile methodology, people were doing all the implementation in ad hoc manner, but there's no formalism incorporated into that process, short processes. Now, agile means they do the same ad hoc manner, the things in small pieces, with a formal approach. That's what... So whatever process we do, all agile, most of the things are agile, we are depending on the kind of solution. If the solution requirements are freezed, no need of changing in between, then they need to go for an agile. If the solution output can be delayed for some time, I can go for a water ball model. That we don't just simply jump into the wagon of agile, agile, agile. What is the situation? Is it agile model is required? Whether requirement of the business is not clear? Then I will show an agile model showing that this is how the requirement will be met through an agile model. Otherwise my personal opinion is I prefer it to be a waterfall model because that will put the people in the initial stage of thinking process. When I start agile, nobody thinks only at the time of situation they will start thinking. So think thoroughly in the beginning, then plan it, develop it. So when you want to development time, only you start doing an agile process. What is there in agile? Formalize the process of doing it. Development only agile. Your thinking should not be an agile. I see. And in the state bank of India, is there an evolution right now or any kind of policies that you might want to share about the adoption or the applicability of agile? Has it been formalized at all about your future roadmap? Our board has approved the policies, in reference to the enterprise architecture, where the application development, there's a policy in place. Okay. This was a fairly generic question, so you may be able to take this where it applies to your bank, but the question was simply what role does Togoff play? And I'm assuming that the person meant in the content, the model that you represented, or maybe they meant in state bank of India? The Togoff gave the knowledge of the body for us how to do, where we got the knowledge of implementing enterprise from only from the Togoff. Very good, we want to hear that. It's playing a major role. So we are certifying our people, not only that, we encourage people to go for Togoff certification, who certify, we'll pay reimbursed the fees, and we also pay some honorarium to them who passes certification of the Togoff. Excellent. I think we just have time for one more. Here's one for you. How do you ensure that during application development, the IT management requirements capabilities are covered in that concept of shift left, that you heard a little bit about it this morning from the other speakers? And so their examples were instrument monitoring, standard logging, updating the service catalog, et cetera. So how do you ensure that during application development, the IT management requirements and capabilities get covered? The capabilities, now we are building the capabilities as far as the, in the process called ITSM, ITAM platform we already set in place. In place of the development of the application with reference to the people capability, we are building it. We don't have a large number of people in the organization. We are trying to hire people and do on base. We have the contract basis, hire basis, permanent basis. All the three models are there. So depending on the need, we'll be applying any of the model depending to cover the capabilities. Okay. I think we, there's one other question about IT for IT and that might be a little early but I think people are interested to know how does IT for IT help the state bank of India in your evolution? Is that happening or is it you're just starting the journey to investigate IT for IT? No, the IT for IT, we were doing long back without knowing that we are doing IT for IT. So now this new terminology gave us some kind of thought process, oh, this is what is IT for IT. We have to do it much more formal way. Definitely IT for IT has to, will definitely help the bank. Every organization has to look for IT for IT. Everybody looking for IT for business only. When you look properly IT for IT, then look for IT for business. They may be, that may give a better results. Yeah, okay. So we should go that route. Excellent. Well, we're delighted to have state bank of India with us now with the open group. Both of us experienced TOGAP users and soon to be experienced IT for IT users. Thank you so much for being with us today. Thank you. Let's give Dr. Rao a round of applause. Thank you. Thank you.