Episode 34 - What is the role of an EA?

 Hey, what's up everybody? You're listening to the Enterprise Architecture Radio. If you're thinking about organizational complexity and agility, if you're concerned about operational efficiencies and thinking of taking it to the next level, if managing innovation is one of your priorities, you've come to the right place on this podcast.

 

We talk about all of that and more. It's a jungle out there, and we'll attempt to navigate this jungle of frameworks, methods, and most importantly, enterprise architecture in practice.

 

As per Glassdoor, the role of Enterprise Architect is one of the best jobs in America in the year 2022 in terms of salary, job satisfaction, and the availability of the enterprise Architect positions. And yet how many people understand the role of Enterprise Architect? What does an enterprise architect do on a day-to-day basis?

 

Now, I've talked about this in my previous episodes. I've talked about enterprise architecture and what it is, um, but I think that no matter how much I talk about it, there's always scope for someone. So let's talk about that today from a different perspective. Fundamentally, enterprise architects are change managers for an organization.

 

Think about it. How do you manage change? How do you change anything? Forget it. Forget enterprise. Forget everything. If you wanna change something, how would you do it? Let's say you wanna change the plumbing in your house, or you wanna change the electrical wiring in your house. How would you do it? The first thing that you do is understand how the wiring has.

 

If you don't have a very good understanding of how the wiring has been done, there's a high chance that you might zap yourself and then understand what, what is the change that you want to do. Now, sometimes the changes are clear. You want to, you know, you'd need a new light bulb or you need a, um, a decorative light set up or what have you, and, and.

 

Things become a little bit easier because you have a clear understanding of what you want. Sometimes you don't know what you want, you know, you know that there are some problems with the wiring. There is short circuits happening or what have you. I'm not an electrician, but you ought figure out what the problem is and you fix it.

 

Enterprise architecture is more or less like that. We enterprise architects, look at the enterprise and try to understand how it's been designed majority of the times in the industry. Organizations are not designed well. And what I mean to say is they're not a conscious design, they're an outcome of organic changes that the organization has to go through from time to time.

 

Whether it's a change in the business model or whether it's a merger and an acquisition or, or, you know, making changes to become more efficient or what have you. A good example that I can give you, uh, in this regard is let's say that there is a farmer and he has a farm. His house is far away from the farm.

 

So what he does is he builds a very small hut near the farm or in the farm, uh, that gives him absolute basic shelter to spend the night because it's a long walk from the farm to home, and he cannot keep going back and forth all the time. So he decides that he'll build a small hut in the firm, and every once in a while it will stay.

 

At night, he'll get his sleep and, and shelter. Now this hut that this farmer builds, does it have design? Does it have architecture? Of course it does. Uh, if it does not have architecture, then the house would not stand still, it would get blown away. By the first strong wind that it faces or, and every time the wolf comes in and huffs and puffs and the house gets blown away.

 

So there is architecture, and this architecture is based on the, the experiences of the farmer. He must have built this hut from time and again many years before, and, and his father must have built it, and his father must have built it. And the knowledge has been taught from Father Duana, what have you, but there is architecture.

 

The only thing is that this architecture of this small hut happens to be accidental architecture. It's not conscious arch. The, the fundamentals of architecture are not well understood by the farmer because his job is not really to build houses. His job is to do farming, and the house is just one of the things that he has to do as a part of the farming.

 

So, while there is architecture in this heart, it is accidental architecture. Similarly, organizations as they evolve over a period of time, organically or inorganically, they have architecture, they've been, uh, uh, put together. As an accident, you know, as the organization changes, we do what we have to do.

 

It's just that the view that we have is very limited. It's a very tactical view, and the organization evolves over a period of time based on these. Tactical aspects, it's a very short term view. What enterprise architecture does is it has a more holistic view of the enterprise. It looks at the entire enterprise and understands how the organization should be designed and, and based on that makes small changes in every transformation, uh, so that over a period of time, the organization becomes more and more e.

 

So technically enterprise architects are really change managers. Let me give you a more practical example of enterprise architecture. Let's say that there is an organization and they have large number of data centers, and these data centers manage. Uh, all the data, all the applications are hosted on these data sectors, and over a period of time they have come to realize that, one, the costs of managing these data centers are extremely high and that, you know, they, they could be something that can be done around this.

 

Second is public cloud is becoming more and more efficient from a cost perspective. And third, there are a lot of native services that public. Offers, which make the entire hosting infrastructure of an organization much, much more efficient, effective, innovative, malleable, flexible, scalable, et cetera, et cetera.

 

So they, they decide that over a period of time, they're going to move all the applications that they have on the on-premise data center, all the workloads, all the data that they have on the on-premise data centers and move them to the public cloud. They put in place a large program that will essentially look at all.

 

Uh, applications that they have on, on-prem data centers come up with some sort of a prioritization mechanism based on a number of criteria, such as it could be end of life of hardware that are there, or it could be end of life of the application itself, or it could be an upgrade of the application.

 

Every time there is a milestone event or a lifecycle event that an application or an infrastructure faces, they will transform the data center by moving that application onto the public cloud. This is obviously a very, very high level use case that I'm giving you, and there are a lot of nuances to this particular scenario, but we'll not get into that for the moment.

 

Now, there are two options that the organization has. One is a lift and shift. Strategy. What this means is that they will lift and shift all the applications from the existing on-premise data centers onto the public cloud, and then think about how to rearchitect those applications. And if you work with these public cloud vendors like a W S or Azure, Azure, this is the first strategy that they will recommend.

 

And the reason is, obviously, when once you have lifted and shifted the applications onto the public, Their billing begins, right? And there is a consumption cost that your organization will have to start paying immediately. Not only that, When you do the re-architecture on the public cloud, there are professional charges and, and, and other charges that they can start applying on, on doing the transformations in alignment with you.

 

Another big disadvantage of lifting and shifting all the applications onto the public cloud and re-architecting the applications over there is that like to, like, if you move the applications from an unpromised data center to the public cloud, It is actually more expensive. It becomes more efficient only when you start leveraging the various native capabilities, the various services that various public clouds offer.

 

So when you move an application from an unpromised data center to the public cloud, it definitely requires re-architecting. It cannot be a lift and shift strategy and still save money. Of course, you can do lift and shift. That isn't, there's, nobody's stopping you from doing that. It's just. Don't expect to save any money if you go for that strategy.

 

The other option is start looking at each and every application that needs to be moving. Move to the public cloud. Start looking at first of all, whether or not that application is adding value to your overall business. And then second of all, how can you re-architect the application to make sure. You can leverage the cloud capabilities to the best, um, best of their offering and save casts.

 

So all things considered the second strategy of rearchitecting, each and every application as you move them to the public cloud is a better strategy now. Is it a better strategy in every single scenario in the world? Of course not. There are so many, so many factors that we must consider, and that is why I said all things considered.

 

I mean, generally it is a better strategy. Of course, there are times when you might have to move an application into the public cloud with the lift and shift method. You know, for example, you might. Very tight timelines. You might have e o l of the hardware, um, uh, coming in, in the next nine months, let's say.

 

And you don't have the time to re-architect an entire, uh, large scale application and move it to the public cloud. So you do a lift and shift and, and these are emergency measures that you have to take from time to time. But holistically speaking, I mean, all things considered. Doing a re architecture is always a better plan.

 

Now, in this particular scenario, what is the role of an enterprise architect? The enterprise architect, first of all, does application rationalization. What that means is it would, he would look at all the business functions that exist within the organization and try to understand which are the applications that are truly adding value to business processes and services.

 

Do you really need each and every application? Are there applic? That can be reused across multiple processes, multiple business functions, multiple services, et cetera. That is called application rationalization. So we try to understand the value of each and every application and decommission those applications that are not truly adding value because each and every application has a maintenance cost, it has a total cost of ownership.

 

We have to host them, we have to have, we have to manage the hardware costs and what have you.

 

The next phase. Enterprise architects take a look at applications and try to understand what are the interconnections that they have within themselves? What is the data that they are managing and what kind of data is it? And there is a data classification mechanism and, and we try to understand which data is important and which data is not, and how the workloads are being managed at this point in time and whether or not they need to be managed in a similar way.

 

And then we come. Technology architecture where we try to understand what are the native services? Well, first of all, we try to understand how they're being hosted, what are the existing requirements, what are the functional and non-functional requirements from the technology that is being used to host these applications?

 

And then we try to understand what are the native services that. Whichever public cloud we have chosen offers us to give the best bang for the buck. We architect the technology in the best possible manner to move the application from an unpromised data center to the public cloud. Now, that is the general example of what an enterprise architect does in a migration scenario, right?

 

As far as job titles go, I think, um, I don't consider that to be a very important, uh, aspect of course. Are there job titles called Enterprise Architect? Of course they are. There are organizations that. The job title of an enterprise architect, a senior enterprise architect, a junior enterprise architect, and associate enterprise architect, architect, et cetera.

 

And every organization, uh, gets to choose what kind of job titles they have, but it is not a necessary factor. You are an enterprise architect, whether your job title says enterprise Architect, or whether it says architect, or whether it says director or what have you, you could have a title of engineering manager and still be an enterprise a.

 

The role of an enterprise architect is a mindset. A mindset where you look at the organization, uh, holistically from a big picture view, try to understand how everything connects with each other, and then build business intelligence that helps the leadership team to take strategic decisions about the organization.

 

Um, how do you become an enterprise architect? Well, you start by studying the different enterprise architecture frameworks that are out. The, the biggest and the best one that I feel is the toga certification, simply because, um, and I have in one of my previous podcasts done a comparison of the different enterprise architecture certifications that are out there.

 

But the best one that I think is the to afe, uh, certification and. The Zak Man Enterprise Architecture Framework is also an excellent framework. In fact, John Z-Man is called the father of enterprise architecture, and he was the one who coined the term enterprise architecture. And Zak Man framework is also an absolutely beautiful framework.

 

So if you are. Interested in becoming an enterprise architect? Look at these certifications. Um, have a holistic view about the organization. Try to understand the business, try to understand application and data and technology. What I would recommend, and if you want to be an enterprise architect, it's a good idea to have at least 10 to 12 years of experience in the industry.

 

Um, if you're planning to become an enterprise architect, Don. Stick to one particular area of the business for too long. Uh, try to understand different aspects of the business. Be in it, be in program management, be in data, be in application. Be in different areas of your business and try to understand how.

 

Things are done within that, within that section of the organization. This will give you a much better, more holistic, bigger picture view of how the organization functions. This will help you become a better enterprise architect.

 

That's all I have for you today. I hope you enjoy the show more about organizational agility, innovation, and enterprise architecture in the practical world, in the business right here on the show. But before I end the show, I want you to help me out with this one little thing. Pause the show and share this podcast via WhatsApp or text message with at least one person who might be interested in the show.

 

It could be anyone. Your colleague, your boss, someone in your team. That's all I ask. Just one share with one message via text or WhatsApp or any social media for choice, and it would go a long way in supporting this podcast and growing this listener base. Also, please don't forget to follow the podcast.

 

That way you'll get notified when we publish a new episode. If you wanna find out more about us, you can find us@enterprisearchitectureradio.com. If you have idea starts disagreements, please feel free to write to me directly. Uh, we also have a Telegram group if you would like to contribute to the EA discussions or what have you, just search for Enterprise Architecture Radio on Telegram for the URL to join.

 

The group is https://t.me/enterprisearchitectureradio.com while our contact details are there in the show. We're very easy to find. Just search for Enterprise Architecture Radio anywhere, Twitter, LinkedIn, Facebook, Instagram, YouTube, even Discord. Once again, I hope you had fun and I'll see you in the next one.