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.
Make the best architectural decisions
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.
What is software architecture?
"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".
- Architects face a series of design issues that make up the overall design problem.
- Each issue, no matter how small or big, has several alternative solutions (design options).
- The architect has to choose the best option from available design alternatives to resolve each issue.
Why is architecture important?
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
Magnifica's architecture design process
At Magnifica our process for architecting a software solution follows the process below:
- Collect requirements and constraints (functional/non-functional & cross-cutting concerns)
- Identify design issues
- Identify design options for issues identified
- Select best design options (based on criteria determined by requirements and conversations with stakeholders)
- Breakdown solution into architectural components
- Selection of an architectural solution for each component that matches the best design options.
Example design issue (basic)
The challenge: How to allow a user to register to attend a conference
Design options:
- Manage the full conference registration order in one object that manages both booking validation and order information.
- Separate a conference registration order into two objects 'Order' & 'SpaceAvailability'. The 'SpaceAvailability' object being responsible for managing total spaces reserved/available. This object is called by the Order object.
- Use a process manager to coordinate interactions between the two objects 'Order' & 'SpaceAvailability'.
In this example it was decided to use design option 3 because:
- Following a key design principle 'Separation of concerns', it was thought better to separate basic order information from the allocation of places at the conference.
- A highly weighted criteria was to provide a way to handle the concurrency requirement so the Team decided to use the Reservation Pattern which introduced additional communication between the two objects so it was decided a 'Process manager' should be used to help with this communication.
Making good design decisions - use your knowledge
To make decisions the software architects use two different types of knowledge 'current' and 'past' knowledge. Current knowledge includes:
- the requirements
- design decisions made so far
Past knowledge includes:
- technology available
- experiences of what has worked well and what hasn't on past projects
- industry design principles and best practices
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
Always consider dependencies
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.
