Written by: Ben DeBow | Founder and CEO of Fortified | Author of End of Abundance in Tech
Blog Series: The Evolution of Technology’s Role in Business.
Continuing our exploration of technology’s evolving role in business, Ben DeBow returns with Part 2 of his 12-part series, examining the critical differences between efficient, easy-to-manage systems and those that are complex and prone to failure. He examines why certain applications remain cumbersome and fragile despite being heavily relied upon while others thrive with minimal effort, becoming the backbone of operations.
As businesses grapple with the growing pressure to optimize and streamline their technology stacks, understanding the core principles of simplicity, scalability, and long-term sustainability is more critical than ever. This installment uncovers the key factors that contribute to system complexity and highlights practical ways organizations can foster an efficiency mindset—an approach that not only cuts costs but also ensures technology remains an asset, not a liability, for the long haul.
Introduction
In every organization, we can easily identify applications or databases we love supporting and developing against. These applications have fewer outages and are easier to develop against, and the support teams don’t mind supporting them. We often think of them as simple applications that work. On the flip side, we’re equally familiar with those problem systems that constantly have production issues, require modifications for releases to work, and the support teams run away from. You know, those systems no one wants to be assigned to or associated with. These are the trouble applications or what we might consider “complex”. But what makes an application complex and fragile? What did we do differently when building the simple applications which we all love? What must we do to make those complex applications loved by the support teams?
Consider a modern e-commerce platform that is modular, easy to update, and scales effortlessly during peak shopping seasons. It was built with .NET, React, SQL Server, and other technologies with a mature developer community. Contrast this with a legacy inventory management system built on ColdFusion, Informix, and AS400 which was built and added to over the last 20 years and that struggles to integrate with newer systems and frequently causes delays in order processing. Even finding talented support personnel and tools is challenging.
Why Efficient Applications Outperform Complex Systems
So, what distinguishes a simple application from a complex application that is a nightmare to support or enhance? In my opinion, it comes down to the KISS principle: Keep It Simple, Stupid. But more than that, many of these applications were never designed with efficiency, scalability, or operational support in mind. Typically, efficient applications in technology are less resource-intensive, have better performance, are simple in design, easier to support, cost-effective to operate and implement, and energy-efficient, benefiting the environment. Another important point is that most applications were never designed to scale, as their original scope was just to build an application that worked.
How can we determine if our design approach is solid? I have to admit, there is no simplicity flag when designing an application. One way to review the efficiency is to think about the core transactions and functionality in the application and walk through the transaction. If you are making several round trips, converting data, checking 10 places in the database to determine the state, and then returning the data, the application is complex. Is the application hard to understand, communicate the architecture, and troubleshoot? This is where the KISS principle comes into play, but we need to review the application stack, not just a piece of code.
Take, for instance, a well-designed API that follows RESTful principles. It’s intuitive, self-documenting, and easy to integrate with. Now imagine a poorly designed API with inconsistent endpoints, unclear documentation, and frequent breaking changes. The difference in developer experience and long-term maintainability is stark.
Given these advantages, why wouldn’t we design every application to be simple and efficient? Why are we not updating the complex applications to make them simple? Many times, enterprises do try to make complex applications simple, but because there is so much risk, effort, and time involved, they usually only add superficial improvements and do not address significant design issues. The challenge lies in creating something that appears simple yet manages complexity effectively. Based on my experience, several factors contribute to increasing application complexity:
- Overengineering: Developers, DBAs, and/or architects often overcomplicate solutions to showcase their technical prowess. There is something to be said for the single line of code that accomplishes the goal.
- Skillset limitations: Teams often build with technologies that they are familiar with even though there might be a better technology based on the use case.
- Budget constraints: Short-term cost savings might lead to choices that increase complexity and costs in the long run.
- Technology choices: Jumping on the latest tech bandwagon without considering its long-term implications can lead to unnecessary complexity. What is the best technology for the application long-term versus today?
- Company culture: A culture that values quick fixes over sustainable solutions can lead to accumulating technical debt.
- Partnerships with specific providers: Vendor lock-in can force teams to use suboptimal but compatible solutions.
- Time pressures: Rushing to meet deadlines often results in cutting corners and increasing complexity.
For example, I once worked on a project where the team chose a trendy NoSQL database for a system that primarily dealt with structured, relational data. The database choice was not ideal for the use case, and remember, the database is the foundation of the application. The decision was driven by the team’s excitement about the new technology rather than the project’s actual needs. The result? Increased complexity in data retrieval, consistency issues, and a steep learning curve for new team members.
As we move towards consumption-based models where inefficiency directly impacts costs, we must change our approach to designing and developing applications. Every decision in technology comes with a cost, which is often overlooked in both the short and long term. Even as we develop our own software, I find myself constantly needing to reevaluate decisions in light of their long-term implications.
To start designing with efficiency in mind, organizations need to focus on people, processes, and technology:
- Culture: Foster a mindset of efficiency within technology teams. Encourage questioning of complex solutions and celebration of elegant simplicity. For instance, implement regular ‘simplicity audits’ where teams review each other’s code or designs with a focus on identifying and reducing unnecessary complexity.
- Processes: Implement design, build, test, and deployment processes that prioritize efficiency. This could involve incorporating efficiency metrics into code reviews and accepting or rejecting inefficient code as part of the development process.
- Technology: Measure implementation not just on functionality but also on resource consumption and the long-term cost of ownership (TCO). Don’t just have a budget to build the application; create budget goals for the operational cost of supporting the application for the next 5 years.
Designing for Longevity: Shifting to a 10-Year Technology Mindset
Everything in technology should be designed with the expectation that it will live for 10 years or longer. This long-term perspective can dramatically shift decision-making processes, especially when you calculate the TCO for 10 years.
This shift is crucial now more than ever because businesses now view technology teams as enablers, data is growing at an average 23% compound annual growth rate (CAGR), organizations are dealing with 20+ years of legacy technology, and there’s a push to invest in Artificial Intelligence (AI).
To meet these challenges, we need a cultural shift toward efficiency, and businesses must prioritize optimizing existing technology. Only then can we begin to lower the total cost of ownership for technology.
In the coming months, I’ll address how we can start solving these issues across all businesses. It’s time to embrace an efficiency mindset and transform the way we approach technology development and maintenance. The future of our digital landscapes depends on our ability to build systems that are not just functional but sustainably efficient.