Is reducing technical debt worth it?

Dr Tuuli Bell , Solution Architect, 1UP Solutions

Contents

• When and why to de-customise ServiceNow
• When does ‘customisation’ become ‘over-customisation’?
• Background: Enterprise Architecture (EA) frameworks on technical debt
• Learnings
• Read on for… Method and technical deployment steps

When and why to de-customise ServiceNow

Let’s start with a little bit of a background. ServiceNow is a great platform for all things Enterprise Service Management. It is fully customisable and configurable. The ability to customise the platform, and essentially fit any process or framework, makes ServiceNow the world’s #1 platform for IT and beyond.

However, and this is where the catch comes into play, sometimes people overdo it a little bit. Customisations, that is. The reasons for (over)customisations are many, and include, but are not limited to, the following:

• a large number of owners for the platform
• poor handovers between owners / teams / partners
• no governance for data / admin access / release & environment management
• lack of documentation – for both ‘as-is’ and ‘to-be’
• lack of business analysis & story writing
• insufficient UAT and/or unit testing
• utilising legacy features (such as using a CMS portal rather than Employee Centre)
• ‘skipping’ new functionality during platform upgrades
• using legacy custom apps for something that is now part of the out-of-the-box (OOTB) platform
• lack of investment for training/ resources/ time
• misalignment between business and platform strategy

As we can see, there is no need to blame any person or organisation for the fact that a platform is over-customised. It is indeed more common than you might think. Truly, keeping the platform in top form over the years requires a lot of thought, governance, and care.

When does ‘customisation’ become ‘over-customisation’?

There is no one point in time when configuration and customisation would be defined as ‘over-customisation’. Every organisation is different, and that’s why ServiceNow fits so many companies and their needs. If you wonder if your platform may be over-customised, or are looking to conduct an exercise to use more of the OOTB functionality, you could consider the following factors:

• Are there a lot of fields on the platform’s Incident, Problem, or Change forms? In particular, are there many unused fields?
• Are there a lot of custom fields (the field technical name starts with ‘u_’) across the platform?
• Can you create meaningful reports based on your Production environment data?
• How often are your environments synced (cloned) from Production?
• If you look at your core tables in List view, for example Incident or Location, are there records with blank data? Blank or duplicate data can be a symptom of issues with automation (business rules etc.) or integrations.
• Are most of the fields on tables mandatory?
• Do you tend to have ‘Other’ as a choice option on user-facing forms? And if so, is that choice option most used by end users?
• If you have seen the latest ServiceNow demo, does your organisation’s platform look very different to the latest OOTB demo platform?
• Which portal technology do you use? Is it based on CMS, Service Portal, or Employee Center?
• Does your organisation have clear governance procedures for data management?
• With regards to core data, is your company following ServiceNow’s best practice for Common Data Service Model (CSDM)? If not, what is stopping your organisation from adopting CSDM?
• Is there a documented process for on-boarding new employees, and specifically those who work within the ServiceNow platform? Are ITIL roles well defined?
• Is there a strong alignment between your Enterprise Architecture domain, and your ServiceNow platform strategy?
• What does your Change Management practice look like? Is the standard change process used by default, or is emergency change process used often?
• Has your organisation had any data breaches? Are you aware of the ACLs within the platform? And if so, do they align with the security practices within the organisation?
• Do ServiceNow users get inundated with emails? Are they helpful, or mostly ignored by users?
• Is the platform fast, or do users complain about it being slow?
• Finally, when creating new functionality on your Sandbox or Development environments, are there a lot of unexpected bugs due to existing customisations?

Background: Enterprise Architecture (EA) frameworks on technical debt

In large organisations, Enterprise Architecture (EA) frameworks such as TOGAF and DoDAF help govern the complexity of businesses through providing consistent vocabulary. ?Enterprise Service Management along with its applications such as ServiceNow, are integrated within EA components.

Figure 1 depicts DoDAF viewpoints, with Services Viewpoint and Data and Information Viewpoints being of most interest in the current context. Reflecting back on a highly customised ServiceNow platform, both ITSM processes and data may be unoptimised. On the other hand, platform that is well defined and streamlined, works in harmony with DoDAF viewpoints.

Another example of EA frameworks is the NIST Enterprise Architecture, an early reference model from the 1980s. Even though technology has advanced since the last century, the synergy of delivery systems (such as ServiceNow) and business architecture remains relevant. Figure 2 shows these two interlinked layers at either end of the model.

Whilst not an EA model, the ITIL framework is relevant to the Enterprise Service Management, to say the least. ITIL4 introduces a Service Value Chain (SVC) model that is pertinent to technical debt, amongst others. In Figure 3, David Billouz has illustrated examples that trigger Service Value Chains. On technical debt, he says “A demand to payback a technical debt mainly triggers the “Design and Transition” activity of the SVC as it directly treats the design of the solution and addresses the Time-to-market requirements of the requester.”

Learnings

• Whilst ServiceNow is a great platform, it is possible to over-customise it to the point that de-customisation is desired, if not necessary.
• Has your organisation over-customised the platform? Check the list of questions in the article.
• Enterprise architecture frameworks as well as ITIL4 can be used to illustrate technical debt reduction and related systems.

Read on for…

... the method and technical deployment steps in our next blog post! The link to the article will be available in comments.