I saw a question out on the interwebs last week where someone was new to an organization and was considering whether they should refactor(fix) their ServiceNow instance or whether they should blow it up and start again (rebuild). The poster had done a considerable amount of technical work understanding what exists and how it could and should have been built better, and how they would do it better.

Notably, what the poster did not mention was any of the stuff below - the stuff that REALLY matters beforeyou consider any of the technical stuff and BEFORE you embark on what will often be a fairly long, expensive, and laborious process.

The first thing you need to understand when rebuilding your instance is - the tech is the least important part.

Before you even CONSIDER rebuilding your ServiceNow instance, you need to know where the bodies are buried. What does that mean? That means knowing AND understanding the business decisions that led to the current state of the instance. This is much more important than the bad code that’s kept the instance running for some years.

Chesterton's Fence dictates that you shouldn't tear down a fence until you know why it was built. Likewise, you shouldn’t rebuild a ServiceNow instance without knowing WHY it’s in the current state. Not just the examples of deviation from best practices, not just the odd customizations, but knowing WHY those deviations and customizations occurred. Was it just poor workmanship or was there an overarching push by the business to make it work just as it does?

Thanks for reading ServiceNow Success w/CJ! Subscribe for free to receive new posts and support my work.

Next, you need to understand Conway's law. "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure"

Your ServiceNow instance was likely built to mirror the organization and before you set course to rebuild it, you need to understand the business needs that drove it. Things you think are broken might actually be working as intended despite not being ServiceNow best practice because they are business best practices.

If you’re lucky, someone left you good documentation on the business decisions that drove development (stories are often a good place to look in the absence of standardized documentation). If you’re not lucky, you’ll need to practice a bit of ServiceNow Archaeology and dig around in the instance, and outside of it, to find what you need. That means stakeholder interviews, it means reviewing the comments on the code, it might even mean talking to your ServiceNow rep. There are bodies behind every bad decision, find them to avoid becoming one of them.

That brings us to Archaeology.

Archaeology? What do you mean CJ? - Any sufficiently old customizable system is built layer by layer, often with each layer being dictated by different people, business cultures, directives, and needs. You need to unearth each layer, the chain of decisions that created it, and work your way back from status quo to creation (or some divergent point where the instance went from generally well-received to we need to hire someone new) in order to understand the current state. Some questions I typically ask are:

Is this a large global company? If so, can you afford to blow up a key process because you weren’t aware of their existence? Is this a smaller company? Did the owner insist that it works just the way it does because of personal preference? You should know that as well.

Has ownership of the ServiceNow platform changed hands? Is it owned by the business or IT and has it ever transferred between the two? Very important. How many developers/admins/architects were here before you? What was their skill level? Were partners ever engaged? Which ones and when? (It matters)

Has the business ever reorganized? Remember the instance will mirror the business, if the business did a reorg, the instance might be lagging those changes or it might be a product of those changes.

Once you know this stuff you can:

Avoid repeating the same mistakes
Evaluate the true state of the instance compared to the actual needs of the business.
Propose and deliver an instance that suits the actual needs of the business

Speaking of business needs, you did do a proper business needs analysis right? RIGHT?

Well that should be one of the first things you do. If you get to a rebuild, you’ll need to defend your decision in a meeting with executives in the language they understand or you're going to be this guy.

Don’t be that guy. You're probably new to the organization, most people considering a rebuild are. When you’re new, there’s a bias towards seeing a rebuild as an shortcut to bypass the work of truly understanding the instance.

Everyone new comes to an existing company and thinks they can do it better. Many leave without having accomplished anything. Call that one CJ’s Law. Don't be that person. Understand what you've inherited and then understand that many tech challenges just don’t warrant a rebuild. Understand whether you can meet the business needs without a rebuild and understand if there are benefits to doing it anyway.

Finally, understand that if you rebuild without understanding these things, you’ll likely just end up with the same instance, with the same problems, just with new code. This is the trap.

ServiceNow is a rather resilient platform so most ServiceNow problems are fixable. You can fix data architecture, you can fix an immature CMDB (that people aren't going to use anyway), the portal tech was built to refactor easily, and customizations are fine if done correctly - you likely have too many though.

None of these are justification for a rebuild. Really, the only time I recommend a rebuild is when your ServiceNow instance no longer serves the business. That can be a technical limitation. ServiceNow has been around quite a few years and some older instances built on then best practices - or not - are often introducing technical challenges to using new functionality. That’s legit.

Or a business limitation. The instance changed hands one too many times. It started out built for the needs of one department but it now has to serve the entire enterprise. The needs of the two are fundamentally different and existing customizations prevent repurposing without a horrible amount of work. That’s also legit. But that requires knowing the business needs and the archaeology first. 😏

The last thing I’ll mention is that an instance rebuild is a big deal. 10 years ago ServiceNow was an IT Ticketing system. IT could rebuild it twice a month and many folks wouldn’t notice - people hate logging tickets anyway, right? Today, ServiceNow is a BUSINESS tool and it’s now running many non-IT business processes. These processes are important and downtime to them matters. So if you’ve gotten this far and think - yep, checked all the boxes and this thing needs a zBoot, make sure you have executive support.

People hate change and will often argue to fight to keep the status quo out of an unreasonable fear that a new thing will be worse. And those people will use their political capital to stall or prevent your rebuild from happening. Someone will have to spend their political capital to convince those folks, and others to tolerate that disruption to their status quo. A status quo that’s not perfect, but is known and understood. This is a huge thing and it’s almost impossible to survive without a champion of your own.

Last thing, it’s technically possible to rebuild your instance without considering any of these things. You can just look at the tech and the code and think none of this is right, I’ll just rebuild it all. But if you take that route, I guarantee that your successor will show up on Slack or Reddit or Community in a few years looking to rebuild their(your) instance as well. And when they do - I’ll point them here.

Till next time - May all your meetings be productive and your code be bug free.

There’s so much good ServiceNow content in the ecosystem, it’s really hard to shout it all out. But here are 3 things that caught my attention since the last issue.

🔥 Navigation Handler! This is ServiceNow wizardry! Ever wonder why certain links open in certain UI’s? Look no further! ServiceNow Wizard Maik Skoddow talks all about the Navigation Handler table and the one cool thing you always wanted but didn’t know until now.
🔥 Everything Reporting! - No one anywhere knows everything. (read that 3x fast!) If one of the things you don’t know is Reporting than you’re in luck! Thomas Davis posted an excellent Reporting FAQ over on Community that will save you plenty of Docs searches.
🔥 Is it New or is it NEWS? - If it’s NEWS then my man Jace Benson has you covered. Jace has an amazing ServiceNow News aggregator that collects all of the new NEWS worth covering in the ecosystem. Oh, and he’s got a newscast. NEWSCAST?!? Yep! Jace hosts a NEWSCAST(!) where he gives you the new NEWS on Youtube! If it’s happened in the ServiceNow ecosystem, Jace covered it.

BuildSomethingNOW finds me with a few apps on the drafting table. The kids wanted a way to make extra money for chores. Regular people would just write out a list - but we’re not regular!!!! We’re ServiceNow developers in this house - or at least I am. So now I’m sketching out a chore app that has a list of chores that we can ‘advertise’ to the kiddos with a dollar amount attached. Sweep the floor? $5. Oh - and BONUSES! $5 regular, $10 if done in the next 30 minutes! The kids can then assign it to themselves, work it to completion, resolve it, then the client (parents) can verify and close the chore. Triggering a deposit into their virtual bank. At the end of the week, they’ll get a report on the chores they did, the amount earned, the amount earned in bonuses, and then it gets deposited into their real bank account.

I can automate all of that except the deposit but that’s fine. It’s more impactful when they watch me move the money - it connects the work with the reward. I eventually plan to build this out into a kiddie OS where they can make requests, check a calendar, and leave notes.

By the next newsletter, which shouldn’t be a year from now(😖), I should have a MVP at least. Keep me honest!

Did you already #BuildSomethingNOW? Share it! Hashtag it! Tag me! It doesn’t have to be a big project, it doesn’t have to be pretty, hell, it doesn’t even have to work - just Get Started, #BuildSomethingNOW, and let’s grow together.

I guarantee you’ll be happy that you did.

If you have a problem, want to talk shop, or need a ServiceNow Consultant - hit me up.

Click the banner below and choose the ‘Let’s Chat’ option.

Thanks for reading ServiceNow Success w/CJ! Subscribe for free to receive new posts and support my work.

News Jace Pro NJP

DO NOT REBUILD YOUR SERVICENOW INSTANCE WITHOUT READING THIS!!!