top of page
  • Abdulla M Syed

Tech stack problems can hamstring dev teams

Updated: Jan 9

3 min read

By: Abdullah M. Syed on September 30, 2022


In today’s modern world, software is involved with practically every aspect of daily life. Most of it silently does its thing in the background, helping us plan, organize, and use information.

Most people don’t even think about it, but the truth is that software isn’t all that “smart.” It’s a big set of carefully layered and balanced rules and instructions. Breakdowns are quite common amid this complex and delicate superstructure.

Software engineers, along with the teams that coordinate them, are the quiet custodians of code. Updates, improvements, and innovations happen around the clock, hidden by other layers of software that make up user interfaces.

Any business or organization that interfaces with a large number of people either directly or indirectly relies on development teams—these days there’s simply no way around it. Contact centers are no exception. With customer and employee experience strategy rising in prominence, the smooth operation of digital (read: code-based) applications is nothing short of mission critical.

Anything that makes a developer’s life more difficult ends up impacting the bottom line. If the problem is at an individual level, then that can typically be sorted by team leaders. But many problems are systematic, impacting everyone on the team, which in turn compounds the issue.

For example, many contact centers insist on sticking with old, outdated legacy technology. The expense to do an overhaul or even a gradual transformation is daunting. Decision makers fear the short term expense, and thus borrow from the long-term potential for success.

Unfortunately, technology now accelerates at such a pace that continuing to wait to upgrade to a modern tech stack can be a disastrous decision, even in the medium term.

Common dev team challenges in contact centers

When development teams are forced to work with outmoded technology, problems such as the following start to emerge:

  • Configuration data needs to be replicated across multiple systems and environments. Software systems are necessarily complex and get more so every passing year. If these systems don’t use the same language or methods, dev teams need to spend time building “middleware” or customized bridges between them. This doesn’t scale well, and it pulls resources away from other valuable activities such as writing upgrades or troubleshooting issues. Costs inevitably rise.

  • Lack of an exposed relational data model. Relational databases are the heart and soul of many software environments. Without access to the data model, dev teams have a harder time extracting and acting on critical information (or designing systems that can extract and act on critical information). The outcome is slower, less efficient, less “smart” systems.

  • Inability to control the source code. Without access to source code, a system relies on someone else to ensure that things run smoothly and as required. If an organization needs a customization, the path to enabling it becomes much more difficult (read: expensive) and risky. Should the third party make a change to the source code, entire structures that rely on it could cease to function—requiring dev teams to scrabble to try and pinpoint the problem and patch a fix.

Similar to [IT Support teams], working in environments where problems like these are rampant can demoralize and frustrate entire development teams. The demand for skilled software engineers and team leads is huge, so what’s keeping them from finding a job where the tech stack is up to date? Not much.

Investing in a modern tech stack has leapfrogged from a ‘nice to have’ to ‘key to survival’. It needs to stay relevant for years, and must be built to interface with other modern systems. Otherwise, dev resources are going to find their own way to places that have this in place.

For contact centers, a modern tech stack equates to running operations on a secure, public cloud infrastructure.

On-premise vs private cloud vs public cloud

On-premise means the technology is literally on site—physical servers in the building do the work. This is the oldest and riskiest system which many organizations still cling to. It is hard to upgrade, does not ‘talk’ to other systems easily or at all, and is full of inefficient and “dumb” programming that cannot be tweaked without specialist knowledge. It is full of the pitfalls that are discussed above.

Private cloud isn’t much better. The tech is not on site, but with no way to seamlessly connect to the outside world of third-party applications and systems, private cloud systems can fall behind as fast as on-prem platforms.

The modern solution is a secure, public cloud infrastructure. GTS specializes in helping empathically migrate organizations to these systems, which allows dev teams to operate at their full potential. Get in touch today!

2 views0 comments


bottom of page