A hopeful view of cloud-native enterprise architecture (Ep. 73)

Episode 59 · 56:36 · 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. You know, as time goes on, Richard, I'm finding it harder and harder to find about useful, funny things to just start to ask you about at the beginning. Sometimes I just give up and I just totally tank it. I had a great thing in mind and I almost wrote it down here. But I totally have forgotten what it is. But I want to ask you and, and, and guest, you can chime in as well. This morning, I want to, I want to, I want to get some consulting because you do a lot with, you read the internet and link to it. So I've been trying this maybe yearlong experiment that I should use my blog. You remember blogs? Those are fun, right? So I have my blog over at Coté.io because I'm trying to be cool. And every now and then over the past year, I'll try to like put all of my links on there with a little excerpt and then maybe put that in Twitter. Now I've been studying the traffic at my blog and it's like, it's like a red letter day if I get like 180 views and those aren't even unique. Those are probably just me checking on it. That's me hitting refresh. Yeah. And so this morning I thought this weekend, I've been thinking like, I've been, I've been, uh, uh, observing again for quite some time how like James Watters uses Twitter, right? Cause he's one of these people where I'm like, he has a lot of followers. What's going on there. Right. And not that he shouldn't, I'm just trying to study. And then you got, uh, you got that New York times reporter,

Maggie, Maggie Haberman, Haberman, whoever. And, uh, and she seems to be a big deal. Right. And, and then you got monk chips, James governor, who we'll talk about in a little bit. And I think the thing they all do is they basically just dump any link they're interested in, into Twitter. And in addition to being, you know, sort of like, you know, famous, you got that interesting. So my new theory is just like, clearly I've done a, uh, I wouldn't call it a lean startup. Let's call it a fat startup model on, on my blog usage, a, a medium batch process. The blog is just ridiculous. You don't want to waste time on that. Right. So, so this is, this is what I need some consulting on is I've decided I'm just going to start putting links just directly into Twitter. You think that's going to work out for me? I mean, I used to, I mean, I still, I've been blogging since mid two thousands. I still at least blog once a month, but I don't do the link farm stuff anymore. I used to kind of do that. Like, Hey, here's interesting stuff. And now I don't need to do that anymore. That's what Twitter's for. So I use it for long form and I'm sure you too, right. You're not going to do, please don't, don't tweet storm the Coté takes. Like I really don't want to read the slash 15 all of your opinions. That's horrible. So yeah, I think using it for straight up links is probably the right call. And I've also learned that people suggest that when you do include images in your tweets, you get significantly more engagement. And I've anecdotally seen that to be true. Now, you know, the topic we're going to get to is like, like, uh, some more enterprise architecture talk. The next logical thing, if you were, if, if, you know, in consulting would be like, well, what is your goal? I don't know what my goal is. Right. You know what, you know what I think my goal is Richard? I just want to have a lot of followers. Cause it makes me feel good. That's all. Hey, admit it. That's right. And I, I think, I think maybe by my birthday, uh, you know, this little security risk on the 1st of January, I might finally reach 10,000 followers. I don't know. I don't know. We'll see. I'm at like, not that I'm counting, but I'm at 9,918 or so today. So that's a good shape there. Yeah. Yeah. 10 years ago, I had a fairly popular blog. It wasn't that popular, I guess it was 2006 era. And it amazed me how much influence you could

get with, I guess back then there weren't that many tech blogs or something, but I, I think it just amazed me that you could, uh, I mean, I got invited to conferences, I got job interviews, you know, cause I was part of the rest community, which was a bit of a posse that we formed 2004 ish to, uh, to fight against the, the web services death star. And, uh, you know, it was all blog people. And I think, you know, eventually you make the arguments and you, and you get tired of it. And now all I get is complaints on Twitter that my blog's down cause they, they're referencing things over 10 years ago. Uh, man, you know, I am exactly the same way I got, I got my, uh, well, I got a bunch of minor breaks when I was still a programmer via my blog. And then I got my big break to be, uh, uh, a red monk, the first red monk employee, like because of my blog and my pod, my podcast to a limited extent, but I think that's why I've held onto it so long. It's just this fantasy, this fantasy of like the blog. You remember, anyways, it's a fantasy that I mean, my career, I think came from my blog as well. So I mean, I think the takeaway is it, we should all transport back to 2006 and start blogs. If you don't have one, that would be nice. Then, then, then instead of talking about enterprise architecture with our guests, we could talk about, uh, registries, UDDI, and, uh, maybe one of the preferred ways for automotive, uh, automotive. Well, I guess it would be for, uh, train maintenance people to send, uh, messages back and forth about the kind of wheels and trucks and that they needed in, uh, some of what they were in Ontario, but, uh, we won't be talking about you. Is it UUDI or UDDI? UDDI. UDDI. Yeah. I told people to avoid it then. I would say avoid it now. No, it's coming back. Well, speaking of what, why don't you introduce yourself guest? Hello. Um, my name is Stuart Charlton. I am an advisory platform architect at Pivotal. I live in sunny Calgary, Canada, and, uh, I have been, uh, doing various forms

of cloud and enterprise architecture and development for about 20 years. Mm. You see, that's a long span. It's going to make Richard and I feel comfortable. We got a fellow old with us. We'll talk about learning how to program, you know, in Pascal or something like that. That's what I learned in college. Yeah. Pascal. Yeah. First year Waterloo. Good old Pascal. Uh, well, we've got, as always, we've got a little bit of news and then, uh, we're going to talk, uh, some more EA stuff. So, uh, you know, I was excited. I forgot about this until I looked at your show notes. That's how effervescent my brain is sometimes speaking of putting links on Twitter, but it's actually very exciting because I've talked about the rack space, uh, managed service thing with pivotal cloud foundry. And every time I talk about this stuff, I'm always a little worried being a pivotal employee that I'm going to get it wrong that I don't have the official propaganda, but now wouldn't it be handy if we had like the head of pivotal product marketing to come explain it to us? Take it away, Richard. Yeah, it was a good thing last week. They had their, uh, rack space had this event that, uh, our own Ian Andrews was on stage and we did some press and talked about announcing a managed service for pivotal cloud foundry by rack space and rack space, you know, even before they got into the cloudy stuff, uh, I don't know, eight, 10 years ago, started offering IAS sort of capabilities. They offered managed hosting, they offered sort of managed services. And, you know, after the IAS thing kind of petered out for most everybody, but the big three, I think it seems like rack space really did a nice correction saying, look, we're going to also manage AWS. We're going to measure, manage Azure. And so they also just announced they're going to manage GCP, but this PCF on, on any of those clouds is pretty exciting stuff. So the ability to say, look, we're going to manage PCF, not just in public cloud, but you can even run it in your data center and rack space will manage it for you. So it's a really cool offering. Now at the same time, what's always weird, Coté, you probably know this too, is we, you know, we talk about, look, I can run these giant PCF environments with five people. And so your thought is, gosh, why do I need to use a managed service? I only

need like five folks to do this thing. Is it really that hard? And I think the answer is it's not that hard. It always comes down to where do you want to put your investment? And you still may say, look, we don't want to deal with upgrades. We don't want to, you know, even put those five people on it or 10 people or whatever. We'd rather have them embedded in teams. And so I think this is a good story for folks who like the idea of truly running platform as a service and have someone else taking care of all of it. You know, and at the same time, then you just get to do all your fun DevOps stuff down to the platform layer. Yeah. Instead of, uh, instead of like, uh, four to 10 people to manage your entire, uh, platform, you could have zero, just have, uh, have Johnson over in finance, send the invoice and then, then you're fine. So easy. Anybody could do it. Yeah. And then, and then there was another, uh, another, there was a double piece speak, uh, as I mentioned, speaking of, of, of our red monk buddies, I think, uh, I think, I think that in the, in this, in this, uh, pair up, you saw the, uh, the, uh, what would you call it? The classic, I don't know if there's a good version of a hydra. Have you ever noticed if you have multiple heads, you're always a monster, but it was a good, uh, um, uh, uh, multi-faceted. There you go. Even, see, even Janice is bad, right? Anyways, you, you saw Steve. Cerberus is good, isn't it? Yes. I mean, Cerberus is, is cool, but yeah. Anyways, let, let's call it, let's call it a friendly Cerberus, Cerberus, right? And that's, uh, there we go. Uh, yeah. Anyways, if, if listeners know of a positive two-headed creature, please send it to us. Yeah. Fluffy. Exactly. Fluffy from Harry Potter, right? Exactly. He was bad. Wasn't that, it was a bad guy, kind of. Yeah. Yeah. Yeah. Anyways, so you saw both, uh, Stephen O'Grady and James Governor writing the age old question, what's up with microservices and isn't it just SOA? And I think, I think, uh, what you saw from Stephen O'Grady there was good. It was, it was, uh, I summarized it kind of snarkily in a tweet that like, well, the developers didn't like it, which I think is a point that he made. Well, speaking of UDDI and, uh, also he had,

uh, I mean, this is kind of a, um, I kind of first saw Red Monk doing this trick and other people do it. And by trick, I don't mean to belittle it, but you know, just charting the interest in Google trends of SOA versus microservices. And, and there's also some sort of scatterplot things on there to add extra science to it. Um, kind of like, you know, sprinkles on a cupcake. Uh, but like, yeah, it was, and then, and then, uh, I think, I think James Governor gave his sort of like, uh, qualitative history of SOA and all of that stuff happening, but it was, it was one of the better. Isn't this just SOA write-ups, uh, that's out there that kind of explain some of the dynamics. And, you know, I also, I'm always curious with things like this to go back and look at, um, uh, what, what the market size for stuff is. And, and I was very lazy. I didn't actually log into Gartner to look up recent numbers, but you can find some old things that basically the SOA space around 2011 or so was like 19 or $20 billion in, in revenue, which is, uh, that's a sizable chunk of, of spend in it that, uh, I don't know. It'd be interesting to see what it is nowadays, but, but it definitely has waned in at least developer popularity. Sure. At least, I mean, at least a third of that was revenue from my book about SOA patterns. So that's most of that billion went, uh, these were really good pieces. I mean, it Stevens was good cause it looked at like, look, I mean, web microservices seem to have staying power because developers are, you know, it's more grassroots. Like this makes sense to how we should be building software. It's not this sort of consortium based WS star mayhem of what SOA became. But then I liked James's piece because at the same time, we always have revisionist history. I think sometimes when we think about things like this and James looked back and said, what was life like in that mid two thousands where we weren't doing test driven development that same way we weren't doing CI, you know, we didn't have containers, we didn't have public cloud. And so the world was different. You wouldn't have maybe done microservices 10, 12 years ago. It just, you know, SOA was a start of saying that we shouldn't have big monolithic systems. We should have decomposed set of services, but some of the other things weren't

as mature yet. I think it's important to remember that. Yeah. I think the biggest barrier I saw was we did all this work to decompose systems, but then we couldn't deploy them. And so we had, we wound up with the same monoliths that we were trying to get rid of. And therefore cloud came out, which was really just dogfooding SOA for it. It was like, okay, so we can't actually deploy this stuff. All right, let's pause and SOA our world of computers and disks and stuff. And then maybe we'll be able to SOA the business. How about that? Let's just wait 10 years. No, it's a great point. I mean, that was before we were really thinking of continuous deployment, DevOps teams and actually pushing it all the way through. So that was good. You know, the other quick bring up related to that, Coté, your point earlier about your blog, Governor, James Governor started writing every single day. And, you know, it just reminds you that as much as we all love hot takes on Twitter and kind of quick briefings and things, there's nothing more viral and interesting than long form thought. And I think that Red Monk's actually gotten a higher profile these last few months because they've put more content out there that people consume, not just quick takes. So I think it's a good reminder. We should be writing things down, not just always talking about it. Yeah. Yeah. So let's continue talking about it in the podcast, but Absolutely. No, you're right. I've appreciated the turning on the blogging there. That's good stuff. It reminds me of the old days of Red Monk stuff. We used to, I remember we used to go to, I'll give you a little anecdote, Grandpa Coté here. I remember the first few months I was working at Red Monk. I was trying to figure out what to, you know, how to blog and what to do. And of all things, I went to a BEA conference. Now, two things, one distraction. The badges they had, this is when they had, you remember their, I bet both of you remember this, they had their liquid architecture or something. There's something about it. Yeah, there you go. So the badges they had, they were one of these, it was like a normal badge, but they had one of those little pockets with like that blue, squishy, oily water stuff. Right. I was at that conference. Oh yeah. At the, uh, the palace. Now a starwood

joint. Oh yeah, man. That was, that was fun stuff. But I remember I kept that badge for way too long. Cause I was like, this is pretty awesome. But I still have my thick liquid mug. Oh man, you'll have to send us a picture of that. That's, that's good stuff. But, uh, I remember I had written some like raw notes from that and I posted that as a blog entry. Cause you know, to my mind, it'd be like, I just want to see everything that someone like me does. But, but James Wright was like, you know, you might try to string those into sentences. So so also, also, you know, I, I, um, I guess it's not coincidental because Kubernetes stuff comes up all the time, but there was, there's, there's a rumor that finally the last holdout for sort of like official Kubernetes stuff, or is it, or, is there a rumor or report report is just a fancy word for rumor. Is that the same number of characters in it? But it was saying that, uh, AWS might have some, uh, Kubernetes stuff built into it. Yeah. I mean, you know, there's a slow march to people adopting that at least as a container plumbing component, which I think our belief, even with pivotal and doing Kubo is this is great technology that should underpin a platform. It shouldn't be something you necessarily have to mess with all the time or you're probably not spending the right time, but yeah, I mean, Amazon may be playing with this. They've been the holdout, you know, I think to some extent, cause folks see Kubernetes is a great way for all the workloads to move to Google at some point. And if I'm Amazon, that doesn't sound like a great idea, but at the same time, you know, arguably no one's better in cloud at giving the customers what they want or even the things they didn't realize they wanted than Amazon. So if they see the groundswell for it, then they'd be dumb not to do something there. And, and I'll, I'll put a link to these two in the show notes, but there's also a good, uh, sort of historic thing. You know, I think it's something like two years of Kubernetes being independent. And then, you know, I need to go reread this again, but because it looks like it was like sort of an interview with a, an interested party. There was, there was a fun little write up in the register talking about how, uh, you know, you could use Kubernetes to like run middleware and do all these platformy things, which, which that, that sounds, that sounds like a good idea.

People, people should have a platform, but, uh, anyhow. Uh, and then, uh, there was also last week was Microsoft's, uh, announcement. What they're at like, uh, what is it about a, about a $19 billion run rate. What's a hundred million dollars between quarters, right? That's right. Yeah. Now the cloud business is going nuts over there. And so, I mean, obviously it buries the lead on some other stuff like windows stuff is just kind of okay. And obviously things like windows phone have cratered completely, but you know, and being ads are up a little bit, but I mean, cloud is the top line thing and clouds generating a ton of money. So that's, that's good news for, I think the market, because you always want to get, not have a monopolistic single provider for your cloud stuff. If you're not betting on Microsoft or putting them in your RFPs, you're probably doing yourself a disservice. So, so give me, give me a little, and, and, and if you have, uh, I mean, you, you too, Stuart would be good, but like what at this, this, as of now is a July 24th, 2017. What would you say the state of like, let's call it loosely.net, but Microsoft world development, what do you say this with the state of that stuff is going to the cloud? Where, where are we with all of that? Is it just like just a hundred percent gonzo doing it? Or like, how, how's the, the migration going? I mean, last week in Denver, I taught a, uh, a class to a bunch of developers who are teaching them.net cloud, native.net. Like, what does it mean to modernize your.net? So we had 40 something people in the room and you know, this was financial services mostly for the attendees. And for them, I think it was still new stuff to think of moving this to.net core, which is that new flavor that runs on Linux and windows and other stuff. And they're almost entirely on-prem still with their.net workloads. So, you know, I think like everything else kind of making its way to the cloud, but I think.net workloads are moving more slowly, just anecdotally since those shops have been, it's, it's more enterprise, a little more conservative. It's staying on-prem unless it's going to Azure, which is a, the sort of, you know, there's a stack overflow analytics last week that showed, Hey, if you're using Azure, you're probably writing C sharp. And if you're using,

if you're in the Netherlands, somehow Azure is your preferred cloud, but every other place, the most questions for a country goes to Amazon in terms of a tag. So it was just interesting to see, you know, you can only extrapolate so much from those things and stack overflow questions, but it's real data from, you know, tens of thousands of users. So, you know, it's interesting. Most languages are going to the other clouds more prominently, but C sharp and .net obviously going to Azure. Yeah. We got to get those red monk folks to start slicing up their language thing by cloud. Not only that, but that would be an interesting, uh, what do they call that? A cut, a slice. How about, how about yourself? Uh, how about yourself, Stuart? What up there in trailer park boy land, what's, what's, what's the state of Microsoft stack stuff? Trailer park boy land. Wow. Uh, it's there, there, so there's tremendous, um, uh, install base and they're not going anywhere. Um, there's a lot of passionate Microsoft developers and customers I see across, um, Canada and New England and New York. And what I, what I see the barriers to cloud for Microsoft are kind of the same barriers we saw in other languages. It's about, uh, security and it's about integration. And I find that they're, they've lagged a little bit. Like there's a lot of things in Microsoft land that assumed, well, you naturally have an active directory or controller. And naturally that sits next to you. And naturally you're installing this on a windows machine that has a name after a Lord of the Rings character or some it centric, crazy naming convention, it one, two, three PR East, something like that. Right. And so the whole system is based on that mindset of you deploy something and it stays there forever. And all the security is based on that. And so I think only recently you're starting to see, for example, uh, like Kerberos in Docker for windows and it requires like four pages of PowerShell to make it work. Right. So we're, we're going to get there, but there's a whole lot of technical and knowledge that has to develop. So it's a bit lagging, but I think it's going to happen.

It's just, uh, Microsoft's got their head in half around it. They got to, they got to tell that Snover guy, you can't retire yet. First, you have to move all the workloads. Once you do that, you can retire. But, uh, that, that guy's great. So, uh, also what's that, you know, I, I don't know anything about networking. So what's, what's this, uh, this congestion thing. I almost included that just for you. Cause I know you like to say you don't know the networking stuff. So I was, I was, I was just throwing you, just trolling you a bit with Google news. Now they ship this, uh, yeah, success, uh, BBR, which is not bash, uh, Bosch backup and restore, which is our BBR. It's bottleneck bandwidth and round trip is a new congestion control thing that Google created. And really the takeaway is, gosh, if you're a cloud provider, you have to continue to show differentiation. I just can't be a me too. Cause at some point that's just not interesting. And so how do I differentiate in this case, Google owns a giant network and they can ship now these new sort of algorithms that say, if you're running in Google cloud connectivity to our services, like big table or spanner or whatever is faster, you know, less bandwidth, and then even reaching down to the end user using their load balancer, their CDN is actually faster. So customers using Google products and Google cloud actually can get a faster network experience because of what they've built into that. So that's something it's just harder to do if you're Amazon or you're Microsoft, cause you don't own the fiber and you can't do some of those things. So that kind of a cool example, some great engineering to have a good blog post on that that we'll link to in the show notes here, but it's a, again, I like when people take advantage of their assets and make those competitive advantages and don't just dumb it down and make it a commodity. It's a huge deal. Almost every major customer that's on a public cloud, whether Azure or AWS or GCP, and I've stood up all three for Pivotal Cloud boundary. The number one challenge is networking and getting that right and getting that fast and dealing with all the bugs. So that, yeah, I saw that. That's going to be a big deal. That's exciting. Yeah, that does seem like a problem. Hence, hence my continued ignorance of it.

Leave that to other people. That's right. Hey, it's interstitial mid-roll stuff. I just wanted to promote a few upcoming Pivotal things here. Through June, July, and August, we have 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 pork land. It'll be good stuff. Finally, while it's way in the future, we also have SpringOne 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. 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 informally call it. We've already got lots of excellent talks queued out 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, so I don't know. You know, last week we were talking about enterprise architecture and I'm trying to figure out how it maps in the cloud native world. And since then, you know, we had our episode last week. I also have I've done an episode with with a former pivotal person, Matt Walburn, where we talked about it. We'll do a second one. I think that'll be fun. And then also, I guess on Friday or maybe it was Thursday. I don't know. I had a recording with Matt Curry of Allstate and our very own Andrew Clay Schaefer just talking about it more. And I think I think in that episode, I or the three of us, if you will, sort of forced ourselves to finally trot out a complete theory of it. But I'll put links to those in the show notes. They're over in my my my weird bucket podcast called the Coté Show Variety Podcast over at Coté. Coté Show. But when I was kind of speaking of trolling, when I was casting out a net of people to talk to on this topic, Stuart chimed in. And so so we have him on now to to kind of pontificate and eludicate and other Cates about cloud native enterprise architecture. But before that, so you were kind of going over your background. We were talking earlier. Give people a sense of your your relevant background for this topic. Sure. So I started out doing consulting and in Wall Street and and the dot com thing around the 90s, mostly startup stuff and then shifted into the enterprise. Did quite a bit. I was actually part of the founding enterprise architecture team at at Rogers Communications, which is the biggest telco wireless, wireless telco and cable company in Canada. And that was around 2002 when we did, you know, enterprise architecture things early.

So actually, you know, really predating the the market groundswell, I'd say, in the 2003 timeframe and starting to get into more DevOps, the agile things, too. And from there, I worked at BA systems for about five years. I was a lead architect across Canada and we did a lot for enterprise architecture consulting and SOA across the country, trying to convince people, no, don't throw everything into a single ESB. That's not the architecture we tried to recommend, but people didn't want to listen. And then on there, I did a couple I did a cloud startup in San Francisco for a few years that tragically all I got was a T-shirt at the end. I think I think what they say is there were a lot of learnings that you had, right? Yeah, there was a lot of learnings. Yeah. Yeah, definitely did everything we could do wrong. And then after that, I actually became the lead architect for a set of services at Canadian Pacific Railway that eventually led me to become general manager of IT operations, mainly because I was I knew the CIO who used to be my boss at Rogers. And so we did a major transformation there in sourcing, starting to do some early cloud and some EA work moving towards SAP as well as keeping some services around for the actual operational railway side, which SAP couldn't really run. And then from there, I went on to to work for Pivotal, which I've been trying to work for for a number of years, actually, when it was first formed. So most of my my background is I've been vendor side, I've been IT executive side, I've been IT developer, you know, and consultant and trainer side. So I've kind of seen every piece of this and I've interacted with, you know, a dozen plus EA groups being part of them or just fighting them or, you know, cooperating with them, depending on the context, I guess. Yeah. So, yeah, you just need to go be a an industry analyst now and you'll have achieved tech career bingo.

Like, like, you'll, you'll, you'll covered all the bases. No, yeah, that's, that's interesting. So, and, and highly relevant. So, I mean, let's start off with like, given, given that experience, like how without, without sort of like, you know, jabbing some spears of cloud native into it, like, like, what is it? What does an enterprise architect do? Like, how do they come up? What are their responsibilities and what does it end up looking like in practice? And, you know, just how would you describe what it is? I think it varies from company to company, depending on how IT focused the EAs are. I think mostly they are. There are some folks that are more interested in the business side, especially SAP shops. You tend to have enterprise architects that aren't super technical, but they understand a business domain and the process is really, really well. So those do exist, but I think most EA groups are responsible for, I guess, three things. There's the, the do and do not list of here are the things you are allowed and not to do technically within the company. There's the buy list. If you're the products you're allowed to buy or use, and then there is the, they know where the bodies are buried. They're, they're, they're, they sort of are the, the corporate memory. Like if you, if anybody's a Game of Thrones fan, there's the Citadel and the Maesters. They're, they're that. They, they, they kind of remember what happened and, and, and which projects died and which ones survived and what works around here. Uh, how does this place actually get things done or, um, you know, we, you know, what is something that's going to fall over if you look at it funny, uh, in the existing systems, right? So I think it's those three things. The last one is probably the most important. Um, because, you know, very often the enterprise architects, I think for the last 10 to 15 years, at least have been really focused on how do I actually get things done quicker, uh, and better with, with safety. Right. Which is the same thing we talk about with cloud native. We just talk about it in a different way, but they've all been trying to find ways that in a very ordered structured way that, um, allows them to centralize the decision making, create something that makes people move faster, which seems to be a bit of an oxymoron, but that seems to be the case.

Right. And this is why they're, they're, they're always looking for that new tool or they're looking for that new, um, model that allows them to say, ah, I have something. And this will be the thing that will allow us to me to not have to, you know, handhold everybody, but I can give them a set of constraints or a tool and that will make them go faster. And, um, while staying safe, I think that's been kind of the Holy grail that they've been looking for, at least it architects from what I've seen. Um, and it's this kind of iterative cycle of, you know, trying to control things, failing, getting totally irrelevant, watching things fail, getting more relevant again, coming up with a new idea or a new, you know, paper to explain a new idea. And iterating on that over, over a series of 10, 20 years is what I see EA doing. Yeah. You know, it's a very like helpful, not helpful, hopeful sort of definition. It's almost like the, the enterprise architect is, is the, uh, I don't know what, what word am I looking for? The one who's always ensuring that, well, let me use some BS terms that, that the business has enough agility with its IT, right? That, that, that you're always using the, the best stuff to, uh, the best process and technology and everything to just help out, help the business out, uh, if you will, versus. That's the intent. Yeah. Yeah. That's the intent. That doesn't mean they actually do it. Um, so where does that, I mean, so those are three good categories. I like that. So, but where does that come from? So where do I get my list of do's and don'ts? I mean, is that patterns? Where do I get my list of tech I should or shouldn't use? And how do I become a successful matchmaker or understand that there was this being embedded in projects? Is this where you see there's a lot of innovation lab sort of work happening? Kind of, how do I get, how am I capable of doing those three things as a successful EA? Well, there's the old school way and then there's the new school way. Right. Uh, and they're very, very different, right? The old way you used to do it was, it was a combination of, um, you know, classic first principles of design and, um, you know, just history of learning the hard way of things that did and didn't work in a particular context.

Right. So, you know, everybody's interested in, you know, if you like data architecture, you're, you have familiarity with the history of how data evolved. You have a bit history of, of how middleware evolved, right? Originally it was these trans, these crazy mainframe transaction processors. Then it was, you know, app servers and now it's lightweight containers and microservices. Right. And so you have a bit of history and you understand, okay, well, um, uh, I think you were talking last week about enterprise architecture strategy, right? Which is that book that was in 2006 with, with real and Ross. Right. And their whole point is, okay, our business is trying to do X. We make shoes or we run trains. Um, we don't have 50 business units that all run differently. We do one thing. So that lends itself to saying, okay, a list of at least high level do's and don'ts in terms of, you know, we really don't need 15 email servers. We really don't need 15 ERP systems. Right. And yet this is what we see time and time again. I mean, there's, um, organizations, even in Canada that have like a hundred ERP systems in the federal government. Um, just because they just let them proliferate and they never actually said, no, you can't actually do that. That's, that's not right. So I think there's, there's just a basic history and learning things. And then there's the, um, I think all architect enterprise architects, at least they've been around 10 years have an allergy to duplication. It seems like their mission in life is to eliminate all duplication of effort and all, uh, anybody that might possibly be doing something that has already been done, which is a bit misguided. Yeah. But that's trouble. I mean, I, I, again, I experienced that in my own role with that, but yeah. How do you find to make sure that you don't accidentally stifle innovation? Because you know what? We're a vSphere shop. Stop screwing around with cloud or, Hey, you know, we have X. It's worked fine. It's this relational database for years. Stop screwing around with no SQL. I mean, obviously it's not always that black and white, but how do you sometimes encourage reusability as long as it are not reusable using, right?

Starting fresh as long as you allowed you some quick learning and some quick feedback. Well, I had this conversation with the head of SAP architecture at a bank, uh, here in Canada, uh, a while ago. And I, I was explaining that the new model, I mean, if you're thinking about digital transformation and the, the whole onus on, look, we got to change our customer experience. We got to become, uh, more quicker responding to kind of, you know, not only just, uh, fixing our mobile apps or our website to look better. It's, it's, it's, you know, it's design isn't how it looks, it's how it works. We have to actually change our backend systems and this isn't something we can just sit and stare at the ceiling and come up with. We actually have to experiment and we have to do it in a decentralized way with fast feedback. And not only are these teams iterating, we have to iterate as architects too. So now it's about, oh, all about duplication of effort. It's all about, let's try a few experiments. Let's make sure that they are, uh, can succeed or fail quick. They're funded, fairly contained, and they're, uh, something that can be run by a team without having to require the entire organization to do steering committees or, or all these kinds of checkpoints and whatnot. You want to have, um, this kind of more decentralized focus model than we have in the past. If you think of it is kind of like this, this pendulum that swings politically between decentralization and centralization, it's always about the balance of power. It's not about one or the other. And I think we're, we're swinging back away from centralization towards decentralization radically now with microservices and with, um, you know, with cloud native, which is a way of saying, even if you are a unified company, even if you are having one mission, there is no way one group can actually solve all these problems. You're, I mean, nobody's that smart. We have to, um, you know, uh, uh, technical people with, uh, uh, actual users getting feedback and using that to learn.

So it's a little bit, it's a bit of a, the test a little, um, you know, build a little and then architect a little, um, I think matters. So the intent really now for the EA is about how do I get out of their way and provide constraints so that they're maximizing all these little, you know, these little pockets that are, um, going to be able to come up with these ideas. But we have a, uh, kind of a standard way of ensuring, you know, what's really important to the enterprise. Well, I want to mitigate, mitigate risk on my data to some degree. So I'm going to have some standards around my data. Um, but they're not going to be technical standards. It's not going to be, you must use Oracle. I'm going to let a little more freedom on my teams to say, well, use the data standard or tool you want within some relative bound, uh, as long as you can run it, um, and operate it with what the business wants. But, you know, here's what the data standards are or some, something like that. Right. I think having a much lighter touch on the standardization, um, is, is the real key. And then, and learning from that and evolving from that is what I'm saying. So, and also making sure that you realize there's no one size fits all. So, so I think, I think, I think Richard has zoomed in on perhaps the, uh, I don't know if it's the, uh, pivotal, if you will, the, the, uh, the, the, the pivotal conflict that scurries around between like cloud native and enterprise architects. But you, you've, you've, you've talked about it quite a bit. And so I wonder how you would explain, well, I wonder, I wonder how you would explain what I'm about to say, so to speak. But it seems like going back to that book, the, uh, enterprise architecture is strategy, which, uh, uh, maybe I need to read more books, but man, that book's pretty good. Now that I think of it, keep mentioning it. But in that book, the, the task of a circa 2006 enterprise architect, in my view was to guide the company, not just it, but guide the company along the gradient of decentralized it. And the first way that they decided to do that is basically like, uh, you've got these four types of business models or ways that businesses operate.

Um, and based on how the business operates, highly siloed or highly centralized, you shoot, you're on that gradient somewhere. And I don't know, it's starting to feel like, I don't know how strong this is. Maybe you can tell me on a scale of one to 10, how, how true this is or how deep it goes that a lot of the proposition of, of cloud native stuff is that we used to have this constraint where you would have to think about standardizing and centralizing versus not doing that. But now there's like this third option where you can get all of these efficiencies by having a more siloed approach. I don't know, but by somehow you allow people to be a lot more independent and not be told exactly how to operate. And it removes a lot of the, well, a lot of the dangers of having a sort of a, a, what, what you might've called a cowboy approach back then, perhaps now you call it a cow person approach. Uh, but you know, having more of a, each team deciding what they should do is actually not necessarily, I mean, not that it's better, but it's a lot safer to go about that path. I don't know. I mean, that's all jumbled up and weird, but that's the kind of the notion that I keep coming back to again and again, that that's a lot of what cloud native stuff does for enterprise architecture. What, what, what do you think of that mess? Yeah, I think that the, there's been a fundamental misunderstanding about what centralization actually should be. Um, I think we forgot about things like lean and about all the lessons we're learning in business about, you don't want to insert yourself in the process. You don't want to be a bottleneck. And what was happening is we were inserting a human process of, uh, you know, checks and balances and making sure things are right. And, or, oh, that's not on the buy list. You can't do that as opposed to a more trust-based approach that is, okay, let's allow some experimentation. And in, you know, we'll have kind of this convergent engineering approach where eventually we'll come, we'll come up with some insights about, all right, don't do that anymore.

Or, or, or no, this is a good idea. And I think that the standardization doesn't go away. I think standardization is important. If you think about what we say in cloud native, um, it's about creating a standard set of patterns and processes and automation that gives you a pipeline. It gives you a way it's a, it's a very, you know, it's like a, it's not a single lane highway. It's like a 10 lane highway of here are the 10 ways in which you can get something deployed, you know, develop, delivered, tested into production quickly. Um, as opposed to, um, the, the, the two extremes that are, that tend to be kind of done in a lot of enterprises. One is there is only one way and it's SAP or this, there's only one way and it's using our existing monolithic platform or whatever that we built in house 10 years ago. And the guy left for Google five years ago, and we don't know how to maintain it. Right. The other opposite opposite is, um, you know, the, the quote unquote, um, enterprise DevOps approach where you're basically chasing taillights. You're paving the road behind the developers, hoping that somebody will use it in the future. Development teams are off doing something and you're using shepherd puppet or whatnot to automate what they did. And it's not exactly generic. It's kind of like, Hey, look, I can turn the crank on the thing that you did. That's great. Next project comes around. I might be able to read pieces of that, but I can't actually apply it as opposed to, no, let's actually build a set of capabilities or, you know, purchase or some combination. That is a standard that forces a certain set of practices and constraints, or at least really encourages you to think in a certain way. Um, and I think that the, you know, that enforces enterprise architecture. It's having it in the software. I mean, if you think of like something like ITIL, these standards for operations, it's basically a bureaucratic process to enforce things through Excel spreadsheets and ticketing systems, which really should just be in the software to begin with.

And so we've inserted humans in the mix for safety sake. And what we're now saying is, no, the kind of robots can make this thing safe. Um, we don't need humans to do it so much except to operate the robots. We're, we're, we're, we're maintaining software to run the software rather than having humans kind of in the mix, keeping an eye on things and being panicked all the time and doing change advisory boards and other things that just slow things down. They don't actually, you know, make things safer necessarily when you're trying to change things at speed. So there's almost this, uh, sorry, sorry to overrun you there. There's, there's, uh, uh, there's this third way, if you will, that sounds all fancy, like some seventies, uh, self-help stuff. There's this like, uh, third way of enterprise architecture that is beyond the, uh, the tail light chasing the sort of cow path thing, if you will. Uh, and, and, and, and, and it's almost a compromise of the two things. It sort of, it sort of feels like, at least when I look at what, what we at pivotal would call cloud native stuff, right? It says we are going to incredibly standardize and centralize a certain part of the IT stack. And then above that, well, we'll figure out what to do, right? Like we might, we might all mandate the same language and mandate the same way of operating, but there's almost like, uh, it's not so clear cut. And that's why I always struggle with it. But there are in a cloud native way of operating, there's an extremely strong, almost take it or leave it sort of set of EA principles. Um, you know, like you should be running on cloud for first. Otherwise it's, I don't know, whatever native, uh, but you should be running on a highly automated cloud platform. Like obviously self-serving something like pivotal cloud foundry, which basically removes all choice about your infrastructure. And then as you get closer to, uh, you know, the, the, the pivotal James Watters value line, it's like all this stuff. Basically we mandate and you can't decide to do or not to do it. And, and so that is like extremely strong, old school, um, much not liked enterprise architecture, like mandating, you can only do this thing.

But then in turn, it seems like, and this is, this is where all the interesting stuff happens. The constraint that gets lifted is like above that. And there's exceptions. You just sort of do what makes sense now. Oh, well, first of all, and now that there, there becomes some confusion of how do you make sure all these things coordinate. And it's gotta be more than that one article that Martin Fowler and that other guy, no one ever remembers wrote about microservices. Obviously it's more complicated than that, but there is some way of coordinating these things better. But one, I mean, what do you think of the, of my notion of like, you sort of have like sliced in really strict enterprise architecture at one point, and then you allow the, the cow person stuff above that. So that's exactly the point is that I think EA either tends to locking everything down or it tends towards locking nothing down depending on the culture. And what we're saying is that there's some things that need to be locked down. And there's some things that don't, I mean, you're always going to fight cultures where you have developers that want to, they don't trust anything that ops does or the EA does. And they want to compile their own gen two kernels or whatever. Um, and, and then you have other people that are like, they want everything spelled out and they want everything checked by a committee. Um, I'm a big fan of Simon Wardley's work. I think that his approach to, I guess, trimodal IT or his mapping approach where he says, you know, there really are, there's town planners, there's settlers, and then there's pioneers, I guess, in any organization. You know, just, just sort of at the meta layer. It's, it's odd. I mean, he's British, right? That, uh, that a very, I mean, something that, that I think when we're born up here, you know, in Canada and America, we understand that model perfectly. I think it's one of the, one of the doctoral procedures that like conquering the West is injected into our brains directly right after they slap us. So it is a, it's a good metaphor. Anyhow, I got excited about my little side note. Yeah. But I, and so I think that, so I'm actually dealing with a very, a very large bank, the top 10 bank, and we're, we're working through this, uh, model right now. And it's three different enterprise architecture patterns. There's a mode one, which is a legacy.

So that is mainframe plus old school web sphere plus old school Vitria or, you know, nonsense EAI from the nineties. Um, there's mode two, which was, I guess, cloud 1.0, um, DevOps 1.0, um, didn't really get a DevOps culture, sort of use Jenkins, sort of use cloud foundry, sort of use, um, you know, Docker. Uh, but it's all kind of, they didn't standardize the middle layer. Like it was complete, basically use these technologies. Um, and, uh, that's it. Um, and so what wound up happening is there really isn't a lot of productivity benefits because, um, it's a bit of a mess in terms of what's actually supportable. Um, everybody, every team's kind of doing its own thing, et cetera. And then mode three is really, uh, you know, is what they're trying to be is more like what the intent of the settlers are or the pioneers where it's like, I'm not building a single lane highway, like mode one. I'm not building kind of like this, uh, smorgasbord, which is what they did in mode two, which really is more what pioneers want, which is give me freedom or give me death. I don't care if I have an SLA. I just want to be able to run my ACA clusters, damn it. Um, whereas what, what they've created is this new one, which is like, no, we're standardizing everything from here down. You have to use our CICD pipeline. It's going to be Spinnaker and Concordes. You have to use our way of doing, here's 10 different languages, right? Uh, we're going to container. It's going to be these, uh, Java.net, Python, Ruby, et cetera, done our way. And if you must use Docker, it's going to be based on our root image. Uh, you don't get to bring an image. Um, and, and it'll be deployed in this exact way. And on top of that, you get to do whatever you want. And so that, um, has had, um, a lot of traction with the development community. This is obviously leading to new problems in the data community and in the interoperability side of the business.

But, you know, let's crawl before we run, I guess. Yeah, that's what I was going to ask you. Cause, you know, I think back to my EA time where we do some master data management efforts and, hey, you had to, you know, fill out a form. If you wanted access to the data entity, you wanted to maybe access or change. And, you know, to some extent that was for reasons, right? I mean, it's all good intentions, but as you say, just because you automate some of the infrastructure layer and your container base image and your runtime, that doesn't mean I still can't use, or I could still accidentally enforce too much on data entity definitions or messaging patterns or what have you. So do you just feel like that's stage two, like let's get some of the infrastructure aspects of architecture nailed down so teams can start to at least pick up velocity. And then we take a look at some of the data patterns, integration patterns, and the like, and figure out what kind of light touch is needed there. So we're not accidentally mixing too many things that make maintenance tough or make it really tough to share information. Or to Coté's point, is this all local optimization within your microservice? And if you choose to define a data entity this way, and I might choose to extend that because my business unit is not just use customer, but it has a different perspective of customer, that that's fine. And I just do that kind of translation. How do you see the data services mixing in? Good question. I think, you know, the way I always liked the way Adrian Co-Croc used to talk about microservices at Netflix and that it was, you know, the business person, the developer, but also the analytics person. And I think that it's important that as you're doing this, you do have to have some standards about providing a tap or an interface or something to be able to hook anything you're building into a broader analytics ecosystem, call it a data lake or whatever you want to call it. That at least allows me to get at your data. It's not, you know, you didn't, it's like, Hey, I wrote this thing using GRPC and, um, Golang and you can't get at my data. Ha ha. No, you have to have something where people can get at it right at the very least. But then the actual definition of, of what do you do with that? I think it is a bit of a phase two.

One of the things I learned, I used to run a data team, um, at Rogers. We did major, we, we integrated seven different lines of business from cable video stores, the Toronto blue Jays, um, wireless, you know, trying to get customer centricity basically across the company. And the thing we learned very quickly is you have to, the business has to own its data. The business has to, and when I say the business, I mean the people that actually, you know, run the, they run their business and they can't just blame it when my data sucks or I'm capturing things. It's like, you know, your own employees are actually typing in things with typos. We can help you give you tools to, you know, spell check and stuff, but you have to actually care about this. So I think that very often with data governance, we've, we've, um, we've kind of overcompensated with data quality problems of the past where, you know, in the sixties, we didn't care about customers. We cared about accounts or we cared about addresses. Actually, the funniest thing in the cable business is nobody actually cares about customer. They care about addresses because the addresses are the persistent thing. It's where the drop of the cable is. Right. And so this notion of customers being the thing that is carried over was like foreign in, in the early two thousands. So we were like, well, let's never do that again. Let's overcompensate by putting all these checks on about data and whatnot, which just completely stop progress. Really it's about, okay, if a business person today doesn't care about that, then we don't care about that. We don't build that in. And when we do care about that, we invest in it. If there is, you know, if there is five different things that disagree, somebody has got to invest in that and say, okay, we're going to now make sure. And then we'll put a standard in place that is at least light enough to the level of investment they're willing to put in. Because if you slow everything down, you're angering your peers, right? That's why it's good to force that on kind of the business side. And this has been always the challenge with classic IT where it's like the business versus IT. I think the whole thing about cloud native is that the business and IT are completely together. They sat to sit together. If you think of it as throwing it over the wall or all those geeks are going to work on my stuff, it's not going to work.

You're not going to move fast. Right. That's why I always hate that designation of business and IT. Most companies, legal is not the business either. So like what is the business? We're all the business. No, exactly. And nobody's structured that way, I think, in classic IT sense, unless they're doing like agile projects or whatnot. And they seem to be more like curiosities, I guess. But eventually it's going to permeate everything. And you're already seeing this with what things like Gartner and whatnot are recommending for marketing groups and whatnot, that they all kind of just correlate the teams together. They don't separate them. Sure. Yeah. Yeah. Well, that's great. Well, hey, thanks so much for being on. You volunteered. And I think it was a good choice to volunteer to keep on one of the minor themes in my cattle call. So that's great. Yeah. Well, we'll have to talk some more on these topics. I mean, there's a few more things I want to delve into with you and other people more. Like one, what's up with this mapping the business stuff? And then more on what the standards that get put in are like. And I like the notion that both you and Richard were starting to talk about where there's sort of like this five-year journey that enterprise architecture is going on. And we've got to sort out the infrastructure stuff. And then if you start it early, maybe you're in the middle phase. But the middle phase is something else. And who knows what it will sort of look like at more of a steady state of what they do. But that's been interesting. So if people want to follow you on Twitter or whatever, I mean, or maybe your blog. If they want a 404 on their blog, like where can people look you up? It's kind of like on S3 or on the Wayback Machine basically at this point. My Twitter is SVRC, which is my initials. I'm also at StuCharlton.com, which is still kind of up sort of. It dates back to 10 years ago. But it's some classic post on REST architecture and whatnot for people that are geeky about those sorts of things.

Yeah. Yeah. You must be like me. You joined Twitter in like 2006 or 2007. You get such a short name. But yeah, that makes sense. Yeah. Yeah. All right. Well, great. As always, this has been Pivotal Conversations. If you want to get the most recent episode, if this is the most recent one you're listening to, find the RSS feed to subscribe to and see all the delightful other ones. Some of them grouped together, like where we talked with actual end users and people and other stuff. You can go to SoundCloud.com slash Pivotal Conversations. No space in there or anything. And every Thursday, we post the full show notes of each episode over at Pivotal.io slash podcast. And, you know, it's always helpful if you tweet about this in your Twitters or put it in your other social holes like LinkedIn, maybe even a Facebook. You can tell your junior high friends what you're up to today. And they'll be like, that person was always really fun at parties. I see they've maintained that throughout the rest of their life. Although, I don't know. Maybe it's your computer club people who follow you. So, whatever. But it's always good if you help us get the word out and if you want to write a iTunes review or anything like that. And with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.