Software architecture is a metaphor derived from the architecture of buildings. It’s a way of describing the high level structure of an application and is considered to be a balance of science and art, but I'd describe it more as a silent killer. Get it wrong and it will handcuff you beyond escape. At that point, the business impact will be devastating.
A client came to us to add features to their 4 year old application. You’d expect development over this period of time to result in a refined and well architected application. In our experience this is rarely the truth. It was an overly complex system lumped into one application.
The condition of its architecture and lack of tests today gave us big hints as to how future development was going to pan out.
It was going to be slow and painful. It makes you wonder though, how does this happen? How does an application back itself into a corner?
One common cause is what developers refer to as a “tightly coupled” codebase. That means code that’s dependant on other code and is very resistant to change. As you attempt to add a new feature to a tightly coupled codebase you'll find you have to change other seemingly unrelated parts of your application. Repeat this process and your application development will slowly grind to a complete halt.
You’ll end up with a monolithic application: One application that does everything. It’s a frustrating tangled mess to deal with.
At first you won’t know you’re headed down this path. Development will be rapid, agile and appear to be going great. Fast forward several months and you’re now considering a rewrite and freezing all new features until it’s fixed.
As you attempt to scale a monolithic tightly coupled application, it will tax you in just about every way possible. It will:
- be more time consuming to add new features and you’ll have a higher chance of introducing bugs when doing so.
- be tricky to upgrade because you have to change your entire application in one shot.
- make it difficult to onboard new developers as they’ll have to learn so much before they can start any real work.
During the lifespan of a project, you should expect significant requirement changes. Architect your application accordingly.
Instead of a single large application, what you need is an application that’s modular and expects change. Modularise your application into logical, organised parts. You might even split those parts into a new application. Your admin area or marketing website are common examples of this.
Aside from the larger segments of the project, the details matter too. Within these modules, focus on keeping them decoupled.
Give your developers time to identify and refactor appropriate areas within your codebase.
Easily said but you’ll no doubt have other important todos you’re going to have to put aside. You need to be prepared to take the time to improve what you have without adding new features. This will help decouple and enhance your application’s architecture.
Writing tests (code that tests code) is crucial to confidently refactoring your codebase.
A quality test suite makes your codebase more open and inviting to being refactored.
Your developers will use it to check the external functionality still works while they refactor the internal workings.
Focusing on architecture regularly has some real business benefits too:
- You’ll be able to pivot and adapt your business more easily. This is vital for startups.
- Your developers will be happier, stay around for longer and it will be faster onboarding new development team members.
- You’ll be able to adopt new versions of software you rely on in smaller more manageable chunks. This is considerably less risky than attempting to upgrade an entire application at once.
- Most importantly you won't hit a wall where you're considering a rewrite or feature freeze while you attempt to fix your application's architecture.
Just remember, architecture is important but not urgent. But when it’s urgent, it’s often too late.
Join The Conversation
More On The Blog
Are Spree sites meeting Google’s page speed standards?
A study of 680 sites built on the Spree OS platform reveals nearly all are mobile friendly, but only a handful achieved a mobile speed score high enough to be considered by Google as performing well.
Barry Harrison — Sep 12, 2016
Machine Learning and eCommerce Talk at SolidusConf
I recently spoke at SolidusConf about Machine Learning and eCommerce
David Jones — Jun 14, 2016
Top 7 Product Recommendation Options
Top 7 Product Recommendation Options Ranked by Revenue Generation
Barry Harrison — May 31, 2016
Get every post in your inbox (see sample)