A false choice: systems of record vs. systems of engagement (Ep. 49)

Episode 36 · 38:41 · SRT · archive.org · all Tanzu Talk

So I've rediscovered lentils. Now, when I was in the 80s, and by when, I guess I mean alive as a child. I don't mean like I was time traveling. My mother somehow got mixed up with this person who was big into, I don't know, Indian mysticism stuff. I don't know. And we spent some time and a lot of time in some, I don't know the right word for it, some ashram up in Rochester or something. And, man, I remember the food was terrible. And I think this got me in dim view of lentils. But recently, I figured it out. So we have a guest on who will ask to introduce himself shortly. I wanted to get y'all's input on like proper lentil preparation because all I have so far is like salt, garlic, and a bay leaf. And I experimented a little bit with some tomatoes today. Turned out well. But surely, surely that you guys have some sort of like lentil thing you would pro-offer. You have high expectations of this size. I'll do a mean lentil soup. That's my extent of lentils. Okay. So lentil soup. I feel like if you put some bacon in that preparation, you might come out with a tastier thing. But I know your wife, she's on the vegetarian box, right? Well, she used to be. She used to be. Oh. No longer. She's coming back. Yeah. Back to the light. Yeah. That's right. That's right. She's returned from the vegetarian. Yeah. It was a long journey. Kind of like Cain walking the deserts, I guess. Through the darkness. That's right. Well, why don't you introduce yourself briefly, guest? Sure. This is Ian Andrews. I'm VP of products at Pivotal, which means that I get to hang out with Richard and yourself quite a bit, as well as the rest of the corporate marketing and product folks at Pivotal. I get to have a little bit of a say in product strategy every now and then when they let me in that meeting. And I've been around since a little bit before the beginning of Pivotal, so I'm always game for trivia or history challenges about where Pivotal came from and where we're going, if we happen to veer into those topics today.

Yeah, yeah. One day we should write down a chronology of all the various brand names we've used for things. I think that would be fun when we have spare time for Cain humanity. I'm game for that. It would have to go back to the depths of my memory for sure, but it could turn out to be a fun little game. That's right. Well, I wanted to get Ian on to talk about some systems of record and bimodal stuff, which we'll get to. We don't really have a lot of news to go over since last time. I'll just mention a few things. I don't know if you all two have anything. One, I write a book review over at the News Stack, and I try to do it every couple of months. And by do, I mean this is the second one that I've done, so bully for me. But I wrote one recently that I think, given the stuff that we all work on and listeners do, I think might be interesting. It's all about automation and digital transformation. I look at these two books called The Wealth of Humans and then one that's called Silicon or Silicon Collar. And they're kind of like, you know, the frowny face and the happy face of the effects of digital transformation. And I think it's kind of worth looking at them. The second one in particular, if you're just all like about the marketing and use cases, it's just like a compendium of positive use cases about digital transformation, which is fun. And there's some commentary from John Alspaugh on my Facebook posting that points to some good follow-up things to look at. And then also, you know, I try to keep politics out of this as much as possible. But if you're interested in my take and by some internal conversation that we've had at Pivotal is kind of reflective of several Pivotal people about kind of what's going on in American politics. I'll put a link to it in the show notes on my own blog that I think summarizes. I would say like what's going – how all of this stuff affects the tech world and how I would recommend thinking about it. And then finally, I'll be next week in Charlotte at DevOps Days Charlotte.

I think I hesitate to aggrandize it, if that's a word, and saying I have the day two keynote. But I have the day two keynote. I think my charity majors, Mipsy Tipsy, she's doing the first one, which I'm looking forward to. I think – I don't know if I've ever seen her give a talk in person, but she's delightful. So if you're in the Charlotte area or you want to just like, you know, be like Nelly and drop some money to fly over there all of a sudden, you should come see us. We'll have a Pivotal booth there and give away some books, and we might even have some like pens or something. But that's all I got for this week. I think we also have some spare passes for DevOps Days Charlotte. But if you email me at Coté at Pivotal.io, I'll – send me a good lentil recipe if you want, and I'll see about giving you a pass. Do you guys have any newsy stuff you wanted to go over? No. I mean, congrats on making it, though, keynoting. It's a long journey. That's right. You know, things are finally happening for me, Richard. It's about damn time. That's right. Hey, one news item of note, maybe a little premature, I don't know, since it's not until June, but Cloud Foundry Summit is happening in the beginning of June in Santa Clara. The call for papers is still open for a couple weeks. So I think we have until February 19th, which is like maybe three weeks from now, something like that. So anybody that wants to talk at that event, they're still accepting submissions, and I think they'd love to have folks to listen to this podcast, at least, would be a good fit. Yeah, yeah. Yeah, great call. Yeah. Pivotal has a track, so obviously that doesn't impact how people submit, but I think we'll be doing one on Java microservices. So if you have things on that topic as well, you know that's going to be a focus that we're looking out for. I think it's extremely similar to our own SpringOne platform, which I believe is in December in San Francisco.

That's right. But I think it has a good mixture of, I don't know, the suits and the nerds, if you will. So there's a lot of talks about how people are doing cloud-native stuff and using all the great Cloud Foundry distros. And then there's also a lot of highly technical talks. So it's great. And I think the booth floor there is one of the better ones as well. So that's a good recommendation, Ian. And on the topic of giveaways, actually, before you jump ahead. So the team has come up with a new giveaway for all these trade shows and events and conferences that we sponsor. I don't know if you'll have them in Charlotte, but maybe we could figure out how to FedEx some to you. In the world of Big Brother that we now live in, where everybody's got a camera on all the time, it's a camera cover for the one that's built into your laptop. Oh, nice. It's a pivotal brand. It sticks on the frame of your monitor, and it has a little slide that you can slide open and close. So your mechanical process to actually put yourself on video intentionally versus accidentally the camera turning on. Yeah, that'll be much better than the folded up piece of paper that I've built over. That's what we're trying to solve for. We're replacing the Post-it note camera cover with something that's a little more stylish. That's right. It's like pivotal data, compassionate. That's right. That would be way too long of a phrase to put on a tiny thing like that, but whatever. Anyhow. Well, so as I mentioned, it's actually the three of us were on, we were having a conversation with some folks recently, and we were kind of explaining what we think about DevOps and cloud native and just kind of how Pivotal thinks through that stuff. And someone mentioned the idea of, so how does this, you know, I forget how they phrase it, but basically they brought up the topic of systems of engagement and systems of record, which just to add some context, I'd be interested to hear how y'all would define that.

But it's sort of like the, I mean, I guess it actually came from Jeffrey Moore. I remember hearing about it first at, of all places, an Adobe briefing with, what's the guy's name, Tarkov, who works for, I forget where he's the CEO of now, but they brought in Jeffrey Moore to kind of go over of Crossing the Cosm fame and bowling alleys and such, to go over like how things were shifting to basically systems of engagement. And this was in, and this was in, must've been 2009 at the latest. And they were, he was essentially explaining how there's these ways of dealing with customers and, and new things. And this is when social was really popular. And so I think it was conflated a little bit into that. I would just call it external facing things. And then the system of record was basically just a really fancy name for ERP systems and, and sort of existing back office stuff you have. And I think that's, this notion has kind of been subsumed into a Gartnerian bimodal IT stuff. And, you know, not to steal Ian's thunder too much, but like, I think a lot of the, the suggesting of, would you call this a dichotomy or a pairing or whatever it is, is that you need to divide your IT into the ERP stuff, the system of record and the systems of engagement, which is sort of like the ways that you interact with people, I would guess internally or externally. And the way you think about and manage those things is different, which leads to a different type of process and a different type of strategy and different types of technologies that you use. So I thought when that topic came up, like Ian had a, a very interesting reaction to it, which, which I agreed with. And I wanted to have him on to kind of like explain that you're not to replay it word for word, but like what, what's your sort of like gut and or well reason reaction to this kind of like splitting things up? Just off the cuff, I think it's, your view on this tends to depend on whether or not you're pessimistic or optimistic about the world of tech inside of large enterprises and the ability for organizations to change or improve over time.

Because ultimately when you set up this, you know, the bimodal IT scenario, which I think feeds into the systems of record versus systems of engagement, having different policies and process models around them. You're basically saying, hey, there's a big chunk of your workforce that's unfit to do technology well. We're going to do it fast, at least. And I, I just personally fall on the optimistic side, which is, you know, given the opportunity, most people will step up to the challenge and can learn new things and are incredible, you know, incredibly capable. Just in a, in a very broad kind of sentiment on the human race. And so I find the, the, hey, you know, we've got to run two distinct teams because these group of individuals and these systems are just hopelessly irretrievable. Too depressing to really believe that that's a broad based truth. So I'll, I'll kind of get that out of the way and, you know, more from a tech perspective, my view on this is, uh, uh, they're all apps, right? It's, it's all application infrastructure. It's all technology. Sure. There's, there's unique or, you know, certain dependencies within each category, but I think the people who espouse the systems of record versus systems of engagement as a tool to divide up how you manage and operate these systems. Is setting up a false choice, right? I think, um, I think the, the, the actual measure of, uh, of most IT organizations really comes down to one of operational efficiency, right? How many people do you have to throw at the problem? And so if the core system in your environment happens to be something that, uh, you know, an analyst firm might term a system of record, uh, and you spend 90% of your IT. Uh, budget in terms of people in dollars maintaining that system.

Well, I would actually argue that that would probably be the first place we should go look if we were attempting to optimize the way you do technology, right? That's going to have the greatest impact to the, to the business versus say, looking for a system like, um, you know, a website that we're launching or a new, you know, mobile app. Uh, so, so I think, I think going after these things and saying, oh, well, exclusively we should only apply new techniques like continuous integration and delivery or agile software development and planning process to these systems of engagement is a little bit upside down. If your ultimate goal is actually to try and, uh, uh, improve efficiency around, around operations, which I think most of the things that, that we talk about at Pivotal that is, you know, uh, folks at the forefront of, of, uh, thinking about how technology can be done well or really espousing. Yeah, that makes sense. I think that, yeah, I mean, do you think that separation comes in because the perception is systems of record have a slower change rate and you can incubate ideas on these systems of engagement, even if that, again, that's a real separation and then fold them back eventually into these systems of records. I think even bimodal IT is meant to be pitched as a journey of sorts, not a fixed end state that you will always have slow systems and fast systems. It's a, like, hey, over time you might have to start somewhere and you just think there's a different place to start that you're slicing it at the wrong level. Uh, yeah, to, to be fair to the people that, that, uh, like the bimodal concept, I actually am totally fine with it in the context of, hey, we, we've got to pick someplace to start. And so we're going to carve off a small team of people that are, uh, of the willing, right? They want to do things differently. They have a strong, uh, appreciation for what we're trying to do differently. And, and they're, you know, they're willing to suffer some of the pain of, of actually being the first through the tunnel, if you will.

Um, that makes a ton of sense to me. And I think, you know, picking an application, um, that may be, uh, where the immediate return is greater. And you can, you know, I, I like to try and judge, um, fit for one of these type, type of things. I, I don't like the systems of engagement versus systems of record framework. The way I look at this, you know, I think first and foremost, people often will just gravitate towards technical fit. Like how close is this app that today I'm running on premise on bare metal, or maybe on some VMs, uh, how, how technically suitable is it for me to take this onto, you know, a cloud infrastructure. And that tends to be the, the driving factor for which ones they go after first. Not to say that I would exclude technical fit, but I would add to that, that there's a, um, a measure of value to the business, right? Is the application something that one analyst in an office looks at once a month, or is it something that's driving decision-making across all your lines of business, right? So there's a spectrum of value to the business that I think you can measure on an, on an application basis. And then there's this other question about quantity of plan change. So if we've got a backlog that's, you know, 24 months worth of work to be done to a particular application versus something that, you know, it, it works fairly well for what it's used for. And there's nobody aching to change it with, with a lot of, uh, a lot of anger in their voice. Uh, you know, again, that spectrum, I think you can then combine that with the value to business and technical fit and, and come up with some sort of a stack rank. That allows you to determine where you can have most immediate impact. If you're looking to take an app from kind of legacy way of doing things to this, this, uh, new world order, if you will. Uh, I think that's a more useful framing. Now, if, if, if going after and attacking that work comes from, you know, this small team, the, the Marine expeditionary force, highly trained, highly skilled, highly motivated, that's great.

Uh, I think where a lot of people get stuck though, is they don't have a plan for bringing the rest of the organization along with them. Uh, and so it becomes the case where you have, uh, the small, highly skilled team that's doing one thing and the rest of the organization doesn't see a path to ever get there. And that actually tends to increase the organizational resistance. Um, you know, they, they start to fight against, uh, fight against the new thing in the organism. Um, and so I, I think that, that last piece is where people really tend to get stuck when they, they start on the bimodal path is they don't plan out well enough how, how they're going to bring the rest of the organization up to speed. Yeah. You know, I, I, I like all that framing cause, cause it, uh, well, one, cause it matches my own thinking. So it validates how, what a wise person I am. Uh, but, um, it, I, I, I think it touches on, on something that's oft overlooked with, with things like this, which is the unintended consequences that, that what is otherwise more or less a good idea might have. Right. So like, even if, even if we concede that like, well, sure, the state of the universe you described is correct. Um, the, I think the follow on effect is that not only is there, as, as, as our friend Bridget would say, the sort of sad IT and happy IT, uh, you know, as a way of making fun of it. So you have this demoralizing effect of people, um, that they're working on the, uh, the boring stuff. Um, but I, I think, I think it also like, as, as you're the, what you're pointing to is the more correct approach is like, no, there's just, there's basically just the, you're prioritized IT. Like it's all IT, I mean, to, to describe it as all apps. And so you should prioritize like the, the IT that you have, whether it's apps or whatever, and figure out the, or the value it has to your organization and proceed correctly. And, and if it does turn out that your ERP system is your most valuable thing, then great, right?

Like you should focus on that, but, um, which is often not the, the, the case with, uh, pivotal customers at least, but it's more important to not separate things out by a category, um, before you separate them out by business value. Um, and I think, again, I think even though the framing of bimodal and everything might be helpful, I think it, it's, it's somewhat, I don't know if it's irresponsible, but whether it's irresponsible from the authors or just as a concept on its own, like it, it tends to have these, uh, these negative, uh, knock on effects that could be avoided with a, with a different framing of things. And so I'm, I'm, I'm also curious, like, uh, I mean, uh, you, you, you go out and talk with a lot of people, like when this comes up with, with various like teams that you have and things like that, like what's, what's the conversation? Like what's some notes from the field on this topic? You know, I, I visited a old insurance company last year. Um, I w I won't put their specific name out there to protect the innocent, but, uh, the, the exact leadership had gone very much down this. And it was an interesting conversation because, uh, they had done kind of an age measurement across the tech technology organization and something like 60% or slightly higher of the staff was in their, uh, late mid to late fifties. And so, you know, rapidly approaching retirement age. And so the, the leadership was, was legitimately concerned, I think about appetite for the organization to do anything different than they had ever done before. Uh, and you know, whether they would, even if they were able to retrain the staff to do things differently or better, could they, you know, they wouldn't likely be able to retrain, retain them long beyond the, the retraining period. So was it even worth trying was, was sort of the challenge they were faced with, which, um, they, they never came up with a really good answer to this.

Uh, they set up, no, it really is. You know, they set up a, uh, uh, you know, a small go fast team, um, who, who they, they allowed to break a lot of rules, uh, you know, took an app, deployed it direct to Amazon over the course of six weeks or so. So their first foray of anything serious into public cloud, uh, and, and prove that it was possible and kind of documented all the things that they would need to chain were they to make this, this a wholesale strategy shift. Um, but they weren't really sure to what to do with the rest of the workforce, right? Should they just let them age off or should they, uh, should they invest in, in kind of technology to bridge the gap between these two teams? This is ultimately why I was in the room was they were trying to figure out if, if they brought in the right tools, uh, you know, could they augment some of the maybe process changes that they were going to have to make? Um, so that would be one example where they'd gone down the bimodal path, had some early success in that it helped them understand what would theoretically need to change in the organization in order to do a wholesale shift from their historical IT process to a new one. But they, they stalled out on this moment of, well, how do we actually do this at scale, right? The first app they got through it, but they didn't know how to do the next 20 or the next 30. Uh, and, and I, this, this is actually part of the reason why I'm fairly critical of bimodal is, is, you know, and, and suspect that a lot of people land a spot of, uh, hey, great. It sounds like a good way to get started, but what do we do next? Yeah, no, that makes, I, I, I think that makes sense. And, and, and again, to emphasize the point, like it's almost, uh, I don't know, the, the, the, the word ironic is, is almost useless at this point in, in Western culture and language. But, uh, like, cause it's so overloaded, but it's, it's sort of like one of the great ironies of like, uh, this kind of bimodal thinking that the reason you get into this mess is you are separating.

You, you weren't paying attention to the, what's next, as you were saying and evolving things and setting up a system that, uh, where things are evilly, not evilly, maybe easily evolved. I mean, it's sort of like my, my ongoing joking about the definition of legacy software is legacy software is software you have to change, but you're deathly afraid to change. Uh, you know, otherwise you just call it your software and it seems like, um, yeah, there's not a lot of great answers about what to do with the old stuff that is starting to, whether it's because of, uh, staff attrition or whatever, but you're sort of like fear it. And, uh, unfortunately until we invented time machine, you can't do the ultimate fix, which is to go back in time and not screw it up. But, um, you know, to appropriate another phrase, it's sort of like the best time to plant a tree is yesterday, but, you know, barring that today's a good idea. So it's, it seems like, uh, it's, it seems like further enforcing this bifurcation of different classes of it and trying to, instead of trying to make all of them the best possible is, is a, is a bad idea. And I guess like a, uh, sort of like a footnote to that is like, this also sort of assumes that you try to minimize working on it. That's not actually valuable to your business, which I think, I think, I think this is a part that's often, uh, overlooked by people is like, probably the first thing you should do is make sure you use, you're using as much software as a service as possible. And, and there's, you're sort of taking off the load of all this stuff that you used to have to manage on your own and spend a lot of stuff on, but make sure that you're only doing the absolute minimum of it management. And then you can have all this highfalutin think about like a happy it versus sad it. Are you trying to say that I shouldn't be running my own email server? Cause that's going to make me really sad. I mean, there's multiple reasons why that's proven to be a bad idea. I have no idea what that reference is. I can't imagine somebody got into trouble for running their own email to me.

I wonder who that was. Do you think on that point, I mean, to some extent it's sometimes I'm a fan of. You know, you mentioned kind of don't do that, the dumb undifferentiated heavy lifting stuff, but I mean, to your earlier point where you talk about stalling out, sometimes you advocate, I mean, you see with our customers, you almost have to shock the system and say, let's not do these things tiny over time. But instead let's try to do a bigger top down endorse change so that you don't stall out after that first team shipped and then the antibodies swarm on it and kind of kill the process. I don't know. Do you see people try to do bigger changes versus the incremental stuff? No, for sure. I mean, that's my admonition in a lot of these meetings, right? Cause people's initial reaction is, Hey, let's do something small. I can kind of prove it out. At least get a PowerPoint level ROI that I can share with the organization. We'll use that to mass support. And, and I'm all for a short project, but my guidance is, look, you've got to do something that has enough visibility and importance to the organization that people care to look at your PowerPoint ROI. And, and if you're picking too small, often you pick something that no one cares about. So the, the evidence becomes irrelevant very quickly. This is, this is why I think, you know, of my three things that you need to measure value to the business is, is right there. Right. It's a big deal. I mean, I think a good example of this is actually, uh, you know, big telecommunications, uh, uh, cable TV provider that that's a customer of ours. The, the system that they've put onto, onto cloud foundry, um, is responsible for core service provisioning, uh, billing, customer management drives, all their call center help desk interactions for their, you know, 40 plus. So, you know, you couldn't pick a more important, uh, piece of software in the business, right.

In terms of its impact, when this is down, it costs the organization and ungodly amount of money because it, it impacts nearly everything in, in the organization on the flip side of that, uh, even, uh, you know, a 10th or a hundredth of a percentage point increase in service availability has an equal positive return. And so one of the biggest challenges they had was service availability across the collection of, of services that make up this platform. And, and that was really the problem that they were seeking to solve when they first started working with us. So they were able to demonstrate really significant impact on a really large application. And it wasn't purely just, you know, Hey, let's, let's move this app onto cloud foundry. They adopted a lot of unique and new processes. They went from, you know, a waterfall driven, you know, quarterly release train to continuous delivery into production. Right. So radically different, uh, uh, radically different shift in terms of, um, approach and concept. So I, I think that shock to the system, that massive improvement that becomes widely visible, it has the effect across the rest of the organization of people saying, wow, that's amazing. I want to be part of that. How can I learn, get on the boss and, and start working on that team. And, and so I, I think that value to the business is a huge metric in terms of where you choose to start. Yeah. Especially when it's not rogue and, uh, you know, some person in a fancy office somewhere says, this is what we want to do. You don't feel like you're, you're being bad about that. Let me, uh, so speaking of that, as we think about what are some of those things that help the rapid transformation and, you know, you've been here since the beginning, you've seen kind of spring go from, Hey, something kind of an interesting part of the portfolio to now a super critical one. Um, as companies are betting on spring boot at kind of crazy levels, but, you know, so I wanted to give your quick take on the spring boot phenomenon and then kind of tangentially, since you got roped into the, uh, Java EE madness at the end of the last year, when, uh, they shipped their market guide, it really riled up some, some folks and, and got them all hot and bothered.

You commented on an info queue story. You had a quote in there as well, just focusing on cloud native, but I just wanted your take on kind of what, what happened with spring boot? Why did this take off so much? And what do you think about some of that? I don't know, brouhaha about Java EE where, you know, what's your reaction to the reaction? Ooh, lot, lot, lots of meaty topics in there. I'll start with spring. I mean, I, I, uh, I'm completely blown away by the, the rise of, of spring boot as, as kind of the de facto framework for doing Java microservices. Um, I mean, I think we're now seeing somewhere over 10 million downloads a month from the, the Maven repos, which, you know, the, the absolute number is actually less important. I think then, then an appreciation of the fact that, uh, you know, three years ago it was around 200,000. So you're seeing this kind of exponential move to that as, as a default framework. And it's important because in the, the enterprise space and the enterprise software space, the de facto language is, is Java, right? I think it's greater than half of all the software written, uh, in the last, you know, 15 years is, is Java. A lot of accounts also have a significant amount of .NET. But when you look across that landscape, the skillset that enterprises employ or their, their consulting partner outsourcer of choice, you know, either the, the big American ones or the big Indian ones have an incredible number of Java developers. Um, and so I think this collision of, you know, companies suddenly emphasizing, Hey, I want to go fast, uh, being able to, to change applications quickly, add new feature sets, ship new apps. Uh, with as little overhead as possible, highest possible developer productivity, um, has contributed to, uh, to looking for any, uh, opportunity to, to, to optimize development process.

And so, you know, spring boot was unleashed into that, that climate and has, has stuck, right? Uh, the, the, the, the historical thinking about Java as being kind of heavyweight and difficult to change and update and, you know, confusing to configure and set up and build environments. Almost all of that concern goes away when you move to, to spring boot as a framework. And so it just made, uh, it, it made a lot of the hard things easy, uh, as our friends on the spring R and D team like to say. Um, and, and, and it is timed perfectly to this kind of world condition that just makes, uh, has, has made it so necessary, right? It, it, uh, it, uh, it, uh, it drives such an increase in, in developer productivity that, uh, it's almost become a no brainer. I, I subscribe to, uh, a bunch of job posting boards and I like to look for, you know, who's hiring for our key, key technologies that come out of the pivotal portfolio. And, uh, my inbox is just slammed with people that are hiring spring boot, uh, expertise. And now we're starting to see the rise of spring cloud, which I'd like to talk about as a scaffolding around, uh, spring boot. As you build out these microservices applications, you're starting to see that be complimented with rabbit as everyone's going down this event driven kind of async message passing, uh, application architecture. Um, it's a really interesting shift in application architecture that's happened really, really quickly. Basically in the last two, two years, uh, we've seen an explosion there. And so how do you contrast that to, uh, potentially some of the existing, you know, legacy tech that served its function, but maybe, uh, struggling to maintain the same relevance? Well, I think, I think the, uh, the piece that InfoQ published, you know, mentioning, uh, in Thomas's, the market guide for application platforms, it was really interesting because the, um, obviously the people who, who are likely to, to suffer the most, or at least benefit the least from a shift away from JEE or, or IBM and Oracle, right?

They've built, you know, uh, uh, over, uh, over the last couple of decades around JEE middleware. And then you add on top of that, you know, things like consulting services and architecture support, uh, really large and profitable business. And you now, all of a sudden have a huge number of customers in the, the core buyers of that technology, by the way, who were saying, Hey, uh, the, the tech stack you've supplied us with and the app architecture you've told us to build with no longer fits with the speed at which. We want to, we want to deliver capabilities to the business. It also no longer really fits the infrastructure we plan to run on because, you know, everything's going to cloud, whether it's public or private or some combination of, of both. You know, our, our world has changed radically from the day when we made the decision to implement web logic or web sphere. And so the, the shift that Ann talked about in the market guide away from JEE to, to spring, specifically spring boot, I think is really, um, she actually called this out in the paper. You know, this year for the first time in history, both IBM and Oracle's middleware business is going to decline sequentially. Uh, you know, that's, that's never happened before. So they've seen kind of consistent growth for years on years and, and all of a sudden it's turning the other way. So the, the reaction you could kind of predict, right? All the, all the folks who are, uh, you know, extracting those premium dollars from, uh, from, from big companies are coming out of the woodwork to deny the obvious, right? It's not happening. Everybody loves JEE. Oracle's continuing to invest deeply in it. Don't worry. This is still the right tech stack for you, right? Kind of perpetuating this myth that everything's okay and you don't need to change. Uh, you know, frankly, that's just goofy, right? I, I think the, uh, the smart money is already woken up to the fact that this changes has happened.

And the, uh, you know, the, even the, the laggards of tech will come along here pretty quickly. Um, I, I think it's, you know, call, calling the end of, uh, JEE is, is, uh, you know, it's not premature. I think it may even be a little bit late to make that call, right? It's sort of an obvious thing at this point. There you go. Yeah. And I, and I mean, just to add my, uh, my, my extra seasoning as I like to do, like, I think, uh, I, I think, I think, I think whenever you're sort of, uh, and, and to be clear, I don't think anyone used this phrase, but it's this genre of tech analysis. Whenever you declare something dead, I think, I think what's, it causes such a kickup that I think the thing that's, that's, uh, to, to reprise something you, a phrase you used earlier, it's sort of like ruins the conversation of what's next. And I think, I think what I've seen over the years, and I used to see this at the height of JEE is that it's not so much that this, uh, this way of life programming is over. It's just that it's evolving. And so there are, there is functionality and just as much interesting stuff that does things in a, uh, a JEE way. It's just a different like set of, of APIs and specs and technologies and all this stuff going on. Uh, so it's not sort of like the, uh, the bottom is being sort of like pulled out from under you while you're cooking your lentils. It's just like someone's retiling it. I, I, I will totally agree with that. I don't think this is a, uh, uh, all the change happening here is very much for the good. So I'm, I'm with you there. Yeah. Well, well, on that note, I, uh, I appreciate you being on. We, we, we, I think we did this at extremely short notice over the weekend was, which is, uh, which is nice. And, uh, I think, I think, I think, I think as you demonstrated, like, like so many people, uh, at Pivotal, it's, it's always fun to see the, uh, the sort of hat rack approach you have to things, you know, having, having, having many different, uh, many different hats and things. To speak to. So, uh, so thanks for being on. You're welcome.

Anytime you want me back, just let me know. Indeed. Well, as always, this has been Pivotal Conversations. You can go find us at soundcloud.com slash Pivotal Conversations. I'll put the show notes for this on the official Pivotal blog. Once I do the training of how to put it on there. And also on my website at Coté.io slash conversations 49, because this is episode 49 as, as a bonus exercise, figure out the, the standardized URL scheme I use for show notes. It's, it's always great if, if you enjoyed this podcast to go into iTunes and leave a star rating or write us a nice review. It's even better if you, uh, recommend it in Twitter or whatever systems of engagement you like operating in. Um, and if you're in something like Overcast, if you just hit that recommend thing, I think that does something positive. I have no idea, but it looks cool. And if you want to contact us, uh, you know, I'm Coté in Twitter. Where, where are you, Richard? You can find me at rsaroter on the Twitters as well. How about yourself, Ian? I am at Ian Andrews, DC. Oh, exciting. So, uh, with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.