The Fat Baby in the Water: Cloud-Native Enterprise Architecture (Ep. 072)

Episode 58 · 1:02:03 · SRT · archive.org · all Tanzu Talk

Hey there. I wanted to tell you about a new podcast we got going over here at Pivotal. It's called That Moment. Don't get confused like I was initially. It's not the moment. It's called That Moment. That Moment explores the pivot that changes everything, moments that open doors for discovery and growth, but also brings the looming possibility of failure. Each show features different leaders and innovators sharing their stories and taking risks in business life. It's, you know, classic Pivotal stories. Also, it's fancy with all the crossfading music and optimized editing. It's really some good pro stuff. So if you're interested in those kinds of stories about how people are wangling their way through all this digital transformation, DevOps cloud native stuff, go subscribe to That Moment wherever you get your podcast. But you know, for your weekly dose of unprofessional old school podcast rambling, let's get on with the show. So do you have, you got, you, you, you have kids, you know, you have like summer camp shenanigans going on? Yeah, I got one doing gymnastics, another one doing sports camp this week, then some tennis camp coming up. So now what is, what is the, what is the, the, the operating procedure in your family on a summer camp? Do you just pick a camp for them or do they choose? Cause you got to book this stuff like three years ahead of time or something. Like, so like, how do you sort through which ones for the kids to go to? Yeah. At this point it's been brute force since the, you know, it's like, Hey, you're going to take tennis camp this summer because you've never played tennis before. So learn something new. So we did that. And I also signed him up for karate, which he now likes. So yeah, at this point I'm picking them. And if he hates them, we dropped them. Of course. Is it, is this like canonical karate, karate, or is this one of these other martial arts forms? And karate is just a, like a Kleenex or a Google for it. No, it's traditional. He's not doing, you know, jujitsu or anything like that. Or the Taekwondo. Yeah. Huh. Right. Yeah. Yeah. You know, my, uh, my son, Cormac goes to Taekwondo, uh, uh, highly related. He's in summer camp this week as you might be able to guess, which means he can't go to Taekwondo today, the day he normally goes to it. But it is like, I, uh, I think there needs to be like a Harvard business review study of this tiger rock

franchise model. Cause they are, they're an effective business unit. And, and I think, I think one, I think there's a lot of money in that. The, uh, as we call him the big guy who owns it, he seems really happy. He's totally chill. Things are all right. And he's a good instructor. He seems like generally happy to be telling like, like, uh, six to, you know, 40 year olds had to like chop and kick stuff. And, uh, and, and then he's also really good him in the whole organization. It's sort of like telling you things you could spend money on. Right. So he's not, he's not like that, that instructor you might, you remember from Napoleon dynamite. Like he just seems to have a good business snack. And, uh, it seems, it seems like my guess for the, uh, this is why I want the HBR study. My guess for the martial arts business model is it's basically daycare, right? Or daycare and, you know, kids, like you're always dealing with a lot of kids. So, um, I have to imagine that the kids are the high margin, high top line revenue part of the business. And then as people get older, that becomes lower top line margin and, and lower, uh, what's top line margin. It becomes, becomes less profitable because the adults actually show up and there's fewer of them. But I think with the kids, there's a lot of kids and there's probably a high not show up rate. I don't know. I like your dissection of this business. I mean, it's not mixed martial arts. We're not paying kids to fight each other in a cage, which would be interesting, but that's not what that is. Yeah. Then they would have to pay the row of parents who are sitting there watching every, I mean, they would, we would have to pay to watch. Right. Exactly. I mean, that's a way to make some money. I'd pay 10 bucks a lesson to see, uh, to see that happen. Yeah. Go work out your aggression, little Johnny and Jane. That'd be great. Uh, well, well, uh, well this week, once again, we don't have a guest. So, uh, I, we thought we would look more into, uh, one of the ongoing research things we have my, my delving into whatever enterprise architecture is. I, I have some, uh, I have some more material that I've read through actual three-dimensional dead tree stuff. And then, uh, and then we've

have some collected things we'll go over. But first I was just, uh, I was just complimenting you on your ability to find news in the desert. That is the late summer. What's been going on there? Yeah. The summertime is funny because I mean, next week we could be talking about a, you know, a point release of, of windows notepad or something like that, but no, they're still legitimate going on right now. Uh, I started off with the, uh, Google cloud team opened up their London location, which is great. So it's two locations in Europe. I think they've got two or three more planned in the short time. And, you know, again, as always, they, the March goes on, but they also showed that, Hey, latency is a lot less, obviously, if you're closer to there. So there's good benefit to not just saying we have one location in Europe. And of course, when Google opens a location, it's multiple sites or multiple, whatever data centers. It's not just a facility. So yeah, they've got a nice redundant, uh, set up out there and it looks like most of the services are available already. Yeah. I wonder what the, uh, I actually know a, uh, a person who's in like local government IT. I think they call it council over there. And, uh, I wonder what the environment is for selling to stuff like that. Like, you know, here in the U S it's basically, uh, everyone's interested in optimizing their IT, but there's a lot of, uh, there's a lot of, I wouldn't call them regulations, but like a lot of not wanting to take risks. And, uh, so, you know, I was just reading and speaking of my, my dead tree book, I was reading a case of the city of Liverpool, uh, who you may remember as being funnily named and also where the Beatles are from and, and, uh, of them revitalizing their ERP stuff in the two thousands. And, you know, I hadn't read a good, uh, UK local government business case in a while, but it would seem like you open up your data centers over there in the UK. Now. I don't know if, if London covers all the bases, but, uh, over there, at least in that, that area, like, uh, uh, I I'm, I'm sure that meets some of the, the sort of like regulatory and risk concerns people would have. I don't know. I think so. They're big on data sovereignty there. So, I mean, there's a lot, there's a main reason people open up locations in Germany and then they opened them in England because

you know, a lot, there's some strict rules about taking data out. Yeah. You know, you know, not, not to, uh, not to nudge too close up to political stuff, but like, you know, uh, the, the, the release of like sensitive voter information sort of, uh, validates all that data sovereignty, freaking out that people have been doing for the past 10 years. That's a, that's a, you should probably control your data because it is just, it's tricky. Cause you just don't know where, I mean, whose network is it going over? Where is it at rest somewhere where someone walks out with a thumb drive? So I think to some extent, all this is theater because I think most people have no idea how their data is protected. Maybe that's just me. Well, you know, I like to keep my data busy. I don't let my data rest. Always moving, always moving in motion, always be doing stuff. Yeah. Yeah. There you go. Well, also, uh, there was, there was some more follow-up on the, uh, the Azure stack. So yeah, you know, like, uh, this is, this always excellent, uh, fun stuff for people who would listen to this kind of thing. We, uh, to plug my other, uh, part podcast over on software defined talk, we talked about it at length last episode and I'll put a link to it, but, uh, there's, there's some more perspectives you can get there. And, uh, you know, also on that episode, if you're interested, we talked about, uh, some container orchestration, uh, shenanigans and, uh, the, uh, you know, probably you and I have the same type of fun for like people like Matt assays column style. And, uh, he, he had a good, uh, a good, a good inflaming column about all this, but, uh, you can go see some commentary over there, but, uh, apparently they announced something exciting for us at their, at their conference over in DC. What was it? Yeah, a couple of good things. So this was this inspire conference. It was called the worldwide partner conference, which I've been to a couple of times before. This is a big conference. It's like, you know, how many partners is over 10,000 partners. I think they're the giant show, uh, our own Ian Andrews was there and said they actually used like three hotels plus the conference center. So big, big show, all kinds of partners, schmoozing, making deals. Uh, one thing was that we talked about, uh, with Azure stack that pivotal will be a launch partner with that. So pivotal cloud foundry on Azure stack, which is a good deal. And then kind of the more

interesting thing is we actually won an award because Hey, it's nice to win awards. So we were partner of the year, uh, with regards to consumption. So in terms of us consumption of Azure, PCF drove the most or pivotal drove the most. So that's pretty cool. Given we only hit the marketplace like eight months ago. So already one of the most heavily used things in Azure, I think it validates big investment in us 12 months ago at the same time shows that people like deploying big things at scale with us. So that was pretty cool. You know, that, that reminds me one of the few Grammys I ever watched. I remember at one point, all of a sudden they were like, Hey, let's have Dr. Dre stand up. Cause that guy has sold a lot of CDs. Number one partner for consumption there in the music industry. But yeah, it is. Uh, that's one of the things we were talking about on that, that episode is, uh, once, once you get this stack in place, as we kind of mentioned last week too, uh, it's, uh, you know, it's, it'll, it's interesting to see if you have this full stack that people have been talking about wanting basically private cloud, uh, how that works out. And, and of course to rehash a lot of what even you and I said last week, right? Like obviously being in pivotal, we know that people are building a lot of these, these, uh, private clouds on their own, but having like a fully unified stack, especially in the Microsoft area, right? Like that's another wrinkle is that, um, it's always been Amazon and, and, and Google and, and of course Azure, but sort of like behind the firewall, Microsoft stuff and getting, getting into that, uh, that market will be, will be fun to see it, uh, pan out. Now, the other thing I was thinking this since you, you work in, in, uh, in marketing, what we need to start doing, just if you, if you can write this down, maybe, maybe Richard, you can go up to your boss, Ian. See, I've, I've sorted that out. I use the right names. And you can say, we need, we need to get a few of these stack things that we can start shipping to conferences. So we can just have a little, a little box right there at the booth. You gotta have that box. There we go. Yeah. The other piece of that news, you know, if you put on your, I know you're an M and a junkie and, you know, do it, looking at financials is fun for you.

I just wonder, I haven't done the math myself, but it seems like this was a good ROI for Microsoft. They gave us a lot of money last year as an investment and we're already their biggest consumption partner. That seems like a good deal. That doesn't happen very often from my recollection. I mean, when do these companies plow money into startups or other things and actually see that turn into something outside of an IPO or an acquisition somewhere. So this seemed unique. I think that's actually a pretty cool story that maybe it's a not money down the toilet. Yeah. I always like that. I mean, sometimes you got to clear the toilet, but that's a whole tool they use. Correct. Wow. We're really going from, from Dr. Dre to toilets, covering the bases. This is, this is what happens when you eat a spicy bison hot dog before you podcast and have a cup of coffee as, as, as I did. That was my next password for a system. There's your, you know, I usually do this on the other podcasts, but every now and then I like to throw out a Costco tip here. If you buy the grass fed, you know, the grass fed, you know, well-employed, you know, hippie with a 401k natural beef, hot dogs, they have there, make sure you don't get the hot link ones. Now I like the hot ones, but when you try to serve those to your kids, you know, it's, it's hard enough to get the kids to eat anything. And then all of a sudden you've given them a hot dog, which they normally like. And they're just like dad, my mouth just burned out. And, uh, and then man, and then you got to come up with something else, maybe a mini pizza, but just make sure you get the ones that aren't spicy. If you got kids. There you go. Now quick, quick eat these jalapenos. It's going to calm things down in your mouth. That's probably. So speaking of huge amounts of spend, uh, you know, we also referenced, I think the, uh, the IDC black book the other day. And when I was reading through the press release, I think they've updated their black book and they were finding, what was the percentage? IT spending is up like 2.5% or something like that. Let's see. Yeah, I think it was 4.5. 4.5%. That's crazy. Don't sell it short. Yeah. Yeah. No, I, I, I just, I've been reading, speaking of MNA stuff, I've been reading the, uh, the stream of MNA news that comes out of four or five one research from, uh, Brendan over there. And, uh, and it's, it's, it's, it's the kind of thing that you shouldn't read because it's a very

rocky road. Like one, one week, everything's awesome. The next week, there's just not enough of it. And I, I often have a similar, uh, reaction, although I guess it's on a quarterly, yearly basis to the, the IDC worldwide spending update, because sometimes it gets corrected downwards and sometimes it's upward. Like it's always, uh, it's always a little crazy, but 4.5%. That's crazy. That's a, that's a CAGR for you. Yeah. These are big numbers. So even that kind of growth is pretty cool. So cloud seems to be driving a lot of that, you know, obviously the usual technology spend, but you know, mobile and hardware as well, but yeah, it's cool to see that. And that, I think they also mentioned it, uh, Asia Pacific leading a lot of this, this spend as well, because this is a global assessment, obviously not just us. Mm. Yeah. And, and that mobile is kind of a flat as they say, which, which you could take that as a bad way. But I think the, the current analysis, the, the, the, the shared analysis is that it means that there's a pretty much maximum penetration, which is to say, uh, everyone has a phone. Everyone who's going to buy one more or less has a phone. And so I think we covered that when we were going over like Mary Meeker stuff. That was a big, uh, interesting point she had. And then, and then also, uh, as, as they were covering, there's a lot of, uh, cloud infrastructure spend, which that's always depending on what you do with these numbers. If you're just like, uh, entertaining yourself with them, as I suppose I do, uh, like that's fine. Cause you want to see the total spend, but if you're more interested in the state, well, it's a small amount of companies that account for that infrastructure spend and it's some somewhat bigger that sell into it, but it would be interesting to take that chunk out of the spend as they kind of do in the press release and, uh, and see what the effect is. But it's, uh, you've always got to be careful. Like if there's a small amount of the market that accounts for a huge amount of spend, I mean, basically like, I don't know, I'm sure it's like Google, Facebook, Microsoft, and people like Salesforce and all, and all these other big companies, you got to, uh, yank out that to get a more realistic, uh, to revert to the mean of meaningfulness. There's this, that's my math pun right there. There you go.

The mean of meaningfulness. I got to work on that. Yeah. Yeah. You'll, it's your workshop in here. That's what this is. Uh, the, uh, last piece I listed was, uh, I'm just seeing more platforms pop up work day. The, uh, company there announced that they're doing a, I guess a platform as a service and the blog post will link to in the notes. So saying, Hey, it's time for us to have a platform for people to build on. And why not add a 67th category of paths for Gartner to identify? So this will be good. So, you know, it's just been interesting. Cloudflare did too. MongoDB talks about them being a platform now. And again, those things make sense. I'm reminded of the Simon Wordley comic about kind of each layer of the stack saying I'm a platform and the top layer is a platform saying, no, you're not. And so, you know, what is a platform? Obviously it can depend on context. You know, Uber is a platform for Uber eats and other things that kind of build on top of it. And all sorts of things are platforms. It's just interesting to see some of these software as a service providers or Cloudflare, you know, CDN providers now offering sort of application platforms and ways to build some customized things. It probably makes sense, but it's, uh, not going to make things any less confusing for people. Yeah. Yeah. No, this is like, like to add my usual, uh, context or color commentary, like, like I, it's an interesting, I wouldn't say a return, but like, you know, way back when paths was first an idea, right. Which, which I'm sure historically there's other things, but like you could kind of peg it with like Salesforce having their apex platform. And there were, there was like Google app engine, like, uh, some things like that, but it was essentially, uh, as, as you were doing, I used to call this like, uh, paths as plugin or whatever. There's all these phrases. No one uses anymore, like plugin and SDK. It's, it's, uh, maybe, maybe retro stuff will come back. That'll be fun anyways. Uh, but yeah, I mean, that is, that used to be the kind of like the only way paths was done. And I remember working on market sizing, um, when I was at four or five, one and analyzing them when I was at Dell doing strategy and, and pretty much all the meaningful revenue way back then came from these segments.

And, and then, you know, people like, uh, like Heroku and stuff like that. Uh, this is like four or five years ago. And so, yeah, it's, and then there was also service now, which is always positioning itself as, as a, as a platform. So yeah, it's a natural progression of stuff that if you're, I mean, every, every chunk of enterprise software more or less has SDKs and plugins. And so as they move to more of a SAS model, it makes sense that they would, they would have those things. And, uh, hopefully it makes them more sticky and, you know, make some more attractive platforms for more than just their original core thing, which of course means you make more money. So yeah, natural extension. And, and I, and I think, I think there's, there's a couple of interesting things to look at here. So one, uh, like I haven't checked in them on a long time, but as a notable example here in the making, like SAP is rewriting big parts, not rewriting, but making big parts of their stuff run on cloud foundry somewhere. Like they're a member of the cloud foundry foundation and stuff. And I don't know, maybe that's changed, but last I checked in there, they're doing stuff on top of that. And they are in, in theory, there's two things happening there. One, you get the private paths situation that as a Pivotal are always talking about, which also, uh, has the same thing. Well, similar thing that if you had a, a, uh, a SAS version of whatever's running there, you would have the pass alongside the public pass alongside it. And it would be interesting to see two things with that one historically, uh, when it comes to ERP systems, it's very difficult, risky and expensive to have add-ons to it. Right? Like, like the, the, the sort of like interfaces and often programming languages you have to use are like kind of esoteric to, to the normal world. And it's just sort of like risky to mess with them. And then the other, the other wrinkle is, uh, there's this, there's this, um, what would you call it? Core belief in, in the ERP space that once you start customizing it, that's the path to madness and destroyed ROI. Right. It's kind of like the equivalent in, in our,

our little cloud ops world is, um, uh, any sysadmin will tell you the best way to have a stable system is to never release anything. Right. And, and so the most valuable activity, customizing an ERP system is the riskiest. So, you know, I, I could see that there could be, uh, some improvements for the long-term viability of customizing things. If, uh, if sort of architected, right? Like in theory, a lot of the benefit of a bunch of microservices stuff is, uh, you kind of remove a lot of the intertwined dependency nonsense that causes customization stuff to, uh, not pan out. Well, I guess, historically you could look at like, if that panned out in service now, which is a pure, like SAS thing that you can customize. Like, I wonder how, uh, how much they get over those problems, but anyhow, it feels like, yeah, you end up with a tricky level of, I mean, it depends on the portability, right? I mean, when I, I've done a giant SAP implementation project at a large enterprise, and we did it in, I think a year and a half, which is among the fastest they had ever seen. It cost us a fortune. But the question was, where do you do customization? So in our case, we would just publish data out from it and then use an actual message bus to route things versus using SAP's built-in messaging engine. Cause that would have been a sticky mess. So, you know, you had to choose where do you customize things or where do you, you know, decrease your portability options by embedding it in that software you just bought. So it'd be interesting if these platforms let you have something that feels somewhat portable, or are these just more ways to glom on to the, the bigger product that you bought in the first place, the SAS product? Yeah. So which, you know, that's a good transition to our topic with, with the joke, like probably it's good to have some people, some function at your organization who can figure out if a net weaver is a very comfortable relaxing hammock, or if it's a spiderweb that's going to ensnare you and trap you. And it all depends on how you're going to use it and what your needs are and how you're going to implement things. It's not a one size fits all sort of thing. See, there's, there's my late 2000s joke there. That's go look that up kids.

Hey, it's interstitial mid roll stuff. I just wanted to promote a few upcoming pivotal things here through June, July, and August. We had the cloud native roadshow coming to all sorts of cities. This is a free day long event we do with Google that goes over what exactly cloud native is and how our customers are using pivotal and Google technologies and approaches the cities. And this is a long list. So get ready. The cities are Stuttgart, Dallas, Denver, LA, Seattle, San Francisco, Amsterdam, Seoul, Hong Kong, Sydney, and Singapore. There's a big list of dates that you can look at. You can check out the show notes for a link to it. Or if you just want to go and Google for pivotal cloud native roadshow, you'll find it pretty easily. We also have Spring Days Atlanta coming up July 18th and 19th. It's chock full of sessions for developers who want to learn more about the spring framework, cloud native style development, and of course, to be fully buzzword compliant, microservices. If you go to springdays.io, you can get more info. And that's the last Spring Days we're having so far that we have scheduled this year. So get that one in if you're over in Grits and Porkland. It'll be good stuff. Finally, while it's way in the future, we also have Spring One platform coming up December 4th and 5th. Now registration just opened recently for this. I think you might have missed the early bird thing for it, but that's fine. There's also still the CFP open. It closes on September 1st. Now, what goes on at this conference? Well, it's full of what I would call the suit track and the technology track. In the suit track, you've got case studies and managers and developers as well, but organizations talking about how they've transformed their company and what they're doing with cloud native and their organizations, how they're getting good results by switching over to doing things in more of a pivotal way. But then there's also plenty of events. For those of you out there who enjoy more nerding out and doing technical things to check out. I'm one of the chairs of the DevOps pipeline and monitoring track that we inform informally call it. We've already got lots of excellent talks queued up from the likes of Home Depot, Express Scripts, Allstate Northern Trust, and of course, plenty of pivotal people. I'll be speaking in that track, if that's anything. So come on there. Again, it's in San Francisco, December 4th and 5th. And if you just go to

springplatform.io, you can check it all out. And with that, enjoy the episode this week. Well, that was our choice. That was what we were dealing with. Was it NetWeaver or using the Enterprise Service bot? So those are real choices that architecture had to make. Yeah. Yeah. Yeah. Love it. I used to go to the, not to hold this back. I used to go to a lot of the SAP TechEd. That was like, that was like one of the more functional, awesome tech communities I ever got poked my head into. A lot of people don't get exposed to it because it's off in ERP land. But like, there were some like really happy people scurrying around there. Like, yeah, I presented a couple of those. It was actually at the beginning of my career, I got to go to Berlin for one and then in Vegas. And it was the first time I ever saw entertainers become corporate shills. Like to have Lenny Kravitz on stage screaming, go SAP. It completely destroyed my picture of Lenny Kravitz. Yeah. Yeah. Well, anyhow, so as I was mentioning, uh, I've, I've, I've done some more, some more research pondering, uh, in, into, uh, into whatever cloud native enterprise architecture is. And I thought, I thought we could spend some more time, uh, you know, instead of just pointing to links, uh, talking about it. Cause so awesome. So I major development in my research, Richard, I finished reading the 2006 blockbuster book. It wouldn't be a blockbuster, it'd be a bestseller, right? Maybe, maybe bestseller in its category of enterprise architecture, the, the enterprise architecture as strategy. Now it's by three authors. I don't remember their names, even though I have the book here, but whatever it's, uh, you know, I think it's a good book. So I read this book with the intention of like, so let me, I kind of, let me, let me re-explain a little bit, but contextualize, right? Like, so, uh, we meet with a lot of enterprise architects in, uh, in, in pivotal land here. And oftentimes, uh, you, you know, they're not always too thrilled about what's going on. Now thrilled is a little strong, but they're, they don't kind of take on the role that you would expect as like major leaders of change agents. Now this happens sometimes,

right? But they're often, uh, some, a group of people that you have to spend some time, uh, talking to and translating. Like once you do things in a cloud native devopsy, whatever way, what does the enterprise architect do? And, and, you know, so, so to, uh, to answer this kind of question, uh, and you know, beyond all the anecdotes and theories that I have, like, I thought it would be good to get a baseline for like, what exactly is in our enterprise architecture. And like, you know, like any good, uh, phrase like this, the answer is probably like, like, well, what do you want it to be? Right? Like, but which, which is not very helpful. So I, I figured I would go back to some of the classics like this book that really seeks to, uh, define that. And, uh, I think this book's pretty good. I read that one. Yeah. Yeah. Yeah. A few years ago. There you go. Like, like, so, so one thing, so part of what I'm doing here is to try to like, uh, uh, you can't really say troll anymore cause that's negative, but I'm, I'm, I'm trying to, uh, I'm hanging out a sign for people to send me information, not a sign like a symbol, but just like a Lucy sign. And, uh, yeah, like I, uh, after, as I was reading this book, I searched around for, you know, the phrase DevOps and enterprise architect and like cloud and all this. And I, I don't know if there's been any updated literature since then that sort of describes what this is, which is distressing. Um, so anyways, if someone knows of new things, that would be good, but let me, let me just give a brief overview and, and, uh, you know, I've updated, I shared my notes document. You can look in the show notes and I'm kind of collecting all my research, but I put my little summary, which is much more detailed. And, and so a summary of this book, and just until I find something new, I'm going to treat this as a, uh, as my, uh, my functional straw person of enterprise architecture, right? Now we'll see if this straw person ends up having a heart and ruling Oz, or if it's just a Socratic straw person, but anyhow, basically, so you got an, you got an organization now let's set aside government. So we don't have to, uh,

government and nonprofit. So we don't have to caveat about nonprofit motives, but just whatever transmogrify profit motive into government nonprofit motivations in your head. So you got a business, an enterprise. First thing that's not necessarily stated in, in our, our EA straw person is that it's probably big, right? Like this is, this is kind of a baseline assumption that you kind of start with. I think, I think the first thing we can all agree on is that enterprise architecture has limited utility, not to say no utility, but limited utility. If you're like, well, Spotify in year one, like, you know, like if you're, if you're like a little startup that's working on stuff and eventually I would argue, and maybe this is for another time, but I would argue that someone like a Google or a Facebook probably does have enterprise architecture. They would just never call it that, but they're, they're big enough and old enough to sort of have like how things operate around here. But at the beginning, having a, an enterprise architecture probably is not a good idea and just probably not needed. It's sort of like, uh, oh, whatever I'll, I'll dispense with silly analogies. Um, so, so you have a large organization. Now you got a business. Now the first thing that this book lays out that I think is valid, right? Is like, so you're going to use computers to help run your business. So you got that. The next thing you should probably do is like, how are we going to run computers to help the business? Well, let's back up. It's probably good to understand how the business runs. Now, what they call this is the businesses operating models. And, uh, so these operating models, they reduce it down to four, right? And, and like anything, it's sort of like, you know, there's probably 60, but that's a big book. So let's reduce it down to four and none of them are perfect, but it's just, you know, something to, to think about and it fits in a quadrant. We can all agree on quadrants, et cetera. So you got the form. Let's see if I remember them. So one, you have the, uh, they call it diversified or as we would call it in cloud native land, siloed. Now, again, when I go through these, hopefully, uh, when you, the audience won't

fall asleep, we'll see if I can keep Richard awake, but he did say he read the book. So, you know, that's true. That's right. But, uh, when I go through these, all of what I'm about to say is about the business with a little bit of it implication. So the diversified model is basically like we have a bunch of business units and they all pretty much operate in their own way. And they all pretty much have their own customers and products. And so we don't really have any commonality in the business and there's not really any, um, I'll just use it. There's not any synergies when using synergies in this case is basically like cost savings by doing the same things or ability to sell more stuff by the business units coordinating with each other. Um, you know, synergies. Uh, so no, I like that you pause there at least that you had to think about it because I go there or not. Yeah. You know, and then synergies in an M and a sense are different. And then synergies, if you're making fun of people is different, you got three types of synergies. So, uh, anyhow, so, you know, you look at a business like this is something like you could probably think of like Samsung, lots of Japanese conglomerates, GE, um, stuff like that. Right. Like they're just like, you can buy, uh, I, a 258 gig, like micro SD card from Samsung, and you can also buy a TV or you can go to like, you know, I forget if this is true with Hitachi. You can go to Hitachi and buy like a bulldozer or a hard drive. I don't know if they sell bulldovers anymore, but you know, you get the NGE will sell you a wind turbine and then also like a jet engine. And I guess those are things that rotate, but you know, they're all different businesses. Yes. Right. Yeah. Almost like holding companies more. Yeah. Just, I have a lot of different businesses. So you got, you got a business that's basically a holding company siloed business. Now the implication for it is sort of like, eh, let them be silos. Like at best the business as, as we do in the, uh, Dell technologies thing and at EMC before that, you might use the same expensing system and you might

use the same payroll system or not. Like, you know, when it comes to back office, we have a different, uh, um, like benefits like health insurance and other benefits system than people in the rest of Dell technologies have for strategic reasons. So, you know, who knows? Uh, and so then another model is the, I don't understand this model very well, but this is what they call the shared model. And I think the shared model, as they state it is the business operates as follows. You have a bunch of small, I think it's like a branch store thing, right? So you've got a bunch of usually geographically dispersed things and they all operate the same, but they have different customers. And I'm very confused about this one. Like they use McDonald's and seven 11 Japan as an example of this and bank branches. And so I think, I think this one is maybe the most affected by cloud stuff. Because I think the idea is that if you're a seven 11 store, a bank branch or a McDonald's, you probably, it's a franchise model. So you don't have a centralized data center somewhere that's all running the same software. You literally replicate that stack of software and it runs independently, um, or something like that. Now it might also be, go, go ahead. So I think like, if you go into a Walgreens or you go into like certain retailers, they have servers there. Yeah, exactly. They run as like little business departments. Exactly. So, so, so there's that model, right? So that, that's a business model that as we're going over has, uh, has things. So then you have another one before we get to the one that, you know, the, the, the big old honking one, the, the enterprise architecture, ivory tower in the sky, called coordination. And the coordination one is, is, uh, it's common out. It's like the reverse of the shared thing is you have the same shared customers and product that you're selling, but each unit operates in its own way. So it has its own operating model or business processes. And I think,

I, I think I forget the, I think maybe modern day examples of this would be something like, maybe like the way, or this is not modern day, I guess, maybe the way like an insurance broker works where like, you've got a centralized, you've got the same book, the same model at the central insurance company, but then they have franchisees like branch people who might use the same systems, but their relationship with customers is the same, or maybe that's a shared one. I don't know. It gets really confusing, but, but there, there, you know, Uber might be another interesting one, right? Where they're, they got the same customer base sort of, but anyways. So then you'll see where I kind of get chomp through all these when I'm done with my little monologue here. So then you have the unification one, which is like, it's all the same, right? Like we all, we all use the same stuff. It's all one unified system. And I think if I remember an example of this is, is like an airline design where like, uh, you know, what we do is we fly people in metal tubes. We have one process, one way of doing that. It's all basically the same and things like that. So all of the, I've already kind of gone over it, but the first thing an enterprise architect has to do is like, so how do we operate? Do we operate in a way where we don't need to unify it or a way where we should unify it? How do we share the data and the customers? How do we map all of this? And how do we computer across all these business models? So that was kind of like a not helpful, perhaps a very boring summary of it. But I think that part, as far as figuring out what enterprise architecture in a cloud native world is right, like that seems valuable, right? Like it does, you know, in the organization structure. And I mean, even to the, you know, your final category, again, when I was in enterprise IT for whatever, five, six years, even though we probably fell into the latter category, you still had manufacturing would do some of their own stuff different from, you know, legal in HR versus R and D versus whatever. So even though you were kind of using some commonality, you had little IT groups in each one, you still had technical leaders in each one. So I haven't seen too many companies that are totally holistic, that latter

one, where like, everybody's just, you know, doesn't matter where they are, they're all using the same tech. Yeah, I don't know. That seems a little more unique nowadays. Yeah, yeah. Yeah. So here's, since I, I looked up in the book, a unification when they use like Dow chemical as an example, but basically somewhere where like, I guess, pharmaceuticals are kind, probably kind of like this, where it's just like, you create one product, and you sell it to one group. In the case of a pharmaceutical, you're like, you create one product, you sell it to humans. Right. And so the process around that, the way you manufacture it and distribute it, and I'm sure there's regional differences and stuff, but it's sort of kind of all the same, maybe like groceries are a similar thing. But, but anyhow, I mean, I think at the meta level, sure. I mean, I went for a pharma company where I did this. And again, there were, I wouldn't call it unified, but in concept, it was, it's just a reality can't be. So, so then the next layer, and then, and then all of this, right, is, as I was writing in our notes, is, is, is a baby in bathwater exercise, right? It's sort of like when it, when it comes in a cloud native devopsy world, is it all bathwater? Or is there a baby in there somewhere, right? Like, you know, to use the idiom about don't throw out the baby with the bathwater. Nowadays, thankfully, we have drains that babies don't fit through. So you don't have to worry about that. But maybe that's automation for you. Anyhow, so then, basically, it follows from these four models that here are four different ways of managing your IT, which, which took there, there's like, I could go on for another 10 minutes about the models that they have. But as I was reading over it, basically, it's just a linear sort of gradient that you have of like, so how much do I standardize and centralize this? Right? Like, do I allow people to run all their own things? Or do I go all the way to the other end, where basically, like, we have three systems that you use, and you have to use those three systems, like everything is centralized and standardized. And there's all sorts of like routes that you go to that basically based on the models. But that's sort of like the next major, like, enterprise architecture thing. And again, this 2006 view that you're supposed to come up with. And then and then so you figure out what your ideal is. And then the whole rest of the thing is is about

just two things. And then and then, you know, I kind of pause about this book, we can be hammer about stuff. But like, the first thing is like, so, if you have a way of doing your enterprise architecture that you're not at, right, like you're, you've got all this siloed IT, that's not unified, and you need to unify it together for for business for strategic and cost reasons. How do you get to there? And like, how do you go through that path? How do you go through a maturity path to get to it? And then the third thing, as you have to do at the end of every book is like, so once you've done all this hard work, what is the reward? And then they have, they have the fifth model. And the fifth model is basically what all of us cloud native people go Yammer on about, which is like, now you can be super innovative and growthy. And they even have like, you know, the quotes of like, they don't really say mash up an SOA, but it's sort of like the not that we say that either. But it's sort of like the realization of that vision of like, if we had a perfect SOA or mash up, as as many of our customers say, like, I can think of something on Monday, and by Friday, I can have it in production, right? And that's, that's once you've gotten all the EA council has gotten all their their cats in a bag, then you can start having your cats go in a quick unified direction. Bad analogy. But, but so that's the end state you want to get to is basically what the cloud native people like are, are us are always promising. So couple, there's, there's a summary about there. Yeah, I mean, so one thing it's interesting, because 2006 is when we started to do cloud. So it's funny, this book came out before that shift really kicked in, I think S3 came out in 2006, right around then. So that was like pre cloud, like right on the cusp of that happening, as well as it wasn't a thickness of SOA getting going. And, you know, now we would say, you know, back then you were, you would ship on Friday, with an idea on Monday, because you found a bunch of reusable services that you smashed together and shipped. Now we would say you shipped on Friday, because now you have an automated delivery pipeline that cuts through everybody's stage. And it doesn't matter if that's not a reusable service or not,

I can build software better and faster. So I mean, same end state. But how we would get there is very different 12 years ago, 10 years ago that I think how we'd answer that today. I don't know if architecture has caught that though. Yeah, yeah. No. And I think that comes to the whole bucket of the, there is no baby counter arguments, which is counter arguments to enterprise architecture being valuable, which is like, the technology has changed so much that all the constraints that drove to this type of thinking, like, don't really exist in the same way, right? Like, like, as you were saying, like, we can do things so rapidly and resiliently, if that's with such resilience, that you don't need to put so much upfront thinking into controlling and centralizing and standardizing things, or something along those lines. And, you know, just conversely, though, you know, that those that EA discipline is still at the companies. And so even though you can technically do those things faster, you know, logistically, you can't, because you actually have more to have to cut through to make that happen. And it's, you know, you and I talked about this. It's funny, because I think, arguably, even what Pivotal does should be a godsend to people in enterprise architecture, because you're actually codifying patterns, you're changing how you deliver, you're simplifying your architecture. But, you know, it's a big shift to go from this sort of governance and control model to efficient delivery speed, right? It's not about IT efficiency anymore. It's about business productivity and things like that. And just for a lot of the eight teams, I've either been part of or talked to, it often morphed into IT efficiency and reuse and cost cutting. And how do we kind of squeeze the most out of technology versus how are we delivering the awesomest service for our customers? How are we actually tying it back to actual business objectives and measuring success that way? I think we just lost our way a little bit, and maybe we're starting to come back to that. So then that, like, as with all of this, right, pretty much everything I'm going over is like theories I'm floating out in so much as I have a position instead of summarizing other things. So there's, to run by you and the listeners, there's two, as you were saying, there's two

theories I returned to about, what were you saying, how it went wrong? Right? So, so like, again, going back to 2006, right, which is interesting, because that's the year I stopped coding. So if you think about everything that's changed since then, like, I don't have a lot of firsthand experience with, I don't know what, what a, what a pull request is. I don't understand what all that nonsense. I mean, obviously I do like, you know, uh, anyways, um, so it seems like, and, and, and they mentioned this in the book, they're very good about not actually saying SOA or web services. So gold star there. Uh, um, but I have a, I, one of my theories I returned to is that all of the good intentions of enterprise architecture were ruined by web services, data standardization and sort of like, uh, as we would say prematurely worrying about the schema and, and locking that down. And then what comes after that is having to deal with, um, you know, I'm sure there's infinite threads out on the internet that have long been deleted over on like the, you know, server side.com or whatever. Um, but, uh, you know, then you got these gigantic XML files and, and it turns out like, I like XML a lot, but I think I'm the only person in the world and, uh, you know, nothing like reading the X path spec that you should check that out. But anyways, uh, like people don't like XML and it's big and difficult to deal with. And then you got, you got the old, uh, DHH guy coming in and just like setting the fire that blows up all of this stuff. And then, and then we have JSON and YAML and then like, it's just like this sort of like, uh, enterprise architecture kind of gets isolated down this dark path that no one cares about. I don't know. I'm putting no one in air quotes. So, but it all kind of is like, we all got obsessed with data interchange and like setting the format, which people really didn't like and ended up slowing down things. Um, and again, that gets a situation where you throw out the baby with

the bathwater. Right. And then you're just like, whoever this enterprise architect person is, they're just, they flip the bozo bit and they're totally wrong. So I just think all of that's trash. Yeah. That's an interesting take. I mean, I, you know, back in that was when I was starting to really kick into architecture and, you know, on the surface, all that WS star stuff you referenced, you know, atomic transaction and attachment and all these things, it was probably an architect's dream because here's all these ways I can kind of design these high level relationships. And as a developer, I'm doing, yeah, not only massive XML, but SDKs didn't keep up and there was no interoperability between different platforms for these things. So yeah, it was this absolute slog that completely took everyone's eye off the ball, which was using technology more strategically. So, I mean, potentially that was just a big detour that took people into a weird direction. And all of a sudden, once developers were empowered again, gosh, I don't care about XSDs and I don't care about schema definitions. I just have some data for services. I just need to move stuff around. All of a sudden, architects are stuck holding onto schema as an XPath, meaning the developers moved on five years ago. And then, and then, so there's another thing. This, this gets the other thing that's from, from this idea, you can kind of, you can kind of, you know, you imagine you're in a pitch black room and you discovered some piece of bread and you're like, I'd like to make a sandwich out of this. And so you're just feeling out in the room for some lunch meat and cheese, or, you know, maybe some toasted tempeh if you're into that. So you're kind of searching around for something vaguely connected to this. And like, I think another criticism people have of enterprise architecture that is sort of valid related to the technology all the way up to it is there's not, there's not this strong emphasis on a strong feedback loop to, to sort of change how it is you think about the system and what you should be doing. Right? So the, the, my terrible analogy, uh, is that's all I do nowadays. It's really bad analogies. Uh, but it's basically like, so you put your W, your WS star stuff in place and you got your great schemas and it's really hard to change them. Right? Like as, as a developer, uh, you, you sort of like, here's, here's our consolidated services

backend that you can use to rapidly pull together things. And the developers are like, yeah, but this is really hard to use. And the enterprise architects are like, la la la la. I can't hear you. Right? And so like, it doesn't really change that much now. Maybe they wanted it to, but because of the heavyweight nature of the implementation, it's just like, we can't change it. And to put it another way, that there's no concern for usability, right? Like, is this a good way of going about doing things? And I think, I think this kind of like simmering, uh, I don't know, long forgotten about beef between the EAs and the dev teams is basically like, they keep giving us this technology that's not easy and useful to use. And then a follow on, I wouldn't call it a non sequitur, but, but once, you know, the ad hominem attack that gets into this is like, EAs have no idea what they're talking about. They never actually code anymore. So they keep telling me these things that I need to do, and they don't actually come down here and work on the projects, which, you know, in your, uh, your advice to enterprise architects was a key reoccurring point is like, you should come understand the new technology and how they're applied. If you're going to be prescribing this stuff. So now if we look at microservices, right, like, and, and this is like almost an old tired, like joke to be had, but it's sort of like, there's a certain point where you read about, uh, so what WS star and microservices, the chapter one of both of those books are pretty much the same. Yeah. And then, and then they go on separate paths. And I think, I think one of, there's two key things, at least in my mind that like, other than the tech, well, I guess there's three, one, the technology used for microservices stuff is all different in theory. And then two, there's the sense of like, we need something that's fast evolving, right. That, that can respond to a fast feedback loop of how should we evolve this thing and how should we change it? And it's kind of implied that like, it should be easy to use. There should be some usability to it. And then third, the other thing, which maybe this was originally back in the mid two thousands, but the idea is like, when we're

architecting these microservices, we need to think a lot about the meatware implications for it. Like, how does this affect the team doing things and how does it affect organizational structure? And this is why people talk about Conway's law all the time, right? Like how do people actually operate and how can we make sure that the, uh, the services they're using and how they're combining them together are compatible with how people think and how teams operate. And so, I don't know. I mean, again, it's like the goals are the same and it gets down to like the implementation seems, uh, vastly different. Yeah. It's hard to reboot this, this stuff. I mean, you've got a lot of entrenched thing. I mean, again, I think architecture has never been more important than it is now. It's not saying architecture isn't important. I think the old enterprise architecture is business architecture. I just don't see that as much anymore where those people designed the business. It still seems to be more it centric, but gosh, I mean, getting, as you mentioned, I gave some advice a few months ago for EA teams and you know, it is about maybe shrinking your workload because you know what, to your point, yeah, maybe I don't understand that this stupid spec, I just defined all the developers hate it because I'm on 14 projects, 3% a piece. And so I'm just dipping in once a week for a Friday status meeting. I'm not actually sitting in the room with them. So cut your project scope in half. Now, again, I, I was an architect on a 10 person team and a few thousand person organization. You were just always going to be spread all over the place, but maybe things have to change there and you should be on the high innovation projects, not just the kind of rope. We're updating our CRM system. Maybe that is one you dip in more and not the same. So I think there's just a different approach to how you staff these things, how you approach it. And then, yeah, these architects should be technically aware. I remember when a great architect, who I still respect, he's awesome, but came into a project room I was in and I was sitting with the developers and said, what is all this client side JavaScript? This stuff's a mess. You got to pull this stuff out. It's like, dude, I mean, I know you haven't coded in a while, but that's where the logic goes now. Like it's not all server side anymore. This stuff needs to sit on the client. So it was just, it was just disconnected, right? I mean, architects can't be so disconnected from the tech their developers are using, or you become, you know, I don't know, just a casual observer versus someone

who can change things. Yeah. Yeah. So let me, before we wrap up, let me float. Yeah. That's good. So let me, let me float my current, uh, unified field theory of cloud native enterprise architecture. Right. And again, this is all theoretic just to like throw something up to see, uh, to see what survives the, uh, the, uh, the, the come at me action of, of the cloud native kids. Uh, that's all with case, I guess. Uh, anyways, uh, so, so first of all, it seems like, like, I, I, here's the argument that, that enterprise architecture is a fat baby, which is to say, there's a lot of it that should be preserved. Not there's some bath water to take out. And that is, so first of all, you mentioned one thing I forgot to mention. Uh, so this, this 2006 straw person, um, they don't really ever use the word custom written software, but they do spend a lot of time talking about package software. They don't even say package software, but you can tell what they're talking about is getting, um, Sure. Commercial software, you know, caught software, you're like software that you don't really customize. Right. So let's just take that off the table. Right. I think, I think, I think the two thousands, that was a huge concern, but in a cloud native thing, and this is actually like, I don't know if they'll accept it, but this was kind of like the, uh, uh, the, the topic of my, the, the column that I submitted for the the register this month. Uh, but if, if you just sort of like take all your commercial off the self shops for your cots and just like move that to SAS, don't worry about that anymore. I'll be, I'm being dismissive, but when it comes to thinking about DevOps and cloud native, that's not really your concern, right? Like you have to interface with it and do things with it, but it's not, if you're not running it on your own, it doesn't consume as many resources inside it as, as, uh, it used to. So anyways, we got that now, uh, what that means, I think for, for this, this unified theory of cloud native enterprise architecture, I don't even know what a unified field theory is, but it sounds good. Yeah. Is so it's probably a good idea to have someone in

an IT understand how the business runs, right? Like, like, and not just on a team per team level and not just on a business unit level, but to understand how the entire organization works, even if it's a big holding company, right. And to understand like what strategy in the sense of how that company would like to sustain itself and grow revenue, like what it wants to do in the future. Uh, and just to understand the goals of the business, how the business makes money. And again, you can translate this to government nonprofit stuff, but like, it's a good idea to kind of understand what's going on with the business, right? So that you don't show up with, uh, you know, you don't want the CIO showing up and saying like, this year we moved all the windows desktops to Linux desktops. How about that? Right. Right. So it's good to have someone who not only understands that, but, but, but can like, um, translate it into an engineering mindset. Right. And, and I'll, I'll, I'll point to a tweet where I took, I think there was some good enterprise architecture, uh, like global diagrams in this book. The Delta airlines one is the best because it's, it's very easy to understand. Cause like I was saying, I mean, their basic job is to put stuff in metal tubes and fly it from one place to the other. Right. And it'd be good if it showed up, uh, undamaged. Um, so you can kind of see where you can kind of map how it services, all of that. So like that role should probably exist. Now the way to cartoonize like cloud native people is they're all like, oh, we just have this emergent order of like the ants that like know how to get from one place to the other. And there's no, I'm, I'm, I don't mean to be making fun of Matt Stein. I'm just using him as an example, but you know, you've got this emergent order of things that, that, that happen that that's probably not the way that things pan out. So you have that now. Okay. So the next part is like, so someone has to define the business. Uh, so you gotta have that role. Uh, and that's what an EA usually does. So good for them. The baby's getting fatter now. Now the, the, the next part is that like, to the point that comes

up over and over again is like, so there's a lot of stuff changing nowadays, right? Like, but there's always been a lot of stuff changing and you know, you've always gone from mainframes to, uh, desktops to client server, to the web, to mobile, to cloud. And then, you know, you also had like exogenous things like regulatory things you had to do. There's always like every year, the pace of it has increased, so to speak, which is, which is a joke. It's there's always annoying stuff to deal with, right? Like it's, it's always that you had to adapt and change, but nowadays, like that's as true as it's ever been as they like to say. So it's probably a good idea as an EA to like, keep up on things and have firsthand experience with it because you're going to be prescribing how people are using these, these stacks and how they're using this stuff. And like, uh, you're not going to have any credibility to change people if you don't have firsthand experience now. So this brings in, uh, the, the, the other part, which I think perfectly aligns, obviously I'm biased having been here, but like, I think the major technological thing that's different that we've alluded to is like, so if you have like cloud, uh, there's a lot of stuff that is automated, centralized and standardized. So if you go back to those four operating models, like a lot of that thinking and managing that you do, like you don't necessarily have to battle for that. And in fact, uh, we sort of in the cloud native world espouse a pretty strong, I would argue enterprise architecture, which is, we'll just use the pivotal cloud foundry one, which is like, we have this concept of a value line, right? That I think, I think waters came up with that, but it illustrates this thing is like, so the value line is basically everything. It's kind of gray at the middleware stack, but it's, it's, it's somewhere in the middle of your middleware, right? And like below that, you should not worry about that stuff at all, right? Like you should just standardize on all of the infrastructure you have, the, uh, the sort of platform as a service you have all of this stuff. And as, as many of our customers do, you should have like, I don't know, five to 10 people who run

that whole thing more or less globally. It probably scales up to maybe like 50. I would imagine if you had like 20s of thousands of things you're running, but whatever, like you just have a, you standardize on like a very small amount of things. And then there's no, like, there's no like question of like all these different models that you have. Now, what I find interesting about this is I think, I think a lot of cloud native people who like argue against EA stuff don't realize like how, as we would say, opinionated of an enterprise architecture they're espousing, right? So it's sort of like, I think this is what makes the baby ultimately fat is, is the enterprise architect has to sort of like be like, that's our enterprise architecture, right? Like this way of unifying the way that we, and it goes even beyond pivotal cloud foundry stuff, right? Like the way that we do build pipelines, like we should standardize on that, right? Like there is, there's probably very little advantage, no matter what type of, uh, non, even a tech business, no matter what type of business you are to everyone having a different build pipeline, like maybe in a highly regulated industry, I think, you know, there's always exceptions, but pretty much like you should all be using the same build pipeline probably. Right. And then like, there's probably not that much advantage to using a bunch of like microservices frameworks. And there's probably not that much advantage to using different like infrastructure management things and on and on and on. Right. And so like, and again, this is like that value line concept is all of this stuff is commodity. So like, why would you allow people to do things differently? And so that is a very, like, if you remember the unification thing, like all this stuff, of course, us, different vendors have competing ideas of what that stack should be, but it's sort of like, everyone should use the same stack. And then you get all these huge efficiencies that you read about. Cause you're not managing all these different things. So I don't know. I mean, I feel like, I don't think this is always the case with enterprise architects, like for whatever reason. And this is part of why people have complaints about them. They're often, uh,

the boat anchor in the organ or at least they're perceived to be. So the boat anchor that's preventing, and then someone else is the champion for introducing all of this stuff. But it feels like if you go back and read the 2006 straw man, like the EAs are the people who are supposed to be like figuring all this out and driving it. And I mean, it seems like easily what, uh, they could slot in and, uh, continue doing because someone at an organization level has to decide to use whatever platform stack you want, uh, rather than it kind of bubbling up from the bottom. Yeah. But that's only my theory. Lots of potential there. I mean, they should pick up the SRE book and look at that almost as a form of architecture that happens nowadays. And just, there's a lot of ways that you can re, I don't know, reignite enterprise architecture as what it's supposed to be. And it's hard because you need support at the top to make that happen. But you know, I don't think we're ready to write it off. I think instead it can be awesome. We just have to, uh, yeah, follow some of those models. That, that, I mean, just, just as, as a last bit that, that raises the last thing that I haven't sort of figured out is like, uh, uh, and it's only alluded to a little bit in, in, uh, in, um, in this book and other stuff from, from the old, the old days, the old times, uh, which is like, I'm, I think nowadays, well, someone needs to be in charge of saying about talking about all the process stuff. Like, how are we going to operate and kind of like define that. And, and again, at least in pivotal land, right? Like we're pretty prescriptive about like, you need to have your balanced teams and you should do pair programming. You should work on a weekly cycle and do this. And so it is like that. I don't know if EA enterprise architecture stuff classically would prescribe things like process, uh, that globally. Like, I guess maybe, you know, there's always a lot of people, as I often joke, like, uh, large organizations always like to tell me how many scrum masters they have. So there is kind of that, that sort of like putting it in place. But again, I think it also goes back to that thing of like, but there's, there's not the chance to like relearn how to do things and reevaluate it and things like that. So I think that's another

missing link in the unified field theory of cloud native enterprise architecture is like, what role do they have in telling people what process to use? Which again, you could be all squishy about like, if you're a DevOps or a cloud native person of like, oh, that should be emergent ball of ants. But like, I'm pretty sure it's highly, there's, there's a highly prescriptive set of things you're supposed to do that, you know, Nicole and friends over there at the DevOps report, they got some good charts and they're like, you should do this stuff. Uh, and so like, there is some things to be prescriptive about there that, um, I don't know, maybe when the office, the PMO people come and they're upset and they think that they're just all water and no baby, maybe that's their job, but, but we'll see. So there you go. Well, I'll put a link to my ongoing notes and, uh, I have submitted a talk to several places, uh, saying that I'm going to describe all of this. So eventually I'll have something to say if someone accepts my talk and I'll, I'll hopefully publish something. So, uh, that's what we got to, you got, you have anything you want to add on? No, I think I said, we'll have a lot of pointers to some content and, you know, we know the people for spring ones, maybe we should get you on stage there. Yeah. Yeah. And it would be great to talk with anyone. Uh, so there's a lot of, uh, as we call them platform architects that I have lined up to talk to. I've, I've talked to, uh, to, to, to one of them already. He had a lot of good things to say. And, uh, there's a few other ones, but it would be especially good to hear from, uh, from people who are not just vendors, but actually like doing this stuff, whether they, whether they like think all this cloud native stuff is bonkers and we should go back to, uh, we wouldn't figure out what togaaf, togaaf is or whatever, or like people who have built this stuff up, but it would be, uh, be good to get that written down. Cause you know, I have a feeling that just telling enterprise architects that they're not needed anymore is, is like, not the answer. Like we got it. We got it. We got it. We got to get the fat baby out of that and, uh, and evolve it around. Cause like, you know, you probably would rather write software than figure out which type of the four business operating things you work with. You want to get someone else to do that for you.

So as always, this has been Pivotal Conversations. If you want to, uh, get the easiest way to look at all the past episodes, find the RSS feed to subscribe to and see what kind of corny spam bots have liked our episodes. You can go to soundcloud.com slash Pivotal Conversations with no space or anything. Uh, we've got a lot, a lot of fun episodes there, including the one last week we talked about. And also if you want to see the full show notes, we post those, uh, more or less every Thursday, uh, over at pivotal.io slash podcast. You can scroll down and find ours. We have a excellent, uh, commentary about a chicken smoothie innovation that last week that you'll see there. Uh, we'll see what quote we get this week. Uh, but it'd be great if you, uh, if, if you, if you subscribe to the podcast over an iTunes or overcast or whatever, and it's always good if you recommend it to other people and, uh, and post things about it. And, uh, you know, I insert our, our events and other ads in there, but, uh, check out the other podcasts that we have, uh, that the moment, the moment or that moment podcast, and then, uh, pivotal insights and, uh, pivotal life and other things like that. And with that, We'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.