Welcome to the Bizzdesign Enterprise Architecture podcast. I'm your host Will Hardison and in these podcasts we talk to leaders in the areas of enterprise architecture, and how they and their teams deliver value to their organizations to advance strategy, optimize operations, and reduce and manage risks to help. Let's get down to business.
Well, welcome back to another episode of the Enterprise Architecture podcast by biz design, I am your host, we'll Hardison, the mark one of the marketing managers here at biz design. I've got a very interesting guest with me today, actually, we connected through a listener of the podcast. So you know how, at the end of every episode, I encourage you to email podcast at biz design.com. With guests suggestions. Well, someone did that. And through some emails, and connecting and LinkedIn and conversations, I got to know my current guest, who is Dan Warfield, and felt like he would be a perfect addition to come on the show. So Dan's IT leadership career spans more than 35 years, he has had senior roles in r&d, strategic planning, enterprise architecture, software, product marketing, and IT governance for Fortune 100 organizations, including Lincoln, financial, Walmart, IBM, and dxc. He's also an expert in it for it and TOGAF standards, and currently teaches these certifications. He actually grew up in America, and is currently based in London. Welcome, Dan, to the show. How are you?
I'm great. Thank you.
So Dan, just by reading through that, and telling our listeners I mean, in I know this moreso, from the conversations we've had leading up to this recording is you have done a lot throughout your career when it comes to the enterprise architecture space, which means you've seen it all right, like The Good, the Bad, and The Ugly, so to speak. But throughout our conversations leading up to today, you know, one theme continuously came up. And that is what makes a successful enterprise architecture team. And I'm really excited to have you kind of explain your methodology in you know, kind of the pitfalls that you see teams fall into when they are planning a enterprise architecture, team and practice. So really excited. So I will give you the the layup here to go ahead and kind of go through your points, because I know Part one is laying a solid foundation. Can you kind of unpack that for us a little bit?
Yes, well, the issue with Enterprise Architecture teams is they tend to come and go, people have a big it mess. And they say, oh, we need some enterprise architecture stuff. So they let's let's create a team and teams get created. And if they do well, they are effective, and the chaos subsides. And then after a while they get rid of them, then they start over. It's like Phoenix. So that's an aspect of this. So usually, when you're setting up an enterprise architecture team, you're building on the ruins of the last one. And sometimes he's doing Greenfield. But in every case, there are three things that you have to understand before you get very far into it. One of them is to know your scope. So what is the breadth of your assignment? What are you actually being asked to do? Who are the top three stakeholders? Maybe top five stakeholders who who's paying for this? What do they want? What pain do they have? And you also then based on that need to figure out what kind of capability to do we actually need most of the people I've seen doing this kind of startup work for an EA team have not asked us questions of themselves or their sponsors and they get the scope wrong, they focus on their own problems or they get the size of their team incorrect and they set it up in the wrong way and then they have trouble with that.
I think I could draw some parallels you know, to my own kind of experience in marketing right I mean, in business in general and then I think that that is solid advice for setting up anything in business and marketing and sales etc is you have to understand the scope you have to understand who needs a seat at the table in terms of you know, from a decision making process and who needs to understand, you know, what is going on? And then you know, what are the end results like what are we looking for at the very end right? So, now identifying big rock Box is next. And what do you mean by that?
Well, what I mean by that is that. So I'll tell you a story about someone who worked for me or who I was a mentor for actually said to me, I'm applying for this other job in the company. And I put this little resume together. And what do you think of that? And I let him through. And I said, Well, what are they trying to do? She said, I don't understand. So well, actually, the only reason they posted this job is because they want someone who can help them with something, you know, what they're trying to get done. And she was like, I never thought about it that way. You should. Because that's, that's how that works. And so if people do team is an expensive strategic investment, it is not something that comes into life overnight. And the people are expensive, the training is expensive, the tooling was expensive, somebody should have made a decision if they're trying to do that about what they expect that team to help them with. And I had a meeting with a team, we were helping, I worked with a an international group of people who do this kind of consulting, and we were helping a team at US regional bank last year to try to raise their game. And we said, So tell us, what do they describe the corporate strategies and goals? What are they trying to do that you should be helping them with? Focusing on? As it did? You know, this'll they don't tell us that was fun, you should go and ask them? Yeah. Because if you don't know that, if you don't know who the people are, who are sponsoring you or who on your side, then then you won't actually know what to do next.
No, it's I mean, that's very true. I mean, if you don't understand what they want, and are looking for, in the end, you're just kind of running in circles, right? In no matter if you have yourself or if there's 15 people on a team, I mean, you are all just running in endless circles. And nobody really has a clear vision, right?
That's right. And if you are an Enterprise Architect, type of person, it's very easy to identify lots of things. One of the CIOs I work for, said, I don't, I'm not worried about the low hanging fruit, you can see the pumpkins as a ground. Let's start with those. And it's really important to clarify that because in any big organization, it's easy to quickly find dozens or hundreds of things that look like they need attention desperately. But most of them are not the really important ones to the to the stakeholders.
We actually use the saying, and it's I mean, we didn't coin it, but we use this saying on the marketing team here biz design, if everything seems important, nothing is important.
Right?
Yeah, that's right.
So you've got you've got your scope, you've got your big rocks, defining a minimum viable EA capability?
Yes. And so the EA capability, this is a textbook Enterprise Architecture stuff is that you need to understand what the, what the scope is for your team's existence? If you're the Enterprise Architect, what enterprise is that? Is that your whole company? Is it your local part of the company? Is it something that includes your company and other organizations, which often happens in public sector? So you need to know that you need to know what are the sort of, as I say, big rocks and things you have to deal with to be successful in the short to medium term. And then you need to look at yourself and say what needs to be in place for us to do that? That includes first of all setting up some kind of governance framework that makes sense. It includes picking the right methodology and the right tools, which could be software and probably should be software if you have the maturity to know what to do with it. It should include skills training or hiring people who have skills that you need so if the if the issue is that we need to get control of the belt that there's a at Walmart Walmart was challenged by Amazon they're the brick and mortar big store business was was under threat from from Amazon. And there was a perception there that was the kind of thing that makes people want to get any a change and look at the big picture come up with a strategic change suggestion that we must do something about this. That's we didn't have ecommerce we had. Big Box stores everywhere really, really successful ones. But Amazon's like the big three So, yeah, is that the big rock? Is that while you're there? Was it something like that? Is it we're terrified of AI, is it? We want to grow the company and by acquisition, and we want to understand how we're going to integrate other companies. So things like that. And those are usually Enterprise Architecture kinds of topics. The bank we were working with last year, is trying to move most of their core applications to the cloud. And that's a complicated process. It's also perhaps informed by a misunderstanding of what you're going to get when you do that. That's a different question. But so to define the, the, the minimum viable EA capability is to say, what is the governance model that we can use? What kinds of decisions that do we need to make? What skills do we need to bring to the table? What tools and methods will we have to use to get this done? And and then you, you need to put a price on that if you are trying to develop a new sales team for Ohio, you would make a plan on how many sales calls will you make? What kinds of customers will they approach? What kind of marketing support are you going to need in order to do that, and you would come up with a budget for that. And you'd say, well, we need this many people, these locations, these skills. And by the way, you want us to sell things to current part manufacturing companies, we don't know anything about that. So we did find some people who know that and bring them in, and the hiring will take a while. And that's that's what I mean by the capability, you define that you go back to the sponsor, and say, if you want us to move these big rocks for you, this is what it's going to cost to set it up. And this is sort of how long it will take. And at that point, you may find that you adjust the scope, or the size of the target, or you may adjust the size of the budget.
So I'm picking up a theme here, I'm picking up a theme, and I think the kind of the buzzword that we could use on that theme is called alignment, right? Like making sure everyone is aligned out of the gate. And even before the gate opens, you know, on budget on capabilities on the goals, key performance indicators that we're going to look at to measure success, the skills and you know, you've used it when we've chatted about the skills, and there's a big difference in skills and actually being able to use those skills, right. So I mean, I can understand and know what every single button in the cockpit of an F 16 fighter jet, what it all does and where it is and everything. But at the end of the day, I probably can't fly a fighter jet. Right?
Yes. So that's right. So we're talking about tools in particular. Such as this design, for example, I can. I had a friend call me from the Gartner Enterprise Architecture conference, he said, I've seen this great tool, eh, at the conference, should I buy it? I said, Okay, so tell me what you're going to do with it. How will you? What what are you going to? How will you use that in your team? What's your plan, and you didn't really have a plan. He just thought it was cool. I said, before you do that. Develop a plan. So that you're buying a tool to do some kind of a job if you are, if you're going to be pounding nails into wood, you don't go out and buy a screwdriver that you make sure you understand the requirement. And he hadn't thought about that. I think he did wind up buying the tool. But it was a few months after they'd sat down and thought about it. And that's, that's the issue in modern software tools. And I've designed and dented those I've sold those bought those. Everybody with a big software tool is is constantly trying to extend the functionality and make it better and more interesting and more and more complicated. So they do a lot of things. But what do you need it for most of this, most of the people buying big enterprise tools like that need a specific subset of it every day. If you are going to use it for enterprise architecture, which is fundamentally about communicating in a consistent way and about capturing data about your architecture. Before you fire tool, you need to decide what are the communication styles and structures and templates that matter to my company? What is the data that we need to gather to Do the kind of work that we were meant to be focused on why we're here. So this bank I'm talking about is, is a business on customer, we worked with them. And we, they had done on a lot of training about which what the buttons do. But what they didn't get out of that is, how do we do our work using it. And we help them with that their work was developing architectures for how to migrate a lot of interconnected systems into the cloud. But that's a very specific kind of problem. And because these tools are so rich and powerful, you can think of lots of different ways to describe how you would do that using the tool. But if your team is going to be effective, you will have to use the same templates, you'd have to use the same common workflow. So you're working as a team, not just everyone pulling their own direction. So that's something that no tool vendor can give you, you have to figure that out for yourself. And that's the, that's part of that capability. So if you say, Well, we are, we are doing this work primarily to support an aggressive company that is trying to grow by acquisition, and usage needs of standard ways of modeling, how you're going to integrate the technology and operational parts of those companies as you acquire them. And hopefully get some repeatable ways of describing that. If that's what you're doing, then you can go look at a tool and a methodology and say, These are the things we need to major on, and know how to use and be good at. And these are the skills we need to bring in and then you're in, you're able to help otherwise, you may find yourself floating off into the clouds.
And I think, you know, not only do we have, you know, kind of the internal alignment, but you also have, which is such a fast pace. You know, technology is moving so quickly, everything is changing. Honestly, by the time we wake up and go to bed, something's changed, right? So how can we do architecture governance in the Agile world?
Well, the governance just as we talked about a minimum viable capability, we also talked about building Minimum Viable architectures. So that the core function of enterprise architecture is to lead it is to support a holistic design, see around the corners, understand how some something that people are working on fits in with everything else. And also to protect the organization by guiding the architectural design work away from Cliff edges is various cars, which is sort of what we call governance. And in order to do that, there is a an old style impression of an architect who is sort of the policeman. And if that was the right way to do governance, then every intersection would have a policeman watching, for people who run the stop sign or something, you can't do that. That doesn't work anyway. What you need to do is agree with the people who are doing the development work? How are you going to help them to help you? And how are you going to help each other to be successful what we try to achieve? So if if you're doing continuous deployment, you're constantly pushing new code into production in very short cycles, then you can't expect the everything to stop for a week while you do some kind of review. Every time they change something. What you need to do is figure out how do we govern the way that this is done, so that if someone is going outside the outside the guide, Rails will know about it, and we can help them not get too far out. And so that you have to be more engaged, you have to come out of your ivory tower if you're anyone. But it's very possible to do that.
Well, now you kind of also explain this idea of you know, now you've got your big rocks, and now you need a big rock battle plan.
Yeah. When we teach people about Enterprise Architecture, they come in thinking we're going to talk about code and stuff. We not talking about code. There is no code. We start with no your stakeholders, who are the people, in your context to our says have a significant interest in what you're doing. I think it's quite useful to think about people who can veto your idea once they learn about it. They shouldn't you shouldn't be hiding from them. You should bring them in. If you bring them in and they immediately veto your idea. and your sponsor your sponsor for you, then you've probably overestimated your scope of authority. Yeah, so that's these, this is a self correcting problem, really. But it's better to find out early, if you're wrong. But what we need to do is, make sure that we know what the key stakeholders care about what they want, and do our design work in order to support them. And in order to help them resolve conflicts, most people who are asking for Enterprise Architecture were are fairly senior people. Most of them are not very knowledgeable about any kind of details about the implementation of complex projects, certainly not technology details, especially if we're dealing with new things. So as we go through the design processes, figuring out how to get from A to B, we need to keep explaining to them what we're learning about it, what's possible, what is possible. And, and make sure we keep them on board, every single large project has at least two fundamental requirements that have to be followed that are totally in conflict, because of the stakeholders misunderstanding each other. So this isn't what one says, This has to be introduction, by the end of the year, or the banking regulator will kill us. And the other one says, you're working on this new thing, you have to deploy it on the new platform that's going to be finished at the end of next year. Well, you can't do both of those things. The part of the architecture skill is to help the stakeholders resolve those kinds of issues. Very few people have the big picture. View, that's that's part of what you bring to the table. So if you understand the stakeholders, you understand what all of them will need in order to be happy with the outcome, there will always be big issues that surface, you have to help them with that. And work through that. That's that's a lot of the job. So it's not, it's about people, first of all, and sometimes people who come into an Enterprise Architect role, because for the last 20 years, they became the best network engineer that anybody ever knew may not have the people skills to suddenly do that kind of thing. That's an, again, part of your what is your EA capability, if you're doing work that needs lots of soft skills, conflict resolution things, maybe the best networking engineer in the world is who you need. But maybe this is general.
That's one of the most undervalued skill sets right in any job is kind of those soft skills and being able to get all the people on the same page, right and resolve conflict or move forward when we need to park something when we need to.
Absolutely. And it's very important. Another another skill that comes into play a lot that you have to be good at it is really hard, I struggle with it certainly is to operate at the right level of detail. Some people want vast amounts of detail and spreadsheets with 40,000 lines of pictures, two sides of the wall. Other people want three bullet points. This is part of understanding the stakeholders is to be able to service all these different points of view effectively. We're doing a training this morning. And one of the things we were telling people about is what's called a a concept diagram where you're showing, here's what we're planning to do. And the example I like is Walt Disney's plan that he laid out on the 50s, which you'll find on the internet is a diagram connecting all the different pieces of the Disney vision, theme parks, movies, music, cartoons, television, all of that. And they have these big nodes. And then with all these lines, connecting them showing how they're how they support each other and synergize. That's the kind of it's a picture on a page. It's an architecture on a page while Disney drew it and then he did it. And you have to be able to do that kind of thing to be really good at this as well as knowing all kinds of obscure details.
Now I'm gonna I'm gonna set you up and we'll actually use set me up to set you up. Because you probably need a tool right for success. So once you get everybody on the same page to find goals, KPIs, what's around the corner, like defining all of that. Now you actually need a tool or set of tools to help you achieve success.
You do and mostly the teams have about half the EH teams in the world. Their tool set is Microsoft Office, including Visio, and PowerPoint and Word and Excel. And those are the tools that are typically used to capture data and to to provide data back to people. That doesn't scale. Yeah. And and it is, you wouldn't keep your payroll system and an Excel spreadsheet.
Yeah, I hope no, but I hope not either.
So and especially if you're dealing with anything at scale, where a lot of the data that you're working with an enterprise architecture actually is owned by other people. It may be the HR system, the authorization systems, an Active Directory, or something like that, that's owned by the security people. That will be the operational data that's in the Service Desk environment, and CMDB, project management data that's owned by project managers. And all that changes all the time. To understand the details of the technical landscape, you need to be up to date with that. And you need to be able to connect that. So for example, it's a fundamental part of the EA methodology to check to see whether your design has covered all the requirements. How do you do that? If you have a list of 300 requirements, and you have 1000, design elements, how do you make sure that all the requirements are connected to something, you do it with a database, in which each of those things is an object of the database, and you create an association between the requirements and that design element. And then you can run a report that says, show me any orphaned requirements that we need to think about, we forgot to include and it's easy to do that. If you're using Visio, or something, you just, it's impossible. And you will make a lot of mistakes.
So by hand, I would assume, right?
Well, yes. And also the almost all the architecture artifacts that we showed people, the diagrams, big tables and things like that, if you're if you're keeping all your architectural data in the tool, you can generate those things from the tool, there's are reports on a database, rather than a picture that somebody drew, probably even generate that Disney picture. But there are some pictures you can't generate, that are just artistic, and sometimes those are really important. But most of the architecture data that we collect, should go into a database where you can manage all the relationships. And most of the architectural information that we present to people should be generated out of that database. Maybe it'll generate a diagram that's a bit ugly, so you can move the boxes around if you need to. But you should shouldn't be doing it in PowerPoint or something if you're serious. So yes, you do need a real tool, and that we tell everybody that they need a real tool, they need a, a solid methodology. And, and they need proper skill set for the scope. And the expectations that they're working with. They have all of that, then they have a chance of being successful.
Well, that is certainly true. I mean, going back to your you know, F 16 analogy where you can know all the buttons and everything of a fighter pilot, you know, cockpit, but still don't know how to fly the F 16. You also can't get into a single engine prop plane and expect that airplane to fly like an F 16 as well. Dan, thanks so much for coming on the show today.
Dan, it's been a pleasure talking to you kind of picking your brain as you have over 35 years of experience all the way from a you know, probably a single man show all the way to Fortune 100 companies and like we said in the intro have seen everything in between when it comes to setting up a successful EA team. And hopefully, there's an Enterprise Architect that's you know, either they're trying to start a practice they're sitting on a team where things feel like it's just spiraling out of control. So hopefully walking away with some just good nuggets of practical, you know, things that they can take to their own team and say, oh, wait a minute, we're not all on the same page, right? Like we're, you know, somebody's over here in left field I'm in right field someone's playing centerfield. We're not all on the same page doing this and that the other. So I really appreciate you diving into just making sure that people understand that it it really does come down to alignment, right like making sure everyone is aligned, and then clear and consistent communication around that alignment to continue to move the needle forward.
Well, welcome back to another episode of the Enterprise Architecture podcast by biz design, I am your host, we'll Hardison, the mark one of the marketing managers here at biz design. I've got a very interesting guest with me today, actually, we connected through a listener of the podcast. So you know how, at the end of every episode, I encourage you to email podcast at biz design.com. With guests suggestions. Well, someone did that. And through some emails, and connecting and LinkedIn and conversations, I got to know my current guest, who is Dan Warfield, and felt like he would be a perfect addition to come on the show. So Dan's IT leadership career spans more than 35 years, he has had senior roles in r&d, strategic planning, enterprise architecture, software, product marketing, and IT governance for Fortune 100 organizations, including Lincoln, financial, Walmart, IBM, and dxc. He's also an expert in it for it and TOGAF standards, and currently teaches these certifications. He actually grew up in America, and is currently based in London. Welcome, Dan, to the show. How are you?
I'm great. Thank you.
So Dan, just by reading through that, and telling our listeners I mean, in I know this moreso, from the conversations we've had leading up to this recording is you have done a lot throughout your career when it comes to the enterprise architecture space, which means you've seen it all right, like The Good, the Bad, and The Ugly, so to speak. But throughout our conversations leading up to today, you know, one theme continuously came up. And that is what makes a successful enterprise architecture team. And I'm really excited to have you kind of explain your methodology in you know, kind of the pitfalls that you see teams fall into when they are planning a enterprise architecture, team and practice. So really excited. So I will give you the the layup here to go ahead and kind of go through your points, because I know Part one is laying a solid foundation. Can you kind of unpack that for us a little bit?
Yes, well, the issue with Enterprise Architecture teams is they tend to come and go, people have a big it mess. And they say, oh, we need some enterprise architecture stuff. So they let's let's create a team and teams get created. And if they do well, they are effective, and the chaos subsides. And then after a while they get rid of them, then they start over. It's like Phoenix. So that's an aspect of this. So usually, when you're setting up an enterprise architecture team, you're building on the ruins of the last one. And sometimes he's doing Greenfield. But in every case, there are three things that you have to understand before you get very far into it. One of them is to know your scope. So what is the breadth of your assignment? What are you actually being asked to do? Who are the top three stakeholders? Maybe top five stakeholders who who's paying for this? What do they want? What pain do they have? And you also then based on that need to figure out what kind of capability to do we actually need most of the people I've seen doing this kind of startup work for an EA team have not asked us questions of themselves or their sponsors and they get the scope wrong, they focus on their own problems or they get the size of their team incorrect and they set it up in the wrong way and then they have trouble with that.
I think I could draw some parallels you know, to my own kind of experience in marketing right I mean, in business in general and then I think that that is solid advice for setting up anything in business and marketing and sales etc is you have to understand the scope you have to understand who needs a seat at the table in terms of you know, from a decision making process and who needs to understand, you know, what is going on? And then you know, what are the end results like what are we looking for at the very end right? So, now identifying big rock Box is next. And what do you mean by that?
Well, what I mean by that is that. So I'll tell you a story about someone who worked for me or who I was a mentor for actually said to me, I'm applying for this other job in the company. And I put this little resume together. And what do you think of that? And I let him through. And I said, Well, what are they trying to do? She said, I don't understand. So well, actually, the only reason they posted this job is because they want someone who can help them with something, you know, what they're trying to get done. And she was like, I never thought about it that way. You should. Because that's, that's how that works. And so if people do team is an expensive strategic investment, it is not something that comes into life overnight. And the people are expensive, the training is expensive, the tooling was expensive, somebody should have made a decision if they're trying to do that about what they expect that team to help them with. And I had a meeting with a team, we were helping, I worked with a an international group of people who do this kind of consulting, and we were helping a team at US regional bank last year to try to raise their game. And we said, So tell us, what do they describe the corporate strategies and goals? What are they trying to do that you should be helping them with? Focusing on? As it did? You know, this'll they don't tell us that was fun, you should go and ask them? Yeah. Because if you don't know that, if you don't know who the people are, who are sponsoring you or who on your side, then then you won't actually know what to do next.
No, it's I mean, that's very true. I mean, if you don't understand what they want, and are looking for, in the end, you're just kind of running in circles, right? In no matter if you have yourself or if there's 15 people on a team, I mean, you are all just running in endless circles. And nobody really has a clear vision, right?
That's right. And if you are an Enterprise Architect, type of person, it's very easy to identify lots of things. One of the CIOs I work for, said, I don't, I'm not worried about the low hanging fruit, you can see the pumpkins as a ground. Let's start with those. And it's really important to clarify that because in any big organization, it's easy to quickly find dozens or hundreds of things that look like they need attention desperately. But most of them are not the really important ones to the to the stakeholders.
We actually use the saying, and it's I mean, we didn't coin it, but we use this saying on the marketing team here biz design, if everything seems important, nothing is important.
Right?
Yeah, that's right.
So you've got you've got your scope, you've got your big rocks, defining a minimum viable EA capability?
Yes. And so the EA capability, this is a textbook Enterprise Architecture stuff is that you need to understand what the, what the scope is for your team's existence? If you're the Enterprise Architect, what enterprise is that? Is that your whole company? Is it your local part of the company? Is it something that includes your company and other organizations, which often happens in public sector? So you need to know that you need to know what are the sort of, as I say, big rocks and things you have to deal with to be successful in the short to medium term. And then you need to look at yourself and say what needs to be in place for us to do that? That includes first of all setting up some kind of governance framework that makes sense. It includes picking the right methodology and the right tools, which could be software and probably should be software if you have the maturity to know what to do with it. It should include skills training or hiring people who have skills that you need so if the if the issue is that we need to get control of the belt that there's a at Walmart Walmart was challenged by Amazon they're the brick and mortar big store business was was under threat from from Amazon. And there was a perception there that was the kind of thing that makes people want to get any a change and look at the big picture come up with a strategic change suggestion that we must do something about this. That's we didn't have ecommerce we had. Big Box stores everywhere really, really successful ones. But Amazon's like the big three So, yeah, is that the big rock? Is that while you're there? Was it something like that? Is it we're terrified of AI, is it? We want to grow the company and by acquisition, and we want to understand how we're going to integrate other companies. So things like that. And those are usually Enterprise Architecture kinds of topics. The bank we were working with last year, is trying to move most of their core applications to the cloud. And that's a complicated process. It's also perhaps informed by a misunderstanding of what you're going to get when you do that. That's a different question. But so to define the, the, the minimum viable EA capability is to say, what is the governance model that we can use? What kinds of decisions that do we need to make? What skills do we need to bring to the table? What tools and methods will we have to use to get this done? And and then you, you need to put a price on that if you are trying to develop a new sales team for Ohio, you would make a plan on how many sales calls will you make? What kinds of customers will they approach? What kind of marketing support are you going to need in order to do that, and you would come up with a budget for that. And you'd say, well, we need this many people, these locations, these skills. And by the way, you want us to sell things to current part manufacturing companies, we don't know anything about that. So we did find some people who know that and bring them in, and the hiring will take a while. And that's that's what I mean by the capability, you define that you go back to the sponsor, and say, if you want us to move these big rocks for you, this is what it's going to cost to set it up. And this is sort of how long it will take. And at that point, you may find that you adjust the scope, or the size of the target, or you may adjust the size of the budget.
So I'm picking up a theme here, I'm picking up a theme, and I think the kind of the buzzword that we could use on that theme is called alignment, right? Like making sure everyone is aligned out of the gate. And even before the gate opens, you know, on budget on capabilities on the goals, key performance indicators that we're going to look at to measure success, the skills and you know, you've used it when we've chatted about the skills, and there's a big difference in skills and actually being able to use those skills, right. So I mean, I can understand and know what every single button in the cockpit of an F 16 fighter jet, what it all does and where it is and everything. But at the end of the day, I probably can't fly a fighter jet. Right?
Yes. So that's right. So we're talking about tools in particular. Such as this design, for example, I can. I had a friend call me from the Gartner Enterprise Architecture conference, he said, I've seen this great tool, eh, at the conference, should I buy it? I said, Okay, so tell me what you're going to do with it. How will you? What what are you going to? How will you use that in your team? What's your plan, and you didn't really have a plan. He just thought it was cool. I said, before you do that. Develop a plan. So that you're buying a tool to do some kind of a job if you are, if you're going to be pounding nails into wood, you don't go out and buy a screwdriver that you make sure you understand the requirement. And he hadn't thought about that. I think he did wind up buying the tool. But it was a few months after they'd sat down and thought about it. And that's, that's the issue in modern software tools. And I've designed and dented those I've sold those bought those. Everybody with a big software tool is is constantly trying to extend the functionality and make it better and more interesting and more and more complicated. So they do a lot of things. But what do you need it for most of this, most of the people buying big enterprise tools like that need a specific subset of it every day. If you are going to use it for enterprise architecture, which is fundamentally about communicating in a consistent way and about capturing data about your architecture. Before you fire tool, you need to decide what are the communication styles and structures and templates that matter to my company? What is the data that we need to gather to Do the kind of work that we were meant to be focused on why we're here. So this bank I'm talking about is, is a business on customer, we worked with them. And we, they had done on a lot of training about which what the buttons do. But what they didn't get out of that is, how do we do our work using it. And we help them with that their work was developing architectures for how to migrate a lot of interconnected systems into the cloud. But that's a very specific kind of problem. And because these tools are so rich and powerful, you can think of lots of different ways to describe how you would do that using the tool. But if your team is going to be effective, you will have to use the same templates, you'd have to use the same common workflow. So you're working as a team, not just everyone pulling their own direction. So that's something that no tool vendor can give you, you have to figure that out for yourself. And that's the, that's part of that capability. So if you say, Well, we are, we are doing this work primarily to support an aggressive company that is trying to grow by acquisition, and usage needs of standard ways of modeling, how you're going to integrate the technology and operational parts of those companies as you acquire them. And hopefully get some repeatable ways of describing that. If that's what you're doing, then you can go look at a tool and a methodology and say, These are the things we need to major on, and know how to use and be good at. And these are the skills we need to bring in and then you're in, you're able to help otherwise, you may find yourself floating off into the clouds.
And I think, you know, not only do we have, you know, kind of the internal alignment, but you also have, which is such a fast pace. You know, technology is moving so quickly, everything is changing. Honestly, by the time we wake up and go to bed, something's changed, right? So how can we do architecture governance in the Agile world?
Well, the governance just as we talked about a minimum viable capability, we also talked about building Minimum Viable architectures. So that the core function of enterprise architecture is to lead it is to support a holistic design, see around the corners, understand how some something that people are working on fits in with everything else. And also to protect the organization by guiding the architectural design work away from Cliff edges is various cars, which is sort of what we call governance. And in order to do that, there is a an old style impression of an architect who is sort of the policeman. And if that was the right way to do governance, then every intersection would have a policeman watching, for people who run the stop sign or something, you can't do that. That doesn't work anyway. What you need to do is agree with the people who are doing the development work? How are you going to help them to help you? And how are you going to help each other to be successful what we try to achieve? So if if you're doing continuous deployment, you're constantly pushing new code into production in very short cycles, then you can't expect the everything to stop for a week while you do some kind of review. Every time they change something. What you need to do is figure out how do we govern the way that this is done, so that if someone is going outside the outside the guide, Rails will know about it, and we can help them not get too far out. And so that you have to be more engaged, you have to come out of your ivory tower if you're anyone. But it's very possible to do that.
Well, now you kind of also explain this idea of you know, now you've got your big rocks, and now you need a big rock battle plan.
Yeah. When we teach people about Enterprise Architecture, they come in thinking we're going to talk about code and stuff. We not talking about code. There is no code. We start with no your stakeholders, who are the people, in your context to our says have a significant interest in what you're doing. I think it's quite useful to think about people who can veto your idea once they learn about it. They shouldn't you shouldn't be hiding from them. You should bring them in. If you bring them in and they immediately veto your idea. and your sponsor your sponsor for you, then you've probably overestimated your scope of authority. Yeah, so that's these, this is a self correcting problem, really. But it's better to find out early, if you're wrong. But what we need to do is, make sure that we know what the key stakeholders care about what they want, and do our design work in order to support them. And in order to help them resolve conflicts, most people who are asking for Enterprise Architecture were are fairly senior people. Most of them are not very knowledgeable about any kind of details about the implementation of complex projects, certainly not technology details, especially if we're dealing with new things. So as we go through the design processes, figuring out how to get from A to B, we need to keep explaining to them what we're learning about it, what's possible, what is possible. And, and make sure we keep them on board, every single large project has at least two fundamental requirements that have to be followed that are totally in conflict, because of the stakeholders misunderstanding each other. So this isn't what one says, This has to be introduction, by the end of the year, or the banking regulator will kill us. And the other one says, you're working on this new thing, you have to deploy it on the new platform that's going to be finished at the end of next year. Well, you can't do both of those things. The part of the architecture skill is to help the stakeholders resolve those kinds of issues. Very few people have the big picture. View, that's that's part of what you bring to the table. So if you understand the stakeholders, you understand what all of them will need in order to be happy with the outcome, there will always be big issues that surface, you have to help them with that. And work through that. That's that's a lot of the job. So it's not, it's about people, first of all, and sometimes people who come into an Enterprise Architect role, because for the last 20 years, they became the best network engineer that anybody ever knew may not have the people skills to suddenly do that kind of thing. That's an, again, part of your what is your EA capability, if you're doing work that needs lots of soft skills, conflict resolution things, maybe the best networking engineer in the world is who you need. But maybe this is general.
That's one of the most undervalued skill sets right in any job is kind of those soft skills and being able to get all the people on the same page, right and resolve conflict or move forward when we need to park something when we need to.
Absolutely. And it's very important. Another another skill that comes into play a lot that you have to be good at it is really hard, I struggle with it certainly is to operate at the right level of detail. Some people want vast amounts of detail and spreadsheets with 40,000 lines of pictures, two sides of the wall. Other people want three bullet points. This is part of understanding the stakeholders is to be able to service all these different points of view effectively. We're doing a training this morning. And one of the things we were telling people about is what's called a a concept diagram where you're showing, here's what we're planning to do. And the example I like is Walt Disney's plan that he laid out on the 50s, which you'll find on the internet is a diagram connecting all the different pieces of the Disney vision, theme parks, movies, music, cartoons, television, all of that. And they have these big nodes. And then with all these lines, connecting them showing how they're how they support each other and synergize. That's the kind of it's a picture on a page. It's an architecture on a page while Disney drew it and then he did it. And you have to be able to do that kind of thing to be really good at this as well as knowing all kinds of obscure details.
Now I'm gonna I'm gonna set you up and we'll actually use set me up to set you up. Because you probably need a tool right for success. So once you get everybody on the same page to find goals, KPIs, what's around the corner, like defining all of that. Now you actually need a tool or set of tools to help you achieve success.
You do and mostly the teams have about half the EH teams in the world. Their tool set is Microsoft Office, including Visio, and PowerPoint and Word and Excel. And those are the tools that are typically used to capture data and to to provide data back to people. That doesn't scale. Yeah. And and it is, you wouldn't keep your payroll system and an Excel spreadsheet.
Yeah, I hope no, but I hope not either.
So and especially if you're dealing with anything at scale, where a lot of the data that you're working with an enterprise architecture actually is owned by other people. It may be the HR system, the authorization systems, an Active Directory, or something like that, that's owned by the security people. That will be the operational data that's in the Service Desk environment, and CMDB, project management data that's owned by project managers. And all that changes all the time. To understand the details of the technical landscape, you need to be up to date with that. And you need to be able to connect that. So for example, it's a fundamental part of the EA methodology to check to see whether your design has covered all the requirements. How do you do that? If you have a list of 300 requirements, and you have 1000, design elements, how do you make sure that all the requirements are connected to something, you do it with a database, in which each of those things is an object of the database, and you create an association between the requirements and that design element. And then you can run a report that says, show me any orphaned requirements that we need to think about, we forgot to include and it's easy to do that. If you're using Visio, or something, you just, it's impossible. And you will make a lot of mistakes.
So by hand, I would assume, right?
Well, yes. And also the almost all the architecture artifacts that we showed people, the diagrams, big tables and things like that, if you're if you're keeping all your architectural data in the tool, you can generate those things from the tool, there's are reports on a database, rather than a picture that somebody drew, probably even generate that Disney picture. But there are some pictures you can't generate, that are just artistic, and sometimes those are really important. But most of the architecture data that we collect, should go into a database where you can manage all the relationships. And most of the architectural information that we present to people should be generated out of that database. Maybe it'll generate a diagram that's a bit ugly, so you can move the boxes around if you need to. But you should shouldn't be doing it in PowerPoint or something if you're serious. So yes, you do need a real tool, and that we tell everybody that they need a real tool, they need a, a solid methodology. And, and they need proper skill set for the scope. And the expectations that they're working with. They have all of that, then they have a chance of being successful.
Well, that is certainly true. I mean, going back to your you know, F 16 analogy where you can know all the buttons and everything of a fighter pilot, you know, cockpit, but still don't know how to fly the F 16. You also can't get into a single engine prop plane and expect that airplane to fly like an F 16 as well. Dan, thanks so much for coming on the show today.
Dan, it's been a pleasure talking to you kind of picking your brain as you have over 35 years of experience all the way from a you know, probably a single man show all the way to Fortune 100 companies and like we said in the intro have seen everything in between when it comes to setting up a successful EA team. And hopefully, there's an Enterprise Architect that's you know, either they're trying to start a practice they're sitting on a team where things feel like it's just spiraling out of control. So hopefully walking away with some just good nuggets of practical, you know, things that they can take to their own team and say, oh, wait a minute, we're not all on the same page, right? Like we're, you know, somebody's over here in left field I'm in right field someone's playing centerfield. We're not all on the same page doing this and that the other. So I really appreciate you diving into just making sure that people understand that it it really does come down to alignment, right like making sure everyone is aligned, and then clear and consistent communication around that alignment to continue to move the needle forward.
