Evolving Software Architecture To Adapt With Product Growth
Lean Startup • Software Architecture
Evolving software architecture to adapt to product growth helps you deliver faster and refactor easier as the project progresses.
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
Are you making decisions about what technologies and patterns are used in your software product?
Today I’d like to talk about some considerations you may wish to entertain when you select technology for use on a product being delivered to customers with software. Evolving software architecture to adapt to product growth can help your team deliver faster and accommodate refactoring needs easier as the project progresses.
We should determine how mature our product is in the market first. Geoffrey Moore’s famous book “Crossing the Chasm” describes how a product goes through segments of customers along the maturity of a product’s timeline in the market. In this video I talk about how to change the software architecture depending on where you are along that timeline as you chase market fit.
Are you selecting technologies that are appropriate for how mature the product is? If you have team members who’s only work experience was on more mature products, they may need help with making technology decisions that are simpler and support the speed of change necessary for a less-established, exploratory product.
If we select a comprehensive, full stack set of technologies for our minimum viable product (MVP), we can be susceptible to over-architecting. We can never make perfect decisions, but I recommend considering the maturity of your product in the market, and if choosing simpler architectural patterns and technologies might be better.
Once a product has growth needs, the business should be profitable enough, with enough additional revenue, that updating the architecture to meet the new growth needs can be afforded. This takes pressure off the team early on as they are able to product changes for early customers to validate business ideas quicker.
We should also consider the skill level of our team members, and whether they’ve mastered the foundational technologies upon which pattern and stack decisions are based. If a team is especially proficient choosing a more comprehensive stack may be appropriate.
If not, it may make more sense to select the minimum viable set of components needed to simply produce changes to get that market feedback as you’re still crossing the chasm.
It’s worth considering whether to innovate with our own frameworks or libraries when we select technologies for a project and how their patterns might benefit the software architecture. If we go this route, we should consider whether we really have the time and support from the business to train people on it, document it appropriately, and provide support for it.
We might consider spending more time fully researching all available options for existing components and frameworks that meet the needs of the product first before innovating ourselves. Whether using nodejs, C#, Java, python, ruby – or any other core language, there are a huge number of available packages on the community to implement most concerns of a modern architecture. The exceptions to this are the “secret sauce” where your product provides its core value – but this is what you should probably spend the bulk of your time building – NOT architectural building blocks.
You might consider resisting the temptation to select patterns and technologies that allow for future flexibility until you actually need them if ANY additional complexity is necessary to do so. Though this leaves you up to the chance to need to refactor at a later date, it also eliminates any waste spent supporting possible needs down the road that aren’t capitalized on. Emotionally detaching from having to think the architecture is “right” and will “never change” helps us have the mindset necessary to be more lean in how we develop software.
I’d encourage you to educate stakeholders whenever possible on the realities of the architecture’s suitability for the product at any point along it’s market adoption curve. When businesses understand the implications, they are often very supportive, and will feel less frustrated when changes to the architecture are recommended by the team at a future time.
Simple Strategies For Identifying When To Evolve
So if we know evolving software architecture allows us to gain efficiency by being deliberate about it, how do we know when to actually make changes?
The first thing I’d recommend is to bake monitoring of components and infrastructure into the development process. Whenever a change or feature is being designed, think about how to monitor its performance and anything else about it that might indicate a need to change the architecture.
The second thing I’d recommend is to monitor the throughput of the team, and watch for any fluctuations. Though a team delivering slower than they had before can be for a variety of reasons (most often technical debt), it can also signal a need to make revisions to the architecture.
Resources
- Software Estimation – Trading Perceived Effort for Outcomes
- Scrum vs Kanban – How Do They Help You Be More Lean in 2017?
- Minimum Viable Product – Letting Software Customers Help You Profit
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.