Administration

• 1: Managing Base Code and Configuration

1 - Managing Base Code and Configuration

Overview

Having inherited an installation performed by SN service division installers/developers, sadly, I was faced with a heavily customized installation. They did commit the level of customization according to the requirement of the client project team. They failed to forewarn what the impact on maintenance would be. Upgrades are mandated on a quarterly basis. It was apparent that though the SN installation developers were highly competent, it was equally apparent that they had not battled the ongoing mandated quarterly upgrades (aka patches). In a company I had worked for, on each upgrade/update effort, there were some 1200 exceptions that are generated out of the upgrade process. These exceptions related to ITIL related applications with a few out of ITAM that came “out-of-box”. After filtering out the exceptions that I didn’t care about such as UI mods, workflows, email templates, there were still some 300+ exceptions that required manual review and remediation over code/configuration difference (e.g. Business Rules or Script Includes).

At the time of this writing, no utility is available that evaluates at a high level, the impact of code change to baseline. Note that these exceptions are only generated over baseline and only appear as a function for performing an upgrade. Any custom extension that was created was not affected since there is no baseline equivalent to compare with. This showed me that creating custom apps were really a good option since baseline is not affected. I also saw that it could be better to possibly consider creating custom ITIL based apps (e.g. Change) in order to better manage baseline and controlling functional enhancement where the business requirements were substantially different than baseline they supplied. The only issue I saw on custom apps was around parsing the DOM hive on a major version upgrade resulting from having to work around a client-side bug that SN had yet to fix. SN seems to regularly change the DOM structure.

Lessons Learned

Here are lessons learned from my experience working with upgrades and managing the code base:

• Maintain adherence to base as close as possible and document in both code and capture the functional/structural deviations and justifications in an architectural style master repository/document. This way others will understand where to look for the skeletons. If your organization is large enough, possibly have a technical review and approval process over justifications on deviations with additional approvals on major deviations.
• If functionality of the baseline installation has to be extensively modified to cover your requirements, extend the tables creating your own custom application. You can always revert back to baseline should SN incorporate your functionality as baseline in the future. (One simple example was in the Aspen release, Change only provided a single CI relationship to a Change Request. It was custom to create and related table of CIs and modify the rulesets for the related table to replace the baseline single relationship. This functionality became baseline in about the Eureka release. It would have been better to extend the task table to provide the extensive deviations from baseline to cover the business requirements.)
• Provide inline documentation as a developmental and administrative standard to explain the deviation and why. This has always seemed rather basic to me, but surprisingly this discipline is not practiced by modern developers.
• Try to move the mod into a custom Script Include or Business Rule that overrides or is executed in concert with baseline. Having separated out custom code at upgrade time helped in cutting down exceptions in future upgrades/updates.
• ServiceNow is not an “end-all” solution for every business need even for service management. If the business process does not conform to the service management functional process flow, don’t try to make underlying core functionality conform to a single use case. Likely, you need to develop it yourself using another developmental framework. I’ve seen how the Service Catalog, which is a basic, generic service management task be perverted and provided limitations over the ability to upgrade and incorporate new generic functionality that the user community desired. This could not be done since it was a structural modification that required all of the Service Catalog to be reworked.

See Recurring Maintenance as an example where it was beneficial to extend baseline and create my own custom app leveraging on the baseline code.