10 September, 2015 · 3 minutes to read · written by Craig Pickles
Redeveloping a digital product can be daunting, especially if you have a customer base that relies on your product to run their business.
At Magnifica, we have many years experience bringing digital products to market. That's why we wanted to share some best practice approaches for kickstarting a redevelopment through a series of blog posts so that you can build better products based on strong technical foundations, that improve your technical teams productivity.
There are a lot of 'legacy' products on the market and we are often approached to help redevelop them. Sometimes these products haven't scaled as they should, may have pivoted or lack features available in competing products so now need a technical rethink.
As a Technical Lead charged with heading up a digital product is redevelopment we are presented with a lot of questions as well as opportunities to improve things. First up we're going to talk about architecture.
When starting the redevelopment of a software product it's important to re-visit the software architecture used. It's important to look at what architecturally has worked well on your existing product and review what hasn't worked so well.
With new technologies and practices becoming available all the time and business needs changing making the very best architectural decisions is essential. Without solid foundations, you will find your team under pressure to keep your product on track and stable. Getting the right foundations can also vastly increase the speed of future development.
"A problem-solving process whose objective is to find and decide on a way to implement the functional requirements while respecting the non-functional requirements and delivering "Good" quality".
Like any complex structure, it is important that software is built on solid foundations. Failing to look at common problems and appreciating potential long-term consequences can put the project at risk. On the other hand making sound architectural decisions can put you at a real advantage when it comes to things like scalability, speed and product agility.
Build software designed to change not just to last.Craig Pickles - Technical Director
At Magnifica our process for architecting a software solution follows the process below:
Example design issue (basic)
The challenge: How to allow a user to register to attend a conference
In this example it was decided to use design option 3 because:
To make decisions the software architects use two different types of knowledge 'current' and 'past' knowledge. Current knowledge includes:
Past knowledge includes:
Internal development teams usually have great domain level knowledge about their product and customers, however it can be beneficial to look outside of the immediate team for extra knowledge around new techniques and technologies.Rob Gregory - Director
Having lots of unnecessary dependencies is an indicator of poor software design and can make code hard to work with. It's much easier to understand things when they are represented in isolation.
However even with the aim of creating loosely coupled systems some design decisions are going to introduce dependencies, it happens. It's always worth thinking about whether using 'X' excludes or enables the ability to do something else when determining the best design option.