Managing Tech Stack Complexity: When Does it Make Sense to Diversify?
The tech industry is facing an unprecedented level of complexity. Almost every week, new databases, platforms, tools and languages emerge, leavinig businesses constantly assessing their viability for their existing tech stacks.
The problem with constant technological evolution is how to keep things simple and homogeneous. Is simplicity always the answer? Or when does it make sense to diversify and, therefore, add to a tech stack’s complexity?
In this article, we’ll share a few ideas for reaching the right balance between non-complex tech stacks and staying relevant in a growing sea of new technologies.
Complexity vs. Simplicity
Before today's diverse technological landscape, software engineers used to stick to a simple tech stack, for instance, PHP and MySQL. That was all they needed for many years.
While single tech stacks are still a valid option, they often stifle innovation and prevent scalability, so deciding on the best technology is no longer as simple as choosing one provider for everything. The process requires a nuanced approach that factors in the pros and cons of several solutions from within a diverse, competitive marketplace.
Most new technologies are specialized for specific needs, such as scaling a product or managing billions of data records. For such complex solutions, it is often tempting to diversify your tech stack and adopt these technologies, as they allow you to innovate faster and better than your competition. However, they come with a huge complexity cost, often making it difficult to change things quickly and efficiently. Engineers can often feel like they’re turning an oil tanker around in a puddle just to add a new feature.
Amid this endless technological evolution, organizations should take a proactive approach to assess the viability of these new solutions against their business goals, budget and engineer capabilities. Don’t just shoehorn a new technology into a stack without a deep understanding of its potential impact on workload, users and ultimately, cost.
Strategic Tech Stack Standardization
Many companies have found success with a particular tech stack standardization strategy related to technical archetypes.
The approach involves identifying and enforcing a tech stack for each subset of use cases or technical patterns. We will only add a new archetype (and therefore another tech stack) when a certain use case or pattern doesn’t fit with any existing archetypes. Once implemented, we provide training for the new archetype and share it throughout the organization, solidifying it as the new standard for similar challenges.
This technique promotes openness to new technologies while ensuring teams are selective enough to ensure they make sense in current strategies — it is perfectly possible to end up with only one archetype, which is a good sign of pragmatism.
These Companies Excel at BPM and Process Automation and You Can Too
How to leverage business process management (BPM) for operational excellenceRegister
Mondelēz: 3 Steps to a Data-Informed, More Proactive IT Department
How to build a new team culture dedicated to the proactive mindset.Watch Now
How to Create a Successful Hybrid Enterprise Using Slack
Learn the three steps companies should take to create a successful hybrid enterprise and enable better productivity.Watch Now
How to Modernize Your Intranet and Avoid the Build or Buy Headache
Join Workgrid’s Rob Ryan and Frank Pathyil to discuss the challenges in building or buying an intranet.Watch Now
The technical archetypes strategy only works alongside a clear communication and training strategy for your teams. Sharing knowledge, explaining why those archetypes exist, and outlining your expectations for colleagues around their role in the decision-making process makes all the difference.
Related Article: From Service-Oriented Architecture to Microservices
Does Your Team Have the Skills Needed to Work With New Tech?
People require specific skills to successfully use technology — whether existing or emerging. As these technologies increase in number, so do the skills required to work with them.
Some technologies and projects might require companies to hire fresh talent, bringing the experience and qualifications to implement them more quickly. In most cases though, organizations provide internal training to learn the necessary skills to implement new languages or tools, but this takes time.
By keeping your tech stack simple, organizations can ensure their teams are fully versed in the most project-critical technologies before introducing anything new. This approach gives companies the chance to review any new technologies and assess people’s ability to handle them, revealing what to train for and what skills to recruit for.
A good guideline is if a product roadmap can succeed without implementing new technology — in other words, your programming languages, databases and front end technologies work well — then it’s not worth the time, effort and expense it would take to shoehorn new skills into your existing strategy. Remember, any addition to a tech stack must be about solving a real business need rather than simply buying into the hype due to FOMO (fear of missing out).
Above all, focus on building a collaborative environment that enables developers and engineers to share knowledge, develop new skills and learn from one another. With the right culture, teams will organically improve their skills and get ahead of the curve, making them more prepared to work with new technologies efficiently and successfully.
As a final thought, be sure to involve your team throughout this whole process because it’s essential to the growth and maturity of the organization. These tricky decisions related to tech stacks are a great opportunity to reflect on your engineering principles and develop stronger teams as a result.
About the Author
Sebastian Velez is head of technology and also oversees PSL’s training and development program and R&D innovation lab. He has been in the industry for more than a decade, with experience as a developer, software architect, scrum master and college professor.