In this blog post, we'll explore some of the key factors that enable scalability and adaptability, including modular design, automation, and a cloud-based infrastructure. We'll also share real-world examples and practical tips that you can use to make your solutions more robust and resilient, and help your organization stay ahead of the curve. So whether you're building a new application from scratch or looking to optimize an existing system, read on to discover how to make your solutions scalable and adaptive.
Most custom solution projects begin with gathering requirements. The solution requirements are often based on “what is used now” and “how things are done now”. Inherently this will result in a solution which will be outdated the moment it is released, because time will have passed between gathering the requirements and implementation. As Heraclitus famously stated “the only constant in life is change”. More often than not, requirements are refined during implementation as new scenarios, situations and information arise. This can cause severe technical issues due to architectural decisions made based on the initial requirements. Still, gathering and refining requirements throughout the project is crucial in order to be able to work in an agile way.
To combat this dilemma, solution designers should aim to design solutions which are scalable and adaptive. What is scalable? Its definition is “capable of being easily expanded or upgraded on demand”. Adaptive is defined by Webster as “adjustment to environmental conditions”. In ServiceNow and IT solution design in general, scalable and adaptive means that the components interacting with the solution can change in type and size and still the solution is able to function without dramatic reworks.
Finding a balance
The question most projects need to answer is how much scalability and adaptivity do they require from the solution about to be implemented. It is always possible to make a “single-purpose-tool” which will answer the need of “how to solve this single need right now”, but in most cases these types of solutions will either break or require refactoring in the near future as the environment around it changes. The other approach is to think about “how can this solution be made in a way that it will not only meet the current requirement, and also some possible future requirements” and at the same time consider “will the technical and design decisions made, lock the solution down and prevent it from adapting to future requirements”. Of course, we cannot predict the future, but we can and should prepare for it. For example, a solution designed to work with a specific type of task, will often need to function with multiple different task types in the future, so it could just be made generic to all task types from the beginning. So why isn’t everything made generic, multi-purpose and extremely adaptive? Because implementing that will often require more effort then implementing a simpler “single-purpose-tool” solution. The Agile approach is to first create a “Minimum Viable Product” (MVP) and quickly as possible, with minimal effort and then refactor the solution through continuous improvement. Even this approach can have its problems; constant re-implementations often cause confusion among users who utilize the solution, data flowing through the solution might require manual adjustments, and refactoring a poor MVP solutions might require more effort then implementing a better initial implementation.
Quick Wins
Fortunately it’s possible to add some adaptivity and scalability with very minimal effort by following a few technical best practices and of course through gaining experience.
Below you will find a list of technical quick wins in ServiceNow, which will help create solutions which will scale and adapt better with less effort in the future.
-Use choice -type variables instead of booleans, because the value you are storing might not be as black or white as it may seem.
-Use arrays and objects with for loops, instead of individual value processing statements. A for loop can run as many times as needed and will not require code changes every time a new value is added.
-Use switch statements instead of long “if, else if and else” statements. A switch statement can process multiple expressions with a single common code block. And finally, the default keyword can be used as a failsafe to catch unspecified cases.
-Introduce new fields in the correct table. Custom fields are often implemented in the parent table at the very top of the hierarchy or in the last child table at the bottom of the hierarchy. “Configuration Item” (cmdb_ci) is a prime example of the first scenario and “Desktop Software” (cmdb_ci_desktop_software) of the latter. Oftentimes the correct level in the hierarchy is something in the middle, for example; adding a field to store “Installation file directory” to the “software” table (cmdb_ci_spkg. This way the new field is inherited to both desktop software and application software, but is not polluting CI classes like computers, which can not utilize the field.
Can you get flexibility without effort?
I believe we should not try to come up with the “theory of everything” for IT during each solution implementation, but as we can see from the examples above, you are able to implement solutions in a scalable and adaptive way with very minimal if any extra effort. The main change required is the design mindset. We need to accept and embrace the constant change around us. Let’s take a step back when defining requirements and look at the situation on a concept level. “Syncing work notes between Requested Item and Request” can also be seen as “Data synchronization between parent and child task(s)”. When we break away from the bad habit of providing partial solutions as initial requirements, we are able to come up with completely new ways of working and solving problems. There is no point in trying to invent “a flying car”. I would rather see a solution for “a fast,non-polluting and safe way of transporting people in six degrees of freedom”.
