# Enterprise Architecture Fundamentals Bootcamp: What Enterprise Architects Actually Do

## Метаданные

- **Канал:** Go Cloud Architects
- **YouTube:** https://www.youtube.com/watch?v=NVya6mYIpw0
- **Дата:** 07.05.2026
- **Длительность:** 3:24:56
- **Просмотры:** 1,260

## Описание

Enterprise architecture fundamentals are essential for anyone who wants to become an enterprise architect, understand the enterprise architect role, or learn how enterprise architecture connects business strategy to technology execution.

Pre-Order the free Enterprise Architecture Fundamentals Study Guide, https://bit.ly/4wcn1Dc

In this 12 hour Enterprise Architecture Fundamentals Bootcamp from Go Cloud Architects and Go Cloud Careers, Mike Gibbs explains what enterprise architecture is, what enterprise architecture is not, and why enterprise architects are critical to business transformation, technology strategy, governance, risk reduction, cost control, and organizational agility.

This enterprise architect training is designed anyone pursuing an enterprise architect job. You will learn how enterprise architects align business strategy, applications, data, technology, operating models, business capabilities, roadmaps, standards, and governance across the enterprise.

This enterprise architect course also explains the difference between enterprise architecture, solution architecture, domain architecture, cloud architecture, and engineering. You will learn why enterprise architecture is not just diagramming, not ticket taking, not approval stamping, and not cloud engineering with more meetings.

We also discuss enterprise architecture frameworks, enterprise architecture TOGAF concepts, architecture governance, business capability mapping, current state architecture, target state architecture, transition states, reference architectures, stakeholder alignment, and executive communication.

If you have searched for what is enterprise architecture, what does an enterprise architect do, enterprise architect training, enterprise architecture framework, enterprise architect role, or enterprise architecture fundamentals, this bootcamp will help you understand how real enterprise architects think, lead, communicate, and create business value.

Join our free live architecture webinars where we teach you:
• What architects really do
• The skills needed to get hired
• How to position yourself for executive-level roles
• How to stand out in competitive interviews

Register here, https://bit.ly/3Sw9iDW

-----

FREE Career Resources for you! 

ebook Certification Guide for Architect Careers, https://bit.ly/46HyZcZ

ebook How to Get Your First Architect Job Guide, http://bit.ly/41rixJl

ebook GEN AI Architect Career Guide here, https://bit.ly/4aOp9Zf

ebook How to Land Your First Tech Job, https://bit.ly/3OXWSH2

ebook Winning the Interview Guide get yours today, https://bit.ly/46FkiqQ

ebook Why Tech Skills Aren’t Enough, https://bit.ly/4b5P79t

-----

FREE Training Resources for you!

AWS Solutions Architect Associate Course, https://bit.ly/41TQKE8

AWS Advanced Networking Course, https://youtu.be/HvH181B4BSQ?si=5Us8zx54Mh9uROj3

Azure Solution Architect Expert Course, https://bit.ly/3C1heZP

GCP Professional Cloud Architect Course, https://bit.ly/4rCwmRW

CCNA (Cisco Certified Network Associate) Course, https://bit.ly/41U2HcU

BGP Workshop, https://bit.ly/4a0hXqN

Subnetting Workshop, https://bit.ly/3W0dajc

CCSP (Certified Cloud Security Professional) Course, https://bit.ly/3BC6qBu

CISM (Certified Information Security Manager) Course, https://bit.ly/4k34anM

CCSK (Certificate of Cloud Security Knowledge) Course, https://bit.ly/4m3m62N

-----

Mike's LinkedIn Page: 
https://www.linkedin.com/in/michael-gibbs-75820a/

Go Cloud's LinkedIn page: 
https://www.linkedin.com/company/go-could-architects 

0:00:00 -  Introduction
0:04:55 -  Welcome to Bootcamp 
0:09:17 -  Introduction to Enterprise Architecture 
0:12:23 -  Purpose of Enterprise Architecture 
0:18:27 -  Definition of Enterprise Architecture 
0:19:50 -  Business Architectrue 
0:23:22 -  Application Architecture 
0:26:13 -  Data Architecture 
0:30:02 -  Technology Architecture 
0:31:26 -  Horizontal Architecture 
0:33:10 -  Q&A 
0:38:44 -  Enterprise Architecture Operations 
0:39:20 -  Organizational Strategy 
0:42:05 -  Mapping Strategy 
0:43:37 -  Current- vs Future State 
0:45:50 -  Enterprise Architecture Roadmaps 
0:47:26 -  Governance and Guidance 
0:48:05 -  Enterprise Architecture Artifacts 
0:57:15 -  Q&A 
1:11:52 -  Misconceptions 
1:15:24 -  Diagramming 
1:17:35 -  Architecture Communication 
1:20:50 -  Enterprise Architecture is not Ticket Approval 
1:26:15 -  Enterprise Architecture is not Engineering 
1:33:41 -  Q&A 
1:51:15 -  Enterprise Architecture vs Other Architect Roles 
1:56:57 -  Enterprise Architecture vs Project Roles 
1:58:55 -  Poor Enterprise Architecture 
2:03:45 -  Q&A 
2:10:27 -  Enterprise Architecture and Exec Value 
2:11:05 -  Enterprise Architecture vs Strategic Enablement 
2:17:37 -  Speed to Change 
2:27:45 -  Measuring Enterprise Architecture Value 
2:30:45 -  Summary 
2:31:32 -  Q&A 
2:35:00 -  Enterprise Architecture Lab 
3:17:16 -  Q&A 

#EnterpriseArchitecture #EnterpriseArchitect #EnterpriseArchitectureFundamentals

## Содержание

### [0:00](https://www.youtube.com/watch?v=NVya6mYIpw0) Introduction

Heat. My name is Richard Fur and I can say I am cloud hired — that yes Come and join and get cloud hired. I'm cloud hired. — Hey go cloud architect family. I'm cloud hired. — I'm cloud hired guys. — So I'll just say I'm cloud hired. — I'm cloud hired thanks to go cloud architects. It worked for me and now I'm cloud hired — because of Google architect program I am cloud hired. — Thank you Mike and the glowout team. Hey

### [4:55](https://www.youtube.com/watch?v=NVya6mYIpw0&t=295s) Welcome to Bootcamp

Welcome everyone. We are here for our funals mendles of enterprise architecture our four-week free boot camp on enterprise architecture. So we have a lot of fun things prepared for you. We're going to talk about enterprise architecture and we've got lots and lots of things. Before we begin, tell me where you're from. I am over here in South Florida. It is nice and warm where I'm at and I am here in Port St. Lucy, Florida. Where are you from? And in the chat box, well, let me know. I always love to know who's out there. Tell me what kind of architect you are functioning in your job, want to be long term, whether it's a cloud architect, security architect, enterprise architect. I suspect a lot of enterprise architects. So, let me know. And uh we have a lot of fun uh scheduled today. Uh for example, we're going to talk about the purpose of enterprise architecture. what enterprise architecture actually is, enterprise architecture as a business strategy. We're going to talk about the scope of our work as enterprise architects. We're going to talk about the domains of enterprise architecture today and this is the first day. Uh we're going to get into how we actually operate as uh enterprise architects. Everything we do from organizational strategy to mapping strategy to capabilities. We'll talk about enterprise architecture road mapaps today. We'll talk about the kind of enterprise architecture artifacts we create and then we'll get involved in some of the misconceptions about enterprise architecture and we'll have a lot of fun with it. And at the end of that, guess what? We're going to do an architecture lab and we're going to look at an organization start looking at the capabilities that organization needs and what we would do as enterprise architects. So, it's going to be a lot of fun. So, that's what we're going to be doing today. I absolutely love that I've seen now everyone's here, whether they're in South Carolina or Argentina or Florida or England or South Africa and many more. I love it. So, welcome everyone. Before we begin our actual architecture discussion, I wanted to let everybody know that tomorrow we're going to have a webinar on how to become an enterprise architect. And in that, we're going to have lots of fun. And then, you know, how do I recommend becoming an enterprise architect and the five steps that you should take to become an enterprise architect and the exact skills you'll need to get hired and how to get the world to see you as an architect. That's tomorrow and it's free and it's going to be live on Zoom and you can ask me any question about any kind of architecture career there. I've been an architect for about 25 years and I really want to do what I can to help you. So, hope you sign up and come tomorrow. Now, as it turned out, me and my good friend Jasser, who's a great enterprise architect, uh we're actually going to build a book to go along with this course, and we're going to release it uh at the end of this course, four weeks from now. So, if you want to sign up for the study guide, we will email it to you at the end of this. So, you can go through live, you can focus live, and then you'll have that to go over the course again and go back through your notes and help develop you as an enterprise architect. So, uh please register for that as well. my team is going to pop the link for the registration for tomorrow's webinar in the chat box as well as for the free enterprise architecture ebook will also be in the chat box. So that's the schedule for today and I promise when we wait to the end because we're going to have fun with this enterprise architecture lab. We'll start high up like we do as enterprise architects and as we work through the program we'll actually bring it down from the top to the bottom of a full architecture picture. So uh strap in have some fun. If you like our content, please hit the like button. If you're enjoying it and gaining value out of it, please hit the subscribe button as well and tell friends to join because we want to do as much as we can with this free training. Chris, why don't we get started with the free training and uh what happened is my wife went away for about a month and I was totally lost in my house. It was just me and my cat without my wife. So, I pre-recorded some of this because I know my schedule gets crazy. So, uh, some of this will be, uh, live like right now and in the end when we do the workshop and some might and some of it was me just filming it when my wife was away. Chris, roll the first, uh, part of this presentation.

### [9:17](https://www.youtube.com/watch?v=NVya6mYIpw0&t=557s) Introduction to Enterprise Architecture

What is enterprise architecture? Hi, I'm Mike Gibbs. I'm the CEO of GoCloud Careers. And I want to start with a very simple question. Why do big technology programs fail even when the technology is great? And that's because most failures are not caused by a bad technology. They're caused by a disconnect between what the business is trying to achieve and what the teams are actually building and deploying in the IT department. And if you've been around enterprise and enterprise technology long enough, I'm sure you've seen this before. Here are the three common themes that show up again and again. projects get delivered but the business outcomes are not met. So the team ships something on time and maybe even on budget but the business looks at it and says well okay but did this actually help the business? Did we move the needle? Did we reduce cost? Did we improve customer experience? Did we increase revenue? Did we reduce risk? And the honest answer in most of these cases is not really because the technology teams did what they wanted in a vacuum away from what the business actually needed. Now what's also going on is technology teams are moving fast. They're all working hard but all in their own direction. There's no coherent direction in many cases. So you'll see some teams that are very doing very well at what they do. They're shipping code for example. They're busy, but the enterprise isn't getting any benefits because it's speed on the tech without alignment to the business needs. And then what's worse in many enterprises, every new initiative spins up a slightly different technology stack. And this means we may have 50 applications doing almost the same thing without any kind of sharing of information between them. And that becomes a bigger challenge long term. It's a security challenge. It's a cost challenge. It's a scalability challenge. It's a complexity challenge. And the reality is these s these problems don't ch don't turn into symptoms for a pit. They're not bet they're not going to happen on day one. It's going to happen a while from now. So that's why we exist. We are the bridge between strategy, which is the business strategy, and execution on the technology side. And we're there to prevent that kind of chaos. So if you think about it, enterprise architecture exists to fix the disconnect between strategy and execution. Now enterprise architecture works by not creating more paperwork, not by slowing down teams, but by creating clarity, creating direction, uh having some decision making that's got some discipline in it so teams can move fast together. And that's the key, fast together, not independently going in their own direction. So in the context of that, let's make enterprise architecture really simple.

### [12:23](https://www.youtube.com/watch?v=NVya6mYIpw0&t=743s) Purpose of Enterprise Architecture

Here's the working definition of enterprise architecture I want you to remember and I'll repeat it a few times. So make sure you get it. Enterprise architecture is the discipline of aligning business strategy with execution in the enterprise. I'm going to say it again. Enterprise architecture is the discipline of aligning business strategy with execution across the enterprise. Now let's break that down into a few parts because each part of what we're doing truly matters. The first really looking at is business strategy. Where is the company trying to go? And when we say business strategy, we are trying talking about where is the company trying to go as a whole company. What markets is the company pursuing? What uh customer outcomes matter the most? What capabilities must we build into this business? What risks do we reduce? What operating model are going to be using moving forward? That's where enterprise architecture starts. Not with technology choices, not with vendor pool tools or anything like that. Because if you don't have strategic clarity first, then architecture becomes an opinion and an opinion won't scale and it won't do anything for the business. So if strategy is first, the second key component here is execution. And that's the reality of making the strategy real, getting it done. And this is where people often misunderstand enterprise architecture because execution for us enterprise architects is not the tech. Execution is everything that can deliver results from the business. So that includes the organization's people. Uh the jobs that people have, the skills that people have inside of the organization, uh the processes, how the business works, how business decisions get met, the technology, the applications, the platform and the underlying infrastructure, could be data centers, could be clouds, networking, what have you. And uh then we have to look at the data and that is how is information defined, governed, shared, categorized, what have you. And then we start looking at security and risk controls. And here is how we keep the enterprise safe while it's still moving. So if you look at enterprise architecture, it's not as theoretical. It's not as ivory tower as people think. It's about the real world. How to make that enterprise successful every day. how to help that enterprise produce better outcomes every day. So if you look at enterprise architecture, it's not a single product. It's the entire landscape across the enterprise because most organizations don't fail inside of a single project. They fail in between project. They fail at the seams of and the disconnects inside the organization. Failures occur between teams. Failures occur between systems. Failures occur between data domains. Failures occur between business units, between old and new. So enterprise architecture focuses across the entire landscape. The organization doesn't have 50 versions of the same capacity, 50 different applications doing the same thing, for example, because you see it all the time. And in enterprise architecture, we're asking questions like, are we building this capacity once or are we building it 10 times? Is our data consistent across the business? Are we standardizing in places where it's helping us? Are we allowing flexibility where it matters? And as our technology choices reinforce our operating model, are they doing so or are they fighting the operating model we're using for that organization? So, if you really think about it, the clear emphasis of what we do as enterprise architects is decision and direction, not documents. Sure, we write a lot of documents, but it's all about making the right decisions and guiding the company to the right direction. So, enterprise architecture is about decisions and direction, not just documents. And sure, architecture artifacts and documents will be helpful. Models can be helpful, diagrams can be helpful, but they're not the point. The point of enterprise architecture is making deci better decisions and a decision-making system for the entire enterprise. So enterprise architecture will enable you to make better decisions faster in a repeatable manner and at scale. And it helps you decide when to standardize or when to differentiate which platforms are strategic and how to design for reuse of various patterns. It helps you manage technical debt intentionally when we're working in enterprise architecture. And it helps us evolve our organizations from today's current state to the future state that it needs to be going from here to there without breaking the business. So I've always viewed enterprise architecture as kind of that intersection between business, technology, and change. And that's kind of where we sit in that intersection of business, technology, and change because strategy changes, markets change, customer expectations change. And that means our architecture must either adapt or our architecture becomes the thing that's slowing us down. So enterprise architecture isn't a nice to have. It's a capability that makes transformation possible. So if you really think about it, what we're really talking about here is if you remember that enterprise architecture is the discipline of aligning business strategy with execution across the enterprise. You've already got the message of this first video. Enterprise architecture is about alignment. It's about direction and it's about making decisions that prevent fragmentation across the enterprise. So the enterprise can move fast and with coherence. Now let us discuss the scope of enterprise architecture and the four domains of enterprise architecture.

### [18:27](https://www.youtube.com/watch?v=NVya6mYIpw0&t=1107s) Definition of Enterprise Architecture

So if you'll recall, we defined enterprise architecture as uh aligning an organization's business strategy with execution across the enterprise. So what does enterprise architecture actually cover? What is the scope of enterprise architecture and what are the domains? So generally speaking, when people hear architecture, they think technology diagrams, but enterprise architecture is far broader than that. And to be fair, as an enterprise architect with about a quarter century of experience, we don't draw that many technology diagrams, but we do a lot of other things and we'll talk about that throughout this course. But enterprise architecture typically looks at four lenses and I'll show you what those lenses are. They are the business side or the business architecture and we'll talk about what that defines in a minute, but this is everything related to the way the business is organized and the businesses uh systems work. We then look at the application architecture which uh probably is a lot more obvious. It's the organization's applications and I'll talk more about that next. Then we look at the organization's data and we'll talk about what's related to that and then we'll look at the infrastructure or the technology so you can see what covers that from the perspective of an enterprise architecture and our scope of work. So when we think business and that's

### [19:50](https://www.youtube.com/watch?v=NVya6mYIpw0&t=1190s) Business Architectrue

where I start the business architecture, what are we really talking about as far as the business architecture? Well, maybe we'll draw that out a little bit because most people aren't used to it. So if we consider this to be business architecture, everything in this domain, I want you to think about uh this first. So the first thing is what's the company's business model? Obviously, we have to know the company's business model because if we don't and what they do and how they do it, we're never going to be at a credit strategy to help them. Now, the next thing is how does the company create value? Now, what I mean by this is how do we go from whatever it is we start with to the final product. So, if we were going to be creating car doors, you know, we might start with raw metal and then there's a process to make a car door sell the car door. There's a process to ship the car doors. So, you know, how do they create value? They're often called value streams. We'll talk more about that. What does the company do to make money? And then we have to typically look at when we structure an enterprise from a business perspective, we need to think about what capabilities does the company need to succeed. Okay. So, what do we mean by that? So, we've got a company, they need sales reps to sell. Otherwise, there's no coming in. If it's a software company, they probably need uh developers, for example, and they need to be good at development as well as other things. So, that's what we're typically talking about when we first think about business and business architectures, the business capabilities, the things that the business needs to be able to do. For example, we've got a customer, how do we on board that new customer? We've got, if it's an insurance company that has to process a claim, how would they do it? How would they detect fraud, for example, how would the company fulfill orders? And like I mentioned, the value streams are about how we go from the trigger to actual uh outcome. So, if we had lead and we turned the lead into cash, for example, or an issue revolution and then we look at the operating model and how that company is structured. Is it centralized everything? Is it federated? Do they have shared services, various types of components and product teams? How does that company work? So the business scope of enterprise architecture is really clarifying what matters, what's critical to the business and what we have to improve to give that business a competitive advantage. So if you want a quick test, if you can't explain the business's capabilities and value streams, I promise you the technology is going to fail. And you can usually see how and why people got into these situations because if you ask the architecture team you know what are the value streams what's the business capability and they don't know now you know why they invested a lot of money and why they didn't go very far. So if you'll recall there's four domains of enterprise architecture and that means the business side which we talked about the application architecture the data architecture and the technology architecture. So we're going to go back to that next. So now what we're going to talk about is the application portfolio and the application scope that we typically think about from an enterprise architect perspective because remember we're that strategist side. We're not engineers here as enterprise architects. Big difference in what we do. So if we start thinking about the

### [23:22](https://www.youtube.com/watch?v=NVya6mYIpw0&t=1402s) Application Architecture

organization's applications, we have to think about it in a lot of different ways. So for example, you know, one of the things we might need to think about first is what are the company's major symptoms or systems I mean. So this might be one of the first places we need to figure out what are the company's major systems and then we need to figure out what do these systems and applications they have do? What do they do? Because what you'll find is a company might have some critical application. People don't know what it is and it gets displugged and all of a sudden things break. So we need to know what we're doing. And if we look at our applications and we look at the systems and applications of what they do now, we also have to think about what capabilities are these applications support. For example, if it's an e-commerce website and it's an AI recommendation engine recommending that you other things to you to buy, it's supporting a sales function. And then we typically have to think about how do these applications integrate at least from an enterprise architecture perspective. Remember, we're not engineers. Because here's what happens in enterprises. Team A buys a tool for its capability. Team B custom makes something that's almost identical. Team C extends an old platform that's doing the same thing. And now we have three ways to do the same thing. Each with different data, which means we can't really make any major benefits from the data. Each with different security patterns, concerns, and integration. And it becomes a mess. So enterprise architecture is not there to control teams. Enterprise architecture is there to make sure we can ask the right questions. Do we already have this capability somewhere else? If so, how do we maximize it instead of trying to figure out in another place? Can we reuse a platform or service that we have or do we need to build something new? If we build something new, where's it going to fit? So that way we don't have a whole lot of one-offs that add a lot of complexity. So the goal is not fewer applications just for the sake of it. The goal is a portfolio that's going to make change easier, the company more secure, the architectures easier to make them more nimble. So that's really what we're going to talk about with that. Now remember when we went back and we started into the domains of enterprise architecture or the scope, we talked about the business architecture, application architecture. Now let's discuss briefly what do we think about in terms of the data architecture and then of course we'll talk about the technology

### [26:13](https://www.youtube.com/watch?v=NVya6mYIpw0&t=1573s) Data Architecture

architecture. So what are we really looking at with data so this is uh where things often break especially as we move into AI having access to good data quality data that we can trust will be essential for everything that we do because data becomes a source of truth in our AI systems as well as every other business decision we might make. So this really matters. So enterprise architecture is going to look at several components of the data architecture. Now we will get involved in others but to summarize and make it fairly quick what's the first thing we need to look at and that's going to be the key data domains. Now what do we mean by that? So whose data is it? Is it customer data for example? Is it product data? Is it employee data? Is it financial data? So the that's the first thing is whose data is it? What kind of data or are we talking about? Then if we realize this is customer data, this is one domain for example. And uh then we realize we've got product data and employee data. Now we need to figure out who owns that data. So who's accountable for the data and the accuracy of the data? It's usually an executive. Now we also are typically very concerned about the quality of the data and the integrity and I'll explain both. So can we trust this data because it's accurate and quality data or did a hacker change it and that's where the integrity would be breached. So we're concerned uh so very can we trust the data and then the last thing we typically want to think about is the flow of the data. Now obviously we might get a little deeper in some things but what when we think about the flow of the data so where does the data originate uh how does the data move and I'm doing these live in real time for the spelling errors which I'm trying to fix as we go through and is the data duplicated or where most likely because if it's duplicated somewhere and that doesn't have the same amount of security, we'd be concerned. So, here's the thing. Many digital transformation problems are related to bad data, bad information. Not always, but a lot of things. And generally speaking, data is going to be critical. And that's why we're here because, you know, if we've got teams that are disagreeing on what a customer means, for example, what kind of fix are we even going to get? So, enterprise architecture is going to create that coherent, that shared definition of who owns what, who's accountable for what, and even how the data flows through the organization and how the data is consumed across the enterprise. So talked about the business, we talked about the application architecture, data architecture. Well, there's one more domain to enterprise architecture and that's going to be the technology architecture. So

### [30:02](https://www.youtube.com/watch?v=NVya6mYIpw0&t=1802s) Technology Architecture

you can see now that's this is where we've got all four elements of here. So now let's talk about what the technology actually is. When we refer to technology architecture, this is the platform. This is the infrastructure. This is the cloud computing that we typically think about. So the foundation for everything, the security controls that would be in there, the networking that would be there, any kind of observability platform. So this is the big scope. It could even include robotics potentially if things are there. So rel resilience, continuity, these are the kind of things that we're typically talking about. So this is where we enterprise architects establish guard rails. So teams can move quickly without reinventing the basics. Because if we have every team building their own cloud stuff, their own identity stuff, their own logging systems, we don't have innovation. We have chaos that will really slow innovation down. So this technology scope of enterprise architecture is about enabling speed safely. So we've got consistent security patterns, reliable platform foundations, repeatable reference designs for various components to redo the same thing in a similar way, the optimal way, at least as a starting point. Clare standards where standardization is going to help.

### [31:26](https://www.youtube.com/watch?v=NVya6mYIpw0&t=1886s) Horizontal Architecture

And the key is enterprise architecture really looks horizontally across the silos of things. So we're looking at the entire business across all of those domains. So we look at it this way. You typically have project teams and technology teams that go up in a vertical manner and they deliver everything with the boundary. So what does this typically look like and why is enterprise architecture so important? If we've got business doing its thing here and then we've got software developers for example making their applications here and then we've got uh security people doing their own thing. What'll happen is the security people will secure something in a manner that's going to block an application and not even know it. the application people write code that's going to damage the business. So that's the key is all these if we've got all these silos, we've got nothing. So when we're here as enterprise architects, what are we doing here? We're kind of that bridge to make sure that everybody's talking to each other. So that's what we're doing. So we should be asking, are we creating reusable patterns that are going to make us easier to do things in the future? Are our patterns consistent across the enterprise? Are we creating co coherent enterprise or a collection of dis disconnected projects? That's where things get tr troublesome. And the goal here is cons coherent consistent patterns instead of one-off solution. That's the scope of enterprise architecture. That's why we do what we do as enterprise architecture.

### [33:10](https://www.youtube.com/watch?v=NVya6mYIpw0&t=1990s) Q&A

Welcome back everyone. So if you have questions, I'd like you to bring them to me. Uh to recap, we talked about the purpose of enterprise architecture and what is enterprise architecture. We talked about enterprise architecture and business strategy. We talked about the scope of enterprise architecture and what that includes. And then we talked about the domains of enterprise architecture which are business architecture, application architecture, data architecture, and technology architecture. So when we come back, we're going to talk about how enterprise architects actually operate and we're going to talk a little bit about understanding organizational strategy and mapping strategy to business capabilities and you know planning from where we're at to where we're going to go. We'll talk a little bit about enterprise architecture road maps and some government of governance and other things as well. So we should have some fun with that. So uh if you've got any questions uh please give it to me. If you're enjoying the content, please give it a like. Uh please subscribe to our channel and hit the bell to be notified of new videos to assist you with in your architecture career. Hi Paul in Uganda. That's fantastic. Welcome from El's. Would the enterprise architect be acting in a project management capacity or work alongside a project manager? So not really. So Alice, when we look at where we're at, we have the enterprise architecture which focuses on the big picture strategy. So we're thinking the entire organization and we're building road maps for example. And actually I'm pretty sure I released a video on road maps uh fairly recently that talked about, you know, a road map versus a uh versus an actual project plan. A road map is what we're going to do very high level and a project plan is all the steps. Now, as enterprise architects, I'm not very close to a project manager. As a platform architect, like a cloud architect where we're planning a threecloud migration, I'm working much closer with the project manager. Now, if I'm working down at the solutions architect level where they're typically focused on one project, that solutions architect is going to work very closely with the actual project managers if they're associated with delivery instead of pre-sales. But not for us. Our work L's is going to be much more meeting with stakeholders, managing stakeholder expectations, communicating with the seauite, influencing the seauite, guiding the company into say more strategic decisions. So that's much more of our work. um more mediating between things but some project management skills are always good because you know we may have to approach an architecture in phases and what I mean by that uh we may have to have an architecture and we may have to look at the network key business processes along the way we may have to reoptimize the business architecture and how people may do their job we might be looking at the cloud we might looking at the private cloud we might be looking at security we might be looking at data and any other things. So we're going to be managing our architecture team and we might want to pro project manage that team say network architects I need your information by this date and this time platform architects from security I need your information. So in that way maybe but not generally we're really not a project manager go uh kind of environment are the four pillars aligned to frameworks such as TOGAF? Well, not really. This is the four pillars of any enterprise architecture. The business structure and how the business operates, the applications the organization has, how those applications support the business. And we'll talk more about that. Uh how data flows through the business, who owns data that flows through that. And of course, the technology infrastructure, which is your private clouds, your public clouds, your AI, your robotics, and any other technology you use to support the business. So, TOGAF does list those four elements of enterprise architecture in their framework, but then again, so does every other enterprise architect. So, we're going to talk more about enterprise architecture frameworks, but really they're more of a structured way of doing something. And what I mean by a structured way of doing something is using the same number of steps each time, using the common vocabulary so you don't have confusion, errors, and those types of things. So that's more of what TOGAF is, but we're going to talk about TOGAF on the second day. We're going to get involved in lots of TOGAF ADM work as well. So we will get to that and I'm glad you asked the question. Are there any other questions there for me in the back end? So maybe give me a hashtag enterprise architecture or enterprise architecture is fun and uh then we'll get back to the content. But do remember tomorrow we're going to have a really fun webinar on how to become an enterprise architect and that's going to be completely free live on Zoom. So if you don't have a chance to ask me a full career question here, you can on that. So please register and uh my good friend Jasser and I Jer is a great enterprise architect. We're going to be releasing a book on enterprise architecture at the end of the session for all of you. It'll be based on this content loosely and have some more things in it. So you can sign up and register for it and it'll be emailed to you in the end of the sessions and it's all free. All right, we're I don't see any other questions coming in. So, we're going to go back to the content now.

### [38:44](https://www.youtube.com/watch?v=NVya6mYIpw0&t=2324s) Enterprise Architecture Operations

Now, we're going to discuss uh how we do what we do as enterprise architects almost an operating model of enterprise architects if you will. Now, that will be different than enterprise architecture operating models which we'll talk about later. So I want you to think about this that enterprise architecture is not a one-time architecture phase. It's an operating model a repeatable loop of what we do. Now depending upon the framework you use there may be more steps or less but the steps really boil down to the following things.

### [39:20](https://www.youtube.com/watch?v=NVya6mYIpw0&t=2360s) Organizational Strategy

things. The first component of what we actually have to do in any enterprise architecture project is this. We have to understand what leadership is looking for. What are we trying to do? So what that means is in many cases we need to understand the organization's interest right here because we can't design something with for a target we don't understand. So when we start here what are we really talking about? We're talking about strategic goals. We're looking for something called objectives and object. What were our objectives and how do we succeed? So, we're going to be looking for metrics of success. You often hear them called OKRs. We're going to be looking at market pressures and market forces. For example, uh if interest rates are high, it'll make it harder for a home builder to sell houses. So, what might we do to help that home builder sell houses? We're looking here at the top at this at the competitive realities of the organizations. What is their true state in the business and their market positioning? We're going to be looking at regulatory drivers because for example, a law may change and that may actually change what the business needs to do. We're going to be looking at the organization's risk and risk posture and risk tolerance and what they're doing to manage risk. Now, this step is absolutely critical because when we know this, when we've gotten that from the organization's key executives, here's what we now can start thinking about. What is our target? What are we optimizing for? Is it faster speed to market? Is it reduced cost? Is it an enhanced reliability of our systems? Do we need to comply with some new rule or regulation? Are we trying to give our customers a better experience on our systems? And we need to know this because every architecture choice we face will have a trade-off. And we can't manage which trade-offs we choose without clarity on the priorities. So, I'm going to make it very clear. There's no perfect anything. There's no perfect medication in the world for the physicians to prescribe. That's why they have to consider you and your conditions, whatever. That's why they can't make black recommendations. Everybody should take this. And it's the same thing for us. We may take one security choice and it may make us more secure, but it may stop this, and this that we're looking for. We may choose another security product and it may have these great things, but it's weak at this. So, it's all about trade-offs. And we can only consider trade-offs when we know the strategic target.

### [42:05](https://www.youtube.com/watch?v=NVya6mYIpw0&t=2525s) Mapping Strategy

target. So then what we need to do is we need the second step once we know the goal is we need to start mapping strategy to business capabilities. And this is where enterprise architecture is going to translate the strategy that we talked about before into what the business may able to do well. So we're trying to increase revenue then we need to enhance the sales process or what the sales rep or somehow generate more revenue. So we ask the following questions. Which capabilities from the business are weak or missing? If we've got weak sales, that company's not going to survive. We've got to fix that sales capability. For example, we have to look at what this business could do that's critical for differentiation. We should look at which things are commodity things and which things could be standardized because this stops people from looking at the shiny object system app first. Let's look at the app and figure out how we're going to shove it in our enterprise. No, no. That's not enterprise architecture. Instead, we need a new system. And the conversation becomes instead of that need we need a new system. It becomes what do we need to do? We need to improve our onboarding. Okay, now we know where to look. We need faster fulfillment. Okay, now we know what we need to do. We can figure out the technology supported. We need better fraud direction. Okay, we know the problem. Now we know how to solve it. We need stronger identity cards. That's the starting point. Now we're going to start a new tech project. And the last thing we do is define

### [43:37](https://www.youtube.com/watch?v=NVya6mYIpw0&t=2617s) Current- vs Future State

target architectures. So the target architecture of whatever that is whether it's a business architecture, application architecture or data architecture is what it will be in the future. So let me just do a quick whiteboard thing and I'll talk about this a little more in a second. So when we find a company and we'll obviously talk much more about this as we get through this discussion but or and training program boot camp or but what you can see here is we have the current asis. This is what it looks like right now. This is if you went in there you brought a team of engineers and you mapped out everything inside of the business or whatever or you the enterprise architect for the business mapped out the business architecture. This is what we have now. Here's where we're at. And then we ultimately have to figure out a plan to get to that future state. We'll call that future state 2B. And many enterprise architects consider this the ASIS architecture or the 2B or the Karen state architecture and the future state. But whatever that is. And we'll have to do this process for the business architecture, the application architecture, the data architecture, and the technology architecture. But we're here's our starting point and here's our target. And ultimately, in some way, shape, or form, what we'll have to do is create a gap analysis that says, how do we go from what we have to what we need for what's missing? And then we'll build a plan around it. But for now, let's keep talking about what we're doing as we do it. So, we're not looking for every detail. What we're looking is to gain clarity. What does the future state need to be? What are the patterns that we need to have at this point? It's just patterns. Uh what platforms are going to be strategic for us? What kind of integration should we use on a standard basis? How will the data be owned and shared? What kind of security baselines and security levels do we need for our system? So the target architecture is basically this is what looks really good for us in the future. That's what you can think about it. So

### [45:50](https://www.youtube.com/watch?v=NVya6mYIpw0&t=2750s) Enterprise Architecture Roadmaps

step four of what we typically do is really uh defining a road map. So remember and I said and I'll show you again. We've got our current state and we have to go to a future state. Well, in many cases that's going to require a plan. But maybe we're just doing something completely different. And the real work of the architect is developing the plan to go from here to here first to figure out what we need to do and then help build that plan to get there. So that's really where we're going to be going is now that we have the target state, we need a road map. What do we do now? Maybe we need to make some changes right now. Maybe there's a second step that we need to do along the way. Maybe there's a third step. So for example, if an organization wanted to do super highdefinition video across the offices in a private matter, the first thing they might need to do is upgrade their network. Then they might need to uh and put on quality of service and a few things on their network. Then they might need cameras. Then they might need vine coders depending upon the quality that they were looking to do. But you know that's the kind of thing that we're actually talking about. First, second, third. And uh those kind of transition states are going to be very important because in many cases we can't just go from one to the other. They call that a big bang change generally speaking. We have to take steps or incremental changes along the way. So a good enterprise architecture roadmap will connect that strategy to execution in a fundable uh staged and measurable way. And then of

### [47:26](https://www.youtube.com/watch?v=NVya6mYIpw0&t=2846s) Governance and Guidance

course we've got to govern and guide. And this is where enterprise architecture has to get fairly practical. It's about providing guard rails and helping delivery teams succeed. And enterprise architecture supports these projects by aligning decisions with the road map, identifying any kind of conflicts early. We typically tend to recommend fairly reusable patterns and we typically update the architecture as reality changes. New things change, architecture needs to change because the architecture needs to support the business in a constantly dynamic everchanging world. So enterprise architecture is a living function.

### [48:05](https://www.youtube.com/watch?v=NVya6mYIpw0&t=2885s) Enterprise Architecture Artifacts

function. So let's briefly discuss enterprise architecture artifacts that's going to support the workflow and what we do as enterprise architects. So I'll give you some common artifacts and obviously there's more that we will create. But I want you to see when I go through this how these artifacts that we create as enterprise architectures actually support decision making and execution. So for example, if we look at a business capability map. So let's say we're building, we're mapping out the business architecture, which we will be doing. So if we look at the business architecture, there's certain things we'll look at. For example, we'll look at uh the org chart. We'll talk more about these things later in another video that's part of this uh discussion. We'll look at the org chart. We'll look at key business processes, which is how people do their jobs because we we've got to find technology and ways for people to do things better. We might look at value streams, which is uh which we talked about a little earlier. And we're almost always building a capability map. Now, why are we mapping out the organization's capabilities and as enterprise architects? Well, if we know what capability we're trying to help, if we're trying to inhound sales, for example, we know where our architecture and our money needs to go. So, what we're ultimately doing is getting that business based upon whatever the business needs to do better. So, we're starting at uh I need to uh run across the ocean and then we're building a training plan for figuring out how that would be possible, even though I don't think it's possible, but you get the point. So next the next thing that we typically do is a lot of target state diagrams and the target state is where we're going. So if you look at any kind of architecture including a bis a traditional architecture if we had someone that decides to build a hotel they're going to have diagrams and blueprints of that hotel. They might even have a little model that they could show someone from the sales perspective of what the hotel would be. That's the target straight diagram, their model. And of course, we do that same thing as enterprise architects. Now, realistically speaking, we create a lot of standards and reference architecture. Standards are certain ways to do things. And reference architectures are for example, what should your demilitarize zone look like for say a web application? What would your demilitarize zone for extranet capabilities look like? What would your IM strategy look like? What's your zero trust posture across? So standards and repeatable patterns that you'll use again and again. Now they may be tuned a little bit, but if we've got a starting point and everybody starts at the same starting point, it speeds it up as opposed to everybody doing their own kind of thing. So I hope that kind of makes sense as to why we typically need to look at some create a lot of road maps and transition states. So how do we go from here to there? Well, usually if I wanted to leave my house in Port St. Lucy, Florida, and visit my family in say Nepadamos, Greece. What I can tell you is this. I can't just disappear from my Port St. Lucy house and go to Greece. I'd have to go say to the West Palm Beach airport and from there I'd have to fly to the Atlanta airport and from there I could typically go to London and from London I could go to Greece. And that's no different than with architectures. We need to build a road map of all the steps that need to occur. So if enterprise architecture and an enterprise architecture practice is healthy, we're not creating bureaucracy with these artifacts, we're accelerating things. We're reducing any kind of fragmentation that it would take across the enterprise and shorten the time that it'll take to make good choices. So enterprise architecture is not a documentation function. Enterprise architecture is really a decision function. You know, it's often funny. People think enterprise architects are documenters and it's a documentation function. And to be fair, as enterprise architects, we do write a lot of documents. But enterprise architecture is the decision function, not a documentation function. And the real job of an enterprise architect is to help leadership make informed and consistent decisions that will yield the best results for the organization. So, we're not making recommendations in isolation. We're not giving uh what we're doing is we're giving an opinion. We're discussing the various trade-offs and the consequences to that enterprise to act or not act for that matter because without enterprise architecture and you can see this in organizations that don't have a great enterprise architecture practice and an architecture pract practice every project makes a locally rational choice. So the security person may pick what they think is the best firewall but not realize that firewall may have an impact on other components of the business or they may pick their favorite uh IM product but not realize how that may affect other parts of the business. So what we need is decisions based upon capabilities and that's why we have enterprise architecture because we need a landscape that's agile not one where the teams decided to build what they built without understanding the greater trade-off for the organization. So what kind of decisions do we support as enterprise architects? Well for example one might be which platforms do we standardize on? So instead of uh spreading ourselves too many too thin across many tools, too many patterns and ways of doing the same thing which costs us more and typically opens us up to more security problems and adds complexity. We need to figure out how to simplify. We enterprise architects often make the build versus buy versus reuse type of recommendations or decisions. So, should we build the custom capability for that business because they need it and there's no available commercial off-the-shelf product that could do it? Do we buy a product or do we reuse what we have? So, if you think of enterprise architecture in context, it's bringing in integration, data, security, life cycle management, total cost, not just feature checklist. So it's much higher level than other more focused roles like a solutions architect for example because this is the entire enterprise. So we realize that all organizations have constraints. Constraints on money, constraints on people, constraints on everything. So what we're doing as enterprise architects is we're helping the organization re know where to spend their limited time and limited money on what's going to give them the best results for where they're going. So enterprise architecture provides tradeoffs not just answers. I made this decision because of this this. We would have chosen this but this had a deficiency which would have affected this component of business. We may have chosen that pattern which is a great pattern which would be good at this and this but it's going to be weak here. So that way we're giving the decision makers the information as to how and why we made our recommendations because remember we're consultants. We're always consultants in any kind of architecture role but especially enterprise architecture. So good enterprise architecture doesn't say no just no. Can we do this? No. What we say look here's three viable options. Here's the cost. Here's the risk. Here's the impact of us doing this on speed. and this is how each option will affect our future flexibility. That's decision support. And you're basically saying even if you say this is generally not recommended because of this, but here's your options here, and here, and I want you to know how I got to the decision that I think is probably risky, but we could still do it these three ways. Now, you're giving that CEO or the CIO or the board the decision to make an informed decision about the key things that they would care about. So here's some the line I kind of want you to remember. Here's the way I want you to think about it. If you're going to think about it in one sentence, if enterprise architecture is not improving the quality and speed of the decisions, it's just creating documents. So again, if enterprise architecture is not helping the quality, the speed of decisions inside of the organization and it's only creating documents, that is not enterprise architecture. And that's the litmus test between a real enterprise architecture practice and a non-real enterprise architecture practice. So when enterprise architecture is well done, it doesn't slow delivery down. It helps it go faster with fewer surprises because the enterprise is making consistent choices. And from here the conversation more becomes what does good enterprise architecture functions look like in your organization? And that means skills, roles, governance, and how it even partners with product.

### [57:15](https://www.youtube.com/watch?v=NVya6mYIpw0&t=3435s) Q&A

All right. Well, we're going to take a short break to see if anybody has some questions and we're going to answer those questions and then we're going to come back continue the content. But we saw a few questions were there. So, if you've got any questions about enterprise architecture, bring it. Uh again, today I'm going to answer any of the questions that you bring. But if they're deeper questions, tomorrow we're going to have a how to become an enterprise architect webinar and it'll be on Zoom. So if you got any career questions, please feel free to ask me on that. So uh by all means, uh Chris, bring in some questions, uh from the audience. So the first question is I struggle to convince sales to follow architectural principles as I alluded to be enterprise architects could be seen as blockers. It's possible but inevitably trying to do things quickly will always fail. How do we change their point of view? So the question we have is do we need to change your point of view or their point of view? And I'll tell you exactly what I mean. So the biggest problem most architects have especially new enterprise architects is it depends where we come from. So 50% of the enterprise architects come from a technology background and the other business background. I come from an internal medicine background. But in either case, you know, we both come from both sides of the world. So when we're dealing with sales, sales is paid to sell stuff. They need to be able to sell stuff fast because that's what their job is. They're paid on it. Their commissions are forward. If that sales rep doesn't sell, they get fired. sells a lot, they make an incredible amount of money. So, that is their initiative. Now, we can create our architectures in two ways. We can create architectures that speed things up. For example, in cloud computing, the cloud architects will create a landing zone that'll make it much more easy to have a lot of things preset up architecturally and uh still adhere to the organization security needs or whatever their architecture needs are. As enterprise architects, we can make up reference architecture patterns. Here is the architecture pattern we're going to use for our generative AI architectures. a demilitarized zone for an extranet provider. And when we architects actually create good architecture patterns, that speeds things up. So the reason I have to say is that our thinking or their thinking is it's a combination of both. We need those sales reps to see what's in it for them to have a better product that's more architecturally sound in terms of repeat business, in terms of being able to sell it and getting less push back. So as the architect we need to help that and we need to directly talk about how our architectures or whatever we do as an architect will impact the sales rep, impact the sales team and impact the organization sales. If we're not doing that, they're going to see us as a blocker. So what that really means as an enterprise architect is we're going to be speaking to sales organizations. We're going to speak to marketing product organizations. And they all have conflicting things because the people that produce the product in an organization are really concerned that it's going to be solid, everything is used exactly correctly, and that it's mature before it's released. The salespeople, by comparison, have to sell something because they need to do their job. Now that puts them in conflict. So as we talk about through this, we'll talk much more about managing stakeholders along the way because the key is to really find the stakeholders, find what the stakeholders need and be able to serve them. And by doing so, it'll be a lot. This involves a lot of organizational politics, a lot of executive work. You'll be there. So I'd like you to frame everything you have in terms of dollars or risk. Those sales reps will be all over it and they'll be very happy to listen to what you have to say. Great, great question. We'll talk more about that as we go through this uh four-week uh session. You're getting confused about the border between IT strategy and poor business strategy that an enterprise architect needs to know and to what extent. And can I clarify with examples? Absolutely. So where this is coming from most likely is there are really three kinds of architects and each one of us as an architect has three very distinct functions. So if we look at enterprise architecture, what are we really dealing with? We're dealing with the three main elements of the business. who we hire, the kind of people we hire, how people do their jobs, the way the organization does things, and of course the technology. So if we're a real enterprise architect, only one-third of our role is technology. The rest of this is how the organization operates. So an enterprise architect is going to be a senior business executive. Now there are various levels of enterprise architects for example and of other architects in your architectural realm. And what I mean by that is uh if we look at the architecture continuum at the entry level role we typically have our solutions architects and then platform architects like a cloud architect a security architect or an AI architect. You don't necessarily have to follow this order, but here you're focusing on one workload, right? all the organizations clouds as a cloud architect or a security architect is focused on the security strategy to protect the organization's asset organization's assets as people. We move up one level, we get into the first level of enterprise architect. And as we move up, we get into chief architect roles, which are also architect roles. But when we get to this level, we're talking about extraordinarily highpaying director and VP level roles. And the enterprise architects at this level are pure executives, almost no technology knowledge. The executives at the enterprise architect level are 85 to 90% business executives and 10 to 15% technology professionals. So enterprise architecture is all about the business. Where is the business trying to go? What is the business's challenges? What's for example, did the interest rates go up? Did a regulation change? Do we have a new entrance of competitors? Is there a disruptive technology that enabled a competitor to be stronger for us? That's not most of our work is at that level. Looking at that business, looking where it's trying to be, working across every element of that business to figure out what they need, and then creating an architecture team. Now that architecture team will have specialists so they can dive deeper into much more of the IT strategy where they are for the enterprise strategy. How do we architect the enterprise? And that means playing with the levers of people, making sure we have the right people, they have the right skills, processes, how people do their jobs, find a most efficient way to do it. And then all the technologies that support that business, which could be including robotics, it can include AI, it can include your cloud providers, your networking, your security, your data center. So it enterprise architecture is highly strategic. platform architect levels in the mid are mostly strategic and the solutions architect levels tend to be more tactical and that's where that confusion comes in. This is a pretty strategic highle business role. It's a role to help businesses make decisions executive make better decisions. What investments do they fund? Great questions. Bring in the next question. How are enterprise architectural principles applied to small medium businesses and startups? Generally speaking, they're not. You don't hire an enterprise architect and pay them, you know, a couple hundred,000 a year to look at a small business that has five people. But how could enter small businesses really benefit from great enterprise architecture practices? So if you look out there right now, you're going to see about a million and one new AI startups. Now most of these startups have a solution to a problem that doesn't exist. And that what happened is we had a bunch of smart people. They were probably great engineers, great software developers that didn't really understand the business challenges that exist. And they went out there and started up a business, created some kind of application that the business world doesn't need. Now these may have been the smartest people in the world. I mean incredibly smart people that designed this. But why do they design what they did? In many of these cases, these applications and businesses are designed that way because the people that are designing them don't know what the actual end client needs. So if we really look at how would you start a business or what is an enterprise architect actually do, the first thing we try to do in enterprise architecture is determine where we're going. Then we determine how our business should operate. Now how it should operate includes what kind of people, how people actually do their job and they figure out their entire business. Then after business and only they figure out whatever capabilities their business needs, then they start looking at the data application technology architecture they need. And at that point, those technology strategies, those architectures are going to support the business needs and the company's going to get great results. And that's really the benefit of enterprise architecture. Here's what exists without enterprise architecture. And you'll see it in many organizations. Imagine you were going to take a trip. Now, you didn't know if it was going to be Antarctica or Aruba. and uh somebody else was going to pack your suitcase and they had no idea where you were going to go. Now, I've been to Aruba. It's like 95° every day, 37° C somewhere in there. And in there, I want my bathing suit and my flip-flops. Now, if you're going to Antarctica, you want a lot of winter clothes because you're going to freeze real fast. Now, if somebody thought you were going to Aruba and packed your bag for Antarctica, you're going to overheat. And if somebody thought you were going to Aruba and add on Anarcha, you're going to freeze. And that's really what happens is that disconnect between the business and the technology teams. That's why we enterprise architects exist. So a good enterprise architect can consult to a small business in terms of how do they design their business? How should they operate the business? Because that's what we really are. We're really management and strategy consultants just like anybody in a business architect role with technology as well. Great questions. Why is the chief not executive officer not at the chamom diagram? They are. So if you actually looked in the diagram that I actually created, if you look very carefully, what they do is they go architect architect seuite position. And normally what I would show if I was going to show this to other people is we'd have the CIO over here. We'd have the CFO a COO over here. And at the top we would have the CEO uh on top of all these. And what you could also see in some organizations is they might actually move a CISO at the same level as the CIO. But this is typical. But I was really trying to show you the architectural the scope of the architectural realm where they have the beginner architects as the solutions architects then the platform architects then the enterprise architects then the chief architects then the seuite and then the extreme seuite. But good point. I probably should have showed that. Jasser, why do studies show from major firms report that about 80% of digital transformations and technology programs fail to meet their objectives? Well, great question, Jaser. So, here's the thing. Did you know that it was surveyed uh they surveyed businesses right now and all businesses are spending a fortune on AI? And they asked the businesses they said how many of you are making the attempt a strong strategic attempt to really look at your critical business needs and business capabilities and map that to your AI architectures and you know what came in the number actually was it was 14%. So with 14% of the people mapping their technology their needs I expect maybe 13% of them to be successful because that's what it takes to be successful. Now of the other 80% maybe I expect five to 10 percent of them to be accidentally lucky and get it right. So that's about 80%. What happens if your architects focus on tech and not transformation? They design technology systems that provide no business value. And the key is we need every level of architect. engineer. We need those enterprise architects like me that are focused on business strategy and you Jaser to make the business more effective. We need those platform architects that are going to be so focused on cloud or security or AI to make sure those organizational needs are there. And we even need those solutions architects to focus on that end product at a higher level of detail. Now there are organizations they try to have an enterprise architect do a platform architect work. That's usually a problem. So uh because you can't do two jobs at the same time. So that's generally what we're actually referring to. Any others? All right. So, you know, we have a lot more fun stuff. We're going to start talking about more concepts in enterprise architecture. So, give me a hashtag architecture or enterprise architecture. Uh, please save up your questions and ask them. We really want to help you. And, uh, maybe give us a like. uh subscribe to our channel and hit the bell to be notified of new videos and tell a friend. And Chris, let's get back to the content.

### [1:11:52](https://www.youtube.com/watch?v=NVya6mYIpw0&t=4312s) Misconceptions

Let's talk about what enterprise architecture is not. So if we work on the working definition that enterprise architecture is about aligning business strategy and execution across the enterprise, I want to talk about something equally important because so many enterprise architecture programs aren't really enterprise architecture at all. So let's talk about what enterprise architecture is not because there's just far too much ambiguity in the world of architecture or enterprise architecture. And if you want enterprise architecture to be taken seriously inside of your organization, people need to know what to expect and what not to expect. So that's why we have to define what enterprise architecture is not. And if we walk into a company and they say we have enterprise architects, but nobody really knows what they do, that's a problem. Sometimes it's even worse. And I just hear enterprise architects just slow things down. That is not enterprise architecture at all. Now, I want to be fair here. Most architects that I know are smart, committed, and trying to help. But the problem is not usually the people. It's the definition of enterprise architecture that's unclear in the organization. If people don't know what enterprise architecture is or is not, it won't gain the respect that it needs, and you may not be able to do what you need to be effective in the role. That's why you need to fill in the blanks because if you get the wrong expectation, business leaders will think that enterprise architecture is there to build the master plan. If delivery teams think enterprise architecture is there to improve their decisions, you know, that's going to be another set of things and executives think that enterprise architecture there is there to miraculously standardize everything overnight. If people have those kind of wrong expectations, nothing is going to be effective. And that's why we have to come up with realistic and healthy expectations. And uh for example, here's another perspective where people get lost into what we do. While we architects do get pulled into working by making slides and making graphics, our job that's not the main component of our job. And here's failed enterprise architecture slides for example. So, if we make slides that look pretty, but they don't drive decisions and don't get the executives on board, they're not effective enterprise architecture slides. If we just create a rule and enforce a rule, but there's no context around the rule, there's no enterprise architecture there. If we're going to be asked to solve a problem that's too late to be able to influence the outcome, that's ineffective enterprise architecture. So that point business and technology teams will not have the right respect or credibility that enterprise architecture needs to be functional. So if the business says enterprise architecture is theoretical and the technology teams think that enterprise architecture is a bureaucracy then enterprise architecture becomes a checkbox instead of a business capability and a strategic business capability. So, we need to be real clear about what we do because the fastest way to make enterprise architecture valuable to the organization is to stop doing things that make people roll their eyes and to start doing things that make a big impact in the organization.

### [1:15:24](https://www.youtube.com/watch?v=NVya6mYIpw0&t=4524s) Diagramming

Enterprise architecture is not diagramming and I alluded to that earlier but uh this is absolutely critical. A diagram is a tool. It is not the job of the enterprise architect. A diagram is simply a way to communicate. Now, drawing a diagram does not automatically create alignment between the business and uh strategy in execution. Doesn't do that at all. Uh a di a diagram is not proof of a good decision and it's not going to prove business value. So, the key here is a document or a diagram is a tool to help communicate And we can use perfect notation, perfect documentation, whether it's in UL or Arcomate or whatever your favorite diagramming tool is, and still be building the wrong thing. And that's the biggest pitfall that I've seen. Sometimes architects hide behind tools instead of having the difficult conversation. So an architect that we want an architect that's going to model things closely and properly and then be able to u be able to bring it to the seauite. We're not looking for someone who's hiding behind the tools that's doing endless models and polishing the visuals to make them so beautiful. Uh they debate notation of the way you're going to diagram things. They create what you almost call architecture theater. uh but they avoid the real core work of uh clarifying the strategic intent, resolving tradeoffs, creating shared direction for the organization, influencing decisions early. And if the architecture can't be explained in plain business language, it won't be adopted because the seauite doesn't fund fancy diagrams. They fund uh understanding what uh they fund business and investment in the business. So that's the key. So if the ar if you got us an architecture that's for security and the organization needs that security but you can't influence the seauite that company may be hacked. So that's why this is so important. So

### [1:17:35](https://www.youtube.com/watch?v=NVya6mYIpw0&t=4655s) Architecture Communication

let's talk about what healthy behavior looks like for an enterprise architect. Uh or an enterprise architect will still use diagrams but we're doing it to help make decisions and direction more understandable. So, we're using diagrams to help communicate. It's just another form of communication, not to show off complexity to assist in communication. We want to use simple before and after views to tell a story. Here's what it looks like now. Here's where we're going and what you'll get by what you'll have in the future. And we want to use plain language that's going to say this picture, this new website thingy that we're talking about should increase sales by this percentage based upon what other organizations have gleaned from a similar project. Something like that. So you know something that the executive knows exactly what they're going to get there because the diagram is not going to change if a diagram doesn't change direction of the organization. If your communication doesn't change the the way the organization does things, it's not being communicated properly because a good enterprise architecture diagram or discussion for that matter will help the organization know why are we standardizing and what are we standardizing? What platforms are strategic to us moving forward? Which ones do we get rid of? How does this thing that we're going to do, this project either reduce duplication or reduce cost potentially speaking? How does this new project improve time to market or reliability of our system? So the sequence of now, next, and later because things that we're going to be talking about are going to be for the future of the organization. And a good storytelling example will help you stand out very much as an enterprise architect. And it can be fairly simple. before we have five different customer systems, three identity patterns and data copied everywhere. The future state uh we'll have one identity pattern that'll be shared. We'll have a customer master approach and we'll have reusable integration services and then I will say something like this is going to reduce time improve our security in a consistent manner. This will lower our integration costs and it will make it easier for us to acquire new companies. Now that's using the architecture artifact to and the architecture what it's going to do for the organization and communicating it in business terms. Now that's not here's the complex diagram and here's the story how we go from fragmentation to coherence. We need something more substantial like we're describing now. So that's what I need you to think. If you look at an architecture diagram and say wow that's impressive. Look how complicated. It's probably not the right architecture diagram and it's probably not going to change anything inside that organization. So I'll say it again, enterprise architecture is not about diagramming. Diagrams are tools. They help the enterprise architect do their job better just like any other tool, but it's not the job of an enterprise architect. We previously discussed how

### [1:20:50](https://www.youtube.com/watch?v=NVya6mYIpw0&t=4850s) Enterprise Architecture is not Ticket Approval

enterprise architecture was not uh diagramming. Well, now we're going to say that enterprise architecture is not ticket taking or approval stamping either. And what I mean by this, it's not where we just stamp or approve things along the way. That's more of what I like to call an architecture police model. We've got someone that says yes, you're allowed to do this. This is or no, you're not. That's not what we're talking about here. We're here to basically create a strategy. The architecture police is what you call an architecture antiattern or something which you don't want to do. So here's how that architecture antiattern works when you've got a ticket giving or a stampling thing. Somewhere along the line, you've got your enterprise architects in a central group and the basically the people uh create a ticket and then uh they say something like please approve this design and enterprise architecture reviews that after any decisions are made and then enterprise architecture says either yes or no and they say no a whole lot of time or ask for changes so far disconnected reality. the delivery teams resent it and leaders wonder why things are slowing down in that environment and that's an architecture antiattern for enterprise architects of what not to do. Enterprise architecture becomes a bottleneck. No, that's not going to work. It's not going to build trust. It's going to add delay in the system and that's not going to be good either. So because if enterprise architecture is reacting to tickets, they're not functioning as strategic drivers. They're often not going to be able to focus on constraints, the trade-offs that the teams may have made already. They're typically going to be too far away from delivering realities. So guidance will become so generic to the point that it's almost useless. So that's why it'll create this kind of resentment from the delivery team. You didn't help us in any way and you bogged us down. So this is not what we want. Now let's talk about a great healthy enterprise architecture model. So in a real great enterprise architecture model, enterprise architects are partners. They're strategists and we get involved early and we're embedded into the entire process and that's what good enterprise architecture looks like. So we're going to engage early long before a project is ever locked in. And we're going to show up in strategy and planning cycles, discovery workshops, product and portfolio conversations, uh capabilities discussions, and even sequencing and roadmap decisions. In other words, we need to be in the room anytime the strategy or the direction is shaped, not when designs are there. And that's why we need to be part of that whole process that we initially talked about because the reality is this changes everything. If we're involved in every time direction is going to be shaped, well then we're no longer the gatekeeper. We become the partner. Instead of saying no, just as a matter of fact, no, you can't do this. Enterprise architecture can seems can say yes in many cases faster because we've created or already where people are using our reusable patterns that we may have created or various reference architectures or they're doing things inside of the guide rails that we've set forth. So they're complying with policy and we can speed things up. If there's integration standards based upon how we know to integrate in a standard way that we've secured what have you. And that's why we can make sure all security systems meet a certain baseline and we can be very clear with trade-offs and options. So if you really think about it, that's good enterprise architecture. So if we think about it, enterprise architecture should reduce rework, not create it. So if an organization's enterprise architecture functions are routinely discovering issues at the end of a product, that's because they're not doing enterprise architecture in the first place. The issue is that the enterprise architects are not engaged when they need to. So that's what we need to deal with. And at the same time, what should good architecture governance feel like? Good architecture governance feels like, you know, we met early, we clarified intent, and we avoided surprises. We reuse proven patterns and we accelerated things that we're doing. We made one or two key decisions up front that saved us months or years later. That's good enterprise architecture. Now, bad enterprise architectures. We filled out a template. We waited for a committee. We got your feedback too late to use it. So, that's what I really want you to think of. So, enterprise architecture is not diagramming. Diagramming are tools, not the job. Enterprise architecture is not ticket taking or approval stamping. Enterprise architecture is not the architecture police. We defi enterprise architecture in a way that makes sense that we're connecting the organization strategy with execution along the way because that's what we do as enterprise architects. We exist to help the enterprise make better decisions earlier in the process. So execution is coherent at scale especially enterprise scale.

### [1:26:15](https://www.youtube.com/watch?v=NVya6mYIpw0&t=5175s) Enterprise Architecture is not Engineering

Enterprise architecture is not engineering. So many thing people think that enterprise architecture is a network engineering job or a cloud engineering job plus a whole lot more meetings engineering and architecture totally different world. So we've clarified a few what enterprise architecture is not myths. Now I want to hit a myth. It's become so common in the last few years and uh especially when cloud adoption accelerated people got all kinds of confused over architecture roles where we architects whether it's a cloud architect, a security architect, enterprise architect are doing actual architecture functions at different levels and we'll talk about those different levels at some point throughout this training. But the key is they think it's engineering and architecture are very different things. So I keep hearing enterprise architecture is engineering. It's not. So it's that misunderstanding that's one of the fastest ways that drains the value out of enterprise architects, cloud architects and other architects. So let's separate the roles of architect and engineers. And it's not engineering with meetings. Let's say we've got a cloud engineer. And these are very important people to make the systems run and be built and be optimized on the cloud. And I'm an enterprise architect. I have been for 25 years now. And I respect engineers very deeply. But cloud engineering, enterprise architect, I mean cloud architecture, enterprise architecture is not any kind of engineering. And the difference is not seniority. here this person needs to be an engineer for 10 years to be an architect. No, no. It's just a different job and that's all it really is. So if we look at what an engineer focuses on, say a cloud engineer, they or how a solutions engineer or most even a network engineer for the most they think about what do they build typically a specific workload or a specific solution they're focused on. They think of configuration, performance, reliability, networking from the how to build it kind of perspective. And when we're dealing with engineering, they're deep into the how. Now, when we look at the focus of an enterprise architecture, for the most part, most architects, we're focused on which platforms, which patterns and solutions will make sense to the enterprise after evaluating trade-offs. We're looking for enterprisewide uh technology choices and the implications of it. So if we do something in Japan, how will that affect someone in say New York City? So the impact of any kind of technology on the entire system or changes to the system. Now we're focused on consistency at scale. Can we reuse certain uh patterns so therefore we don't have to rework them each time and create a standard thing which might be more secure and cheaper as well. uh is there a standard way to integrate that we can do so in a secure manner so we don't have a bunch of one-off things and challenges to try to manage later is there a standard that we can follow is there you know how would we map to a various security posture like a zero trust uh framework so we architects are focused on how our choices will work ac work across clouds across systems across business units across every component of the enterprise So we're thinking uh how decisions should be shaped. How will this shape the cost of things? How will this reduce the organization's risk? How will our decisions that we make increase agility in that business over yours? And the see the key is uh we're focused on the why and the what at enterprise scale where the engineers are focused on the how because it's a different job. And the key to remember is enterprise architects we need to understand cloud but the value is different of the cloud for us than that engineer. We have to understand the value of data centers and private clouds and hybrid clouds and multiclouds and every kind of architecture you would imagine as an enterprise architect. But our value is not being the best person in the room at Terraform Kubernetes or tuning or service by service configuration. That's not us as enterprise architecture. Enterprise architecture's primary value is linking technology choices to the business strategy. So the enterprise moves in a coherent in fashion and that's why we will always have our engineers I love cloud engineers for example network engineers all kinds of engineers they build on the playing field but we architects choose what kind of playing field we need what's the right playing field and even which one we should use. So, it's not a poetic line. It's a totally different job and a different function. So, I kind of hope that makes sense because the biggest enterprise mistakes aren't made in CPU sizing, for example. They're made on the technology patterns and technology that's not aligning with the business's needs. So, we're focused on the bigger issues. Are we standardizing on one cloud, multicloud or hybrid cloud? Why? Because we gain different things and we lose different things with each approach. What's our platform strategy? Why what security patterns for us are non-negotiable? What integration patterns do we want we reuse? See, we're thinking about these things as enterprise architects. When do we build? When do we buy versus when do we reuse? What capabilities are strategic right now? and which capabilities are strategic long term for us that we should invest in long term and that's why engineering or engineering experience doesn't answer these questions because it's something very different uh these are enterprise architecture questions and these have serious technical consequences. So if a team were to basically for example to just choose a cloud service because it's the best path for their workload and they choose something fairly proprietary and another Oregon team does something that is fairly proprietary with another system. We've got two problems. One is we've got multiple patterns uh typically speaking of different systems. We often have different identity patterns. uh we may have different logging standards, we may have uh inconsistent security, inconsistent networking, data that's duplicated in multiple places. So, we've got more risks. Now, if we could reduce it to say one that actually makes sense and a better set of identity patterns and we can send all our logs to the same place and we can enforce some extra degree of segmentation, data loss prevention, what have you. Now we're there creating an environment. So that's why we have to ask these questions. So we're guiding the organization. We're looking for everything they need. And that's really the strategy consulting role of what we do.

### [1:33:41](https://www.youtube.com/watch?v=NVya6mYIpw0&t=5621s) Q&A

All right, we are back. Uh so we talked a lot more about enterprise architecture in that last section. We talked about what enterprise architecture is not and fallacies about enterprise architecture and even antiatterns in enterprise architecture. So I see there were a couple questions in there. So let's bring in these questions. Uh before we do, I'd like to say if you're having a good time, maybe give the video a like, maybe subscribe to our channel and hit the bell to be notified of new videos for your architecture career. Whatever type of architect that may be, maybe hit that like button. Uh tomorrow we're going to have a webinar on how to become an architect. Uh tomorrow's webinar will be I believe on and how to become an enterprise architect. If I'm wrong, Chris can pop that in the chat box. Uh but we're going to talk about what we do, the exact set of skills you'll need, how to get employers to come to you. It's live, it's free, it's on Zoom. So I hope to meet you there. So let's bring in some of the questions that we actually have in the from the audience. Chris, bring in the first one. Henry, how or where do we see the impact of the enterprise architecture on a company and what proves they're actually delivering results? Henry, absolutely great question. So, I'll show you where we typically are able to gather this information. So, I'm going to show you Mike's enterprise architecture framework, which is typically what I teach people. It's loosely aligned to TOGAF. other major consulting systems frameworks, but let's just walk through this for a second. You know when a client calls me and says Mike I need some architecture consulting the first phase is meeting with the executive sponsor of that project. Now when I meet with that executive sponsor and let's say it is uh someone from the seuite of an e-commerce provider and when I met with that executive sponsor they said Mike we're looking to use AI uh to increase the sales on our website we want when the user comes here for them to get recommendations based upon what cookies have been in their browser what they've recently been reaching in plus their buying history and what we know about them to try to upsell them while they're there. And in that first meeting, we determined, you know, what's in scope, what's out of scope, who the key players are, and what business requirements we have. Now, this afforded us two things. Now, first, we now know what the goal is. The goal here is to increase revenue on that website. And we've also identified who our key players are. Now these are going to pe to be the people from all the business that we actually need to know. So if that person is in is goal is to enhance revenue. Guess what? It's so easy to measure. We've got the website. Our revenue is $3 billion. We've integrated the AI recommendation engine and the revenue went to $3. 8 billion per quarter. It went up a lot. about uh8 divided by 3M that's about 25% roughly a little bit less than 25% uplift in revenue. Now what else could people do? There could be an organization that came to us for a cloud migration and the organization says we implement a lot of changes and currently our systems our legacy systems are taking eight months for any major change. We'd like to drop that time to four months with by migrating towards the cloud. Now if the client goes to the cloud and they can take their time which their time which was eight months before and then bring it down to four months and then they've actually met their business goals. So in that first meeting I always ask the client how do you define success and I don't ask client in technical terms of how do you define success I ask them what business goal you're trying to achieve. So that's how we know exactly what we're doing when we meet when we find we can meet be meeting with the hospital and the chief medical officer of the hospital says we need to decrease medical errors and they brought you in for do that and you would measure med medical errors before your architecture and then medical errors after your architecture and the severity of the er of the errors and how quickly they were determined. That's how you do it. It's a really great question you had there, Henry. Chris, let's bring in the next one. Angelo, so good to see you. So, Angelo is an exceptional worldclass enterprise architect. He's also a good friend. So, thrilled to see you. Anytime you're here, is always happy to see you. Just passing through, wanted to ask a couple questions. Uh, thanks for this. Uh, what are some ways the enterprise architect gains the trust of their executive leadership? What a great question, Angelo, because this is the big common thing people have. The way you gain trust with the executive leadership is first being prepared, being knowledgeable, but it's in the matter that you speak to them. For example, if I walk into the meeting with the chief financial officer, I'm going to talk to them about the ROI we expect to get. I might talk about the architectures impact on revenue, on operating income, on IBIDA or net income and I'm always going to be using that metric that the chief financial officer is thinking in is looking to gain out of it. By comparison, Angelo, if I'm on having a conversation with the chief operating officer, for example, I'm going to be talking about how the architecture will remove friction inside of the organization and smooth operations and enhance productivity of the employees, and if so, by how much. So, it's really about finding what that business executive actually needs, making sure whatever strategy we will do will actually get to them, and then speaking to them in their language. Where people get in trouble is they meet the executive leadership team and they may meet may have been like really strong as some type of an engineer in their life or a solutions architect and they're really good at that hardcore design. But when they get to the executive team and it's mostly about which I have the option to make my sales rep do it this the job this way or this way which one do you recommend? What are the trade-offs? That's where many people fall apart. So as long as you can stay business relevant, deliver measurable business results, as long as you can maintain executive presency or taken seriously and executive communication and CXO relevance meaning speaking in the same language that the sew cares about, you will have be taken very seriously. That's the biggest key of that. So great question, Angela. What are some ways to enable harmony between standardization innovation? Oh, this is a good one. So, what Angela is actually asking here is if we want to innovate and truly innovate, we need a little bit of flexibility. And you know, your artists that create something creative, your innovators, they're not necessarily the people that fit a cookie cutter mold of clock in at the same time each day, clock out do this, do that. your innovators, you know, they beat to a different drum. They're kind of like a cat going and off in all different directions, whatever the cat finds interesting. Now, the rest of the folks, the more we standardize, the more we can improve quality, eliminate mistakes. So, standardization is a great thing, but if standardization locks us out of any innovation, that's no good either. So what we realistically do in our architectures, in our business processes, is look for areas where we can standardize. For example, if I have an organization like McDonald's, I expect the same hamburger. Not that I've eaten McDonald's in a long time, but I would expect that same hamburger in Philadelphia, uh, Palm Beach, Florida, as well as Cape Town, South Africa, because it's the same machines, the same beef, same processes, what have you. So that's where we need that standardization. Likewise, at the Ritz Carlton, there's some things that could be standardized, but you know, there's a lot of flexibility in what the employees can do to make sure you're satisfied. So, they need customization. So, I look at it this way. Every architecture decision we have is a trade-off. We look to standardize where our standardization will improve operational efficiency in some way, shape, or form, the efficiency of the business, employees. And we look to allow flexibility where we need it. And that way we are playing guard rails which improves speed where it's needed and we're not overly guard railing our creatives or whatever. That's typically the way we want to do it. Great question there Angela. I appreciate these questions. Henry, what are some potential mistakes an enterprise architect might make? And given the significance of the role, what consequences could it be? Oh, so here's the reality. They could be very, very serious. So, let's talk about a kind of mistake you could make. If you truly don't understand the business, you can make a massive, massive mistake. Do you want to see how bad of a mistake it can be? I'm going to draw you two examples of what used to happen in healthcare. So, when I used to practice internal medicine as a nurse practitioner, here's what my visit was. So, the patient will come in and I want you to see the process because it'll make every it'll make sense to you. So, here's the patient. Now, here is your medical provider. Now, the way the process used to work prior to electronic health records is this. I would ask the patient qu the patient would come in. I'd ask them questions. They'd answer me. I'd examine them. And I would spend approximately 12 minutes seeing this patient. Say the patient came in for a sore throat. So the patient would come in, I would see them, I would spend 12 minutes with that patient and I would discover they had a sore throat. So I would literally get on my phone. I would dictate a note which somebody else would type and it would say subjective. Mike comes come cleaning of a sore throat. Objective: eyes, ears, nose, throat. Eyes, ears, nose, normal, throat, red, arommitus, swollen. Diagnosis, fngitis plan. Mike's not allergic to penicellin amoxicylin 500 milligrams four times a day for 10 days and he's better. That was the old day. So I had 12 minutes to actually see the patient. Now in the old days uh what happened is we had paper charts that looked like this. So the US government said to improve patient safety we're going to change the process. We're going to mandate everybody uses electronic health records um to eliminate the mistakes of handwriting. So here's what happened next. The electronic health records were here. Now did not really were not something quick like that note that I used to use. So now what you typically have is you have the doctor sitting behind a computer and it now takes about 12 minutes uh to actually do the actual computer thing. So the medical provider sits behind their computer and they ask a couple of questions and they type in the computer and they have about three minutes to actually examine the patient where I used to have 12 and 12 minutes time in the computer. Well, I used to have four times as much time to treat a patient than I did before the computer. Now there's no guarantees that this was the cause. Well, medical errors on paper error records in the United States were the fifth leading cause of death. 100,000 people died each year. It was horrible. We added electronic health records, forced doctors to work in a way that was not inclined for their medical workflow and medical errors became the third leading cause of death and went up 250%. So that's the stakes. The stakes is you set up the wrong automate the wrong process for a business, you can destroy the business. You set up the wrong process for a hospital, people can die. So that's why this is a very important job like any other important job and that's why we spend a lot of time developing great architecture skills. But this job could save lives. You could also, if you're good at what you do, you could go to that hospital. You can find medical errors. You could find inefficiencies in the way nurses and doctors are doing their job. You can find areas right for improvement. You can put in some AI and decision support to make the doctors and nurses better and really help them. So the key is this can be the best job in the world where you really help save lives, do so many things. It's all about how prepared you are. That's why we prepare for these roles. Great questions. Can introverts be do well as enterprise architects? I'm an introvert. And it's funny when I was on one of the most significant teams at Cisco, the Internet Business Solutions Group were the biggest and the highest level architects in the company were a lot of us were introverts. A lot of our spots were there. So the key is when you're an introvert, now I'm one. I practice going out in public. I practiced giving presentations and at some point it became mostly comfortable for me. But I'm an introvert and I know a lot of great introvert architects. Remember it's going to take all kinds to be an architect. We're going to have to do a lot of thinking and a lot of creative problem solving and that's typically introverts are good at that. We're also going to have some discussions. Extroverts are good at that too. So all there's a place for all of us. We can all have a great job here. The key is just finding the exact niche where you fit in. But even in enterprise architecture, there's three ways you could take your career. In platform architecture, there's multiple ways you could take. There's a place for all of us, Henry. And if you want this career, I welcome you to I and I'd love you to join it. Is one of the best jobs I've ever had. And join our webinar tomorrow and we'll talk a lot more about it. green field revolutionary and evolutionary is there a way to look at all the architecture projects and justify with business value compliance and capabilities or is that part of it so you know it all depends what we're trying to do if I've got a new company I'm going to look at every part of that company and try to create a strategy before that company goes to battle in business and competes with others. The better the strategy, the more they're going to be there. Now, I have worked with organizations that have said, "We're going to just change everything. We're going from average to the new leader, and we're going to do it. " And I'll tell you that was very interesting projects, lots of planning, lots of statistical analysis, and it it's been really fun. Most things that I've done over the last 26 years as an architect, enterprise architect is more evolutionary where first uh we brought the client online then we added some applications that supported the business then we removed some applications that didn't and added new applications that did then the business needed new capabilities or bought another company and we added new capabilities. So evolutionary is generally speaking the majority of your architecture project. But there's a business value for anything. And the question is if we're going to take a car company and turn them into a car and space company, that's a pretty revolutionary change. And that's going to change massively their business architecture, their people, their processes, their technology. So it's all great, but we can integrate all of it. And it's all based on using the right one. That's all part of the architect mindset. Great points there, Andrew. Jasser, does our enterprise architect go program go deeper in this topics? What content does it include to help people become great enterprise architects? Well, Jaser, thank you for that question. Our actual enterprise architect development program includes more than a thousand hours of training. We're going to spend 12 to 15 hours in this free fundamentals course, but we're going to spend over a,000 hours there. And we're going to make sure our enterprise architects have all the executive skills, all the presentation skills, all the business acumen, all the architecture skills, all the leadership skills, all the financial modeling, executive presence, and that's why we spend about a thousand hours in that program. Plus, it's live in a classroom so we can groom people. So, that's typically that. Join the webinar. Uh, Josh, I know I knew you well. You don't need to eat your but uh anyone else join the webinar tomorrow. So the next section is going to be a really short one and then I'm going to come back to questions and then after that we have our architecture lab. So stick around. We're going to look at a healthcare organization. three different departments and look at the kind of capabilities they need. And over the course of this program, we're going to translate into all different levels of architecture. This is going to be lots and lots of fun. So uh I hope you stick around. uh maybe give it a like, maybe subscribe to our channel, give us a some kind of a hashtag like enterprise architecture and we'll roll that last quick video and then we'll get back to the content. But it's going to be very short, just a few minutes and then we're going to get back to the questions and then our architecture lab.

### [1:51:15](https://www.youtube.com/watch?v=NVya6mYIpw0&t=6675s) Enterprise Architecture vs Other Architect Roles

Now, we're going to distinguish enterprise architecture from other architecture roles. roles like solutions architecture versus say platform architecture. We're also going to distinguish enterprise architecture from other roles that people often confuse with enterprise architecture. And people use the word architect very loosely. The reality is architecture is a family of roles with very different scopes. And when the scopes blur, the enterprise pays for it in misalignment, frustration, and typically bad outcomes. And every architecture role is critical. Enterprise architecture is critical. Platform architecture is critical and solutions architecture is absolutely critical too. And when we work together, there's some magic happens. But we need to know what we're doing and how we're doing and where we're doing it. So let's typically look we'll start like to start with you know the two that are almost farthest apart from each other enterprise architecture versus say solutions architecture. So when we focus as enterprise architects, we're typically focused on multi-year views. Where are we going to be in five years, 10 years from now, 20 years from now? We're typically managing a portfolio that spans many different things because it's across the global enterprise. We're typically focused on standards. We're typically focused on shared platforms, capability alignment, and strategic roadmaps for that organization. And we're responsible for coherence across the organization. Now, if you notice, this is all very high level. This is all big picture. This is all strategy stuff. And then we get to the solutions architect, which is a very different role. And another critical role at that. The solutions architect is focused on one project, one product and typically one major and initiative. So focused on one little thing, one tiny thing. Now because that solutions architect is focused on that one tiny thing as opposed to big picture like us enterprise architects, those solutions architects need more technical skill. not hands-on skill, but technical knowledge because they're going to be the expert of that typical solution that they're working with. So, they're going to be making detailed design and implementation decisions uh for how others would implement it and they're typically responsible for making sure the solution succeeds. You're the designer of this specific thing and you're focused on getting that. The solutions architect could also be doing a very similar role in a pre-sales environment where they work for a vendor, say a any a cloud provider, a network provider, a security provider, and they could be designing systems to help cl help the client design something. They present it back and they sell it to them. But that's typically solutions architecture. Now you can kind of look at it as a solution architects. You know, how do we design this thing to meet the requirements for this one thing to work well? Were we enterprise architects or how do we make the entire enterprise work well and how do we create a cohesant portfol cohesive portfolio of applications and services that's going to make that business be more likely to succeed. Now let's talk about the domain architect. And I spent a lot of my time life when I was younger working as a domain architect focused on network architecture and then after that focused on network security architecture. So that's domain architect. And when you've got a domain architect, you've got to respect the technical depth that typically works in one of these roles because if you're a network architect and you really know networking and for the last 10 years you've been working with Cisco and all of a sudden you're working on Juniper stuff or Arista things it doesn't matter because you've got that kind of deep knowledge of every component of networking. So all kinds of infra our platform architects here data architects security architects infrastructure architects integration architects analytics architects and so on and so on. Now these architects is still a business role. They're not typically touching the technology but they've got major depth and the level of expertise here is typically very helpful very helpful along the way. So we enterprise architects are here to ensure that all the domains inside of the organization work together and stay aligned. So when I'm an enterprise architect, I'm going to have some domain architects on my team, some solutions architect on my team, engineers and others because the domain architects can go deep and that's their skill. And I promise you, if we're getting into any kind of complicated networking, you're going to want a domain architect like a network architect there. Now at the same time we enterprise architects go wide. So we need a more of a width of service knowledge of different kinds of things all the capabilities that out there various technologies out there and what they could potentially be used for and how they fit together with that domain architect has depth in that one thing. You can often look at your enterprise architect as your family practitioner, your primary care provider that's there for your entire health. And then if and when you need help, they send you to a specialist. And that specialist is the domain architect. So domain architects really get into the you know the best practice and the mind for whatever they're working on the network or security where we enterprise architects focus again on the big picture. Now often people confuse as

### [1:56:57](https://www.youtube.com/watch?v=NVya6mYIpw0&t=7017s) Enterprise Architecture vs Project Roles

enterprise architects with project managers and business analysts because we do a little bit of project management in our world and a lot of business in our world but that's not really what we do. Uh and there are also project managers are critical business analysts are critical but they perform different functions of what we do. We enterprise architects focus on what we should build and why at the entire scope of everything going on at the enterprise people, processes, technology. We enterprise architects have long-term consequences in mind, strategy, and it could be related to the organization five and 10 years from now. Now project managers and uh business analysts typically focus on different things like how to deliver managing tasks, requirements, stakeholders and timelines in the context of a project or something fairly specific. So we often will need a project manager and often a business analyst to somebody that can help us crunch numbers or figure things out and research or give us information is a great thing too. But uh enterprise architecture isn't about uh isn't about any of those other functions. It's really about that strategy for the organization. Now the key to remember as enterprise architect, you don't need to be the best engineer in the room because you're not an engineer. So I want you to understand that you can be a wonderful enterprise architect. The key is to focus on strategy and helping that organization be more likely to succeed. And that way you're the connector of strategy. people and you're the connector of technology decisions because enterprise architecture is coherence. And we create coherence through decisions, alignment, and direction. Enterprise architecture is absolutely critical for long-term success. We're

### [1:58:55](https://www.youtube.com/watch?v=NVya6mYIpw0&t=7135s) Poor Enterprise Architecture

going to now talk about what happens if you get enterprise architecture wrong. The risks of doing it the wrong way. Because this isn't just semantics. Getting enterprise architecture wrong creates all kinds of systemic failures. And this typically occurs when enterprise architecture is treated as a diagram factory where uh enterprise architects are just creating diagrams and documents because what happens in those environments is business leaders don't trust or even want to work with the enterprise architects. delivery teams won't trust enterprise architecture and it becomes more of what you call architecture theater where things are being used to slow down in paper but there's no real architecture there and uh when that occurs your architects are making documents and diagrams and there's no way to connect the organization strategy to execution which is what we focus on as enterprise architect so the enterprise doesn't change the only thing that occurs in that kind of bad enterprise architecture practice is the number of slides increases the number of documents in the architectural repository increases but there's no digital transformation. Now if enterprise architecture is treated as a ticket desk or stop and stamp approval it slows things down. It doesn't uh create any strategy for the organization and then delivery teams and leadership just views enterprise architecture as a bureaucracy. Again nothing good happens. Now, anytime you've got any kind of enterprise architect or cloud architect and they're focusing on any engineerings, you've got real problems because the architect becomes overworked. The organization doesn't have that architect doing any real architecture. They're just building things and then the architect can't do any connecting of strategy to execution because they're too busy focused on execution and then they become engineers and the organization loses those critical functions. So what's the consequences of getting it wrong? Well, it's pretty significant because there can be a lot of different types of failures that can actually occur. Now, the biggest problem is when that occurs when enterprise architects are not focused on real enterprise architecture or the alignment of strategy and execution. What happens? The organization has a strategy and the strategy doesn't translate into the technology decisions and that's why McKenzie had said that 70 to 80% of all technology investments I think it's 70% fail to provide any transformation because if there's no one focused on connecting strategy and execution all you've got is a lot of expensive technology and when that occurs and there's no good strategic enterprise architecture what happens is every project becomes a one-off solution. Each team starts designing the new thing as opposed to having great enterprise architecture practice where there's a standard and there's guard rails to help people do quickly and use the standards when appropriate. Now when we don't have a good enterprise architecture practice to truly understand what's going on to truly build a future pipeline to evaluate the application's portfolio and evaluate the entire system what happens is cost goes up risk goes up and complexity goes up and when complexity goes up it becomes much harder to innovate and costs go up because you need much more capable people to deal with the complexity. And what happens is as this complexity goes up, integration becomes harder and harder. And then without enterprise architecture tying all the pieces together, security becomes inconsistent at the scale of a global enterprise and everything slows down to a near grinding halt. And then when a company acquires another company or all of a sudden there's a new law or regulation or a market shift, the companies struggle because there wasn't any real enterprise architecture going on. So the goal of enterprise architecture is to make the engineers more scalable in their job by using consistent patterns and a reusable platform so they don't have to continually rework, rework. If there's clear guardrails of what can be done and it's being done inside the guardrails, the ability to get it out there will be much faster. And if we make sure that when we look at the strategy, capabilities the business needs, and we align our architecture to that, that's aligning strategy with execution. And that's where the magic happens. Because when enterprise architecture is defined correctly, delivery accelerates. poorly, delivery gets harder and harder as times go.

### [2:03:45](https://www.youtube.com/watch?v=NVya6mYIpw0&t=7425s) Q&A

Okay. Well, we have about 20 more minutes of content before the lab, which we'll get to fairly quickly, but I see a couple of questions popped in. We really love enterprise architecture. We love spreading the word about various types of architecture careers and what we do as architects. So, let me ask those questions quickly and then we'll get to that. As a reminder, tomorrow we're going to have a webinar on how to become an enterprise architect. It's free. It's on Zoom. We'll talk about exactly what we do, a 100% of the list of skills that you need and how to get employers to come to you. The entire kitten kaboodleoodle about getting your first architect job and it's free and it's on Zoom so you can ask questions. So, I hope to meet you in person there. And uh let me get to some questions now. How should enterprise architects evaluate whether the Gen AI tr architecture will truly add business value or where it will induce unnecessary complexity or risk? So at the end of the day if we look at it and someone says here's your generative AI architecture what do you think about it? It's probably already wrong. And the reason it's already wrong is if the AI people are already recommending AI solutions and they don't actually know where the business is going or how that company actually operates or what it strategic goals are, most likely it will be wrong. So I get a lot of people that try to sell generative AI architectures with me. nonstop. And I'll get things like, "We can make your sales rep sell 10 times more with our AI application. " And here's the question I say. I say, "Well, first, what makes you think I have sales reps? Secondly, if I did have sales reps, do you know how they do their job? And could you tell me how their job will be done differently with your AI application? " And I'll never get an answer. And given that they don't know what I need, where I'm going, or how I do my job, I can almost guarantee without even looking at that architecture, it's a waste of my time because that's someone designing a solution without actually knowing the problem. So imagine someone comes to the doctor and they said, "Well, my friend Billy Bob gave me this medication. Should I take it? " And I'd say, "I don't know. Well, I have to examine you. I have to figure out what your actual problem is before I can recommend a medication. That's really the same thing. So, what I want to do is I want to make sure that I'm working with those generative AI architects to see what the actual source is. Now, if the AI architects brought me something and they actually show me some documentation that's got, you know, the current business process, the current business painpoint, the options that were actually considered, the trade-offs and the recommendation that was made, and why it was made, oh, that person's a real architect, and I'm probably going to take that very seriously. So, we're going to look at it. We're going to see how it'll impact the business, the likelihood of it impacting the business. Does it assist people in the way people do their jobs? Does it optimize That's how we're going to tell. Great question. What is the difference between cloud, security, genai, and enterprise programs? So, it's a good question. So, let me talk about the difference of the four careers real quickly and then after that I can explain to you how our programs are. So, there are different kinds of architects. We talked about the platform architect which is focused on one platform like multicloud or like AI for the enterprise or like secure and we talked about the enterprise architect being you know big picture people processes technology. So in order for us to train an architect in order for you to be great at your job which is what we focus on you have to have the right skills for each architectural role. And we make sure that we spend our time focused on exactly and I'll give you an example. I'll give you two different kinds of roles. So if I'm looking for say a cloud architect or an enterprise architect, it's fairly similar. Although the enterprise architect is more build, but let's say it's a cloud architect, I know that person needs to know networking. I know they need to a degree. They need to understand applications. load balancing. They need to understand compute. They need to understand AI to have some knowledge of IM, some knowledge of data, some knowledge of security, some knowledge of storage, and some knowledge of disaster recovery and business continuity plans. That's their technical knowledge, and they'll have a set of business knowledge. Now, that's kind of a little bit of everything. But what if I have a security architect by comparison? They have a very different focus in their job. They're going to have a different set of skills. So you can see all these skills are fairly generic for an enterprise architect or a cloud architect. But if we look into a security architect, everything changes. And maybe perhaps I didn't actually share the sec the slide that I meant to. So you can see for the security architect, they're focused on data security. They're focused on network risk management, risk mitigation. They're focused on adhering to say zero trust frameworks or NIS frameworks. writing security policies, dealing with application security, coming up with a security governance structure, creating the IM strategy, the zero trust strategy, the I identity federations, the cloud access security brokers. They're dealing with heavy duty encryption and all and things that are very security oriented and of course they need the business skills and we would teach that to a security architect. But if it was a if it was an enterprise architect or a cloud architect, we're going to focus on a different set of skills that would be needed for those roles. Say same thing with an AI architect, it'll be focused on things that an AI architect would be focused on. You can see their focus is more on the data and the AI side. Still the business side, but more focused on that. And that's really the key. What we just do is we make sure that we train people in exactly the job they have for the skills they need. Great question there, Josher. And it's just like the difference between an internist and a cardiologist and someone else, just different things. Still all medical people, just slightly different perspective. Great, great question, Josher. So, I don't think there are any other questions that came in. So, we're going to have that last 20 minutes and then stick around because we're going to actually look at an organization and we're going to literally look at some capabilities they need. We're going to start our four-week evolution of this enterprise architecture. It's going to be fun. So, make sure you stick around after this 20 minutes to go get involved in the actual architecture uh lab. All right, Chris, let's go roll back to the content.

### [2:10:27](https://www.youtube.com/watch?v=NVya6mYIpw0&t=7827s) Enterprise Architecture and Exec Value

All right, everyone. Welcome back. And now we're going to anchor enterprise architecture into something that matters to business leaders, to delivery teams, and to your enterprise architect career. And that's tangible value. We enterprise architects are not about theory. We are not about pretty pictures and documentation for the sake of documentation. And by the end of this discussion, you should be able to explain enterprise architecture in a way that's going to make an executive lean forward and say yes, that's exactly what I need. And that's really what we're going to talk about now. So let's start with the core question.

### [2:11:05](https://www.youtube.com/watch?v=NVya6mYIpw0&t=7865s) Enterprise Architecture vs Strategic Enablement

Why does enterprise architecture exist? And here's the definition that I would give you. Enterprise architecture exists to deline to align the organization strategy with the way they execute or get stuff done. So enterprise architecture is really the discipline that's going to help an organization turn direction into delivery on a consistent matter. Now let's clear up. Uh remember we're not a diagram factory as enterprise architects. We're not a bureaucracy. We're not gatekeepers that just exist to say no. And if the business experiences enterprise architecture as a slowm moving committee that blocks progress, then we're not doing anything related to enterprise architecture. We're creating organizational drag and slowing things down. So not what we're doing. So here's the theme for now. We're going to talk about tangible value in terms leaders actually care about. Now what is it leaders actually care about? Well, leaders care about the time it takes to make a change. And we'll talk about why that is throughout this training program. We'll talk about risk management. Organizations want to reduce the risk. Organizations are concerned with cost control. where can they reuse things they've invested in. And uh realistically speaking, leaders are concerned with consistency. And when you work as an enterprise architect, your job isn't just to know architecture because that's only a small part of it. A bigger part of your job is to explain business value uh in a manner that people will trust. What's in it for you to uh adopt this type of a system? So let's get into the first thing that matters as enterprise architects, speed and speed to change. So here's the problem. There are so many great companies out there that lose and they have great ideas, but the problem is they can't execute or change fast enough to take those good ideas and turn it into reality. And when that occurs, other environments do better. And let's be fair, markets shift, constantly dynamic environment. Customers shift. All of a sudden, there's a new law or regulations which changes things. a competitor produces some new thing weekly, which could mean that you need to keep up or adapt or have some other offering to even be competitive anymore. So, if an organization is going to take nine months just to line up things uh systems, data approval, integration, security, you're more observing than actually competing. So, if we talk about enterprise architecture, the goal is to speed things up in some very practical ways. One of the things that we do is create standard patterns. And if we have a standard pattern for a certain set of thing, the teams aren't doing it from scratch every time, figuring it out, thinking about it, doing the research. So instead of every teaming every team having say their best way to build an API or deploy a service or log events or manage an identity thing enterprise architecture is going to provide a standard place to start a paved road if you will to accelerate things. Now if you think of it like this if every new project had to pour their own concrete before driving you're going to be moving really slow. So the next thing that we need to do as enterprise architects is clarify priorities because we can't do everything at the same time and teams need to know on what matters to most and what do we need to work on right now for what's the priority now and speed isn't about coding faster speed is about doing the right things that work and that's really what we're talking about speed in a helpful manner not just speed to do stuff but not do it right. So enterprise architecture is going to help leadership and delivery teams answer the questions like what is the sequence what dependencies exist and what needs to be true before we build the next thing. So for example we want an IP video application across a business if they don't have the network performance they can't do it. So maybe they need to upgrade the network performance either in higher speed links higher speed routers quality of service what have you long before they can do it. And many times, you know, that's why we have to figure out what's the sequence of what we're going to do and how it. Now, another thing we do as enterprise architects is we break a big change into a road map with manageable increments. Now, in many cases, change fails because it's too big, it's too vague, or it's too risky. But the key is with us as enterprise architects, we're going to take a multi-year transformation and turn it into phases. what phase one, phase two, phase three, we'll have certain milestones. Okay, we've achieved one thing, great. We'll have the next thing that we've achieved along the way. And uh we'll be always focused on capabilities. Again, capability of the business and how are we enhancing that in some way, shape, shape or form. And we deliver at least with a good enterprise architecture practice, our teams are going to deliver in increments that can actually come out periodically. We've got something. We're on the next step. So that's what you're really talking about. So if you join a company and the company says you're here to build a new onboarding experience, you know, you may want to start thinking and say, well, we've got these reference architectures. Here are the approved patterns that we have, assuming it's the case. Here's some shared services, identity, messaging, logging, and monitoring. Here's their typical CI/CD pipelines or API gateways. Pick from the library and move on. So, that could be a great way. You've got something, they ask you to do something. There's a whole lot of library of pre-approved ways to do it. And that's going to make it a lot faster than reinventing the wheel. Now, the next company, you could tell them, "You've got to build a new custom ornamenting experience. " And they say, "Great. Figure it out for me. Start from scratch. We've never figured out anything. We've never found certain patterns that we want to use. So, come up with it from scratch. " Now, that's going to take a lot longer. And the difference is the first company that we talked about that had pre-approved designs can ship very quickly and change on a dime. Now that company that says figure it out, they could be dealing with a very long time to figure it out with a lot of people. So keep that in the back of your mind. So

### [2:17:37](https://www.youtube.com/watch?v=NVya6mYIpw0&t=8257s) Speed to Change

when someone asks you, you know, how is enterprise architecture adding value? The real answer is enterprise architecture increases the organization's ability and speed to change by coming up with reusable paths res reducing decision friction because we've already made the decisions and preventing reinvention. Now the key is speed matters but if you're going in the wrong direction it doesn't matter how fast you're going. If you're going out without controls you could be doing things that could be a problem. So we need these controls to reduce the risk. We want to come up with proof patterns to speed things up in a controlled manner. Now let's talk about another way enterprise architects add value and that's risk reduction. So if we reduce risk that is a huge value for the organization. So let's talk about the types of risk that we may impact in enterprise architecture. Well security and organizational risk we have a big comp component of that. Uh operational risk and reliability risk for the business. There's a lot of what we do that could impact that. and strategic at risk like for example investing in the wrong things. And here's the thing, risk doesn't usually announce itself. Risk hides in various gaps in details between teams, between systems, and between assumptions. So enterprise architecture is there to reduce the risk. So we're there to make sure for example that a new solution either is following a previous pattern or we determine that the pattern is safe and move forward and create the controls. So we're going to provide clarity around what's safe, what even safe looks like in terms of identity standards, encryption requirements, logging patterns, segmentation, data classification, and so many more. Now the key to remember is we're not here to be a slow approval gate. when well done. Enterprise architecture is often a pre-approved decision maker because the teams already know the safe patterns that we helped create with them. So, as long as you're following the pattern, go ahead and do it for the most part as opposed to let's really analyze the pattern. Will it work? Let's put it in front of 10 boards and figure it out. That's the key here. So good enterprise architecture provides end toend visibility of any critical process or any system because as enterprise architects we're connecting the dots between that business architecture that uh technology architecture that application architecture and the data architecture those domains of enterprise architecture. So we're looking at it all and making sure everything's aligned the way it should be. Now if the leader asks and they should what happens if this thing goes down enterprise architecture needs to be able to answer that question or show them what could happen or in that manner. So what we're doing is we're helping leadership see the dependencies, see the single points of failures because a lot of enterprises have failures because no one sees the dependencies. They don't understand how technology will fail along the way. So we help that. So we typically as enterprise architects will find shared services that are potentially overloaded. Legacy systems that the entire business depends on and we don't even know how it's coded or have any documentation about a system. We may find integration points that don't even have an owner. And we could find critical data pipelines with all kinds of fragile handoffs. And I've seen it so many times. So when we're dealing with enterprise architecture, we're mapping everything. So effectively, we're building a map of the enterprise and that way we can find the risk that others wouldn't know because often risk hides in places that nobody's looking at. So, I've seen organizations spend millions or more actually uh modernizing front-end things only to discover that the backend stuff was the things that couldn't scale or potentially had one person behind the entire back end. So, it's not going to be a poding problem. That's an architecture problem. It's an architecture visibility problem. So, enterprise architecture is about moving faster. It's about risk reduction. And that's really what we're talking about. Now the next thing we're talking about in enterprise architecture is cost control and reuse of patterns. The problem in most enterprises is not that they spend money. It's that in many enterprises organizations send spend the same money on 10 different things that are supposed to do the same thing, the same capabilities. So for us, a lot of the time to reduce cost, it's about finding that we've got 50 applications that do the same thing and figuring out the right one and getting rid of 49 of them. Getting rid of unused licenses and unused servers that we don't need to really figuring out what we have and uh coming up with things to help prevent an organization from making a short-term decision that's going to create a long-term cost or technical debt, especially when that debt has interest. So not creating patterns that are going to cause us to have problems later if you want to define technical data start. So enterprise architecture is going to help with you know rationalization and consolidating all the apps and the platforms because it's our job to ask as enterprise architects why do we have six tools doing the same thing? Why do we have four different ways we're integrating applications? Why do we have 12 versions of customer data somewhere and we're paying for this? Now this isn't enterprise architecture theory. This is a budget. This is practical. This is how does the company run. So we enterprise architects are intentionally going to promote the reuse of services. The reuse of AI is the reuse of components when we can because when teams reuse a proven service, the organization wins multiple times. First, it costs less to build something that's already built. maintain something that you typically already have. It has a lot less over operational overhead if you've already got something that's working and to add something new. We've got a lot less bugs when we've got vulnerabilities typically speaking. We've got one product versus 10 of them. And there's less integration headache. So there's a lot that we're doing here from an enterprise architecture. We're guiding investment into shared technologies, shared platforms that can accelerate the enterprise and the enterprises system. We can help the leadership decide on a standard platform versus a product specific platform that we might need and sometimes we need a standard thing. Sometimes we need something specific but it's about knowing which one and being able to advise and that's what we're doing as enterprise architect. Now the key here to remember is enterprise architecture is not about making anything cheap even though we always think about cost. It's about making sure the money is spent one time, not 20 times due to rep replication of services. And it's spent in the right place, doing something for the business as opposed to just taking its money. And if you think about it, and this is why we enterprise architects exist. If every product team builds their own applications with their own authentication, with their own auditing, their own uh monitoring stock, here's the reality. your costs go crazy but your risk explodes too because it's too hard to manage too many vulnerabilities that you have in this sequence and it cost too much nothing good comes from that but instead if we invest in one really good shared identity plat platform one really good set of good logging good observability everyone benefits so cost and reuse are huge but even if you rationalize tools and platform forms enterprises will still struggle with one thing. It's the lack of consistency and that's why we have to do so much. So we also provide a tremendous amount of value by helping with consistency and something called coherence. And what we're talking about here is making sure that our architectures are consistent and that way there everything will work the way it's supposed to. So when system when architectures are consistent, things become easier to integrate. When we don't have consistent, we've got complex integrations, we've got different definitions of the same data, we've user experiences that are different from one to the other. We've got frustrated customers, frustrated employees, and nothing is winning there. So if you go to some companies and you ask what a customer is, you could get six different answers, five or six different answers. And that's a problem. And when you've got no shared language and definition, everything breaks. Everything breaks because anything can mean anything to different people. And when that happens, you've got broken reporting, mismatched experience, very slow decision-making, and uh constant reconciliation work. So what we're doing as enterprise architects is to define that enterprisewide standard and come up with those reference architectures, those repeatable patterns, but not to do it because we're creating paperwork. No, it's all about creating speed and clarity. See, when we create standards, it reduces confusion and it prevents uh some expensive mistakes or divergence from what we actually want. So enterprise architecture is really about the big picture, the discipline of all the thinking. How do we deliver now? How do we fit this into the enterprise direction? How do we make the environment understandable for all teams and all vendors? And that's really what we're doing. Consistency equals better customer experience. Consistency typically equals uh easier scaling. Consistency typically experiences simpler support. consistently you see so usually means faster onboarding and lower operational overhead. So we've uh named four values so far speed, risk, cost reuse and consistency.

### [2:27:45](https://www.youtube.com/watch?v=NVya6mYIpw0&t=8865s) Measuring Enterprise Architecture Value

consistency. Okay, let's talk about how enterprise architects uh communicate their value and our value is actually measured. As I mentioned previously, executives don't buy enterprise architecture diagrams but they buy as outcomes. So if you want your enterprise architecture initiative to be funded, supported and listened to, you need to not only measure but be able to communicate value in business terms. So I'll give you a few examples that you can think of. For example, or metrics or indicators that you can think of. If we as enterprise architects can note that we've created fewer duplicate systems, we've done something right. All because that typically lowers cost, lowers risk like we talked about. now faster uh time to market of new things for the business. So if we can go from idea to the time it's actually start started the project and we can reduce that we're doing a great job as an enterprise architect. So, you know, if it takes six weeks normally to make a decision of yes or no, and good enterprise architecture can knock that down to 48 hours, the enterprise architects are enabling. They're not slowing the system down. Now, the reality is if we're doing our job as enterprise architects, there's less incidents. We have less outages caused by integrations because we've got that all locked down and we're doing it great. Uh we have good observability. we've got uh good data pipelines because many cases these things are broken by poor architectures. Now if we're doing our job as enterprise architects, we're reusing platforms and services. So new things can be adopted quicker or there's less training that goes along and there's less weaknesses in the system. See here's the thing. We enterprise architects can come up with all the great data in the world and data helps but it's the stories that we do that persuade others that influence the board influence the seauite to invest in what we need to. So data helps but stories persuade. So if you tell it like this, we reduced uh time to start by 30% because teams reused approval patterns or we avoided a compliance issue because uh the new solution uses standard controls or we removed three duplicate platforms and reinvested those dollars into a shared capability. That's one thing. But if we can clearly talk about the speed, the risk reduction, quantify the finances, talk about their reuse patterns and what it did for us and talk about consistency, we become far more attractive as enterprise architects to the seauite and the board. And often that's one of the big differentiators in getting an enterprise architect hired is they're not just technical, they're enterprise relevant and they've got that strategy side. So

### [2:30:45](https://www.youtube.com/watch?v=NVya6mYIpw0&t=9045s) Summary

So let's take this perspect this uh section and let's close it with a simple summary. We enterprise architects are about alignment of strategy and execution. Enterprise architecture is not a bureaucracy. It's not a set of diagrams for diagrams sake. Enterprise architecture matters because of speed to change. We want to change faster so we can adapt to the market. We want to be more agile. Enterprise architecture is about risk reduction for the entire enterprise. Enterprise architecture is about cost control and reuse of patterns. And enterprise architecture is about consistency and coherence.

### [2:31:32](https://www.youtube.com/watch?v=NVya6mYIpw0&t=9092s) Q&A

Now, let's see if there's any last questions and uh then after that we're actually going to get into our architectural lab. What are t who are typically the key organizational roles to be identified as sponsors and how to manage possible crossfire due to internal conflicts depending upon concurrent goals. So two questions in there. First is, you know, who's typically your executive sponsor, your CEO, your CFO, your chief operating officer, your chief technology officer, your chief information officer, an executive vice president of sales, a senior vice president of marketing. Key business stakeholders are typically your executive sponsors that bring in an enterprise architect. Now, here's the reality. You are going to be managing conflict in your job as an architect. So the architect job takes a tremendous amount of le of uh emotional intelligence. It takes a tremendous amount of leadership skills. stakeholder management skills because you're always going to have stakeholder conflicts, stakeholder conflicts. And we're going to have a stakeholder conflict when we actually do our hospital. We're going to have two different departments in the hospital. The architecture we're going to do, they're going to have two different needs. So, I'll give you this example. We'll get back to it when we do the architecture. But let's say I've got nurses on the ward and doctors on the ward inside of a hospital. This is where people stay during their entire hospital stay. Those doctors and nurses need as much information as possible to make the best long-term decisions. That same hospital has an emergency department who needs to make a split second decision. They need systems that are fast because they don't have time to put in a lot of information, ask a lot of questions. They've got some urgent thing and they need to fix it fast. So in a hospital, you'll have two people that may want a different system for the same application. And then do you have two systems and try to integrate it or do you standardize upon one? So this is where we really have to put on our stakeholder management house really has really need to identify what that business truly needs and then truly try to find a way to get as many stakeholder needs supported as we can and make sure we're very clear about the tradeoff the considerations made why we made the decisions the options that we actually considered along the way. But you're never going to be able to please everybody in an architecture. We have to please a majority of the organization's growth. And sometimes we need to make exceptions. Maybe there's some unit that does something that's so different to the rest of the business that they just need different things. And then we look at that element of the business and say, is it worth it? Is it worth the complexity? potential risk? Is it worth the cost to do a one-off? And if it is, we do it. But in every case, you're going to have it. So it's all about that leadership skills. And that's why I train enterprise architects. We spend a thousand hours on it. We spend a lot of time on these leadership skills because that's the biggest part of our job. I'd say 50% of our job is going in between organizational stakeholders that all have different desires. But executive sponsors usually start high up now. And they're typically who your things will be. Great question.

### [2:35:00](https://www.youtube.com/watch?v=NVya6mYIpw0&t=9300s) Enterprise Architecture Lab

All right, let's get a lab. Everybody give me a hashtag enterprise architecture and I know you're ready for the lab. Okay, so most of you know I've been an enterprise architect now for 23 24 years now. I had a couple years as a network architect and a security architect prior to that. In my last job, I was a chief architect, a chief enterprise architect and I worked predominantly with healthcare organizations. Oh, today and throughout this process, we're going to create an enterprise architecture for a hospital. Now, most enterprise architectures will take several thousand hours to develop. It's me leading an architecture team of 15 to 100 people for the next 6 to 12 months or 18 months to design our real full-fledged enterprise architecture. So, we're going to have to take some shortcuts. When we talk about the hospital, we're going to discuss three components of the hospital enterprise. We're going to discuss the emergency department. actual wards where people stay in the hospital. And we're going to discuss the business front end of the hospital. We're going to look at how people need to do their job. We're going to look at capabilities, what have you. And then what we're going to do as we go through is we're going to map those capabilities to applications that are going to support those capabilities. And then we'll bring it down into a technology architecture. And maybe we'll even have fun and map it down all the way to a solutions architecture. So everybody gets the feeling of enterprise architecture versus platform architecture or domain architecture versus enterprise architecture. So let's have some fun with this. So we have a hospital and that's who we're going to be working with. So in this hospital we're going to again we're going to start with the emergency department. So what is an emergency department from? If you're from England they call it the A& E. It's where you go when you have an emergency. So, let's talk about the kind of capabilities the hospital emergency department actually needs. And we're actually going to list them, but I want you to see it first before we create the list. So, first part of what we have to deal with in a hospital is the ER has to do triage. So, this is going to be capability one. And I'll show you what I mean. So the first thing we need to see is who gets sick. So right now let's say this hospital at the back of the ER let's say it has 25 beds and it has you know two physicians that it has four nurses and it's got three techs. So that's what we have in the ER right now. Now the beds are at normal in an ER let's say 95% full 90% but let's say it's 95%. So the first scenario is we have three individuals that have walked in to the emergency department. Who do we treat first? Individual one, this is Cindy over here. Now Cindy is arriving at the emergency department and she's depressed because her mother's been away and there's been nobody to buy her prawns and she's been stuck eating cat food and kuna. So she goes to the ER cuz she's a little sad. Now we've got this other individual here. This is Tony. And Tony was practicing yoga with her father and is a little sore. So she went to the ER because she's a little sore. Okay. Now we have Sally over here. Sally is having a hard time breathing. This is an emergency. The cat that's worried about not getting prawns and shrimp, she can wait a month. And the one that's sore from doing too much yoga, well, she could probably wait too. So, we have to look at it. And what'll happen is the patient needs to register or might not register at all. So, let's put a registration thing here so we can actually just understand what needs to occur. In a healthy, stable individual, Cindy, who's sat over here, is going to go over to registration. and she's going to give them her information so they know who she is. They're going to send this one to the triage nurse. The triage nurse is going to say, "Ah, you're healthy. Uh, we'll get to you, but she's registered in the computer. " Then this cat that sore from too much yoga goes to register. They put her in the waiting room and she she sees the triage nurse and she waits. Now, this one, this one walks into the room and she's having a hard time breathing. So, she goes to walk to registration and they go straight, go to the back, go to the back. We're going to give you emergency care. So, business capability one that the hospital has to do is triage. Let's do this. I'm going to list capabilities over here. Now the hospital this ER has to do something else and this is going to be called patient tracking and I'll explain to you mean what I mean by patient tracking and then we'll walk through that workflow so you can see the business architecture patient tracking. So this uh this cat comes in and remember she came in here because she was sore from yoga. So she goes to registration after 4 hours they send her to back and the ER says well I don't think doctor I don't think you have anything but I need to send you to X-ray. So Cindy goes over here to X-ray. They do an X-ray and then they bring her back to the emergency department where she's in the room right now. So we have to track the patient. Now somewhere along the line, let's bring this one back. For right now, we'll just go we'll bring the one that was having trouble breathing in the hospital cuz this is the most critical one. So, we've got this cat that's having trouble breathing. So, we need to do a few things. One is we need to document that patient so everybody knows what's going on. So, we need to do some documentation. Call that uh emergency documentation. Now, this we want to get as quick as possible. are going to look for efficiency here. Now, she's back here. She's having a hard time breathing. So, I am working in the ER that day as an in an emergency department. And I decide that I'm going to give her a nebulizer treatment, which is a medication that's designed to open her lung, say a beta 2 agonist if you were a medical person. So for that I need a med I need a system to enable me to order to enter the prescriptions medications because that way the nurse can go give the treatment of the respiratory therapist after I can be now I had to send Cindy back for X-rays right so I need do I need lab and I need imaging I have to be able to check Cindy people's blood images. So, we have to be able to do this just for the ER. Now, one of the big things that happens in emergency departments and hopefully it never happens to anyone that you know is someone sitting here uh all of a sudden this person's individual is feeling fine and all of a sudden they get leftsided weakness, they get a bad headache and they can't use one side of their body. So, we worry about this is what you call a stroke. This patient needs to not only go to that ER, but needs specialty care. For example, they're going to have to get a CAT scan very quickly and medication otherwise they'll have brain damage for the rest of their life. So, what we need to do is that we need to do some kind of emergency care. So, we are going to have to do emergency stroke care in most hospitals. Um, we might have trauma too. So, trauma care is different too. And what I mean by that is let's say we have one of these individuals. This one uh this one came in uh she was in a car accident driving her Mercedes home from the cat store. I don't know. And now that person needs to not only go to the ER, they need to get imaging, but they need to see a surgeon and probably be in the operating room with an hour. So the key here to see is we've got a lot of things to deal with. And the last thing we probably have to deal with here is behavioral health. Now, what will happen in the ER is say this cat that's doing yoga over here, I have no idea how, but that cat found a bottle of scotch and she started drinking the entire scotch. So now that cat went into the emergency department and she's acting a little crazy. So we're also going to need the behavioral healthc care to deal with these kind of crisises. So that's typically what we need in an emergency department. These are the capabilities we need to use. Now I'll bring this back to some applications right here and then we're going to talk mostly capabilities about the other ones. So how do we do this? If we as architects have to support a business capability, what could support that capability? So realistically speaking, there's processes that support our ability. Like I showed you the process of triage, how to bring somebody back. So, and we have to map all that stuff down. So, let's look at the kind of applications that we might use. So, if we go back here and here's our business capability and we can take this stuff off from right now to try to map it back. But if these are the business capabilities that we need, we need a few things. So, we need somewhere along the way to have our documentation. Where is the doctor's going to see the patient chart? Where are the nurse is Typically speaking, that's through something called an electronic health record. No, I didn't mention a vendor. I didn't say Cerner. I didn't say Epic. I didn't say Metch. I said an electronic health record because we're looking at business capabilities and applications that would support it. for example, right now not knowing where people are and tracking them through the thing. Let's call that an ER information system. Now the doctor, the nurse practitioner, the physic physician assistant has to order medications for the nurses to be able to provide them. So we need another system that's typically used for that. In the health world, it's typically called the computerized practitioner order entry system. Sometimes they call it a computerized physician order entry system. Now, while we're at it, you know, sometimes you get someone in the ER that's a little scarier and crazier than you've been used to before, and you want to look it up, right? Maybe you have a trauma patient and uh before you crack the chest and open it up, you want to look something up, right? Maybe you're looking your patient with your stroke care and you've noticed some things that are a little on the scary side and maybe you want to look that up, too. So typically speaking, we want to have some kind of clinical decision support and that can be something that you could use to give you some information. So we'll call this clinical decision support and this is for the medications. Now we need to know where the medication which medications have been given. So that's typically another system and I'm literally not joking and that's typically called a medication administration record or a MAR. Now when that cat came in and we wanted to send that cat for blood work, we needed to order that. So that means we need a lab system as well. And mind you this is all for the medical people. I didn't talk about any non-medical people. Now, while we're at it, I want to order MRIs on my patient or a CAT scan. So, I need a radiology ordering system as well. That's why I said we're only going to look at three parts of a hospital. So, these are my clinical applications. Now, here's what I want you to think about. We go to that ER and we have 25 beds in that ER. What happens if I don't know which beds are filled and I try to bring people to a room that doesn't exist? That's a problem. What happens if a patient goes to CAT scan? They were having a stroke and we need to get them back to treat it and somebody forgets about them in CAT scan and we lost our 4hour window to make them better. What happens if we just take a patient somewhere and then we lose them? Like this can't happen. So even in this hospital just for this ER uh we'll and we'll go back to this maybe we'll we'll put some better headers to try to make this a little clearer. So here's the cap here's the business capability and at the same time what we're trying to do over here and these are clinical apps these are just for the medical professionals. Okay. But if we don't know where the people are, we've got a problem. We need to know who's where our patients are. We What happens if there's a security event? How do we deal with it? When somebody comes in and we collect our insurance, that's so we can build them. How do we build them? We use medical supplies on a patient. How do we recover those costs? We want to send someone from the ER to the ICU, the CCU, the floor, but there's no beds on the floor. So, we need to track that, too. So, now we're going to need another set of applications for the ER to be able to do their jobs. And we're going to need nonclinical apps. And these non-clinical apps will be things like uh a bed management system so they know where people are. patient transport. Definitely have to have some patient transport. We definitely need some kind of security system. And this might not be a seam system like we're talking about in logs, but it's still some kind of security event management system. Uh, typically speaking, you might call and they put you on a hold, wait for the doctor, wait for this one, somebody else picks up the phone. So, there's typically a contact center that's needed. They there there's bill there's billing systems because you have got to be able to bill for the medical services and uh we'll just keep it at uh we'll keep it at those up. So this is the emergency department. Note this what they're looking for in terms of all these systems in the ER is speed. The ER is sheer chaos. I mean, one minute you're just sitting there having tea with your buddies and the next minute three ambulances come in and 20 people come in at the same time. So, it's your chaos. So, in ER, we got to work. We got to work fast and then we got to move on to the next topic. So, that's the emergency department. Now, we're going to look at inpatient next. And then we're going to look at the front of the house. And as we go through these things, I want you to see it's going to change and maybe there's going to be some conflicts over these applications as well. So now let's so let's make sure this is real clear. We go back to this. We'll call it uh we'll call it two things. Emergency department for our American friends. We'll call it accident and emergency for people that are speaking. Mike, you're not you're not sharing. — Okay, thanks for that. So, we're going to label this slide emergency department accident and emergency. And if you live in a part of the world where they call it something different, uh I am totally happy to add that. So, please feel free to let me know in the chat box. Chris will message it to me and I'll add it. But this is the emergency department. So, now we're going to do inpatient care. That's going to be a little bit different. And so I'm just going to steal this one box so I draw less boxes and I make less spelling errors because believe me I'll make them. And we're going to call this inpatient care. Now let's look at their capabilities. Their capabilities are going to have to be a lot more than the emergency department. Why? Because in the emergency department, we're worried about the next two hours until we get someone to the floor or the unit. In the unit, we're worried about making them better for the rest of their life. So, it's a different focus. So, now here we've got something different. Now, you may notice some similarities along the way, and I want you to tell me where you see them. So, in this case, we have to do clinical documentation. H, we got to do that in the ER, right? We have to be able to enter orders, prescription orders, medication orders. I'm going to and treatment orders. So, we have to be able to enter that. That's a capability we have to be able to do. Now, we've got multiple sets of documentation. We've got I'm going to let me break it out. We have physician documentation who use one set of systems. Generally speaking, the nurses have another set of documents they wrote. We physicians, nurse practitioners, we write the orders and the nurses carry them out. So we have different set of systems. So we have the nursing documentation. You know, if you're ever in a hospital, they check your blood pressure, your pulse, uh your O2 sat, your vital signs. So they're going to be capturing that periodically and this can be automated or not depending upon how we set it up. Uh in this these kind of units they're doing what's called care planning. So care planning could be the plan of care for your entire time that you're going to be there, the PT that you might need, the occupational therapy you might need, uh you know, whatever wound treatment you might need. And this is like a long-term plan to get you better and even after the hospital. So we have to do care planning. Now we have to monitor our patients too. We have to be able to look at what's going on with their heart, their lungs, their EKGs, their rhythms. So we need to be able to monitor people long term. Now, it would be great if we could give our nurses and some and doctors some help along the way. And you know there's some things related to patients safety we have to definitely worried about making sure like who's a fall risk for example versus who's not a fall risk. Uh who's those types of things some safety kind of things if people are restrained with a how long can they be restrained before it becomes dangerous. all these kind of things. We need to track these kinds of things. But guess what else we have to do? We have to get the person home at some point. So, in order to get home at some point, oops, we're going to have to uh focus on how to discharge them. So, you know, I send you home. If I send somebody home from the hospital, do they need to stay on their medications? follow a diet? up with anyone? So, that's discharge planning. And the reality is I better educate my patients when they leave the hospital, otherwise they're going to come back. So many people get sick when they're doing things that are not optimal for the body. And you know, we all have our struggles. But if that's the case, if we don't want our patients to have the same problem again, we probably need to spend some time doing what's called patient education. So that's the that's what we need. Now, in order to be able to document and treat our patients and the nurses do their job and keep track of the patients vital signs and plan their care, monitor them, it's going to take a lot of stuff. It really is. And uh so we think about it. What's going to be the next step? Let's think about the supporting applications. And you're going to notice I haven't discussed a vendor. virtual machine or a container yet. This is intentional because right now we're figuring out what the business needs. I'm not going to tell the carpenter what tools they need to bring with them to build a house until we know what kind of house they're working with and what kind of materials they're working with. If they're working with concrete, it's different than wood. Same thing for our architecture. We're not going to get anywhere close to the technology until we figured it out. If we start with the technology here, we're almost always wrong at least 80% of the time. And it's I don't want to guess with people's billions of dollars of money. And that's what really happens. So let's go back to the applications that are going to support this inpatient care. And I'm just going to keep that here because we're going to run out of space on PowerPoint because I didn't design it very pretty. So let's look at the clinical apps themselves. Now, we're definitely going to need an electronic health record. Oh, wait. We needed one in the ER, didn't we? Yes, we did. Now, the one that the ER is going to like best is not going to be the one that we're going to like best on the floor because they have a different workflow. So, should they have a second one or should we use this? It all depends on the business. Now, we also need to have uh documentation, clinical documentation, and that's typically going to be in the EHR system. Now, in order for the doctors, nurse practitioners, and physicians assistants to prescribe medication, we're going to need a computerized practitioner order entry system. Whoops. Now, we need to know that the nurses actually gave their medications. So, that means we need AMAR or a medication administration record. Now, in the old days, here's what it used to be. I would ask the patient, "Oh, Mr. Smith, your birthday. Could you tell me your birthday? And they'd say 1 1221. And I'd say, "Okay, Mr. Smith, 11121. This is in fact you. Here is the prescription I'm giving you. " And I would give it to them. And now what goes on is to avoid human error, the nurse wants to give a medication to a patient. They scan the medication into a barcode system. They scan the wrist badge on the patient and then they confirm it with a birthday. So they're less likely to make errors. So in order to do that we typically have barcodes for medication administration and other things. So that means we need some kind of barcode tools. We're only talking clinical and I know something looks wrong about this. Uh so again, I might want to give my nurses, my doctors some decision support along the way. We can talk about what those kind of things could be later. Now then, oops, the nurses have to build a plan, a care plan, too. So the doctor's care plan is, you know, medication this, PT this, but the nurses have their own kind of care plans that they write. So we have to get nursing care planning applications here. And we really want to be able to monitor the patient's system. So I want to be able to see the patients what we call telemetry. Telemetry is their EKG kind of thing. So we want to be able to get uh patient monitoring integrated. And of course, uh, we're going to need like, uh, some patient education to send people home. Like, I'm going to send you home with advice. I need a system that's going to help do that for me. And I need to plan your discharge. So, we physicians have to be like an architect. When we send somebody home, we can't just say, "Goodbye, have fun. We have to say, "Do you have someone to take care of you in your house? Do you need help getting up and down the stairs? Do we need to come and take care of you? Do you need education on follow up with this doctor and do this? " So, like in any architecture where we have to build an entire plan, the doctors do the same job as architecture, which is why learning medicine made it a lot easier for me to learn enterprise architecture a long time because it's a similar job. But the key those are the clinical apps. But again, we need more than just clinical apps because we've got to figure some other stuff. So, let's look at the nonclinical apps and then we'll do the front of the house. And uh each week we're going to break this into different levels. And for our nonclinical apps, we're going to need a lot of things. So, we need to know who's where, like who's in what room. So for that we need something for bad management. Now what happens when you're in the room and they want to send you for SC cat scan? Well, we can't lose the people along the way. So we need to track them. Again, these are nonclinical apps because it's not that the doctors and nurses are looking for the tra for people. It's well, hopefully the nurses aren't. Hopefully, it's transport, but the nurses could be doing it. So, there is that. Now, we need to make sure if the room's cleaned, and that's called environmental services in most hospitals. I don't make up these names. Now, something funny about people is we actually need to eat. I mean, we don't survive real well without eating. So, they need to feed us. So, now we need another system to make sure that we've got uh food taken care of. So, food and nutritional services and there'll be apps for that we'll use. Right now, we didn't pick a vendor. We're just looking at what we're going to need. Now, we're going to be need to be able to bill people. Every time we do something, we have to charge the patient for it. So, we're going to need some kind of charge capturing system or a system that'll capture charges. We need to make sure we have the right nurses and enough of them. So, we need some staffing or workforce management. Now, here's what I want you to notice. Look, when we go back to the ER, look, they need that EHR, that COP, computerized physician order entry system, the clinical decision support, medication administration record, and the lab system. In the ER, we want speed, speed. Clinical support for emergencies, speed, speed. Over here for the inpatient care, we want detail. Oh, we want to make sure that we're not making any mistakes, that we're methodical about everything that we do, that we're monitoring everything, we're building medium-term plans for the person. Now, we're also going to get to the front of the house. So, I'm going to just pick the business side of the house just so you can see three different units in the hospital and how they're so different. Like I said, if we went through the entire hospital, it could get fairly extensive. So, let's look at the front door. So, you may actually research a hospital before you get there, right? You may see their advertisements and maybe your doctor says, "Well, I'd like you to get a routine scan, maybe a mammogram to make sure somebody doesn't have breast cancer or a uh or another kind of a scan that we use for a health and wellness scan. So lots of people that go to the hospital to get their blood drawn, to get their cholesterol checked, to get a mammogram, to get a colonoscopy, these are things they plan ahead of time. So now the front of the house, which is more the business side of the hospital, has very different things we're focused on. So what is the main front of the hospital focused on? So we're going to focus on that in terms of aa business capabilities. So the business capability here so this will be this will be front of hospital we'll just call this business capabilities t so under business capabilities we have to schedule uh I'm going to get an MRI for example and I'm going to schedule that ahead of time so scheduling we have to be able to do what do you think would happen if 50 people came in at the same time and there was only space for one of them. Nobody' be too happy. So, we got to get this right. We need to manage appointments. So, let's say you call, you create a schedule and then you actually have to be able to change it because uh your boss asked you to stay late that day. Your wife said, "I need you to go here. " And you can't make that appointment. So, you need appointment management. Now, you might need a referral. or you might be looking for a various doctor. Maybe you're searching for this specific neurosurgeon that you were told is that hospital that has a great registration. So, you need some kind of way you can search for a provider. I'm an internist and I need a cardiologist. I want to be able to see who's available to see my patient inside of our health system. So, we need to be able to search providers. Can uh Lisa see you in the office on Thursday or can she see you next Tuesday? Now, generally speaking, uh you might want to be able to register online some of your information ahead of time. So, I might need to do some online registration now to make sure I've completed everything before I've got it. Now, at least in the United States and many other countries, including Inguir Haba, for example, you're actually going to in some way, shape, or form check their insurance to see if it's covered. So, that typically is typically what's called insurance authorization. And here's what insurance authorization is. If it's an emergency, the hospital will treat you immediately because it's life or death. But if you need some kind of procedure that's not an emergency, that hospital is going to call your insurance company and make sure your insurance company's going to agree to pay before they actually do it. So, we need that insurance authorization. Now, how do we bring somebody in? So, them in? We've got to have some kind of patient intake where they register. We collect all their demographic information, uh their billing information. So we'll call that patient intake because this is when you register at the hospital. Now we need to be able to refer you see the uh internist. The internist is basically the enterprise architect. The internist says you need to see a cardiologist which is the equivalent of a platform architect in the medical world and they send you there. So we need to have the ability to do referrals. We have to make sure you are who you claim to be. What if I think you're Joey and I'm using Joey's insurance, but you're really Sally or Billy Bob. Okay, so we have some form of patient identity management. And this is so critical. What if I mix you up with somebody else and you get the wrong meds? So that patient identity management is going to be critical. Now maybe I'm also concerned at the front of the house of customer experience. So if you hate your experience, you're probably not going to go back. So we typically have some customer experience components and business capabilities that we have to have at the front of it. Now, in order to make this stuff work, there's a whole lot of stuff that we might actually need. Now, some of these applications are going to be overlapping and some of them won't be. So, let's look at first the clinical applications that we would use in this department. So what's going to happen is even though these are not clinical people I don't know what I did there hold on they are going to be pulling information that is actually coming to the clinical application that'll have this some of this insurance probably would be in your medical record your patient intakes needs typical records so it's the same time we're going to have some supporting clinical applications and some of them are going to look very familiar. They're going to be the electronic health record that we talked about that everybody's had so far. There's going to but now we'll have a patient portal. The patients might not might be able to self-schedu or something like that. Uh we might have a clinical intake system where we ask a lot of questions and it gets taken there. We may have a triage application at the front of the house to kind of help us along the way to help us score um our non-emergency things. But here we're going to have a lot of clin non-clinical apps. That's going to be the majority of it. So we will need to schedule people, right? So we're going to need some kind of enterprise scheduling system uh at the same time. Now how do we go back? A patient came to our vis facility. We want to remember them. We want to talk to have them come back for a follow-up care. You know, even the hospitals want to have customer stickiness and increase, you know, the amount of time they spend with their hospitals. So, in order to do that, what are we going to use? Most likely a customer relationship management platform. Most hospitals use them. Now, when you call a hospital, they often put you in a hold queue. You listen to code music. They transfer you here to get you to talk to the right person. Now, that is typically a contact center. Now, we're probably going to need some IM here. And guess what? We're going to need more than one kind of IM because if the patients are allowed to register, we're going to need customer IM. And yet, at the same time, we're going to have our employees that are going to need their own IM. So, I'm just going to put IM down here for right now. Now, we need to be able to check their insurance to see if we're going to get paid before we do something. So, that means insurance verification software. And uh we probably have a website, so we probably have to have some kind of web content management system like WordPress for example or whatever everybody else or another option. And we have to have some kind of customer experience analytics. We have to figure out what our customer side is and whether people are happy. Let's add this in here for right now. Let's call this front of hospital. Okay. So, we talked about three systems that each need some of the same capabilities, some of the different capabilities, and each one is going to honestly want unique things. Now, I'm going to go back to this. You may have noticed that I didn't say Salesforce for the CRM. I didn't say Cisco contact center. I didn't say Octa for AM. I didn't think whether it's going on AWS, Azure, or Google. I didn't pick a firewall vendor yet because it's irrelevant at this matter. Right now, what we're doing is we're analyzing the organization. We're going to look at what capabilities they actually need to be successful and then we will figure out all the other stuff that's going to help them be successful. Throughout this program, we'll help them figure out some of the other stuff. We'll think about how it would work and how we could host it. We'll go through various components because we're going to add an a lab in each and every one of these architecture days. So that's what I wanted to show you today. We start with the organization. We start with the capabilities that organization needs after we know where we want to go. So we've looked at some applications here. Where should we take this hospital which obviously we want to start with first? Well, I'll give that some thought and we'll take our hospital there where we're actually going with this as the next phases. But phase one, here's the business. What does that business need to be able to do to be successful? Start there. Note, if we started at the end technology and picked a PaloAlto firewall, we have no idea whether that's going to be right or not for that business. If we picked the Salesforce CRM, we don't know if that's going to match the way our billing department uses CRM systems. It might, it might not. If we picked a Cerner electronic health record, which is a rockolid electronic health record, it may not be in the best interest of our emergency department, which could be the busiest one in the country. I'm not saying it is or it isn't. My point is that's why we never start with the actual product. We start with what we're trying to help that business achieve. We start nonbiased with no preference for anything except making our clients successful. All right. Are there any questions here at this point? So, while we'll see if you have any questions, let's talk about all the fun stuff we covered today. Before I bring in any questions, we talked about what is enterprise architecture and the purpose of enterprise architecture and business strategy. We talked about the scope of enterprise architecture, the domains of enterprise architecture. We talked about how we operate as enterprise architects and how we map strategy to business capabilities. We talked about an enterprise architecture artifacts as a tool as opposed to the job. We talked about enterprise architecture versus enterprise architecture theory. We talked about misconceptions about enterprise architecture and we talked about how to communicate enterprise architecture and what it is. So I hope everybody learned a lot. Chris, is there

### [3:17:16](https://www.youtube.com/watch?v=NVya6mYIpw0&t=11836s) Q&A

any questions that for them for me back there right now to answer all of this gives an exact idea of the complexity an enterprise architect needs to deal with. Wonderful. And that's what we're trying to show you or exactly what it is. And that's why people think if I learn to code, it's going to teach me this. And I love people that can code, but it's just a different job. So, lots and lots of fun. And yes, I did use cat scans for the cats. Uh I do love cats, so I put them everywhere. Adrien, thank you laugh for the me using Cindy. I kind of use my cat for a lot of things. Jasper, it was wonderful having you here as well and thank you for all your hard work helping me with that book. Uh Adrien, so good to see you as always. Thank you very much. Val, it was wonderful to have you here. You are more than welcome and we're thrilled to see you. All right. Uh, let's have a great day. Maybe end with one last hashtag enterprise architect. If you're having a great time, give it a like. Uh, subscribe to our channel and hit the bell. And I want to see you tomorrow in the enterprise architecture webinar, which is all free. One last point here, not all enterprise architects are the same. What differentiates those who work at an analytical level from those that operate at a strategic executive level? Great point. So the better your business skills are, knowledge is, the more the executives are going to want you on your team. And you're going to be focusing on higher, bigger things. The more understanding you have in terms of how businesses operate, the kind of pain points businesses actually have, the challenges that they have, the bigger and more strategic your work will be. If you can create solutions that drive revenue, drive uh decreases in operating costs, you will be at the executive level. If you can spend your time and you're talking strategy and you're building a road map, how do we go from where we're at to where we want to go today, you're operating at the executive level and it will always stay that way. And the only way it will not stay that way is if the enterprise architect doesn't have the actual business acumen needed for the job. They'll be migrated down towards other things that don't look like enterprise architecture. And I've seen it. If they are focused on product or focused on technology, again, that tends to hurt the person. And if the person looks biased, that tends to bring someone more down towards the solutions architect world. And here's the reason. If you're biased to like Cisco and you know I worked at Cisco so I when I was a solutions architect it's okay to love Cisco it really is as a Cisco solutions architect but as the enterprise architect I can't love any vendor I need to be in love with making my client successful and look at any tool any process any anything to get them there so hope that answered your question there it was wonderful having you all thank you all so much okay who decides the 2B capabilities is this a collaborative effort with the business analysts. So James, we work typically way above the business analyst level. You won't be having any conversations with business analysts who decides the 2B capabilities, the executives in the organization. It could be the EVP of sales will determine that sales needs a new capabilities. It could be an EVP of marketing that determines marketing needs and new capabilities. It could be the CEO of the business that says we need a new capability. So it's going to be the executives that give us the cap that help that help us determine what capabilities they need and we mean to advise them for example that we might that hospital might say we'd like to achieve objective X Y and zed and then we go with them and we learn how their business operates. We learn their actual business architecture, their key business processes, their key value streams and say in order to get here you're going to need to be able to do this, this and this. So a really great enterprise architect is working with that with the key stakeholders on executive teams and we consult back and forth on it. But that starts from the executive team. This is an executive job executive work. So it typically starts from much higher than the business analyst level. Although business analysts are great too and you may get to work with some. I've never actually worked with business analysts. I've worked with the seauite in the last 25 years but I've met many really smart and strong business analysts. Good question. What are the practice to design data projects on the cloud? So let's remove the cloud from the equation and let's look at data. What are we dealing with in an architecture? We are determining who is the owner? What information is sensitive? How do we categorize that kind of information? And I'm not a data guy, but um and uh would love to get Pine here. He's a full-fledged data architect and if we have Pine we'll definitely get him here but uh so I'll have Pine talk about a data architecture day but the key is to remember the first thing we look at is not the cloud what is the business outcome we're trying to achieve for that data architecture then we look at what is the data we look at the actual value of who is the owner how do we categorize that protect that data things like a data privacy which could be anything from data minimization to data tokenization to obuscation for example then we learn how we're we focus on how we're going to store the data move the data throughout the entire systems where that data should be stored is it structured data is it semi-structured data how and where we're going to maintain the hygiene of that kind of data that's data architecture so your your project is not to design it in the cloud The question is to design the right architecture. Now after you design the right architecture then you determine where you should put it without bias. I'm going to tell you right now in at least 50% of the cases the answer is not the cloud. In maybe the cloud. So that is the key. The key is first what are we trying to achieve and then what do we want we pick the vendors last last. So think about that. But I will tell you this, for the majority of things, the data in the data center and cloud is identical with the exception we've got more options and more control in the data center because the cloud provider themselves is just offering virtual data center services. But uh the best practice is don't just start a data project figuring out what you are trying to achieve. Figure out the kind of data that you need to get there. Figure out the kind of sensitivity, how you're going to categorize the data. Figure out make that data flow, where you're going to store that data, and even how you're going to normalize it, clean it, collect it. That's data architecture. I'll bring Preine from my team one day. Preine's a really great data architect. We trained him as a data architect. We moved him to a cloud architect, but he's got a lot of data architecture and he advises some of our students sometime. So, I'll try to get that happening at some point in the future. Great question. And Jaser, I can't wait for the next session either. fun class. Thanks so much, Adrian. And you are so welcome. It was so nice to have you here. Take care, everyone. Have a wonderful day. I can't wait to meet you and see you next week. And I hope to see so many of you in our enterprise architect.

---
*Источник: https://ekstraktznaniy.ru/video/50008*