Introduction
Anyone who has worked for a large Fortune 500 or private sector company with thousands of developers has likely faced this. As we’re taking on a new task, we find ourselves in a position to start work on a new service that will drastically improve the way our product operates. However, what began as an exciting task that would truly make a difference turned out to be a battle against several unknown forces on the other side of a ServiceNow ticketing queue.
Understanding Why ServiceNow Falls Short as a Developer Platform
ServiceNow, while effective for managing IT services and operations, falls short as a developer platform (iDP) primarily due to its rigid, ticket-based structure and lack of features conducive to agile software development. Unlike a true developer platform, which facilitates seamless collaboration, code sharing, and rapid iteration, ServiceNow imposes a bureaucratic workflow that can hinder the swift progress essential in development environments.
It lacks the tools for innersourcing, where developers can easily access and contribute to each other's code, and does not support the kind of continuous integration and deployment practices that modern software development demands. Furthermore, its interface and processes are not tailored to the specific needs of developers, such as easy repository creation, direct code manipulation, or quick deployment options, which are critical for an efficient and fluid developer experience. This inherent disconnect from the agile and collaborative ethos of software development is why ServiceNow is not considered a viable developer platform.
My Developer Experience with ServiceNow
This is an actual story from one of my previous roles, but I’ve talked to so many others that have had similar issues working at the same place or at entirely different companies all together. It started during our sprint planning as team members were assigned tasks and mine was to build out a new service for our downstream partners leading to performance gains and much better error handling.
Initial Challenges and Setting Up
On taking the ticket, I found myself referencing many of our existing projects that were already functioning and able to be built and deployed against our cloud environment, so I raised a ticket against ServiceNow to have a new repository created in GitHub since our organization has certain security constraints with letting development teams create these directly. Thankfully, this process was mostly streamlined and the repository was created automatically once we submitted the ticket. There were a few pain points since certain repository settings were disabled and anytime we changed them, they reverted back. Our team decided this wasn’t worth pursuing and carried on with creating the application.
Overcoming Obsolete Dependencies
Since the repository was initiated with only a blank readme file, I got started by finding a good project within our team utilizing the same tech stack so I could start copy/pasting files that would be needed in standing up this API service. Little did I know that most of the dependencies I’d be carrying over from the old project were in varying states of deprecated, vulnerable to exploits, or in maintenance mode with a quickly approaching end of life. I spent the next hour or two getting all of this copied over and making sure I can still build the project locally once I strip out all of the business logic from the app it was based on.
Deployment Environment Setup
Now, with this part of things complete, there were several stories up next. For me, I was tasked with getting our environment set up that this would be deployed on. The first day of this task was focused on figuring out what all we needed to deploy this application on. Previously, we had been deploying our applications on EC2 instances in AWS but our manager said a lot of teams were moving to AWS Lambdas so they wanted me to take a moment to look into that. I spent the day reading the official AWS documentation, perusing the channel #support-aws, and asking coworkers about their experience, but most of them hadn’t worked on the setup so they weren’t sure where to start.
Another couple days passed and the product owner seemed slightly irritated that my task was still in a blocked state so they started reaching out to fellow POs to figure out if they had any insight. A couple hours later, one of the POs responded to the email I was cc’d on saying I could raise a ticket in ServiceNow to have a Lambda created.
The ServiceNow Ticketing Ordeal
Alright, so the ticket was raised with all the information requested, so I waited for the task to go into a completed state similar to the repo I requested. This would be a big disappointment as I didn’t hear anything back until the next morning, and it was just a notification that a comment had been left on my ticket. The ticket requested additional information and explained some of the information provided was insufficient. This was pretty frustrating to say the least after all the time that had passed getting to this point. We spent the next day going back and forth on these ‘issues’ and it seemed like the man behind the curtain was finally appeased and ready to create the Lambda.
The Struggle with Multiple Teams
You would think that this is the end of this story, however, our team spent another week raising tickets with Networking, Cloud Operations, Security, etc., waiting for each team to find their problem with our ticket to address issues with each of those areas just so we could deploy a simple application that wasn’t even ready for production yet.
A Better Developer Experience
Many years and two jobs later, I got my first exposure to a team that managed a Developer Experience Platform outside of ServiceNow. They used backstage and had templates in place that allowed me to create my repo, infrastructure, and a baseline application all within half an hour. There were times I found templates that didn’t meet my needs, I was able to go directly into the source code, raise a pull request and make a case for changing the way this platform met my expectations. Times are changing, and Developer Experience is no longer hidden behind the walled garden that is ServiceNow.
Pitfalls of ServiceNow
The goal of this isn’t to say that tools like ServiceNow, Cherwell, and others are useless in an organization. These tools play a vital role in operating help desks that extend well beyond the realm of IT Operations. However, what a lot of organizations end up doing is paying an excessive amount of money for ServiceNow-like-tools and their additional add-ons, so they decide to try and make this a one size fits all solution. So let’s discuss the pitfalls:
- ServiceNow does not encourage innersourcing. Teams using this are likely very segregated from those that administer it, and making changes behind the scenes isn’t as simple as raising a pull request. This stifles innovation and creates reluctance to use.
- Tickets are not a good way to encourage collaboration. Having been on both sides of a ticketing system, I understand the benefits of tracking work being completed. However, people on the receiving end of these systems rarely get to interact with the teams servicing them.
- These tools are used poorly. The biggest culprit of this is change tracking. There are so many better ways to account for change and pushing it through these tools is arguably one of the worst ways to manage changes for the sake of audits.
Final Thoughts
There are many options when it comes to building out a Developer Experience Platform. However, funneling development teams into a tool just because it exists in the ecosystem will very seldom be beneficial unless it can solve a problem and adapt to change quickly. Having a product mindset with the team owning this platform is crucial to ensure adoption while encouraging innovation. And finally, ticketing systems need to become a thing of the past as teams push towards platforms that prioritize individuals and interactions over processes and tools.
Liatrio's expertise in DevOps and software development best practices, particularly their emphasis on automating workflows and fostering collaboration, aligns perfectly with overcoming the limitations we experienced with ServiceNow. Their focus on enabling developer autonomy and efficiency could have provided us with the tools and strategies necessary to bypass lengthy ticketing processes and create a more dynamic, responsive development environment. By adopting Liatrio's principles, organizations can transform their development practices, breaking down barriers and fostering an ecosystem where innovation thrives.
