Is the Customer Always Right?

00:00 Adam

Hello again, everyone, and thanks for joining us for another Particular live webinar. My name is Adam Wright. Today, I'm joined by NServiceBus champ and CEO of Kaizen I/O, Kijana Woodard, who will answer the question, "Is the customer always right?" Just a quick note before we begin, please use the Q&A feature to ask any questions you may have during today's live webinar, and we'll be sure to address them at the end of the presentation. We'll follow up offline to answer any questions we are unable to get to during this live webinar. As a reminder, this webinar is being recorded, and everyone will receive a link to the recording via email. Okay, without further ado, welcome, Kijana.

00:44 Kijana

Thank you, Adam. All right. Today, we're here to talk about, "Is the customer always right?" So first up, a little bit about me. My name is Kijana Woodard. I go by my first and last name on X and LinkedIn. I have been a professional programmer since the mid to late '90s. Kind of started off VB 4, 5, 6, and then got into .NET right at 1.0, so since the beginning. I think I still might have some apps kind of built in .NET 1 or 2 out there. I've worked in every kind of organization, company imaginable, from the largest Fortune 500s all the way down to very small startups. In terms of technology, I've done the traditional interior development, SQL server, relational database that everybody in .NET has done.

01:45 Kijana

I've used WinForms, Web Forms, WCF, and then right around 2010, when I started consulting, I learned about NServiceBus, and started doing messaging, and then started just exploring that whole space with messaging, event sourcing, document databases, DDD, CQRS, all the things. Like I said, I've been consulting since 2010, again working for a wide variety of organizations, and now I run Kaizen I/O, and we help mid-market business owners unblock operational bottlenecks, in order to maximize their business performance.

02:30 Kijana

So today, what I want to cover is when is the customer wrong? How can we break apart our systems and make a distributed system? What problems emerge from breaking things apart? And then, how do we tie everything back together? So is the customer always right? And the emphasis is on the word the, because we tend to build systems where there's a single concept, a single model of a customer, and I think that becomes problematic, but you hear it all the time. It's like, you're dealing with microservices and people say, "Oh, we built the customer service, talk to the product service, the order service," and then even at the database level, you'll see, "What's the customer status?" or, "The product description," or, "The order status." And these things, I think they're very natural that this is the way people think, but it causes problems.

03:34 Kijana

I was working on a project one time. The setup was that they sold products, along with some other services, on a website, and there was a customer-facing website and then there was a back end, sort of operational website. And when we started, it was like, "Well, we'll just have copies of the products in both places." And the reaction is, "Well, we need a single source of truth." That's something you hear all the time. "We need a single source of truth for our product information." Like, "Oh, okay, well, fine." And so like, "Okay, what do we got here? We got a SKU, we got a description, we got a price. Okay, fine."

04:11 Kijana

So you set that up and you say, "Well, here you go." And then, when you look at, it's like, "Well, the description that we have is really kind of long-winded, and it's for customers, but the people that are doing pick and pack in the warehouse, that's too much information. And they're really used to just looking at a much shorter description, to find, and pick, and pack the products." And you go, "Okay, well, we'll make kind of a short description for that pick and pack procedure." And it's like, "Well, there's also customer service reps, and they don't know the products of the level of the pick and pack people, but they also don't need this long-winded description that the customers see."

04:54 Kijana

And you go, "Okay, well, we'll add another column. So okay, are we good?" And then, "Well, some of our SKUs aren't really orderable by the customers. We don't want them to be able to order that. They get ordered by customer service on behalf of them for certain special situations. We don't want to show all those products to the customers." Like, "Okay, so we need some flag of whether it's available." And as you kind of keep going through the scenarios, it just gets more and more complex to put all this information in this single source of truth.

05:34 Kijana

And then, the other thing that comes out is when you take a step back, it's like, "Are we getting any value by having it in one spot, because, well, we only show this description over here. We only show this description over there. We only show these products over here. We show those products over there. And sure, there are some that are duplicated, but really, the overlap is just the SKU." And it's like, "How much duplication is there really, just this SKU? Well, that's not much of a problem." Further, if you're trying to go in and add a product to the system, you have to now take into account every possible scenario in the company, and fill out the data appropriately, just to add a product. And if you just wanted to add something quickly for the back office team to put in, you have to kind of go around the company and ask everybody like, "Well, is there ever a situation where I need to enable this feature for these other scenarios?" And it just becomes really complicated.

06:46 Kijana

And at the end of the day, like I said, what problem did you actually solve? There was hardly any real duplication, but it's so tempting to sort of mentally put everything in one bucket and say, "We have a single source of truth for products." So I wanted to explore this idea of how customer, if you want to build a customer table or a customer service, how that typically gets shaped out. And so I decided to do what we do nowadays, and I asked LLMs to give me a design for a customer, for an e-commerce site. And so ChatGPT gave me this output, and it says, "Okay, yeah, you got your first name, and last name, and email and there's a password. Okay, okay."

07:36 Kijana

And then, I see down here at the bottom, it kind of adds like, "Oh, a newsletter subscribed," and you get a Boolean. Like, "Okay, well, I guess you have one newsletter." Loyalty points, and you get an integer. Well, hopefully there's no decimal values, it's not actual dollars. It's just integer. You get an account status, which has some examples, but it's a VARCHAR(20), so it could kind of be anything. So okay, but you get the beginning of a lot of concerns sort of mixed into this table. I asked Grok the same question, and it came back with a slightly different answer, a lot of the same stuff with first name, obviously, first name, last name, loyalty points, but he also threw in total orders and total spent, which is an interesting thing.

08:33 Kijana

Because the rest of this is sort of crud data, but total orders is like, "Well, this is a calculated field from somewhere, so there must be some process that's keeping that up to date, and how would you validate that it's right?" is an interesting thing. But it's just kind of putting everything together in this one table, like, "All right, that's an interesting idea." And then, Claude just said like, "I'm not going to do this single table thing. You're going to get multiple tables, and I'm going to support multiple addresses, and customer loyalty, and it's going to be separate preferences thing." So Claude got really adventurous and did kind of a robust design for this, but again, it's sort of putting all of the concerns close together into one bucket.

09:25 Kijana

And so if we look at those examples, I think they're pretty typical. I also did some searches on Google, and saw a lot of people's designs, and it's all very similar things. If you're anything like me, when you look at a design like that, you look at it and you start picking it apart. And I think the way you pick it apart is you sort of imagine scenarios and say like, "Well, what if we want to do this and what if we want to do that?" And then, you sort of look for whether the model that you've established can support it, and then either criticize it because it can't support it, like, "Oh, you can't hand them multiple addresses," or something, or you want to adjust the model. But I don't think, ultimately, that's a great approach, because really, architecture and design are only relevant in whatever context that they're created in.

10:24 Kijana

And I think it's really easy to sort of look at a design and sort of criticize it based on almost imaginary requirements, and saying, "Well, it's not flexible, it's not this or that," but it's really hard to know what are the true constraints in the abstract for some software. So what is the time constraints, what's the budget constraints, what are the user's needs? You need a context, and that's true for building physical buildings, and it's also true for software. So one thing I want get across is I think we make a mistake as developers, architects when we're trying to chase the perfect design. There's that word the again, where it's like, "There's one right way to do things and one right approach."

11:17 Kijana

George Box has this great quote that I use a lot, which is, "All models are wrong, but some are useful." And for me, that's great, because it sort of lets you off the hook in the sense of, "Hey, we're trying to model the real world here, and whatever model we come up with is wrong. It is not a perfect replica of the real world by definition." And so you can kind of let yourself off the hook to some degree, and go like, "Hey, I'm not trying to build the right thing. I want to build something useful." Something that makes me cringe is you hear a lot on projects is whether it's a re-writer or a brand new project, the kind of goal is like, "We just need to design this right the first time." And there's so much presumption to that statement, the idea that you're going to figure everything out about a project and get it all right before you even start, get all the requirements down and get them correct.

12:28 Kijana

It's so hard to do. I don't know that I've ever seen anybody even come close to accomplishing it. And at the same time, you waste a lot of time not getting feedback. Even if you could somehow manage to get all the current requirements down, for sure, you don't have the future requirements. You don't know how things are going to change in the future. Even if you don't want to change your system, the universe changes out from under you, right? The cloud provider changes things. You're on Google Cloud, and they deprecate some service. You get zero days that get discovered, and now you got to change the system to react. The market changes around the business, right? There's technology shifts, where you did something a certain way, and now there's some new technology available to you, and you would do it differently in the future.

13:26 Kijana

So you can't even know what's good today. You certainly don't know what's good tomorrow. And so instead of trying to worry about making the correct choices, try to make something that's useful, get something shipped. And I am sort of, in my current, thinking instead of like, we always talk about building something that's reusable, "Build something that's robust and reusable that we can reuse this component all over the place," I try to think about building for disposability. How can we build something that's useful right now? And when it's outlived its usefulness, we can throw it away and replace it with something better.

14:11 Kijana

To the point of getting something out and making something useful, shipping is a feature, right? If you put something out, that's the other element of shipping, is when it actually gets in front of customers, they will change the design with how they react to it, how they use it, and you have all these grand plans, and then you find out that the real need that people have is something totally different and you totally didn't think of, and now you're off on a whole new direction. So prioritize shipping over coming up with the perfect design. So with that said, I kind of started talking about microservices in general and how do we take this customer, split it apart? "Our microservice is the right way," the again, "to build software." And sure, there's a lot of benefits to microservices, scalability, flexibility.

15:16 Kijana

You can use different technologies in different places, fault isolation, maintenance, resource utilization, security. Those are all great, but for me, the last two here, faster development and deployment, and better team organization I think kind of take priority. I think that's really the point of dividing up your system, is you're trying to be able to develop in a better way. So you want smaller, focused development teams like, "Here's your sphere of influence, you can focus on that." Clear data ownership. You know, "This piece of data belongs to... Who's responsible for making this? Sure this is correct and available." Reduce complexity for the team, more autonomy in development and decision making.

16:10 Kijana

So to me, this is the sweet spot of dividing things up, not some abstract like, "Well, it's good to have multiple processes," but something, "Okay, how do I enable the teams to go faster?" And more autonomy and clear ownership is, I think, key to that. So you want your teams to be able to go full speed. Well, okay, so do you have to have a distributed system? Do you have to have microservices? Well, I mean, think about it. If the goal is to go as fast as possible, well, what if you only have one developer? There's one developer making all the decisions? Maybe that developer also owns the company, it's a startup. That person can already go full speed, so do you have to divide things up? I would say not necessarily, and I wouldn't get too hung up about trying to do the right thing. I think kind of take your highest and best opinions, and sort of drive forward, get something shipped, and try to find product market fit is the most important thing.

17:23 Kijana

And with one person, just kind of do the best you can, and you'll find out whether customers resonate with it. If they do, well, great. Now, you have time to go and change things into how they, quote, "should be", like you learn things and you can change the code. If it doesn't resonate, well, you just throw the whole thing away anyway, so it's fine, right? So that's in the one person case, you already are unable to go full speed, so choose whatever makes sense to you. Personally, if I'm working by myself, I still sort of have a virtual mapping of different services, even if it's in one process. I think some people call this modular monolith, and I think that's a great approach to sort of breaking things up logically, without breaking them up physically.

18:22 Kijana

So let's say you add another person, so now there's two people that you're working with, and you end up with one connection or communication path that you have to manage between you and that other person. I think it's interesting, because sometimes, two people can go faster than one, just because with one, at least for me, you got to get stuck in analysis paralysis, and you're kind of overthinking things. And with a second person, hopefully they can balance you out and say, "No, no, this is good enough. Let's go," and you can kind of move a little bit faster. The other thing that happens with two people, you already sort of start to see people have an affinity for certain parts of the system, and somebody takes over this area, and somebody else takes over another area, and if something comes up, "I'll take that one, because it's sort of naturally in my area."

19:19 Kijana

I've seen this for over 20 years now, and I just think it's almost like a primitive form of service boundaries or bounded context that just emerges naturally between people, which I just find interesting. You go to three people, there's three communication paths. By the way, this whole communication paths is Fred Brooks's Mythical Man-Month. I've got Claude to generate these SVGs for this, but that's where this idea comes from. And so okay, with one, two, three people, the number of connections is pretty linear, and then you add four people, and now, all of a sudden, okay, there's six connections between all these people. You talk to the other three, but they talk to each other, and now you've got six ways that things need to be communicated.

20:12 Kijana

You go to 5 nodes and there's 10 connections, it's like, "Okay, well, it's not sort of linear. The number of connections is going up pretty fast at this point." Now, I'll stop here to say I kind of think if you have one person who's highly opinionated, highly motivated, they probably can go the fastest. It may not be the best product, but they can ship. I tend to three-to-five person teams. I think that's pretty good, in terms of a balance between redundancy, and being able to collaborate and get things done. But as you get bigger, you get 12 people, and all of a sudden, just at 12, there's 66 communication pathways. Everybody starts to talk to everybody about all kinds of things, and it gets really hard to sort of have this memetic transfer, where ideas make it into everybody's head, because there's so many different versions sort of floating around.

21:17 Kijana

Just as a side note, it kind got interesting, because I asked Claude to generate larger and larger of these nodes, and at some point, not too far after 12, I just kept getting blank screens. It couldn't draw all the connections, but it gets pretty crazy, pretty quickly. If you say, instead of calling these people, you say they're teams, and now they're teams of people, and they're all talking to each other, let's just pretend, in some perfect world, it's just the PMs talk to each other. I think that's what the management dream would be, is that it's just the PMs talking to each other, but still, you just have all of these pathways that have to coordinate in order to make progress.

22:04 Kijana

And what happens when you have what I would call the customer, the order, the product is you have this noun-centric, entity-centric worldview, but when you want to do something, you end up having to have each service talk to every other service. So you want to ship an order, and it's like, "Oh, well, the shipping address is with the customer, the product size and weight is with the product. We got to call the order to figure out what's on the order. We got to do all this coordination just to get the stuff to ship." So the activity of shipping is sort of blocked behind all the services. And the more that goes on, you end up with a situation that kind of looks like this chart, where all the services call all the other services. And if any one of them is having a problem, nothing works. Well, if one thing has a problem and nothing works, then why did we take all this trouble to make everything distributed? There's no resiliency, there's no autonomy.

23:16 Kijana

It is just sort of a big ball of mud, as we say. There's just a big mess, right? So what's a better way to sort of approach, if this entity-centric view doesn't work that great? What's a better way that you could find to divide up your system? Well, I like this approach that I got from Udi Dahan's Advanced Distributed Systems design course, of starting with activities and then sort of figuring out how they group together. So it's more of a bottom-up approach, where you go like, "Okay, what's actually happening? What are we doing?" And then, seeing which one of those are kind of closer together.

24:02 Kijana

So just have some sort of toy activities, like you place an order on the website, change the payment method, you subscribe to a newsletter, place an order by phone, you add a shipping address, and you add a billing address. The billing address, shipping address, I like this example, just because this is an example that every single one of us has experienced with real websites, where they ask you, "What's your shipping address and then what's your billing address? Is it the same as the shipping address?" So we've all seen this sort of split. And I think one idea, if you look at the activities, you might think, "Oh, we should have an address service," and this address service, it's tempting, because, "Oh, we have multiple kinds of addresses." So you have an address service, and we'll say, "Some of them are shipping addresses and some of them are billing addresses," and it feels kind of good that you're going to sort of centralize this.

25:08 Kijana

But then, as you start peeling things back or going deeper into the business, it starts to make less sense. So you have a shipping address, and you have a home address, and then a relative's address because you send them gifts. Okay, and they're like, "All right, billing address." And then, at some point, you kind of realize, "Well, the billing address might be the same as your shipping address, but it might not." And why does it vary? Well, it varies because, "Oh, I need to pay for this with my business card, and my business card, the billing address is the office address. Oh, wait a minute, the billing address isn't tied to a customer. The billing address is tied to a payment method."

25:55 Kijana

So now, you're in your address service and you start to think, "All right, well, I need to say that this billing address is tied to this payment method. So I have a payment method column, but where is that data coming from? Do I have to bring payment methods into the address service? That feels weird." And then, for the shipping addresses, they don't have payment methods, so it's null. So every consumer of this address service has to deal with this nullable column that is sometimes null if it's a shipping address. But we already have a thing that indicates a type that says it's a shipping address. So then, now you have to also account for things like, "Oh, I got a billing address, but it had a null payment method," and it just gets real messy really quick.

26:50 Kijana

But if you start to clump things together and you go like, "Well, okay, look, placing an order on the website is kind of similar to placing an order on the by phone, and the changing a payment method is related to its billing address, and then you have the shipping address. Okay, these feel different. This newsletter one, I'm not quite sure yet what's happening there, but it's kind of marketing, marketing leads to sales. I'm going to kick this one down the road." But you start to see like, "All right from the bottom up, I've seen that these kind of things are similar, and now that I see that they're similar, I can sort of evaluate them and go, 'Oh, I see this is kind of a sales-type domain, and this is sort of a billing context, and this is a fulfillment context'." Like, "All right, that makes some sense." But we've kind of approached it the other way around, from the bottom up instead of from the top down.

27:53 Kijana

I think when you start from like, "All right, I'm going to have sales, billing, fulfillment," and you start trying to put stuff in it, one thing that happens is you start inventing things, just sort of making things up and sort of putting them in there, versus addressing actual activities and actual customer needs. So these names, the key thing about them is that they're stable business capabilities. I think that's a great way to organize, if you're going to split things apart, to organize them under these stable concepts. So they're core, enduring functions that remain consistent and fundamental to an organization's value creation, regardless of changing market conditions or technological shifts.

28:40 Kijana

So if you think about sales, billing, and shipping is sometimes used, but I like fulfillment, just because if you're not shipping products, you still have to fulfill, every business ever has to have a way to sell. It has to have a way to collect money, and it has to have a way to fulfill on whatever it's promised its customers. So this is never going to go away. And when you have breaks like that, well, you can count on it not shifting out from under you. Maybe there are some concepts that, for a particular industry, are pretty stable, or maybe even for a business, this is like there's some unique value prop, that's pretty stable, and those are all fine to use, to find them.

29:26 Kijana

One sort of trap that I see people go to is they sort of try to shape the software around the current org chart, and company org charts are just not stable. They change for all sorts of reasons that have nothing to do with how the capabilities relate to each other or service. Customers, you know, know CFO is in charge of something, and then there's a shakeup, and now it's moved to somebody else's office. So just don't even try to look at the org chart for inspiration on how to break up your system. So okay, we've sort of broken everything apart, but where is that customer? What happened to the customer? Well, the customer is still right there, right? All we're doing is we're saying, instead of saying, "There's a customer service," the customer has different aspects expressed in the different services.

30:25 Kijana

So in this example, I have customer ID one, two, three, four, and I'm sort of saying, "Oh, these are the sales aspects of this customer, the billing aspects of this customer, and the fulfillment aspects of this customer," are kind of broken apart into their constituent places, right? And the value of this is that each one of those places can sort of optimize as it wants to, as it needs to, without excessive coordination with the other group. So for instance, if billing's kind of going along and they decide, "Oh, boy, we need to accept crypto," it's not something that you have to add to the customer service. You just add it to billing. Billing does its thing, collects money, and then tells the other groups like, "Okay, this order has been paid," and all the other groups can... You know, shipping can ship the product or whatever, fulfillment can proceed.

31:27 Kijana

One thing that I think often gets confused with microservices is the idea that a microservice or a service is a process, and it's not one-to-one with a process. So it's a little tricky to think about, because people say like, "Oh, well, the web app is a service, it's got to call all the other services." Well, the web app isn't a service, it's just a host, and each of the services sort of expresses itself in every process. So the service wants to own its data, own its capability, and express that everywhere, in all the systems and all the aspects of the company, whether that's a web app, or a mobile app, or even on an invoice or a receipt, you see the services sort of expressing their part of the system to make that happen.

32:25 Kijana

And the reason you're doing this is because your customers don't care about your microservices, they don't care about your organizations. They want a cohesive picture of their interaction with your business. They could care less whether you have 99 services or not. They just want to have a receipt, or an invoice, or whatever, and have all the information that they expect there. So we've split everything up. How do we sort of get everything back together? One, I wish this picture... If I had more time, I would take this picture and just turn the arrows around, because really, it's just kind of going back to where you were, in a sense, with a slightly different problem set, right? So we need to have a cohesive user experience. We want to bring all of the information that we've separated out, bring it back together. How do we do this? There's a bunch of techniques, traditionally, in NServiceBus, you have a process host, and you put DLLs from each of the services in there, and they sort of collaborate together.

33:37 Kijana

You agree on some interface, and this is where we've spent time sort of being autonomous and going full speed. We can make changes for each service at its own pace, at its own discretion, but somewhere along the line, you have to kind of come to an agreement, like, "All right, we need to present this cohesive picture to the customer. Let's agree on something so that we can bring things together." But it's a very sort of lightweight thing. You're like, "Okay, here's the information that I need from you. Here's the information I need from you." How you actually produce it, no one really has an opinion. Each service can sort of optimize that to its heart's content. The great thing about too is if there's a problem, if you say like, "Oh, hey, the billings isn't happening," or, "Some piece of information isn't showing," you know exactly who's responsible for it.

34:40 Kijana

It's not a mystery. It's not like, "Oh, I don't know. Is it the database team? Is it the networking team? Is it this team?" You're sliced in a way where the responsibility is very clear, and who owns it is very clear. So you can say, "We'll have DLLs deployed together in a process." You could have multiple app, like the web app, mobile app, and have teams contributing PRs that bring their piece of the pie into the apps. You can do a UI composition and some sort of client side composition, to have each service grab its own data, and then compose it onto the screen, or you can do a composition in a database. So you could make sort of like a projection view model, database tables, or what have you, where the idea would be like whatever screen you're presenting to the user is going to simply query this table. It's designed for this experience, and now you've agreed on what fields, what keys are going to be there, and you just sort of put them where they go and style them as the brand advisor wants.

35:53 Kijana

And so it's all displayed correctly. All the data is brought by the responsible service that's authoritative to it. So here's an example of doing exactly what I said, but using Redis as a way to do the integration. This is a Redis hash object, or... And so in this example, I'm just saying it's instead of customer ID one, two, three, four, it's order ID one, two, three, four.

36:27 Kijana

So the key in Redis would be order view one, two, three, four, and sales is going to provide the first name and last name, billing is going to provide the payment method, the identifier, the billing address, whatever. And then, fulfillment's going to provide a tracking number and a shipping address, and they all kind of put their pieces of the puzzle here, and then to display it, it's like, "Well, we've agreed what these names are. Now, we can just take those and put them on the screen, and make everything presentable to the user."

37:07 Kijana

Now, let's say that there's some need to cash. Well, if it's a billing thing and we're going to cash the payment identifiers, well, billing knows all about whatever cash problems there are, like whether this is valid or not, and they can optimize that experience for the user in their context. It's not like, "Oh, the web team is trying to guess whether this is still valid data from the billing team." It's the billing team itself that can optimize that experience end to end. And that's the key to sort of breaking things apart, going full speed, but yet bringing it all back to having a cohesive experience for the user. And that's what I have, thank you.

38:00 Adam

All right. Thank you, Kijana. We have a few questions we got prior to the webinar that I'd like to ask you.

38:11 Kijana

Okay.

38:12 Adam

So the first one is, you might've answered some of this already, so feel free to emphasize a specific thing, but the first one is what is the correct context for the customer service? We've packed everything customer into one service, like authentication and other various services that deal with customers, so...

38:30 Kijana

Yeah, I mean, so that's kind of what I was talking about with even those examples from OpenAI, you end up with this situation where there really is no... When you kind of think about it from the perspective of, "Oh, we've got to have the customer service," there's really no end to that. It just can grow forever, because everything is related to the customer. Like, "Oh, this is the customer's name, yeah, this is the customer's address, yeah, this is the customer's this and that," and it just grows indefinitely.

39:05 Kijana

And then, it gets really nebulous about who owns what and what you can do with things, like you have a customer status, and it says, "They are," whatever, "deactivated." What even does that mean? Can they log in and see previous orders? Does that mean they can't log in? Can they log in? Can they make new orders? Can they see? It just becomes very unclear. Whereas, if you have things separated, and it says you're in some sort of auth context, and you know that they can't log in from this auth status, that's very clear. Whereas, when you put everything in one big bucket, it just becomes very squirrely to try to figure out how to make decisions.

39:59 Adam

All right, that makes sense to me. How do you future proof this approach for evolving technology and business requirements?

40:07 Kijana

Yeah, future proofing is, by nature, tough, because who knows what the future holds? But that was sort of... If I can go back a little bit in this slide. So imagine... I think by dividing things out where the services have autonomy and can kind of control their destiny, you're still going to make mistakes. You're not going to guess right all the time. So right, here I have payment method, payment identifier. Well, maybe we started with just credit cards, and instead of saying, "Payment identifier," I said, "Last four of the credit card."

40:50 Kijana

Well, we wake up one day and, "Oh, we want to accept crypto," and it's like, "Oh, crap, last four of the credit card doesn't make sense as a key anymore." Okay, well first of all, in order to accept crypto, there's a bunch of work, and we can kind of do all that work as billing, figure out how to accept it, and say, "Okay, great." And then, second of all, we can kind of say, "We know where all the integration points are. We know where billing is expressing itself all over the place," so we need to audit through all those integrations and say, "Hey, we used to say last four of the credit card, we're going to add this new key."

41:31 Kijana

And then here, how you actually do this is up for every organization, but, you know, "Here's a PR where we stop using last four of the credit card and we start using payment identifier." We've been filling out both for a while, but for people that use crypto, it would be a little weird, because it'll say, when it says, "Last four of the credit card." But we have all the flex points in place. So really, it's not future-proofing it from the idea that, "No matter what happens, we already have accounted for it," but that we can account for it, and we have a way to evolve into the future.

42:15 Adam

Okay, and this next question piggybacks on that one a little bit. What are the most common mistakes organizations make when adopting this kind of model?

42:26 Kijana

Yeah, I think the first common mistake is sort of the noun- or entity-centric modeling, customer order product. I think that's the first mistake which we've talked about a lot today. I'd say that another big mistake is sort of using a bus, or a queue, or topic as a data transport, where you end up shipping the data all around, like, "Oh, they updated their name. We need to publish that and then have everybody subscribe to that."

43:00 Kijana

And I think the problem with that is ownership becomes unclear, you end up with a situation of what's the source of truth for this information? Well, if there's a service that's providing this information everywhere, it's very clear who's responsible. But if you just sort of publish it for everybody else in the enterprise to consume, you're left in this cash and validation problem, which is one of the three hard computer science problems. So you just put yourself in a worse situation.

43:35 Adam

All right, I think that's all the questions that we have. Thank you, Kijana, for joining us and presenting the topic today. We do have a few very short announcements. Would you like to learn more about the techniques described in this webinar and other challenges related to building distributed systems? Udi Dahan's Advanced Distributed Systems Design course will take place on March 3rd through 7th in Atlanta, Georgia.

44:01 Adam

Early pricing is still available until December 15th. Please visit Particular.net/ADSD for all the details. Also, our colleagues will be speaking next Thursday at CloudBrew in Belgium and at NDC London next month. Go to Particular.net/events to find us at a conference near you. That's all we have time for today. On behalf of Kijana Woodard, this is Adam Wright, saying goodbye for now, and see you on the next Particular live webinar. Thank you.

Is the Customer Always Right?

🔗Why watch?

🔗In this webinar you’ll learn:

🔗Transcription

About Kijana Woodard

Additional resources