How do you keep track of changes to out-of-the-box configuration

[GChanner]

We are 6 years in and have added ITBM, ITFM, HR, CSM to our instance and as we develop and move further away from OOTB we try to minimizing customizations. As we all know there are times we cannot avoid all customizations.

Use-case: Recently we promoted a change to PRD which impacted a large user base. The solution was to roll back the update set. As part of a RCA, my director wants to know what was changed and why.

To better answer these questions and get a better handle on the changes to the platform I am trying to develop a process where we can track changes to OOTB items.

Things to consider are:

1. Where the change was made
2. When the change was made
3. Why such a change was made

We can use a spreadsheet to document Stories, Change request etc. relating to the change but is that the best tool?

Question to the community:

1. Are there any of the shelf tool that allows for this?
2. How does yours or other organization keep track of OOTB changes?

Any feedback will be greatly appreciated.

[Allen Andreas]

Hello,

This is a pretty standard question and has been asked on the forums in the past. What this means is that there's plenty of great conversations, suggestions, examples, and more that you can refer to. I'd recommend searching and looking those over and see if they help. Beyond that, we don't know your organization's operating model and if you have a technical governance board or not. As demands are assessed and greenlit, any technical requests should be passing through your tech. gov. board. There...it's hopeful that the board has appropriate members that can assess if customization or configuration is needed. If customization, it would need to be evaluated and weighed to see if the technical debt is worth it, etc. Those types of things should then be captured and logged and be re-reviewed periodically to see at a later date/time if there is still a need for it to be custom or if there's an opportunity to use configuration/out-of-box (i.e., perhaps SN came out with a fix or now has that feature in an update), thus essentially creating a "technical debt backlog". In sub-production instances, you may be able to use the Agile 2.0 application to help track stories and such and not need to use something like Jira.

We're not aware of your role in all this, but if you're the platform owner, you should have architects/senior devs already doing this.

An additional resource is this link which talks about technical best practices. This guides developers and such to use appropriate commenting in their code so that the story is associated to that customization/edit and explains the purpose/intent. Those types of things help future developers/contractors, etc. know what is going on and helps organize customization better.

Additionally, you didn't provide any information about what went to Prod and caused the issue. It could have been something that someone unskilled shouldn't have done...which then we bring up the point of conducting peer reviews.

So, while your questions are good from a higher level perspective, you'd still need to address the deeper issue as to what occurred this time and keeping track of customizations is just one piece of the puzzle.

Please mark reply as Helpful/Accept Solution, if applicable. Thanks!

[Allen Andreas]

Hi,

Thanks for marking my reply above as Helpful. Let us know if you have further questions/follow-on concerns. Overall, what you're asking is good, just...somewhat unfortunate that 6 years went by and it wasn't done previously, ya know?

A follow-on to all this is then when it's time to go to production, is there an appropriate change request submitted and reviewed? It would be beneficial to then have all development about to move up be reviewed. You may not have the resources to dig in to each and every line of code, but the importance of the impact and criticality of customization and those types of things being moved to Production should constantly be echoed to all who work on the platform and that change request can be reviewed properly before it's deployed to Prod. In the end, someone would need to be held accountable, but if we can mitigate poor development making it there, we should strive for that. Ignorance is one thing, poor judgement when someone knows that they shouldn't do 'x' is another.

Use this last situation as a learning case and perhaps call a team meeting, etc. and then talk about your introduction of new steps to help everyone do better. It'll take a little bit to get all the pieces in place, but you'll have a much better outcome and your team will be much stronger due to it.

Best of luck! Let us know how it goes!

Please mark reply as Helpful/Accept Solution, if applicable. Thanks!

[GChanner]

Hi Allen,

Thanks for the very informative feedback.

My role is an Application Architect and the System Administrator. We do have governance and QA process in place where all requirements, stories, dev and QA artifacts are reviewed by me and the team and while we have been doing a good job at it we are always looking for ways to improve our Agile process that admins, QA and DEV's can employ thus the reason of me posting this topic.

This has been a topic of ours from the beginning and while we have tried various strategies we cannot find one which gets us to where we would like. We know the information we sought are there in the application (upgrade history, skipped records, stories, update sets, etc.) but that in itself is very time consuming, its like putting a puzzle together.

I know there are no quick or easy solution to this but it is good to hear what others have done or are doing.

Again thanks for the great insight