Guest Column | June 26, 2019

Avoiding Legacy System Architecture Traps

By Andrew Gauvin, Freeport Metrics

How To Avoid 5 LIMS Nightmares

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:

  • Lack of automated tests to lock the logic and prevent user errors.
  • Problems with migrating custom logic between test/QA/staging and prod environments.
  • Security misconfiguration caused by inexperienced users that can cause data leaks, especially when your external users are allowed into the system.

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:

  • Performance issues caused by pulling too much data from the server or lack of efficient mechanisms to create more complex queries.
  • Lack of database level schema constraints leading to ‘messy’ data and ‘glue’ code to handle edge cases.
  • Security logic placed in client code, resulting in lack of server-side security that makes applications easily exploitable by the client.

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.

User Interface Tier Selections:  Professional frameworks for “web applications” become outdated very quickly. Tools such as ExtJS (later called Sencha) that makes web applications work like PC desktop applications, GWT - Google’s in-house tech that promises java developers the ability to create HTML/CSS/JavaScript UI’s, the Backbone.js framework, the more complex Angular framework, and Facebook’s React all are examples of tools that have become problematic for development and maintenance as newer frameworks quickly take their place.

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.

AAndrew Gauvin, Freeport Metricsbout 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