Subscribe
Share
Share
Embed
CJ & The Duke decided to play out a thought experiment whereby the complexities of geographies and process areas were mitigated via new production instances, rather than exception management. THIS IS NOT ADVICE, it is simply testing what we think we know.
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
[00:00:00] Duke: Hey everyone. Welcome to another CJ And the duke as always. I'm your co-host Robert, the duke.
[00:00:06] CJ: And I'm Corey, CJ. Wesley.
[00:00:07] Duke: listen, no sponsors, nothing. We're just straight to business. Cause Corey and I, we do this to ourselves all the time. We say, what are we going to talk about today? Corey? And we go on for half an hour. We basically like argue about something or, bounce ideas off each other. And we've already done a full episode. We done, we've spent enough time to make a coherent episode and we didn't record it.
So then we decide on a topic and then we're all worn out. So today we're winging it. , but we do have a topic, right? Corey, what is today's topic?
[00:00:41] CJ: So today we're talking about whether or not it's ever justified to have multiple production instances.
[00:00:47] Duke: Right. And I want to make clear to everybody because it is a controversial opinion. Is it not a Cory? Like the idea of why can't we just have multiple teams with multiple instances.
Right.
[00:00:54] CJ: Yeah, I think a semi, controversial, right? Cause , there's ever-present urge to consolidate right. To get everything on one instance and have everyone in the same place using the same data sets and so on and so forth. Right. So I think it's semi controversial to say, well, what if we didn't do that?
[00:01:09] Duke: we just want to make clear, this is a thought experiment. This is not advice. Okay.
[00:01:14] CJ: Yeah, absolutely. Right. Like this is like a lot of our episodes you can take at face value and, find a lot of wisdom and the such that to implement the right lane. this is all just, we're just riffing here. We're just putting stuff out here. We thought this was interesting conversation.
So we're recording it.
[00:01:30] Duke: So wait a second. Who's playing the bad guy in this episode.
[00:01:33] CJ: I think I'm the bad guy in this one.
[00:01:37] Duke: Okay. Corey, what's your, what's your property?
[00:01:40] CJ: So, so my thought on this right, is that there are occasions, um, and maybe those occasions are probably more numerous than we give credit. Um, we're having multiple production instances. I think the marginal cost of doing this, if my knowledge of service not licensed and is correct. is it too much, right?
It isn't a big deal, big enough deal, especially for like companies that would get benefit from doing this. And, there are a lot of use cases where I can see, or at least a few that are, rather be. Right. And I can see a lot of value return if we were to implement a situ a solution like this, right?
there's always these mega courts, right? Like the, what they call them multinationals. Yeah. So there's multinational corporations, right? They have, operations all the way across the globe. And, you know, from the perspective of America, right. We typically look at regions, right.
fairly big and fairly flat. And if we don't take an take into account, a lot of the nuance, right? when we say a Mia, Like we think of AMEA as just one kind of cold coherent space, but as a bunch of countries with a bunch of languages and a bunch of, customs and, differences that, aren't really fully realized in the word and the branding of AMIA, same thing with Asia pack, same thing with the middle east, so on.
And so. Right. So if you're a mega Corp and you've got, these operations and expand across the globe, and you've got these various different customs and maybe, different ways of doing business in these local offices, and I've been there, I've worked in one, there are different ways that things get done.
Now, why shoehorn those different processes into one global process when they might create more innovative?
you think on that duke?
[00:03:17] Duke: Yeah, I'm, I'm keeping an open mind, , and try not to apply any ethnocentric bias or anything. Would not a business want to take the most efficient way of doing things and just say, this is the way we're doing things everywhere.
[00:03:31] CJ: But why does so, but yes, but what makes one way the most efficient way of doing things? Maybe it's a one to many relationship on the most efficient way of doing things.
[00:03:41] Duke: Mm.
[00:03:42] CJ: maybe a global process ultimately is more inefficient than several local processes that then sync up.
[00:03:50] Duke: So my contention is like for a single company, one instance is better than multiple instances on that's that's, that's my contention. And I think in this case, like why not build exceptions into this primary system for cases where you need local, various.
[00:04:07] CJ: Man, the second exception soft dude.
[00:04:11] Duke: They do, but if they're necessary, right? If it, if the value is justified, like we have some process that like, your contention is like language or cultural reasons, can't the process can't work the same in two different regions. Right.
[00:04:24] CJ: Yeah.
[00:04:25] Duke: Or that's just like our hypothetical scenario.
[00:04:27] CJ: Yeah. Just hypothetical.
[00:04:28] Duke: It's just hypothetical.
So if I had a, if I had something that worked better in, , let's say the middle east, , for a certain set of countries, like what the I'm I'm already saying it's valuable that it works differently here because it works better there. So doesn't that justify the complexity of an exception.
At a cheaper level than justifying a whole new instance.
[00:04:54] CJ: Maybe, I mean it, does it work better there or does it work better there? Right. I mean, that's one of the things, right? So you, you have to figure out whether or not that process is a situation where their process works better at a global level, or if it just works better for them locally, but then you also have to take into account, like how complex is that actual.
And how many of these exceptions are you going to have when you scale out to looking at all your operations across the world? Right? I mean, it could be a situation where you see this one exception and then, as you kind of scale this out and start to look at all your operations globally, maybe you end up with 10 or 15 exceptions.
Now, do you consolidate that process now so that you have one global process and then at which basically smooth over all of those exceptions? Back, a baseline level of service, but not that same level of service that they were expecting. Or do you maybe say it's worth it for these guys to experienced the, a one level of service that we can give them by separating that off and then doing a sync between the instances
[00:05:58] Duke: Uh, sync between the instances
being E bonding,
[00:06:00] CJ: E bonding? , yeah, you.
[00:06:02] Duke: or are you talking about full instance replication where it's like, we do have a common CMDB and a CSDM and it just replicates every night.
[00:06:11] CJ: Yeah, so, right. So you'd obviously want to make some of those decisions. And I think things like the CMDB and such will probably be replicated across your entire instance farm, I guess that's what we're going to call this now instance farm. Right. Just coined something. Um, but you know, I guess like things like your CMDB with CSDM and all of that SF, uh, would be coined.
cloned across a, your entire instance farm. but things like your actual business processes, ITFM processes, ITBM processes, PPM, processes, other things like that, those things could actually be different from instance to instance, region to region. 'cause that's how your actual people in the office do business.
That's how your support staff interacts with your business staff, right? how they deliver that service, how they record it, how they're measured against it, how they ensure that they're giving, you know, that top a one level of service.
[00:07:03] Duke: So my next objection, I have to hear thoughts on is if you have a multinational organization isn't the trend towards more services offered globally than not even if for the benefits of like follow the sun model. Right. We have an application, everybody in the world uses it.
So if somebody in, north America, He has a problem with the app, but they've gone to sleep could not somebody in Vietnam, just pick up that ticket deal with.
[00:07:31] CJ: Had a can, but in my experience, they never want it that, followed us. So follow the sun is great, right? Follow the sun ensures that there's adequate coverage, but in my experience into region, dependencies or into region service, delivery never seem to fit the expectation of the.
Right. Like, so I ran an ops desk in a, in a past life. I ran it for the, America's region. we had to follow the sun model. So we'd often get calls from AsiaPac. We'd often get calls from our, uh, European regions. Right. And they were suffering through it. It was like, they endure it this because it was out of hours and they were trying to work and they didn't have a choice, but you could tell, and in some cases, this actually.
They would just hang up and call someone, in the UK, even if it was like 10 o'clock at night, they'd have like, you know, uh, my counterpart's phone number or whatever. And they'd be like, Hey man, you know, we called America, this didn't work. I need some help. and so it's sometimes it's a comfort level sometimes as, uh, is the level of service that they're used to receive enough familiarity that we don't have with them.
Right. We're used to delivering our service in a way that our users love. that they, you know, and vice versa, you know, I get folks who would be in, in America and they'd call after hours for America and they get Asia pack and they might not like, Asia pack, level of service for whatever reasons.
Not necessarily, it's not a knock on the folks who we had doing service. That was just cultural difference.
[00:08:59] Duke: Or language
[00:09:00] CJ: Or language. Right. And you know, as a, quote unquote, you know, global language was English type of deal. But yeah, I mean, we did have folks who did speak multiple languages, so you could get a support, a support in a different country where sometimes, you know, it would be in the language of your preference.
So, yeah. So, you know,
[00:09:20] Duke: Okay. So like, I get the idea that you have to suffer through it, I guess, to have it on the same instance, but how does breaking up the instances, like wouldn't you rather suffer through it and get it done by somebody, like, by the time you wake up or. Would you rather just wait until the next day and then get support in your own region from your own instance.
[00:09:40] CJ: Yeah. I mean, that's a good question. , I think ultimately it really depends , on the company. I think at some cases sometimes. I can tell you from past experience, some folks would just rather just get the, get the support the next day. some folks, if it was an emergency enough would endure it.
Right. And, there was a level of familiarity that we didn't have with their stuff. And vice-versa so, you know, sometimes when you're trying to deliver a service, that's, I mean, it's it on both sides of the. and it's all quote, unquote standardized.
Right. But there are little differences, right? There's some little differences the way based on the way they work and some of the things that they do, and even based on various different countries inside of AMEA, right. Like, and we didn't know all of those nuances, but you know, our counterparts in AMEA debt.
Right. Like they knew it because it was their business to know it. So they delivered service differently than. Right. And ultimately it, that familiarity from, their co their customers with them, you know, led to a different sort of a process that they utilized and we did. And, you know, and yeah, I mean, do we make it work with one service now in a sense we absolutely dab a man.
Let me tell you about that category tree. That's just, I mean, that's just one, one of the things, right. That ultimately had to be a compromised. Like we've got three different support desks that are, feed it into trying to get one standardized process that everybody can use.
[00:11:03] Duke: this conversation is exciting to me because I did have at least one service where we had all these complications and it was in my first post-implementation. What are we going to do with service now today, Rob? Yeah, we decided to Tell the story, like a bajillion times
[00:11:18] CJ: Tell it again. I always like it.
[00:11:19] Duke: decided to do, , onboarding and offboarding, especially a freelancers at this global organization.
And it.
was just Devon office and every country, this company goes around and buys, profitable advertising agencies in every nation.
So onboarding freelancers and offboarding them. We know who these 15 things have to happen generally.
. And we had exceptions on, except in this country, we do these five 15 things unless you're one of the excluded countries. and then. When it was, how do I assign those 15 things? So there was this idea that some things, some sub tasks were always hyper-local like the people who would bring you your desktop and that's the world we lived in back then, by the way,
[00:12:02] CJ: Yeah, right,
[00:12:03] Duke: had a desktop computer.
the person who brings your desktop would defacto.
[00:12:08] CJ: right,
[00:12:08] Duke: That would be local, assignment group. And then there's other stuff that was defacto global. Like you're, you're getting your Ady set up. Like a global team would always do that. And then there were places where it was conditional. Like this is almost always done globally, except for these few exception locations, because maybe they just got bought or.
Some mechanism prevents them from being done by the global team in this one or two cases. And yeah, it was difficult, but it was also something where it's like, how could we do it and get the global bits to still work? If instead we had just had like, let's even say for prod instances.
[00:12:45] CJ: Yeah. Yeah. I mean, split it up.
[00:12:49] Duke: Yeah.
[00:12:50] CJ: You know, I mean, you said something else too, that, that ping to me as a great use case for this. And you said that your business was in the business of acquiring other businesses. Right? My assumption is that when you acquired those other businesses, you somehow folded them onto the one service now instance, right?
[00:13:04] Duke: Yes.
[00:13:05] CJ: What if you just dropped another production instance? And gave it to him right. And said, all right, you guys have been doing things this way. You can do the things this way. Now we'll sync it back up with the mothership. Right. And so the mothership instance has a single source of truth for all of your various acquisition companies.
Right. And maybe over time, you still follow those. acquisition companies into that bigger instance, but initially, you don't have to go through that consolidation process. Right. You know, that eats up, I don't know, zero to 90 days or zero to six months.
Right? you can scratch that one off. And integrate directly basically mirroring their existing processes. Right. Without necessarily having to push something out to them where they already going through this transition and they have all these other kinds of things that they're trying to figure out.
[00:13:52] Duke: I'll just go to the idea of like more often the services become universal than become hyperlocalized
[00:13:59] CJ: Gotcha.
[00:13:59] Duke: like, And from this company's perspective, it's like they're in the business of buying ad agencies. And so they'd buy an ad agency that maybe had a couple of hundred people. So, you know, a 10 person it team say, and they had some other tool footprints or whatever.
And so it's like, okay, if I'm going to roll them onto a separate service, now instance, I'm doing an implementation anyway. So why not try and get them on the master one. And part of the reason that a big fish might swallow a small fish, is that. There's that economies of scale thing. we can keep your operators operating the people who do all the creative work at this agency and the branding work, let them stay and we'll either integrate or, let go of the administrative layer that we already have in spades.
Cause we're a big fit.
[00:14:48] CJ: Yeah, that makes sense, because it's a good point, right? Like, because there's at economies of scale that you get with a merger. Well, we already have like, you know, at the mothership, we already have all of these, functions, right. These administrative functions, and we got enough people to go around and if we don't have enough people, you got a few people, right.
We'll take a few of yours, lay off. Most of them. Right. And keep all the creative and branding folks, right? Like that then actually doing the work that we actually want. Right. Because we need to scale up that side of the business because that's where the money is being made. Yeah. I mean, I could definitely see that, right.
That to me, calls out as a scenario that's a lot less likely to warrant dropping another instance. Uh, but what if you want to spend on.
[00:15:25] Duke: Well, if you wanted to spin one off,
[00:15:26] CJ: Yeah. one, if you wanted to rebrand it , a lot of times you'll have, um, different service offerings right out to your users.
Right. And you've got like one brand has kind of luxury, like think of a Toyota. Right. They've got the Toyota brand and they got the Lexus brand. are they both using the same service now instance? Probably not. Right. So, you know, but are they own separate service now? Accounts probably.
But. Right. Why isn't it the same staff? I don't know if they're saying comp the different companies or whatever, let's assume
[00:15:53] Duke: But doesn't Lexus have its own company structure, like it's a separate legal entity, right?
[00:15:59] CJ: Yeah, I think so. I'm not, I'm not entirely familiar to be honest.
[00:16:02] Duke: No, it's, I mean, this is a great, like maybe this is only applicable at certain scales. So like, but the scales of the businesses being bought in this ad agency model, the agencies weren't big, they were. You know, they maybe had a small it team that was barely scraping by. And, to that end, it was just a matter of like you're being swallowed by the big fish kind of Deal with it.
[00:16:23] CJ: Deal with it. yeah,
[00:16:25] Duke: But if. yeah. If this is like, I'm a $5 billion company buying a $3 billion company. Well, okay. Now.
[00:16:35] CJ: Yeah,
[00:16:36] Duke: you know what I mean? And, and it'll never be the same brand. Like Toyota didn't buy Alexis to be Toyota plus, right. They bought Lexus to be Lexus and keep being Lexus
[00:16:46] CJ: Right.
[00:16:47] Duke: hopefully get that economy of scale stuff.
But.
[00:16:51] CJ: Yeah. And that's one way to add additional economy of scale, right? Like, so maybe they are still using footprint footprints in Lexus when you buy them. Right. But you're like, that's not going to work for us. We're going to drop service now and here. We're just going to sync it back up. So we're going to get all your data.
back here. We're going to give you something that we know how it works. Right. We got a team that we that's already trained up and knows how to use it. So we're going to just transition you that way. We're going to get you on our account structure and all of that. So you no longer have to worry about any of that, right?
Like we're going to manage all of that from big Corp, but you're, and you're going to, you know, gain some of those efficiencies and some of those bins.
[00:17:26] Duke: Right. You know, it's funny. I think we may have just switched seats cause I'm thinking like what? Okay. Because like we're done with service now being oh, that ism tool, right. We're done with that now. And now it's how big a domain of work can we capture with service now? And let's just say, let's say now we got all the work.
Everybody's everything work is being done in service now. So how do you deal with something where let's imagine massive scale CSM.
[00:17:58] CJ: Yeah,
right.
[00:18:00] Duke: Lexus is front door to their customer base, maybe predicated on service now. And now we're thinking of, it's not just our internal silo teams in which things are global, which, which things are being handled at big fish in which things are being handled at small fish.
Now it's what do the customers expect to go to when they want to talk to you about something to initiate work and would they expect a Alexis service portal? Would they expect it? Toyota service portal,
[00:18:29] CJ: Definitely would expect Alexis one,
[00:18:31] Duke: the service
[00:18:32] CJ: don't even want to be reminded that.
[00:18:33] Duke: Hey, wait a minute.
[00:18:35] CJ: Yeah. I don't even want to be reminded that they're driving basically a high-end Toyota.
[00:18:40] Duke: Right.
[00:18:42] CJ: Right. So, you said something when you said let's, let's talk, let's take this even away from an ITSMs stack. It made me think about another thing. What about risk? Right? when you start expanding this into other areas of the business? HR has a different level of risk than.
[00:18:57] Duke: they do that.
[00:18:59] CJ: Then then CSM, then ITBM HR might have a situation where they don't feel like they can be down. they have a very structured and regimented, , calendar of change and upgrades and what they're willing to, , configuration versus customization on the instance. Right?
Because they want to keep this. 'cause from, from an HR perspective, they feel like, a hundred percent service delivery via service now is their goal. Right. And that's their absolute goal. And anytime that they're down, it looks bad on them and it just goes against their metrics, whatever their motto is.
Right. And it is more like move fast and break things. So, you know, Rome just came out last week. We're on Rome. whereas HR is like, no, we're going to wait out the full two release cycle, before we upgrade. So now you've got the tension, right? You have a tension between, one stakeholder and another one internally.
How do you solve that two instances?
[00:19:55] Duke: I mean that's one way to solve it.
[00:19:56] CJ: Sure. But I am trying to make my argument here.
[00:20:00] Duke: Yeah, no, for sure. So how would I do, I mean,
don't all apps share this in common though. different consumers of each app would have different preferences. And does that justify a whole new instance of that app to satisfy that preference?
[00:20:13] CJ: depends on the amount of value at stake,
[00:20:16] Duke: Yeah. I mean, it comes down to, yeah, like there's, there's $50 problems and there's $50 million problems. right? So let's say. You save HR. Some, we save some hassle by saying, okay, HR team has their own instance separate from it and they can switch versions and stuff. Okay. But now we've added weight to the organization in terms of like management. So whatever team support service now, now has to do extra work.
Because, well, HR wants this new thing, but it's in a version that they're not at, but it is at that version, but it doesn't want it cause they're not HR.
[00:20:52] CJ: Yeah. So are you trying to use. And episodic and this scenario, right? They put it on their calendar, right. They put it on their release calendar. This is, you know, w we want this feature. We realized that it contradicts with, our state at like release calendar. So we either going to make the decision that we're going to bump up a release early, right.
So that we can get this, or we'll just slot it in. And, you know, it's in the quarter three after we, you know, hit the spot where we typically upgrade and then we'll introduce it.
[00:21:20] Duke: Couldn't you also say we, we move as fast as our slowest stakeholder.
[00:21:25] CJ: Well, that's the problem that two instances solves, right? Because you no longer have to move only as fast as your slowest, a stakeholder, because now you can move as fast as your fastest stakeholder on one place and as fast as your slowest stakeholder in another. And those two things can exist individually.
Right. So HR can be slow methodical and a hundred percent focused on uptime, and it can be quick and fast and a hundred percent , focused on functionality and new experiences. And both of those things can still exist at the same time because both of those stakeholders now have their own inherent.
[00:21:57] Duke: Yeah, I see. I want that benefit. I just don't want your solution.
[00:22:07] CJ: Fair enough.
[00:22:09] Duke: Okay. So let's assume we did want to go with your solution, but what would, what would we have to do to make sure that we're not totally like, I don't even know how to articulate this.
[00:22:18] CJ: I don't know. I mean, we, we manage multiple instances all the time, right? Like prior tests Def, I mean, just throw another one in there.
[00:22:24] Duke: Yeah.
but to touch endeavor, definitively not prod,
[00:22:28] CJ: True.
[00:22:28] Duke: they're not treated with the same safety measures or. Governance. Um, I mean, shoot, it's like, you're surprised when you get somebody that has and sticks to a clone back schedule. Like that's,
[00:22:41] CJ: Yeah. Yeah. The
[00:22:42] Duke: that's how, how hard it is to, , but. is not one of the prime value statements of service now, like the unified data set, okay, we don't have to have 50 different ways of holding user accounts and we don't have to have three or four or five different CMBS.
[00:23:00] CJ: And we still don't right when everything's still in the same table structure with the same societies, right? Like th that common. Right. Late at common data still replicated across the instances, what you gain though, is, , flexibility, right? So you're going to still have the same user pool on, HR prod as you will on it.
PRI you're going to still have those same, that same CMDB data, like you'd have to take this into a. as you're developing your solution, but ideally you'd create all of this in one place. And then you clone that common data set across your instances.
Right.
[00:23:32] Duke: So you're saying this must have some amount of, incidents, replication, table replication in order for this to, to pull off.
[00:23:40] CJ: absolutely. Right? Like you can't have like two copies of your CMDB and have them be independent of each other. Right. Like that has to be the same. Just replicate it.
[00:23:50] Duke: And tell me again how the global problems get solved. So let's take ID management, right?
[00:23:59] CJ: Yup.
[00:24:00] Duke: Would you say it's fair? That ID management is a global.
[00:24:04] CJ: Uh, yes. I would say that's likely.
[00:24:06] Duke: Okay. So let's say everybody relies on like the company ID management. so how is it The HR team, or let's say let's do geographically instead. So somebody in the Estonia office hires like five more XYZ people
[00:24:21] CJ: Okay.
[00:24:22] Duke: and. there has to be some kind of global discipline for getting these people into, like they've been hired.
They've gone through all that. Now it's the job of get them into Ady.
[00:24:30] CJ: Yeah.
[00:24:30] Duke: is there a team on each instance or is there one team on one instance?
[00:24:35] CJ: You know, I had probably scaled a team and have one team, a man. Yeah. I have one team that probably manages the entirety of the instances, but I'd probably have that team distributed across time zones. Right. That way that, that, you know, you'd have team members who are in the same time zone is wherever you have instances.
Right. So that those folks aren't necessarily having to wait if they. And I don't know. And that's off the top of my head. I could also see it as being centralized as well because with automation, I think a lot of this could actually be done without human intervention.
[00:25:05] Duke: Yeah, it's not like I win you lose things. It's just kinda like your job in this episode is to be that advocate. Right.
[00:25:11] CJ: Yeah. Yeah, no. And that's kind of what I'm thinking, right? Like is, is they can go either way. And in this specific case, you know, onboarding is, to me, like always the holy grail of automate. you know, you could, I don't know. It depends on the process, right? Just the process start in service now, and then end up with an ADM account gain created, or does the process start at HR, which then pushes the aid and pushes down to your service now instances, but you have to push it to one instance and then replicate to the others.
And there's this precedent for this, right? Like, I'm a Novell guy. Back in the day, we had all kinds of, uh, replication going on with various different, trees or whatever. Uh, and then, even with windows, um, networking, right? Like you create an account in one place at any, it gets replicated across right to all your other, domain countries.
So, I mean, there, there, there's definitely precedent for this and it, where, there's an account gets created in one place and it is replicated across your, all of your various instances so that it is available. There's no reason we couldn't implement that. here.
[00:26:09] Duke: Hmm, man. The only thing I remember from Novell was fire phasers.
[00:26:17] CJ: got a certain Novell I'm certified and, 4, 9 11 certified Novell administrator.
[00:26:22] Duke: remember I took a month long course in it. I remember literally nothing about it, except for fire phasers. I couldn't even tell you what the app does. That's how foggy the memory.
So we've probably got time for like another two minute blurb. Um, actually like 33 minutes into this. Can you believe that?
[00:26:42] CJ: Dude that doesn't even count. The 15 minutes we spent before we hit record talking about
[00:26:48] Duke: like how many times 43 episodes we still haven't learned to just hit record. Okay. I wonder if we could bring the two concepts together. I am certainly not moving one inch away from there's clear benefits to having it all on one instance. Right. But I mean,
as I said earlier, is there's theoretical benefits of having your cake and eating it too.
, I wonder if the two ideas could be like reconciled with a new concept, which is maybe like processing. Instances, like not as service now instance like this company has service now.com, but more of like within one instance, company.servicenow.com, there might be the change process for it in north America.
And then it's just like, snap your fingers, get me another one. And it's just like, boom. Here's another instance of change in your instance. Out of box to it's out of box and then the change management for it and HR in the UK is now on that change. Let's call it a shard, right? You're on that change chart.
And it was basically you could have X number of distinct, separate change management implementations in one instance, without having some kind of master control. You know what I mean?
[00:28:02] CJ: Yeah. So, I mean, so I'm going to say you're splitting, you're splitting hairs on this. All right. So this is, this is my idea. Just kind of repackaged. So you
[00:28:10] Duke: Oh, okay.
[00:28:20] CJ: This reminds me of like a, what is it Kubernetes now, or something like that Docker, right? Where you spin up, these containerized applications that exist as a, instance of an application, I think that will come in really handy. And actually I probably should have started with, change way back at the beginning of this, , discussion, because I think change is a really good.
Process to illustrate the need sometimes for different instances, right? Because change processes vary from place to place, or inside an organization. And typically like I have a very it centric viewpoint sometimes. But when you take a step back and think about these. you start thinking about service now and the manufacturing or factory world, right.
They're going to have changed processes there that are going to be like ISO specific or something like that. Right. And then those change process. How do you account for each one of those? And I'm sure they're different from country to country. Some of them might be different from state to state. How do you account for that?
How many. Do you build out with all of this complex logic that kind of gets spaghetti? I sometimes before you say you should just use another instance.
[00:29:24] Duke: Yeah.
I'm thinking about this more and more like. But what if another type benefit it? Like if we just said, okay, it's all in the same instance. And therefore we don't have to worry about data replication say, or E bonding because it's just, if you need the task over there, you send it over there.
Or if you need the, access to the CMDB, you query the CMDB on the one instance where it can exist and change that needs to change Instant to instant, without having to worry about that data replication complicated. But if we said there was this idea of a shard, this is the change for it in north America, this is the change for everything in the UK.
This is the change for supply chain management in Africa. But a side benefit that if we could just spin up a new change process from scratch out of box, I think of all the rearchitecture problems that suddenly go away, because remember how we talked about earlier, like you can have an instance that's gone super wide and three out of the eight processes that you've built are completely disaster zones.
And now you've got to drag the five that are decent into your rearchitecture hell with you.
[00:30:32] CJ: Yeah.
[00:30:32] Duke: But imagine if you could just say, well, we done screwed that one up. Snap, your finger. Oh, a new change management implementation from scratch from out of box. We can just kind of forget that the other one existed. It's like kind of push it off to the side.
[00:30:48] CJ: I love that. I love that basically like a reset button. Like yeah, no, this, oh man, we shouldn't have done that.
[00:30:56] Duke: great, but you don't even have to worry about the deletion or the cleanliness of it. It's just like whatever mechanism decides. Oh, this is the change process you should be using. Could also be the mechanism to say, is it visible still or not? Right. So partied a that uses change management process a uses it until it's too screwed up and then just click fresh.
[00:31:18] CJ: yeah,
[00:31:18] Duke: the old stuff? Oh, it's in the legacy shard holder. Anyways product owners. If you're listening. You're welcome.
[00:31:26] CJ: Yeah, no. And then Ray, and then maybe like the, you put some auto archive around that, where you take all those records and you'd dump them back into, the same table. Right? So now you're holding the data, but you, but you got all new, fresh products.
[00:31:37] Duke: Yeah.
[00:31:38] CJ: You know, so you can still got all your reporting. You can still do analytics against the data, all that kind of good stuff, right.
That doesn't change. But, you realize you screwed the pooch on, how you implement it, you know, whatever
[00:31:48] Duke: It's such a nasty expression,
[00:32:02] CJ: Oh, man. I just want to know here, folks at home, I don't know about duke, but I haven't had a drink.
[00:32:11] Duke: not me either. All right. We're at 40 minutes of record. So Korea people want to get in touch with you. How do they get that? Uh,
[00:32:18] CJ: All right. So first spin up a second instance and I'm on LinkedIn at Corey Wesley. Uh, shoot me a invite, a connection or whatever they call it out there. I accept all of them, shoot me some, uh, messages or whatever I typically respond. you can also find me@atankpoint.com, , where we focus on practically everything in a service.
[00:32:39] Duke: And you can reach me@wwwdottheduke.digital, where you can contact me about coaching or better outcomes on service.
Now, uh, use the contact me form.
[00:32:50] CJ: Alright, thanks everyone. Uh, this was enjoyable. Yep. Bye.