Joe Gottlieb: 0:00

Hello, and welcome to another Higher Digital podcast. My name is Joe Gottlieb. President of Higher Digital. And today I am joined by two guests. Nicholas Eremita is Vice President of Enterprise Planning and Strategic Enablement at Southern New Hampshire University. And Jason Pyle is Vice President of Digital Integrations and Architecture at Higher Digital. Welcome Nicholas and Jason.

Nicholas Eremita: 0:22

Thanks, Joe . Great to be with you today. What do you want to talk about?

Joe Gottlieb: 0:25

Well, Jason and I have previously discussed the virtues of enterprise architecture along with some best practices, but given your experience, I'd love to go deep on how you see this discipline manifesting at your very innovative employer. But first, let's start with a brief description of that employer, Southern New Hampshire University.

Nicholas Eremita: 0:43

Yeah, thanks Joe. I'd say Southern New Hampshire University really stands by its mission, which is providing access to students, providing access to the students where higher education is not a given. And in the five years I've been here have really lived through the journey of growth of innovation and really kind of hanging on tight as this train moves pretty quickly in delivering products that people need in the business of hope as Paula Blank likes to talk about. And even through this pandemic, we've seen, you know, the demand signal for education continue to grow, and so pretty proud of what this institution stands for and really excited about not only what we're doing today in terms of innovating and meeting people, but really what the future holds.

Joe Gottlieb: 1:31

Wow, that's a great, great summary of one of our favorite institutions and reflective of the leadership we see there. We'll double back on a bunch of that in a minute, but first I want to go to Jason. Jason helped us set the table here. You've been focused on the role of enterprise architect in higher ed institutions. What do you tell our customers that enterprise architect provides for an institution?

Jason Pyle: 1:52

Yeah. Thanks Joe. When I talk to institutions, first off I talk about how the role of an enterprise architect has more throughout the lifespan, especially in the past five to seven years. Enterprise architecture started as primarily a very technical role. You thought of them as somebody specific to it within higher ed. But that's really changed over the past five to seven years. It's no longer simply a technical role that the EA really spends time and works directly with business users on what their needs are, and then bring a view, to bring a fair view to an overall view of the entire enterprise. So the entire institution , without that enterprise architectural view, oftentimes we're looking at, it's looking at the institutions in terms of products , systems, or silos. If you look at the entire enterprise instead, the EA is able to pull together cohesive plan. Um, that's going to deliver on the business needs of those huge business users that they work with. Um, an example of a big part of enterprise architecture is integrations. Um, without an enterprise view of integrations and institution often builds integrations between just between two products which doesn't really scale up as you had more and more products and have 20, 30, 40, or even a hundred products on your campus. Um, whereas the EA and their view of the overall enterprise , uh, ties all of these software products together , um, and helps you build an architecture that's scalable and allows the institution to grow in a responsible manner. Uh, another example is , um , looking at looking at data across the institution. Um, but by providing that enterprise view of the data, the institution can start solving problems that are challenging right now. Um, I I've been at many institutions and have asked the question, how many active students do you have? And oftentimes I get to hear , I hear the answer of, well, it depends on which system you look at , um, by focusing on the enterprise view of your data, you can provide single answers to those questions. Um, and that's some of what an enterprise architecture brings to higher ed.

Joe Gottlieb: 4:27

It's so true. Uh, so Nick, what's your take on this role and then really the need to educate business on the role and what it can provide? Yeah,

Nicholas Eremita: 4:37

My experience in the department of defense and the department of the army and the joint staff and the Pentagon oversees that. But the one thing is it's intimidating people, right? And it's like this big, scary thing. It's really, it sounds complicated, but it's really, it's really about getting rid of soda straws. It's like, you're going around and you gather up all their soda straws and you throw them out because those are dangerous things. So people, organizations, teams, platforms, responsible entities, accountable entities , uh, they've got created events and they, they stand by and believe that driving to success means that they're great graded event and moving their team forward, moving their platform forward, you know, enabling higher levels of technology , uh, is what they're asked to do. That's what they're rewarded for. And then they do the best job they possibly can. The problem is they usually have the soda straw in their hand and they look at the world through that soda straw, not because of mal-intent , but because that's what they've been asked to do. And as the enterprise architecture roles , uh, expand well beyond that, of just zeros and ones. Well, beyond that, of just educating people on things like service oriented architecture, well, beyond the, you know, the , um, the news conversations about how to , uh , manage data In innovative ways, it's really about bringing people together. Um, and that, that allows people to see problems they otherwise would not have seen if not been for the gathering up of those soda straws.

Joe Gottlieb: 6:10

Huh. So the soda straw is what is sort of what , um, sort of gives the tunnel vision , uh, so to speak , uh, from a particular point of view, given a context, right? And we are all, oftentimes we're overwhelmed by the challenges of change and businesses are trying to do this and that and the other. And so we unavoidably, wind up trying to do our part, and that's what gives us this tunnel vision, right? We're more focused on what we can move forward versus wow. Collectively what we could move forward if, if orchestrated that's where architecture comes into play, but you know, why do you think the concept is so elusive and this requires this education? Is there any inherent thing that's causing that gap in people's understanding or, or, or ability to, to adopt this discipline?

Nicholas Eremita: 6:57

Yeah, I'd say it, it's a couple of things. The first is , uh , we now, as, you know, folks in the, in that are trying to drive innovation through technology and business process, the challenge is to get the world view to change, right? And so that those worldviews kind of come down to, you know, systems thinking, organizational structure, and again, kind of the, the back to your corner effect when things get hard. So educating people in things that like a system of systems engineering is not easy. Those principles actually are , uh , are, are diametrically opposed to the natural phenomenon. You see organizations taking. So if something gets hard, you clutch onto the stuff that's important to you. System of systems engineering cannot work, unless those things are brought forward and released out into the parent system. So that's an education thing, right? And, and Jason and I are in the throws of that right now in a particular program where in order to meet the parent objectives of that particular system of system challenge, there will be the perception of winners and losers. Well , there's not right. And getting people to change their worldview there and that education it has to be okay. Cause right now the problem is if I, if I yield to the parent, because it's better for system X to do it versus me, then it's a perception of winners and losers. And actually what's happening is we are satisficing the solution, right? We're not coming up with suboptimal , autonomous subsystems that are going to end up hindering progress.

Joe Gottlieb: 8:38

Wow. It sounds to me like a big part of this is not just education, but even, you know, you could imagine people going through that , a lot of companies go through this personality , uh , whether it's Myers-Briggs or some other structure where they really think about how they differ personality wise and what their comfort zones are. And there's there , there, there , there danger or discomfort zones are , um, because that stuff is just reflex, right? Like, and so I just, when you were describing the collecting onto something that gets hard , um, immediately brought me to that place where I'm sure despite education, there are, there's a tendency for some people to still be uncomfortable and almost need to adopt new, new models of behavior, new methods to resist that, that reflex. And so this, how , how , how has this, how are you applying this at Southern New Hampshire university? I mean, I think this is what makes me so curious about that is because, you know, from the outside, looking in SNHU is clearly a leader. Clearly they're doing disruptive things. Clearly they're innovative, but I imagine on the inside, right, you've got no shortage of the usual challenges that reflect human nature in this. So can you tell us a little bit about that?

Nicholas Eremita: 9:57

Yeah, I , I , so , uh, the , the last five years we've gone through pretty major it modernization invested heavily. I mean, we're an e-commerce business in, you know, delivering education. Right. And so how do you do that? So the growing expectation of your learner does not , um, does not really bore them. So, so when you think about what's happening in the last 12 months of this, this global pandemic, let's just take the last 12 months. People are experiencing , um, modern , uh, interfaces with, you know, the , the , the big boys, big girls on the block, right? So your, your Amazons, your Netflixes , your Disney pluses, three clicks away, and I've got packages at my door and then I go learn and it's like, Oh, Hmm . So we compare ourselves to those experiences. So how do you remove friction? Right. So you do that through a lot of different things. You know, the, the, the modernization of technology is obviously one of, one of many components of that. The challenges , it's not about an it department. It's not about business process. Re-engineering, it's actually all of the above. So how do you actually, you , you rip down the silos and you take your name, tag offices. I'm an it guy. I'm an HR person. I'm a , I'm an admissions person and say, okay, we've got a joint team. I platform team that is responsible for delivering on experiences. So then all of a sudden the conversations change, right. Is that easy? No. I mean, if I were to go out and try to run 10 miles right now, I'd probably be sore tomorrow, but I got to do it over and over and over again for that soreness to go away for me to go. Absolutely. Of course, I'm running 10 miles a day. I'm not a runner. So I can say that. Um, so when I think about systems thinking, you gotta train, you gotta do it. You gotta show it. You gotta do it. You gotta show it. Or people will go back into those trenches. So it's gotta be up. It's gotta be visible. It's gotta be public. You gotta celebrate when it happens. You've got to point out when it doesn't happen. Not for , not, not as an indictment to say, Ooh, that's that's wrong. We need to actually think about multi-platform work, reaching across our technology and business. Not for the purposes of, did you answer my requirement, but to say, okay, how has this impacted our customer? How do these things so together to actually deliver something? Cause if any single platform wins, we lose,

Joe Gottlieb: 12:29

Right? So it's that, there's that constant in effect, there's this, there's this, you , you started by saying, rip off the badges and now you've got it . Now you've now the conversation changes, right? And so now people are no longer representing their function. They're representing the pursuit of the experience you're trying to create. But then as those, as, as you identify new experiences that you want to create, right, you have yet again, an opportunity to tackle it a new , um , so there's that there's that it , it feels to me very much like this iterative collaboration, how much , how much of this is , um, how much of this is unavoidably aligned with agile as a, as a , uh, change methodology. Um, and, and have you seen this work in more traditional waterfall , uh , approaches where you're taking waterfall and you're at least equipping it with this rip the name badges off. Let's have these collaborative sessions where we early are pursuing an outcome together. And even though we might be using, let's say more traditional tools for project management and change any, any opinion on that,

Nicholas Eremita: 13:53

I think I'll start off and give it to Jason and think it doesn't matter what the method, the systems engineering methodology is. Waterfall V model dynamic V agile. Those are neat. Those are nifty. People make money off of the approaches. I get it. And they work. The problem we see though, is people take the square peg and they think it's going to apply to every single hole they see on a methodology piece, set that aside for a second, regardless of the methodology, the composition and mental state of the team in terms of how they tackle things together. And don't think myopically has to be, has to be there. Yeah. And Nick, I totally agree with you. It's not as much the software development, software development methodology , um, you know, different methodologies have different strengths, different weaknesses. And, and even in my experience , um,

Jason Pyle: 14:52

I, I've never really followed a single methodology. We've started with , uh, around a single methodology, but we've always morphed it based on the way the team works and the feedback on the team. Um, however, some of the principles of agile do apply to the organization, even though the process does it , um, the ability to iterate the ability to , um, get feedback right away, the ability to respond to that feedback and make changes. Um, uh, for example. And so even though I don't think it depends on the methodology , um, the principles of agile , um, come into play here because agile is focused on quick iterative changes. You get feedback, you iterate on that feedback and it doesn't matter the methodology. If you're going to make it work for you, you have to have that process of continuing to self-improve on it, through that iterative process.

Joe Gottlieb: 15:56

Yeah. I like , I liked the distinction here between , um, mechanisms for , uh , implementing change and mindset needed to collectively align around what it is we're changing, right. And how we're prioritizing that and how we're achieving the outcome that we we seek. Right. So let's, let's push downward and make, do our bidding, the , the , the mechanism for that. But, but, but let us embrace this sort of, this , this mindset of , uh, of , of collective collaboration, but also iterative. And I think the other thing I, I often like to get people's perspectives on is then so if architecture represents great leverage over systems thinking, and, and let's say sane, thoughtful , uh, structuring of what it is that we want to do and how we want to do it, then really getting leadership to engage so that the experiences that we want to pursue and how those are drived collectively by a vision and how business events or conditions might represent new information, where we have to alter that while not being stuck with a five-year plan, that we can't get our heads out of. Right. So that's a really big part of this, too. Right? And so having, having leadership, engaging and playing their roles at the appropriate plug-in points to this collaborative frenzy, right in the limit in the limit, those things are, it's, it's pure it's happening throughout the organism, right? And there's no massive gap between leadership, execution, performance, measurement, outcome, et cetera, et cetera. I think that's what every organization is shooting for, but very few are accomplishing. And I think part of it is this in an increasingly digital world, the absence of systems thinking and architecture is one of the centerpieces of this struggle. You know , the , in the absence of that centerpiece , I think we have, we don't have a great mechanism for leadership to engage in. Um, and some, some, some organizations arrive at the mechanism first and it almost comes up from technology. That's why some of these, these software development methodologies , I think of have gotten a lot of attention cause under good position, under good conditions, they can rise up and actually give the leadership something better to plug into and steer. Um, but ultimately it is that it is that collective connecting tissue that we're talking about here. Um, interesting. Well, we could move on, we could get philosophical book that and go along , but let's, let's keep driving this forward. Um, you know, I , I like to ask all of our guests, you know, for at least one best practice. So, so Nick, you know, in this line of work that you do, can you share a favorite practice , uh, from your work in enterprise architecture?

Nicholas Eremita: 19:11

Yeah. So when I think about a best practice and how to also touch on some of the questions at the same time, when, when as, as a part of the program that we're running, that cuts across 40 different platforms, you know, a couple of, you know, 300 people working on this thing at any given time. When, when I think about decision-making , when I think about , um, tackling tough issues, you know, I got, I got Jason on speed dial, right? So Jason's there all the time. So our , uh , another , uh, great, great leader in the organization, guy by the name of Jay Cohen, who's an enterprise architect with this new shirt on like, he's there all the time. It's not like, okay, well we hit a problem. Call, call, call Jason. No , it's , it's, Jason's, they're the architects of the air . So when I think about how to move the dial and have different kinds of conversations, it's gotta be native. It can't be an annex. If it's an annex, then it's just like , uh , well, all right , we'll go check with those guys to see if it's not going to break anything. No, no, because it's like, let's design it in so that the questions come in early so that Jason's not going, dude , you really broke 10 things I could have flagged for you. You realize that that's not the best way to do that because you don't just, just turn the page and then the next team's doing it. So it's got to be native. And if it's not, then the conversations are far in . If you have foreign bodies entering into the conversation, what is this system going to ? It's going to reject foreign Bodies. Right. So infiltrate it, make it a part of the native organization. So every time you're talking about stuff, it's, everyone's used to, Oh yeah, come on, Jason. What he got . So it's not an afterthought. It can't be an annex.

Jason Pyle: 21:03

Yeah. And , and totally agree with that, Nick. And , um, in order to successfully look at things as an enterprise, it truly does have to come from the leadership is as you described in that example , um, and it's a different way of thinking for the leadership for the longest time, you'd look at it and you'd say I purchased X product. I have to implement it. I go to this team, they stand it up and we're good to go. Um, and that kind of thinking is what's gotten us into this world of , um, you know, hundreds of different integrations that aren't maintainable or , uh, enterprises that aren't scalable and causing a lot of these large , um, kind of transformation projects. And so when he bring in enterprise architecture, thinking to the table , um, it helps you plan that planning takes time. Um, but in the end, the savings as a result of that, proper planning pay off dividends in the end.

Joe Gottlieb: 22:13

Yeah. It makes me think about a trade-off that is probably all too often dealt with in the wrong way. And that would be if architects are scarce, let's treasure their time and let's invite them when we have an architecture question versus what you were describing. Nick and Jason, both is this very different situation where as I was listening to, it made me think about like, if you're, if you're a basketball player and you wanna , you want to execute an ally , Oop , without the opposing defense to know like you're literally twitching the most minute, not even a wink, like a wink would be too obvious, but you're like, you're cocking her head in a funny way. And the guy's going and you're throwing the ball up there and before anyone can react, it's dumped . Right. And so similarly, you just said, Hey, Jason, what do you got? Right. Like literally there's, there's, there's no context switching required because the architect I'm going to steal your term, Nick, I think you've heard, I've heard you say embedded, right. And maybe that draws on your military past, but, but if the architect is embedded, you know, you all have the context contiguously . And so rather you're spending the you're you're expending architect resources by putting that person there all the time. So you're, you're, you're, you're avoiding the temptation to reflex on scarcity. And instead you were making the investment to have that person there. So collectively you have a much better outcome versus trying to be maybe penny wise, pound foolish with scarce resources and therefore having a more specialized, but disconnected assembly line of, of, of contributions does that.

Nicholas Eremita: 24:06

Yeah. You also, you also then empower the architect with the richness of the context of the problems are solving. So that solutions come from everywhere. So if your enterprise architect is not immersed in that context, then it is harder to make that entity and native component of the work.

Joe Gottlieb: 24:33

And to your point about good ideas come from anywhere. When you share context, you also have shared your, your ideation and also your filtering of ideas. Right? Good ideation happens when there are no constraints on, on the brainstorm, right? It's constantly flowing and you encourage everyone with their diverse perspective to bring things forward. But as a group, you work together to now harness that, that diverse perspective to say, okay, that, you know , keep the good ideas coming, but that one ain't going to work for us. It doesn't fit the strategy, or we don't have the capacity or that's the wrong timing or whatever. Right. But you, but you're now constantly ideated. You get, you really maximize the contributions of all the diverse perspectives, but you also maximize the efficiency of your ongoing filtering. And as a result, kind of like that Al you analogy, right? You're just so much more efficient. And you know, it also reminds me that a lot of this craft is becoming more visible to leaders at a time when there's such a, a , a din there's a, there's a, there's a, there's an angry mob looking to eliminate meetings like meetings are bad. Well, guess what, you've got to meet to do this, right? You have to come together to have these conversations, to share this context to deliberate, to, to collaborate, right. And so well , structured meetings are good and necessary for this, for sure. Poorly structured meetings and, and the odd matrix of meetings you need to deal with bridging the gaps of a lack of immersion, a lack of embedding, you know, and therefore a lot of context switching, those meetings are bad, but anyway, I think there's, we often get lost in some of the sort of avant garde evolutions of the way business is being conducted. Um, while some of these crafts are becoming more visible to us

Jason Pyle: 26:37

Well in Joe BI and I, I've worked in both environments where , uh, like with Nick, At Southern New Hampshire where we're embedded in everything, and I've also worked in the world where , um, you know, the architect was really somebody who put out fires when the development team couldn't figure something out. Um, and by keeping the architect embedded , um, throughout the entire time, the organization, even though the architect has to be in those meetings organization actually moves faster , um, because the enterprise architects embedded and you're able to quickly make decisions and move forward , um , sitting in those days where I would get caught in and say , Hey, we have this problem. It might take a two hour meeting for me to fully engage in terms of what the problem is. And then another hour and a half to talk through. And now you've wasted half a day on a meeting. Whereas if the enterprise architects fully embedded and understands what's going on at the time, you have to make a decision , um, you can make it quickly and you can move on from there.

Joe Gottlieb: 27:48

Well, I think that sets up the, the, the, the next, probably the final, big question that we're gonna have time to tackle today. And that is so architecture as both a discipline I E. Um, and the , and the mindset that we've been talking about that can occur right. In , in terms of the, how we collaborate to, to , um, formulate the what, but also as architecture as the structure that we could actually draw that does reflect the constraints that we feel are going to serve us. Right. So I don't want to throw that concept entirely away, unless any of you are really ready to burn it right now. Um, I think that that's still a thing, right. But architecture champion limited to that. Right. And oftentimes if it's only that you don't get the other thing we've been talking about, which is way more powerful and extensible, but, but both of those things are precious and require work to get to, and you don't get them overnight. You , you don't, you can't buy them. Right. You've got to forge them in your culture with your discipline, with the way that you operate as an organization, et cetera. And so one of the things I like to ask architects for their perspective on is how, how have you been able to overcome the cost of architecture as measured by the impatient friction that has generated while trying to accomplish the benefits while trying to get to the first yields that are visible, that, that teach all the doubters a okay. Yeah, this is a great investment and there are great returns. So, you know, almost like a return on patients, exercise, you know, Nick, have you, have you been, have you had to face that down and, and, and help an grapple With that, that calculus?

Nicholas Eremita: 29:44

Yeah, of course. Um, uh , two , two stories versus when I was working for , uh , I was in the department of defense , working for a command that is no longer in existence called joint forces command at a Norfolk, Virginia, responsible for , uh , kind of a global service, the way we manage forces globally. How do you petty get the right troop to the right place at the right time, across millions of different entities. And they had , uh , subordinate commands that were autonomous subsystems , big, big four-star commands that were charged with. I provide forces for the army. I provide forces for the Navy. I provide forces for the air force. How does the joint force get provided? And it was interesting because I set out to knock down a bunch of stovepipes and was met with stiff resistance. And it took some time. But what happened was we learned, we learned about each other. I would, I would fly down to Atlanta, Georgia, you know, palms up going, how can I help fly back to Norfolk and go, did you guys know this was going on? No. Okay, great. So it's just , it doesn't matter how good the model looks. I mean, I'm a , I'm a DODAF guy, DOD architectural frameworks we use, right. So we'd go down there. We'd make a bunch of models. Is this, does this look right to you? Yes. That's actually what we do. Thanks. I'll be right back, fly on to Norfolk. Say, you guys are wrong. This is what they do. And it took time. It took time. It took time. So at the end of the day, it was people were then pulling like, Hey, I kind of liked the taste of that recipe. Can I get some more of that soup? What do you mean? Well, here are the things we want to do. How is it going to work with what you're doing? I'm glad you asked. So the story now is not demonstrating the benefit and justifying the cost. It's taking a chapter out of organizations that crashed up on the rocks because they chose not to do it. And all the stories everybody got those worst rides , right? Like, like I tried to implement this system or three years behind now. And it cost actually double don't do that. Okay, great. So how do I not do that? Well, I got this ingredient in the recipe is called an architect that we're going to , we're going to kind of dash it into the soup and it's going to taste a little bit better, but in the long run you're gonna be, you're going to benefit. Right? And so it's really looking at the examples of where that didn't happen. And then using the examples like you've learned a lot. Now, the problem is I'm trying to get that as a part of the budget process, how to get people to understand that it takes some convincing. It takes some selling. So sell, sell, sell, sell, sell, sell, sell, you have to. But at the end of the day, it's easy to demonstrate that because now people are really looking around going, all right, we can't have this conversation with Jason's on the phone, so you better go get them right now. So like that is happening. Now, people are pulling, pulling, pulling. Great. I'm glad you're pulling together embedded. I'm glad that it's native. I'm glad it's comfortable. We have platform teams that are big, huge platform teams going. Uh , I, I used to be able to solve this, but I know I can't now and be comfortable with the solution because I don't know how it's going to impact my neighbor to the right.

Joe Gottlieb: 32:58

Well, that's a common theme. You've just come back to Nick. If I , if I'm paying attention here, right? The same, the same behavior of ripping off the badges before, when we wanted to pursue a common outcome of a , let's say a student experience and, and this notion of how, how would you tackle like autonomous four-star commands, right. A slightly different context, but very similar at the end of the day, the common ingredient that I observed here is there's a, there's a listening to each other. There's a learning from each other. There's a, there's a recognition that is , there is a higher objective that we kinda need each other to, to occupy to accomplish. Right. And some of that, when you have time, when you have time and it takes time, right. Is it can be as simple as good listening and sort of demonstrable , um, application of what you learned from listening. Right. And so before, you know, it they're like, Hey , Hey, we'll come back here. Right? Like, like that, that felt good that we had an exchange. Right. And so now you're not so evil. You're not here to check up on me. Right. You're like, I , I think architecture, right? A lot of the first instinct of a lot of people when they hear that term is its constraints. It's rules. I'm going to be told, no, I can't do this. I got to conform to this other thing. Whereas what we've been talking about is literally an alignment, facilitation exercise. And you could argue that the purpose of architecture, when you really tear away all the, all the , um, the noise or remove the noise is it's about alignment, right? Architecture enables alignment. And it always fascinates me how organizations of large organizations of well-meaning individuals, you know, we'll come back to this one . I got the name badge on. I seize up, I go back to my thing, right. They don't want to do that, but, but the tension of complexity and the pressure to perform, causes them to do that. And so you come back to, wow. If we're listening to each other and we have a mechanism in which to take listening and apply it, that's what architecture is. Right. And it's maybe it's most basic form. Um, interesting. Interesting. Well , um, I would say that , uh, uh, any other final thoughts, Nick, Jason, other things you might, you know, you might add , uh, to the portal here. Uh, yeah,

Jason Pyle: 35:38

Just kind of going off of what you just said, Joe . Um, it is important for people to understand that the enterprise architect, isn't there to box you in or create a bunch of rules that you can overcome. Um, in fact, a big portion of enterprise architects role is to listen. Um, if I don't listen to the business users, I can't design an enterprise that is going to satisfy their needs. Um, and I can't constrain a development team too much , um , by putting undue burden on them so that they can't deliver on what they need either. And so all of enterprise architecture , um, in terms of what, what an enterprise architect does is a listening exercise. Um, and, and, and it's an iterative exercise. The enterprise architect doesn't always get it right the first time. Um, you get together with the team and you come up with an approach and maybe four days later, you run into a problem. Well, you go back to the enterprise architect and he talk it through and he listened to each other. Um, and automatically it'll come, come down to that solution. That's going to work within a scalable maintainable system, a system of systems , um, and get to that solution. And so it's not trying to fit people into like , uh , a box, rather it's listening and working together to come up with the proper solution .

Joe Gottlieb: 37:11

You know , it reminds me of , uh , of a notion that is typical and prevalent in the world , you know , in strategy work where I do most of my work. And that is, you know, any organization that's grappling with strategy. I E how is , how is it best going to pursue its vision , um, is often confronted with a choice between the best strategy you can think of and the strategy that everyone can get behind and understand, and really be aligned to execute on. And it's when you, when you , when you're, when you're around this long enough, you come to understand that the pie in the sky strategy that no one can understand and get behind while it may look the best. Um, it will always fail when it's up against the strategy that is well understood, well aligned, and people will get behind and be part of, and , and, you know , that's, that's, it's easy to make those, you know, between those two, those sound obvious, but when in the Mark , you know, in the gray skills, in between, you've got the tricky parts where it's like, wow, this strategy feels 30% better, but it's, ah , it's just outside of our reach architecture feels like the mechanism whereby we, we advisedly participate in the choice of what to do based upon the leverage that we see as in the systems thinking that, that we have going at our organization. Does that make sense?

Jason Pyle: 38:44

Yeah, it sure does. And , and proper enterprise architecture, architecture is a partnership with business users with any other team that they're working with. Um, and so it's not a, you know, this person instills all the rules, it's a partnership and you work together and you figure out what the best solution is for , um , whatever system of systems and however your system fits into that. Um, and so , uh , I can't emphasize that enough. It's a partnership, it's a conversation. Everybody has to listen to each other and we all come up with a solution together. It's not a single person dictating what needs to be done.

Joe Gottlieb: 39:30

Well, I think you've got the last word, Jason, that's a great way to bring this to a close , uh, Nick. Great to have you on today. Really enjoyed hearing your perspectives about SNHU and your past and architecture and Jason, always a pleasure to talk to you. So thanks for joining us today and , and to all of our listeners. Thanks for joining us. Have a great day, and we'll get you another time on another higher digital coffee talk.