Back to the list

If you're rushing to build an MVP, don't put architecture at risk.

Agile development and DevOps processes are popular right now. Most well-run development organizations appear to have or are working to incorporate these processes into their culture. One guiding principle unites all Agile development processes: incremental software development. In their most basic form, agile methodologies focus on developing an MVP that will meet the needs of your business. 



In response to feedback and experience, you incrementally and iteratively add new features and/or capabilities, occasionally removing code and rewriting it, to eventually grow the product into what you require it to be. The goal is to build the best product for the least amount of money possible, which can only be determined through trial and error and experience. The rapid and simple integration of new features and products into a release-ready state is encouraged by DevOps methodologies, on the other hand. Using methods of continuous integration and continuous deployment (CI/CD), these new capabilities can be rapidly deployed for customer use. In conjunction with one another, DevOps processes and Agile development can result in a significantly shorter time between making changes to your software and receiving customer feedback on those changes. This gives you the ability to fine-tune and adjust your application as necessary to meet the needs of your users. Using this approach has improved the quality of customer experiences available in products while simultaneously revolutionizing a company's ability to quickly adjust and pivot in response to changing market demands. This strategy, however, has a flaw.


Architecture is falling out of favor.


Unfortunately, when you build your product "incrementally", solid product architecture is frequently overlooked. An MVP is built as quickly as possible, with improvements made only as needed to add the necessary incremental capabilities. A strong systemic architecture has been lost. A solid systemic architecture directs your product development and ensures that core, fundamental issues such as resiliency and scalability are taken into consideration throughout the process. Every change makes your system more difficult to support, expand, and scale as your needs grow without a solid systemic architecture. 


Creating an MVP is an important strategy for creating the right product, and incremental development and deployment are essential for quickly incorporating customer feedback into the development process. However, simply using DevOps processes and Agile to build a product can result in a large backlog of technical debt. Although you may see immediate benefits, the long-term costs can be staggering. As a result, even if you are building a product incrementally, it's critical to maintain focus on overall architecture strategy and understand how the decisions you make now will impact that strategy. It's possible and reasonable to take shortcuts for the sake of convenience, but you must have the knowledge and understanding to realise what the true cost of those shortcuts is, when the cost must be paid, and how the cost will be paid as you progress. That's only possible if you begin with a strong architectural focus and continuously consider and comprehend the long-term architectural impact of your decisions. 


Keep a long-term perspective. 


How will you do it? Even if you are only building an MVP, having someone on the team who "owns" the overall systemic architectural vision of the product is the simplest way. This professional should be kept apart from the Agile process. Their long-term vision of what you want to build must be developed and maintained. While the rest of the team adapts and adjusts the product quickly, this professional must think longer term to ensure that the development team's short-term decisions do not result in unacceptably high long-term costs. This vision can and should evolve to meet the company's changing business needs over time, but it should do so at a much slower pace than the rest of your development team.