Data-driven solutions are designed so that data and configuration drive and control the outcome of a process. For many, including myself, they are the standard we should aim for when solving problems in ServiceNow. This doesn’t mean every solution needs to be controlled by properties, lookups, or foundational data, but more often than not, they should be. Designing a solution where you can pull levers (data) to influence functionality, rather than performing maintenance or code changes, benefits not only you but, more importantly, the audience you are designing for. If you’re not designing, creating, or deploying data-driven solutions today, I hope this article convinces you of their merits and importance.
ServiceNow already has many good examples of these principles that you can use for inspiration, with the primary one being the CMDB. Think of all the CMDB attributes that exist for managing, supporting, and approving a CMDB object. Think also of the different processes that rely on that data, such as ticket assignment, CMDB Data Management, and CMDB Health. By providing the right data for a CI in the CMDB, we can leverage existing ServiceNow processes to help manage the CMDB and our Service Management processes.
Now, imagine if those attributes didn’t exist. What if approval groups were hard-coded in a script, flow, or any other type of automation? The solution would then be static. If a customer said, “This group no longer approves these CIs; can we change it to this one?” you’d need to modify the functionality to make that change—or likely build a data-driven solution. This is a trivial example, but the concept should resonate and encourage you to ensure that any solutions you design follow these principles as much as possible.
The CMDB example not only uses data to drive and influence processes but also shows how a good data-driven solution can provide scalability to the solution.
Let’s lay out some key benefits that a data-driven solution can provide:
Scalability and Future-proofing your Solutions
By driving your business logic through data, you ensure that your solution can adapt to changes in demands and the environment. It also allows you to scale the solution when required. Scalability might not be at the forefront of your mind/solution, but you must always consider the future state. Ask yourself “Are other teams going to want in on this process in the future?” or “Is this likely to expand beyond the current use case?”. If the answer is YES to either of those, then you should be considering a data-driven solution design for the problem you are trying to solve.
Cost-effectiveness of Maintaining and Updating the Solution
ServiceNow resources are not cheap. It is your duty as an expert in this field to provide a solution that not just helps the customers achieve their outcomes, but also provides value for money to the customer. You don’t get a (good) reputation for building static/non-scalable solutions that cost the customer money each time they want to tweak something. The upfront cost of implementing a data-driven solution might be higher but the potential savings from doing things the ‘right’ way are always worth it. If your solution is driven by data, it can enable your customer to manage the solution, and they no longer are required to call you each time they want to tweak something. That's a win-win scenario. You have implemented a great solution and framework, and the customer is saving money and is super happy with the solution you have delivered. You have empowered the customer.
Regulatory Compliance of the Solution
In highly regulated industries (like finance and banking), a data-driven solution to the problem you are solving might be the minimum standard. If the company needs to audit or provide visibility to key stakeholders or regulatory bodies, then the solution needs to be data-driven and declarative. This could be a data lookup or leveraging a condition builder in ServiceNow to drive your solution. A good example of this is the Data Filtration framework in ServiceNow. This framework is a no-code framework that is used to deny access to records (unlike ACLs that allow scripting and are traditionally an allow based model), it allows us to define Subject Conditions (data) to create reusable criteria as to when data access should not be granted. The whole framework is built to be declarative, audit friendly, and machine enforceable & human-readable.
Give Yourself a Competitive Advantage
Setting yourself apart from others in the ServiceNow space isn’t always easy. We are all generally consuming the same material and leveraging the same frameworks. Competency and skill will set you apart from others, but so will designing the best solutions. Often, I see solutions that are developed in ServiceNow to be static, hardcoded, and built to serve the story/requirements to the letter, and nothing more. Here is where you can set yourself apart; by designing and building a solution that your customer is going to be happy with for the long term. The best way to boost your standing in the ServiceNow Community and with your customers is by doing GOOD WORK. Be the standard and give yourself and your career a competitive edge: advocating for data-driven solutions.
It goes without saying, but Data-driven solutions are only as good as the data that drives them. Before jumping into the world of data-driven solution design, you need to make sure that the data itself has adequate ownership and support. If you don’t obtain this, you can end up designing your great solution in a vacuum and the customer may not realize or understand the benefit that the solution is providing. A key part of maintaining a healthy CMDB is ensuring that the appropriate groups own the appropriate data; the same concepts apply here.
With the above in mind, it is worth considering some of these common pitfalls when designing and implementing a data-driven solution:
Bad Data Produces a Bad Process
Relying on information that is outdated, incomplete, or inaccurate that drives the process is not going to produce your desired outcomes. Our goal is not simply to create a data-driven process for the sake of it, but to create one because we realize some benefit from doing so. Ideally, we have identified patterns in data that can be used to drive business logic. If the data that the solution relies on is not kept up to date, is not accurate, or isn’t entered at all, then we are setting ourselves up for failure.
An Over-reliance on Data/automation in Human Processes
Terms such as ‘hyper-automation’ have become an industry buzzword, they describe a desire to automate as many processes as possible. While this is great, it can often ignore that fact not every process should be automated or should be driven by data. Some processes require human interaction, or human intelligence to drive the business outcomes or customer experience you want to provide. Always keep this in mind, it’s not about COULD you do something, but rather SHOULD you do something?
Time and Effort Required to Maintain Data
Data-driven processes may provide many benefits in one area, such as cost reduction, reduced time to complete a ticket, etc. But those benefits could be nullified if the cost is now redirected or absorbed somewhere else. Maintaining the data required to support data-driven processes can be resource-intensive. A key decision point on whether a solution should be data-driven is “Do we have the resources to support data maintenance?”
To wrap up, data-driven solutions can help your customers drive real value on the ServiceNow platform, and help you stand out as an implementor in the process. The platform is full of data, whether it is foundational, CMDB, tickets, or anything else. Let’s leverage that data to empower our customers to manage the solutions that we build, providing them with control and influence over the solution after development has completed. This will result in reducing customer dependency on technical expertise for tweaks to a process, and prevent introducing any further technical debt to the platform while still providing them with the outcomes they need.
Comentários