Newer / Older

Don’t Put Architecture at Risk in Rush to Build a Minimum Viable Product

By Lee Atchison | March 30, 2022 | App Architectures | Architecture

Agile development and DevOps processes are in vogue now. It seems that most well-run development organizations either already have these processes ingrained in their culture, or are striving to.

No matter which Agile development process you use, they all have one guiding principle: incremental software development. In its simplest form, Agile methodologies focus on  building the minimum viable product that will solve your business’s needs. Then, based on feedback and experience, you incrementally and iteratively add new features and/or capabilities, sometimes throwing out code and rebuilding it, to eventually grow the product into what you need it to be. The intent is to make sure that the product you build is the right product with the least investment, which can only be determined through trial, error, and experience.

In the meantime, DevOps methodologies encourage the quick and easy integration of new features and products into a release-ready state. These new capabilities can be deployed for a customer’s use very quickly using continuous integration and continuous deployment (CI/CD) methods.

Practiced together, Agile development and DevOps processes can give you an incredibly quick feedback cycle between making changes to your software and getting customer feedback on those changes. This allows you to tune and adjust your application as needed to meet customer needs.

This approach has improved the quality of customer experiences available in products, while revolutionizing the ability of a company to adjust and pivot quickly to address dynamic market demands. However, there’s a problem with this approach.

Architecture gets lost

Unfortunately, when you “incrementally” build your product, solid product architecture often gets lost. The minimum viable product is thrown together as quickly as possible, and improvements are only made as needed to add the incremental capabilities required.

What is lost is a solid systemic architecture. A solid systemic architecture helps guide your product development and ensures that core, fundamental issues are considered, such as resiliency and scalability. Without a solid systemic architecture, every change makes your system harder to support, harder to expand, and less capable as your needs grow.

While building a minimum viable product is an important strategy in making the right product, and incremental development/deployment is critical to getting customer feedback quickly into the development process, just using Agile and DevOps processes to build your product can very quickly create a large backlog of technical debt. You may get short-term benefits, but the long-term costs can be astronomical.

For this reason, it’s important to stay focused on an overall architecture strategy for your product, even if you are building your product incrementally, and to understand how the decisions you make now will impact that strategy. It is possible and reasonable to make shortcuts in the name of expediency, but you must have the knowledge and understanding to know what the real cost of those shortcuts are, when the cost must be paid, and how you will pay the cost as you move forward. You can only do that if you have a strong architectural focus from the beginning, and consider and understand the long-term architectural impact of your decisions as you go.

Maintain a long-term vision

How can you accomplish this? The easiest way is to make sure you have someone on the team whose job it is to “own” the overall systemic architectural vision of the product, even when you are building only a minimum viable product. This person should be outside of the Agile process. They must create and maintain a long-term vision of what you want to build. While the rest of the team quickly adapts and adjusts the product itself, this person must think longer term and make sure the short-term decisions the development team makes don’t create unacceptably high long-term costs.

This vision can and should adjust, as time goes on, to the changing business needs of the company, but this adjustment in general should be substantially slower than the quick and Agile process used by the rest of your development team.

More articles by Lee Atchison:

 

Image by PublicDomainPictures from Pixabay.