Cat Swetel

Hello, I'm Cat. Oh, thank you, Dominica. Yeah, everyone be sure to squeeze into the middle so there's room.

Okay, I am wearing sunglasses. It's because I have a light sensitivity. It's not because I think I am cool in any manner.

This is my talk. So who's heard of Wardley maps before? Wow, everybody. Okay, cool. Not everybody, but pretty much.

Right on. So John Willis, I don't know, a few months ago, he's like, "Oh, you should come to DevOps Enterprise Summit and talk about Wardley maps." And I said, "No, thanks." So this should be interesting.

Moving right along. I'm just going to tell you my story, basically. I work for Ticketmaster. I manage the core ticketing engine, so basically the transaction engine at Ticketmaster, and this is how I came to work at Ticketmaster. This guy that I used to work with in financial services, also highly transactional, of course, he called me up and he said, "Do you want to work at Ticketmaster?" And I was like, "Oh, I don't know about that, Mark." And then he said the magic words, "Emulated VAX." And I said, "Where do I sign?" I was extremely interested in that, of course. Being a millennial, we like all things vintage. But I think it has to do a lot with my personality.

The bottom line, you don't need to worry about reading this, I'll explain it to you, but basically, Simon Wardley has this idea of pioneers, settlers, and town planners, and that's how we categorize ourselves. And the settlers is the people most likely to take a 3D printer made out of Legos and turn it into something that people actually want to buy. And that's totally me. In the emulated VAX, I found my 3D printer made out of Legos.

So, yeah, I see people taking pictures. There's the link. You can check it all out there. Simon Wardley, if you don't know him, he's this strange old man that lives in a swamp, and he believes that you should give away all of your intellectual property. There's no such thing as ownership. So there it is.

Anyway, back to my sweet baby VAX. Who knows what a VAX is? Is there anyone who doesn't know? I went to this conference a few weeks ago, and I was supposed to be there recruiting people, and I don't know how many people I ran into who never heard of a VAX before. So an old computer, that's what it is, a DEC VAX.

Anyway, moving right along. The first thing when I say that I run an emulated VAX and my platform is chock full of Macro-32, the first question that people have for me is, "Is that VMS? VMS is my favorite operating system ever. I loved it so much." No, it's not VMS. So I'm very sorry to disappoint you. I don't know VMS, but I appreciate what you have to say. I am sure it was the best operating system ever.

I love with the people at Ticketmaster, because there's people that have been there since the very beginning. The guy that sits behind me has been at Ticketmaster for 34 years. So the platform that I manage is only 43 years old, so he's basically been there only 43 years old, whatever. He's basically been there since the beginning. And they call VMS VAX Made Slow. And I think that is so ridiculous and funny. Something that's that close to the metal would be slow, but it was. For this specific use case, it was slow.

So in ticketing, you need to have a bunch of transactions all at the same time. So it is VAX Made Slow, and that's the first thing here is that they, in order to meet the needs of all of these tickets going on sale at once, and you have to sell out a whole arena, there needed to be a custom operating system in order to do that in 1976.

So it's not VMS, it's a custom operating system. It's in the code literally called Ticketmaster Operating System. And now you may be asking yourself, where does she get parts for a hardware VAX? Right, that was the question? You all, yeah. I don't. I do not get parts for a hardware VAX. It runs in custom emulation. So a custom VAX operating system running in custom emulation, because that's how we roll.

Yeah, there's one guy that's like, "Oh, this is hilarious. I have my own VAX stories." But that's basically it. In order to meet the need of selling tickets in a computerized fashion, which was something completely outlandish in 1976, it required a custom operating system. So that was a decision that the founders and the original programmers made. We're not going to build an application that will run on VMS. We need to have a custom operating system in order to sell tickets and meet the needs of our customers.

So it sounds ludicrous now to have a custom VAX operating system running in custom emulation, but at the time, a custom VAX operating system was the only choice. The only thing that made any sense at all.

Is everyone familiar with this evolution axis? Certainly some of you are because you said you know Wardley in the swamp. So it goes from genesis, which this is like a brand-new thing. Holy smokes, what is that? Custom, which I think I've already used the word custom like 1,000 times. Product, and then commodity. And so that's like electricity or something like that. But we'll go into this more later, so you don't have to worry if you didn't catch all that right now.

I have some news for you. It didn't even start on a VAX. It started on a borrowed PDP-11, which is ridonculous. Am I right? But I think that's a really important point in this story because of this.

So in 1976-- First, is everyone familiar with Mel Conway? Conway's Law? I think I've heard Conway's Law like 1,000 times since I've been here. Anyone not familiar with Conway's Law or Mel Conway? So basically, Conway came up with this law that people love that says basically that our systems will reflect the communication patterns within our organization. Yes? Make sense? Cool. Right on. That was a long time ago, and Conway kind of came up with that law, and he has actually continued to think post Conway's Law.

And this is something that I love from him, and you can look it up. He's written a lot about it. But basically about the history of our very young industry. And when the Ticketmaster operating system was built, it was built at this very interesting time between the pre-software economy and the software economy. So it used to be that you would buy hardware, and you would employ programmers to program. But there wasn't an idea of buying software. And when the founders were creating this operating system, it was right at this shift into the time when you would buy hardware, and you would also buy software to run on that hardware. So it makes perfect sense that at that time, they would think we should build an operating system. Right? Because software was just starting to become an idea.

And so the way that they chose where they would install the first implementation of this operating system is that they found an ex-mathematician who ran a record store. So he knew how to operate a computer because so many businesses didn't even have a computer there. So this operating system basically had to be everything for the business. Because this was you need a computer, and you also need this operating system in order to sell tickets.

Does that make sense to everyone? Does that not make sense to anyone? I can't see you anyways, so I don't even know why I'm asking that question. It's completely irrelevant, but don't you all feel heard right now? Terrific.

So this is what we end up with, the custom operating system and the product, which is the hardware. You can go out and buy this PDP-11 anywhere. The important thing that I think when we map things on that evolution axis, we can ask ourselves this question: How are we treating this component versus how is the rest of the industry treating this component?

So Pete and the other founders made this very conscious decision to say, "Yes, an operating system, VMS, is a product that people will buy. But we realize that that will not be able to meet the needs of this market, and so we're making the choice to create a custom operating system." Yes? So part of plotting things along that evolution axis is to make that apparent when you are treating things in a way that the rest of the industry is not treating them.

So compute now. If you have each beautiful baby server cradled in your arms, and you give it a name from your favorite sci-fi, you are treating compute in a way that is fundamentally different than the way the rest of the industry is treating compute. Yes? Yeah, some people are like, "Oh, I feel too seen right now." That's fine.

So the other way that I like to think about this axis is in terms of being conspicuous. I think evolution is fine, but then you get people that think, what's the difference between evolution and ubiquity? Yeah. Like does evolution mean that it's evolved, so everyone has it? And so for me, a useful frame is how conspicuous is this? So things that are in genesis, people are just filled with awe and wonder and don't really know how to handle the thing. They're more just in shock that the thing exists, and they're not even like, "Oh, how do I use that? How do I interact with it?" Commodity, do you notice electricity? No, you only notice it when it's broken. It only becomes conspicuous when it's not behaving in the way that you think it should be.

Does that make sense to everyone? So that's the frame that I'm going to use throughout the rest of this. So it basically goes from no one even knows what the heck that thing is, of course everyone notices it, it's completely foreign, to this thing I never even notice until it's broken, and it's basically never broken. Except if you live in California, never mind.

Moving right along. Okay, so this is a really high-level map of the ecosystem here. So the customer need is, "I need to sell tickets." Right on. So you need content. You can't sell tickets to just do nothing, stare at an empty stage, right? You need actual tickets. In order to have tickets, you need this operating system. You need a printer. Printers. Printers are amazing. In 1976, a printer would be the most expensive thing that this business owned. So there's all sorts of interesting things in the code to optimize how the printers-- Someone's extremely excited about printers over there. All right. Me too.

So basically, you need these other things. You need reports. Like, if we sell this many tickets, what's the take for the venue or the client? What's the take for Ticketmaster? All of these things. And they've made the choice to have this custom operating system. The printers and the compute are product.

Terrific. So what are we doing right now? Why did they call me up out of the blue and say, "Cat, will you come work at Ticketmaster?" It's because just like a lot of other businesses, Ticketmaster is currently going through this shift where it's shifting from a purely transactional model, we sell tickets, to a relationship-based model. And lots of you are probably involved in this because I keep hearing about it in the halls. Service pivot, anyone familiar with that language? Yeah. People in blue suits love to sell us on that.

So basically, now there's a shift from distinct transactions to maintaining a relationship with customers. Now our clients want to know not, does someone have a valid ticket to enter this event, but who is that person? Can I send them an offer afterwards to get a commemorative T-shirt? Are they going to want to go to the next tour? All of these things. So it's this persistent relationship across touchpoints and transactions.

So what does that mean? If you're going to have relationships with people, people are unique. Yes? Sure. They are, I promise you. So what we need to be able to do here is absorb the variety of the market, all of these different people with the different ways that they'll interact with all of these different clients, all of these things. So we need to be able to absorb all of that variety, and also, as tastes change and new things happen, we need to absorb those perturbations in the market.

Does anyone disagree with that statement, that we should just treat people all the same? Terrific. So that's basically what they invited me in to do. And now it's not they, it's us. Wonderful.

So if we want to absorb all of this variety, we have just one pot of money. One pot of money, regardless of what type of variety it is. Money, time, energy, all of these things. What if my platform is causing variety? If I have a handcrafted, artisanal deployment, that would be a source of variety. Yes? And I still just have one pot of money to absorb all of the variety from the market, so that's value-added variety, and then all of the variety that I am enacting on myself. Yes? So I still just have one bucket of money. It's not like if I cause myself more variety, I get extra money to take care of that.

And I think this is just a thing. Why do organisms die? Because the cost of maintenance to the organism outpaces the metabolic rate of the organism. Yeah? What did we do with Agile? We said we're going to learn really quickly. We're going to deploy frequently, we're going to get information, we're going to get feedback, and we're going to incorporate that really quickly. How do we, as technologists, metabolize information? Through code. Do we not? Yeah. That's typically how we metabolize information. And after you deploy that code, what does it become? A maintenance cost. Yes? Yeah. Some of you, I guess, need time to come to terms with that.

So we had the Agile Manifesto, and we say we're going to vastly increase the metabolic rate of these organizations. We're going to metabolize information more quickly, and that's exactly what Ticketmaster did. And then what? We don't have the ability to balance that with the cost of maintenance. So then what do we see? The rise of DevOps. Yes? And I think what DevOps is, in essence, is a movement that says we have to balance the cost of metabolizing new information with the cost of maintenance within the organization. Right? Yeah. I think that's a useful frame, and you're not on stage, so it doesn't matter what you think.

All right. So we want to absorb this variety from the market, but we have just our one bag of money and time and energy and all of this stuff to absorb all variety. Any big cybernetics fans in the room? This is extremely niche, but I really appreciate you being here. Anyway, so we have this one pot to absorb all of that variety, whether it's value-added variety, increasing our metabolic rates, we're able to metabolize information more quickly, or it's this kind of maintenance variety where just weird things happen in the course of conducting business.

So we have to keep that in mind as we move from transactions to relationships. So we're going through also a shift in the way that we conduct business, and we still have to deal with that paradigm, and we have to not die, which I highly recommend for all you business-minded folks.

So if we want to do that, if we want to decrease our investment in maintenance and we want to increase our investment in metabolism, which is basically what that is. If we want to maintain relationships, then we need to increase our ability to metabolize new information. Then what we need to do to enable that variety in the higher order systems is we need to evolve and perhaps standardize the transactions. So that we can build relationships on top of the transactions. So basically, we're faced with taking these things, which are all globbed up together. And pushing them all into product.

And there are tons of customizations made for each installation of this platform and all of these things, so it sounds quite simple, but unfortunately it is not. So this is like, oh, high level, very cute map. This unfortunately is just a small zoom in of a real map. And if there are any folks from Miro, which they create this canvas, I think you owe me a free membership or something. Just saying, because I'm out here spreading the good word. But there's this template. It's very useful because it takes you through the creating of the map step by step. Yeah, and it has all these tips actually embedded in the template.

So this is a for realsies map, and you see the operating system and the emulation there and the arrow that we need to move it into product, yes, so that we can enable the higher order innovation, all of that, absorbing that variety on top of the transactions. Very simple. We just remove whatever customizations are present in the code, and we're good to go. Yes. All right, so I guess I finished seven minutes early.

No, unfortunately not. The code turned out to be very simple. It turns out to be very simple to somewhat standardize that. Yes, it's just code. We can do whatever we want with it. The things that were much more difficult are all these things in the bottom, which are the actual practices, and yeah, they're kind of blurry because I didn't want to put anyone on blast. But all of these practices on the bottom, which looks like a hot mess of spaghetti, they need to be evolved along with the technology.

So if we evolve the technology to now it's more of a standard offering, a product, but we are treating it in our practices still as custom. We have a bunch of custom practices for our standardized technology. Are we getting the benefit of having this standardized technology? No, unfortunately not. So kind of my unofficial rule is I take whatever the furthest left thing is for the component, and I treat them all as that. So we would not be able to get those product benefits, the standardization, enabling the higher order innovation and absorbing of the variety until we drove out the variety in the actual practices.

So this is the whole big thing. I didn't just make this shit up. Wardley actually has a whole whatever table about it, which again, you can go look up. But we have to take those practices and take them from being this kind of emerging, beautiful, artisanal thing and make them more what are a set of good practices for doing this? Doesn't have to be best practices. We don't have to have driven out all of the variability, but we need a set of good practices for handling this.

So the first thing is basically this bottom arrow and then the big crossed-out part, which is basically everything needs to be in source control. No-brainer. Yeah, but when you're dealing with a platform that's 43 years old, it's a bit more of a brainer than you might expect. So everything needs to be in source control. We don't copy anything from one prod box to another or any of that kind of stuff. So also source control should just be an off-the-shelf thing whenever possible. So that's kind of the first thing there. And you see the heads, that's obviously manual intervention, so we're trying to get rid of some of that.

And then we also need testing. I don't know if you know this, but there's no Macro-32 unit testing framework. Just who would have thunk it? So we had to come up with this way of testing the Macro-32, and there's also Pascal in there, and then there's all the emulation and all that jazz. I'm only 31 years old. Every day I'm like, "Ugh." Anyway, so we came up with this testing framework so that we can have confidence when we deploy something to prod. And we don't have to hand it over to testers to just dream up whatever testing. So you see, we're building a CI pipeline here bit by bit, literally bit by bit. It's VAX assembly.

And then we move on to the deployment. Yes, so we build a CI pipeline, and that involved actually a bunch of things, like we containerized our emulated VAX, which is definitely the most ridiculous thing you'll hear all day. Every time I say the words out loud, it just feels ridiculous. But that's what we did. We containerized our emulated VAX so that we could have a proper CI pipeline, and then moving on to the deployment, which originally we had to home grow that automation, but then moving on to tools.

So through this process of mapping and remapping and mapping and all this stuff, we came up with these principles. And the first one is show respect for history. So I was actually hired by Ticketmaster right after a bunch of failed rewrites of the platform. If you have something that has had 43 years to get really good at its job, and its original intent was, "I want to be so custom for this thing that I'm the very best thing," you're not going to be able to just send some people off in a room and rewrite that.

So first thing, always show respect for history. Go and find out why is this implemented the way it is, and do we now need to treat this in the same way? Do we still gain an advantage from this, or is this some source of variability that we could drive out?

And then all of these other things. That's obviously the most important. Buy when possible. This is just a thing. When you're out so far ahead of the rest of the technology industry like they were in 1976, you have to build all of your own tools because tools don't exist. That's not a thing. They exist now. We have a whole exhibitor hall to show that. So buy when possible.

Visibility is a priority. So we want to make all of the things visible. Dominica could probably talk about that much more better. So we have a monorepo which contains... Monorepo, I don't know. But it contains all of the code that is associated with this platform in any way, and then it also contains the code for the gateways to this platform.

Skills duplication, we always favor that over speed. So if there's an opportunity to duplicate skills somewhere, we would do that rather than just try to get things out the door. And then standardize, then automate. So we are conscious of the fact that premature automation just ossifies things in a way that could be potentially harmful. So we want to make sure that we've actually standardized things, even if it takes a little longer, and then automate it. All because we want to increase the variety that we're able to absorb by driving out non-value-added sources of variety.

So what we're doing here is creating disfluency. So not the way that you've always done things, but examining is that the right way to do things now? And I think that's really important, and I want to get to this because our industry is really young. How do you measure the age of a baby? In years? Probably not. Weeks or months. Has someone ever said to you, "This is five years old. I'm done with it"? We are babies, so we have to learn that respect for history. Our industry, we are babies.

Our industry is so young. So developing this ability to create disfluency and developing this ability to show empathy for the past and respect for history, but also looking forward, that is the critical thing that we have to develop now, not a super awesome ability to deploy everything in Kubernetes.

And that's it.