An enterprise architect argues that blueprints aren't enough. Architects need to stay involved from project start through production, working directly with delivery teams, aligning across roles, and training developers on enterprise context. Regular cross-functional reviews keep work aligned with business goals.
Chapters
It is somewhere you will find the gap. Because still we are having the thought process as an enterprise architect that was sitting at the top that okay, once they have created the blueprint or it is passed by the ARV now their work is over. But it is not the case. Okay, so when you talk about the delivery related architects, they are facing lot of challenges. So we have to use a new methodology called as a sift level where we are just going to tilt towards this delivery. I'm not saying that okay, you are just going to get away of your enterprise architecture work, but you should just go near to the delivery team or the delivery architects or the domain architects and the technical architects. And you should be there from the inception of the project while evaluating and business idea till the delivery goes into the production. So this is the first step. So as a delivery architect, if you see I'm working as a, is a tile architect. Before that I was working as a social architect. Before that I was working as a technical architect. So I pass into all those areas so I can easily correlate the whole process and how it is going. And what are the current perception of the CTO or CIO or those who are just coming from the technical background, they think that okay, only technical people are required, they can do each and everything. So there is a gap. So the current state is this gap and how we are going to fill that gap. That's the most important part of that. So to fill that gap, what we have to do is we have to align ourselves with the technical architect or the application architect and the delivery even you should be available for the, even a small developers who are really working on the ground level because they might be having a question that okay, we have developed this module and we are thinking that if you are going to exchange the data, there might be a data breach, that question might come. So for that a security architect is also required over there. But if they are not available, they will go to the their application architect. They will say no, no, I have no idea so how I'm going to. So for that you have to go to the enterprise architect and then they will align you. If he is well aware about that, then he will sort out the problem. Otherwise he will show you, okay, this is the right person, go to him and solve that problem. So this is how the role is having a chain nowadays. So change is happening here. But we have to think from the enterprise level perspective and we have to think from the ground level perspective where the actual implementation is happening. So this is your current Estate. Now if you talk about what needs to be done, then the communication and collaboration comes in the picture. Communication is okay. It should be well structured and you have to identify stakeholder in the starting itself. That okay, let's say he is a CEO. He might be interested only in the finance, he cto, he might be interested only in knowing that what technology are going to be used or if someone else is business side, they might be interested. I am not bothered about anything how you are going to implement it. I am just bothered that how this business idea is going to be implemented. Whether you are implementing it using your handwritten paper or Excel sheets or some tools. So this is the place where your current estate comes and you are going to take care of the communication part and collaboration part. So communication and collaboration comes in the picture, then comes your what needs to be done. So there are couple of things comes in the picture. One is the training tool which is very important because as an enterprise architect, I understand the whole enterprise. Different verticals are there, different business processes are there. And even if you have so many, you can say vertical circle I understand. But as a developer he might not. So we have to give him an overall training that okay, this is the thing, you need to be at least aware about it besides doing your whole job. So that is one thing which is way forward. We have to take care. Apart from that, the regular communication is very important. The third thing is checks and balances at regular interval at different levels. It should not be only on the technical level, or it should not be only at the enterprise level, but it should be at a different level. You should have a regular connect with a business where business will evaluate okay, the work which you are doing, whether it is aligned with our business or not. Okay, so this is how we are going to evolve or this is how we are going to structure the. This is my perspective. Thank you so much. Those are very practical perspectives. And before we move on to the next table, which happens to be table number 12.
