we don't want any customization this is probably the first statement that i hear in almost any project that i've done over the last eight years that's the basic day one we don't want any customization and then by day seven it's well maybe this one by day eight uh maybe that one too and this one over here and maybe these over here and it's got me to thinking over the years why do we keep doing this if configuration is truly the ideal and customization is something that we should truly avoid then why is it that we keep going back to this why is it that we keep ending up in this situation are we really defining the problem in the right way and how can we go about this in a better way of course i've got the requisite safe harbor i don't think i'm talking about anything forward-looking and no pirates were harmed in the making of this safe harbor so let's start out with the servicenow's official guidance so according to servicenow this is straight out of the knowledge base a customization is any change to code that is part of the baseline install of a servicenow instance now this first of all helped clarify things for me a lot this knowledge base changed fairly recently and had some really good updates and i actually had to go back and change my slide deck because this put a nail in a lot of things that were a little bit confusing any change to code any change to code this makes a whole lot of things in servicenow that we would normally maybe not associate with customization it brings it into that picture now it is so they even give us a couple of examples so you know configuration ui policies form layouts list layouts installing plugins system properties all of this stuff is fair game for a configuration uh two examples that they give for customization one is the ui macros of course jelly even i'm afraid of those and uh you know also building a new custom feature into the product custom applications the scoped applications are a customization and i want to really emphasize that the scoped applications the solution to the customization problems is a customization and third-party widgets we'll circle back to that one in a minute so i'd like to play a game we're going to play configuration or customization audience participation is highly highly encouraged basically i'm going to present a scenario and we'll go by show a hand on who thinks it's a customization or a configuration let's start with the first one a servicenow admin adds the description field to the incident form hopefully this one's fairly simple configuration excellent absolutely this one is absolutely a configuration where we won't even bother with the customization conversation on that one there's no code involved none whatsoever formless view change nail coffin we know what that one is number two a new customer on a geneva instance builds new widgets using jelly ui macros for their cms configuration ah maybe one or two oh all right how about customization absolutely hands down this one is a customization however i'd also like to point out that in geneva there was an issue with iframes where your content would be cut in half if you did not have a custom script put into your system so without this customization your cms was broken not just for geneva but all the way up until jakarta when it was finally fixed so in this case without the customization you were broken let's try another one a service portal developer tailors a theme modifies clone widgets to support corporate branding accessibility and style guidelines so who thinks that this is configuration and how about customization i love it i love it i love it i love it i love it customization believe it or not there's actually code involved in this this uh theme css alone is code and i can attest to this i created a course for service portal and it broke within one version of servicenow because i was doing some bad things in the css so you do have to be careful with what you're doing in the service portal now we also did i mentioned clone widgets that's still code that is in fact a customization however service portal was designed with customization in mind when i get an updated widget from servicenow i can easily swap out my cloned one with the one built by servicenow it's a five minute job so and the cloning in and of itself is designed to prevent you from updating servicenow's widgets now obviously there are some bad practices in there we could turn around there are some widgets you can go in and edit directly bad idea definitely clone but you know this is still a customization and at the end of the day can you really imagine an organization building a service portal changing a logo the color of the banner and calling it a day i i haven't seen it let's try one more a servicenow customer implements test management in jakarta as part of ppm as part of their implementation the customer adds some form fields build out some reporting dashboard or two and a few notifications really just investing in this tool so who thinks that this one's configuration and customization all right looks like the configurations are winning on this one it is a configuration there's no code involved we're configuring form views reports this is all standard stuff there's no code involved in any of this but the gotchas keep piling up test management 2.0 was released in london and it was not a one for one swap there were different tables different processes there was not a clear migration path and so if you were on test management 1.0 you had a choice to make do i upgrade to 2.0 do i make that do i make that leap or do i stick with what i have and potentially be on an unsupported application moving forward in this case configuration failed to prevent the dreaded re-implementation that we all fear when we customize and this is not a hypothetical scenario this actually happened this is an actual customer in fact each of these scenarios are real world customers with real world impacts where configuration had failed to do what it promised to do and customization was occasionally a necessary evil to accomplish what was needed so this really puts a rough spin you know and test management's not the only application that's done this hr grc cloud management i think is probably due for it over and over and over again we're dealing with this and you know i i know i know it feels like i might be coming down a little bit on on servicenow and this is starting to look dark i'm really not trying to i promise you know at the end of the day this is the nature of our business we're we're in the business of developing creating new things change is a part of that process and with any part or with any change process risk is going to be a necessary part of that that we have to learn to manage and learn to manage properly and that's where i want to make the point that everything in life that matters requires risk i love this quote so much i've got it in my house in my living room right on the wall right in front of where i work most of the time i love everything in life that matters requires risk everything that we do is designed to help people is designed to serve business is designed to create something that benefits create something that helps us grow we can't do that if we're afraid to take on certain risks the real question here is how do we go about managing those risks we shouldn't be afraid of the risks we need to embrace the risks and learn how to handle them so that's what i want to kind of pivot the conversation towards away from configuration or customization because it's all a change and it all has risk so project management body of knowledge defines a risk as an uncertain event or condition that if it occurs has a positive or negative effect on a project's objectives a positive or a negative effect risk is not only a bad thing there are positive and negative results when it comes to risk so in this case i'm going to go with some fairly standard industry terms here um for negative risks calling those threats positive risks we're calling those opportunities so our first step in the process of managing risk is to identify what those risks are so some of the threats that we face on servicenow is ultimately if you make a change you're responsible for maintaining any code you create you know that's that's the big one when we talk about configuration that we're afraid of um of course delayed upgrades uh future upgrades can be delayed skipped you can end up an issue with issues where uh stuff isn't working uh you might be prevented from using new applications or features and of course there's the absolute dreaded worst case the total z boot or complete re-implementation the last thing that we want to do is spend a whole bunch of money implementing an application just so that we can spend a whole bunch of money implementing the application again six months down the line so these are the things that that were on the lookout for but there's also opportunities we have the opportunity to reduce our costs to create additional revenue we have the opportunity to mitigate or avoid other risks in the enterprise there are some cases where you'd be hard-pressed to convince a grc uh individual that the risk of changing these little snippets of code over here is bigger than the risks facing the entire enterprise which could be solved by changing those few lines of code and then of course there's also increased process transparency so once we get past identifying our risks you know or sorry my mistake identifying threat sources so some of the threat sources these are some of the things that we want to be on the lookout for and a lot of this does come from our definition of what a customization is changing out of box records yes even the active flag changing newly implemented apps or behaviors or even frequently updated ones as well anytime you're dealing with those applications that are being frequently updated there's a little more risk involved in making changes to those because servicenow might come in and step on your toes um it's usually a lot safer to make changes on applications that aren't being updated frequently and of course using non-standard apis you know for those of us that remember the pre-calgary heyday of package calls um and also modifying default or design behavior going in and trying to re-implement what's already there so really the key point of all this is that any record that can be influenced directly or via dependency by both you and servicenow that's your risk that is where your risk exists when you're making changes the risk is not actually the code the risk is shared implementation the risk is where two people own the same record where two people own the same process because that's when you get decisions that are being made on one side that don't align to the decisions being made on the other and that's where we end up with our conflicts so then step two is to assess the risk now if you're familiar with change management processes assessing the risk is a fairly standard practice and i'm using a rating system that's very similar to what you would see in uh within your change management processes the one thing i'll call out is that i am separating out the severity for threat and the severity for opportunity got a few different definitions in there for how you can determine which ones at which level this content will be made available online so feel free to borrow this modify it as needed step three is plan a risk response and this i think is the part that we miss the most when having the configuration versus customization debate we get so caught up in whether it's one or the other that we forget to mitigate the risks that are present in both we forget to to plan that risk response and actually handle it so what i want to call attention to here is that are multiple strategies available we can for the threats we can avoid the risk that's the one that we've all been taught to do avoid customization just don't do it um but we also have other options we can transfer the risk also known as the not my problem you know we can work with our partners we can work with other departments in our organization to attempt to share that risk load we can also mitigate it we can change our implementation we can make a few changes to bring the risk level down and then we can also accept it which i like to refer to as future travis's problem um you know it's not exactly the best strategy but in some cases it can work sometimes it's worth it just to accept the risk and you've got very similar strategies on the opportunity side of things exploit share enhance really it's two sides of the same coin the the strategies are very very similar but the most important takeaway on this there we go avoidance is not the only strategy within our conversation we've gotten so caught up in configuration or customization we get so caught up on avoiding customization at all cost that we forget to actually have the deeper conversation avoidance is not the only strategy we can use scoped applications yeah it's a customization but you know what it's an application that you own and if you have the resources internally to handle it then you've taken steps to mitigate those risks and you may be exploiting some huge opportunities for your business by doing so in absence of scoped applications you can use new tables to compose behavior so for example uh if you've got some changes that you want to make to the incident table and you're concerned with creating conflicts with what servicenow has done on the incident table create a new table and reference it put your behaviors elsewhere tie it in via related list by simply moving your behaviors and offloading it to a different table you put the processes in parallel which greatly reduces the risk that those processes are going to collide also you can extend tables if composition won't work it provides better isolation than nothing i would tend to prefer scoped applications use your own tables and you know composing behaviors over inheritance because when you inherit there's a lot of scripts that you inherit with it there's a lot of behaviors that you inherit with it and there's a lot of areas where you can very quickly go wrong when you inherit from tables if you have to modify the existing records in place i do want to call attention to the fact that uh the the new uh servicenow recommendation is no longer to inactivate the existing and create a new one that's not the policy anymore now you update it in place by marking it inactive and creating a new one you actually create two sources of risk not one you've actually increased your risk so now you update the one record in place and you get a nice pop when you do the upgrade that tells you hey there's a collision on this record and ultimately record your customization somewhere there's a lot of different options for this you know you can turn around and add little square brackets custom you know different prefixes on the records some folks have opted for using global applications extensively which automatically captures every application record that you create in the system and gives you a nice list at the bottom to say hey here's everything you changed and of course the other option is to create a risk register where you actually document line by line hey this is something we changed this is why we changed it this is the line of thinking for how we plan to handle any of the issues that come our way for having changed this but at the end of the day the keys to mitigating threats and service now customization are isolation and limiting your dependencies again the dependencies the shared ownership that's where your risk exists it's not in writing code code is not the risk there is risk in it but the code itself is not the risk the risk is in who owns the code and do you have the ability to manage that code yourself and do you have multiple teams that are trying to manage it the more trying to manage it the more risk and step four is ultimately to make a decision so i went with you know your very traditional risk matrix here you plot your opportunity on one side your threat on the other there's a lot of different ways of doing this my personal favorite approach to this is swag it i do it in my head probably not the best approach but on more rigorous processes you can actually document this you know again creating a risk register documenting those probabilities and severities probability time severity divided by three equals risk score you can average those standard deviation there's a lot of different ways less less rigorous to more rigorous for actually calculating a risk score for your opportunity and threat and this is an important point about making these risk calculations and something i don't really think that when we talk about configuration versus customization that we truly appreciate is that every organization has a different risk threshold that they're willing to accept where they're willing to say the accept strategy is okay for me you know some organizations are all about threat avoidance you know we want to minimize all the threats possible we don't care how big the opportunity is just don't break anything you know you've got other organizations that are all about let's go let's go let's go whatever opportunity we can get let's do what we have to do to take it mitigate the risks we'll deal with that tomorrow let's make it happen today you have to understand what your risk gradient looks like what risks are you willing to accept what risks do you have to address this right here is what helps you to make those decisions to turn around and say okay how do we go from uh from a high threat to a lower threat how do we reduce that threshold to get us in a range where this implementation decision is something that we want to do so just to recap i've given us a four-step simple four-step process identify the risk assess the risk plan a risk response and make a decision now everything that i've shown you here is all fairly industry standard there's a lot of different variations that you can go with and i'm not here to tell you that there is one perfect way to manage risk risk is messy you know uh it's something that we have to deal with though and it's best to have a process not a definition of configuration versus customization defining those two terms does not get us to a place where we have effectively managed our risk and handled the issues that face our organizations so the key takeaways first of all every servicenow choice involves risk the moment that you spin up the servicenow instance you have accepted some risks you may not be aware of them but they're there and that's not just servicenow that's any application you spin up there's risks associated with it and you are accepting the risks when you bring it down now second debating configuration versus customization is of limited use i'm not saying throw it out entirely there is a point to it the primary point to it is when you call up servicenow's help desk and they say yeah you can't do that you need to back that out you know so that's really what configuration versus customization is all about is what is servicenow's response going to be when you try to transfer your risk to them that's really what that discussion is about so it's not enough to understand what that risk is we have to actually understand the risk for ourselves and deal with it for us not for when we call service now we want to get to a point to where we don't have to call their help desk in the first place and then finally use a risk management process to make better decisions let's get past the discussion of just configuration and customization and move to a point where we can adequately assess the risks put in a mitigation plan and handle this in a more realistic way so i'd like to thank everybody for coming out um a little short on time for questions but feel free to swing by the glidefast booth and i'll be happy to answer any questions that you've got tell us what you think you know please do provide feedback and also you can get to this deck i'll be posting on codecreative.io along with the rest of my content thank you very much hope everybody enjoys the conference [Music] you