Podcasts Technology Thriving Technologist Evolving Software Architecture To Adapt With Product Growth

Evolving Software Architecture To Adapt With Product Growth

Published: July 11, 2017, midnight

Are you making decisions about what technologies and patterns are used in your software product?

Today I\u2019d 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\u2019s famous book \u201cCrossing the Chasm\u201d describes how a product goes through segments of customers along the maturity of a product\u2019s 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\u2019s 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\u2019ve 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\u2019re still crossing the chasm.

It\u2019s 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 \u2013 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 \u201csecret sauce\u201d where your product provides its core value \u2013 but this is what you should probably spend the bulk of your time building \u2013 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\u2019t capitalized on. Emotionally detaching from having to think the architecture is \u201cright\u201d and will \u201cnever change\u201d helps us have the mindset necessary to be more lean in how we develop software.

I\u2019d encourage you to educate stakeholders whenever possible on the realities of the architecture\u2019s suitability for the product at any point along it\u2019s 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\u2019d 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\u2019d 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.

You can also\xa0watch this episode on YouTube.\xa0

Related resources:

\xa0

Visit me at JaymeEdwards.com

Find me on Facebook at JaymeEdwardsMedia

Find me on Twitter as @jaymeedwards