By Andrew Gauvin, Freeport Metrics
Legacy systems are more than just old software — any technology can earn that label from release day. Software architects are vulnerable to certain pressures and biases. Here’s how to avoid trapping your company or customers with problematic systems by making better architecture decisions.
Looking For Silver Bullet Technologies
It’s wise to choose technologies that optimize development but be careful of technologies that promise to massively reduce the amount of effort needed to build your software. For example, many new CRM technologies allow ‘non-coder’ users to extend and customize business logic using UI editors without a single line of code. This is very useful for more basic flows but can be problematic when the complexity of the logic increases.
This type of development creates challenges that are easily avoidable using standard coding practices:
Other technologies promise strong developers that they can eliminate the “drudgery” of some coding tasks. Various code generation frameworks spring up every few months and ambitious young software developers create their own. Many of these tools are great when proven and used for certain business applications - Ruby on Rails and many of its clones are one example. However, when it’s time to update your software, you need a quite sophisticated developer to debug the creations.
Some frameworks promise to “level up” junior coders quickly. Platform as a service (PAAS) tools such as Parse are useful for prototyping or even basic MVP creation, but they often require a rewrite when the system grows. Many mobile PAAS platforms are sold on a promise that mobile developers can create applications without learning backend programming in depth. Unfortunately, this can create client-server programming problems or platform limitations, such as:
Internal developers aren’t the only ones prone to these challenges. Some outsourcing partners choose “heavy” architectures that require a lot of extra (billable) dev hours. The worst offenders? The sometimes-unholy alliance between large consulting firms and large software companies.
For example, historically the Java 2 Platform, Enterprise Edition (J2EE) was used in situations where lighter technologies would be a much better choice. Extreme separation of tiers with a lot of boilerplate and configuration code made it a nightmare to add even a simple feature to an existing system. Luckily later alternatives such as Spring and Ruby on Rails leverage convention over configuration concepts.
Solving For Yourself Instead Of Your Customer
Another prime category of architecture mistakes is those driven by the architecture team making decisions based on their resumes, both from their past experience and their dreamed goals of for the future.
While most developers work on small or midsized projects, they sometimes try to mimic solutions presented by Google-scale internet giants at conferences. A typical misconception is using microservices architecture for a small system built by a small dev team when a traditional “monolith” solution would be perfectly valid choice. The team usually doesn’t gain much besides credibility among peers, but someone needs to deal with problems that come with complexity: handling partial system failures, versioning of interfaces, distributed debugging, etc.
On the other side of the spectrum, some teams simply lack ambition. They base the architecture decision solely on what they know the best despite the business problem or technology maturity. This unambitious team uses the technology they know in the way they always have used without much reflection or learnings from the market. Many developers could choose this technology even when the technology is obviously flawed in some major way or no longer popular, increasing hosting and other maintenance problems.
Avoiding Legacy Challenges Tier By Tier
Your team needs to make architecture decisions at each tier of the application. Here are some legacy challenges in each segment.
The Legacy Middle Tiers: Mobile backend as a service is the most recent example. User interface developers wanted to build/deploy their applications without having to learn or build the middle-tiers. Some of the darlings in this space were quickly acquired (Facebook with Parse and Google with Firebase). When Facebook announced it would shut down Parse, it had hundreds of thousands of live mobile apps using it. Thousands of developers needed to migrate their “back-end” migrated to keep running.
The Legacy Data Tiers: Relational databases have shown their age but have proven themselves as reliable backbones for scalable transactional systems. NoSQL databases have been applied to many problems that would work better for relational databases. Another example is neural network databases for analytics where star schemas hosted on traditional relational databases would be sufficient.
Bottom line: When choosing technologies for application development, take some time to think it through before diving in. Weigh your prejudices against the needs of the final solution and look at the trajectory of the technologies. Are you making a comfortable choice instead of the right one? Are you picking something simply for the geek prestige or investor keywords? To avoid burdening your company or customer with a solution that becomes unworkable, balance these criteria honestly before you write a single line of code.
About The Author
Andrew Gauvin is founder of Freeport Metrics, a custom application and software development firm that helps clients solve challenges and bring ideas to life. With locations in the United States and Poland, the company offers engineering and design solutions for business. For more information, visit freeportmetrics.com.