Agile Mindsets: Don't try to get a perfect architecture; Plan to get it wrong

I still find teams that have adopted scrum and other agile practices, but still strive for perfection when trying to conceive architectures and implementation plans. Some will also try to think through every edge case to ensure that designs are fully future-proofed.

This is an unrealistic proposition for most teams and people. There's too many unknowns, too much complexity, and businesses do not give technology times sufficient time to perform exhaustive planning. And as we know, the requirements evolve and new needs materialize.

We're practicing agile to support evolving requirements, yet many want their architectures and technical planning to be prescriptive and comprehensive.

Planning "just enough" architecture

I believe and always subscribed that the art of architecture is not about overly planning. It's the opposite in fact. It's recognizing that you won't achieve a perfect architecture so your planning must focus on the costs and complexities when you get something wrong.

Here are some questions worth answering around your architecture:

  • How easy is it to perform enhancements without re-engineering dependent systems?
  • Are the tools in place to make it easy to refactor?
  • How will you know that the architecture needs to scale, and what will be your scalability options?
  • How easy is it for new, less-skilled developers to work on the architecture?
  • Is it self documenting, or do I have to document separately?
  • What are my options to shift to different infrastructure if required?
  • Can multiple people work on the architecture collaboratively?

This is just a sample of questions, but as you can see, these are more questions about how teams are working and less about how the team develops architectures.  

Architecture principles for nimble teams 

When I think about these questions, it leads to several architecture principles
  • Much less proprietary code - Because more code is hard to refactor and get new developers to maintain. Don't fall into the trap when a developer says that they can code something quickly because it often sacrifices maintainability. 
  • Leverage low code, self-service, and visual programming tools - Especially when it meets 80%+ of primary requirements. 
  • Use modern development practices when you do build - Develop with APIs, object oriented patterns, design principles, and common frameworks.  
  • Invest in automated testing - Which makes it easier to refactor and extend
  • Have at least basic CI/CD and monitoring - So that the development process is efficient and repeatable
  • Leverage containers - So that applications are portable and scalable
  • Design primitive data models - Data lakes versus warehouses, databases with built in data lineage capabilities. Virtualize if you can.
  • Target small and portable - If your team has the technical chops, consider micro-services and serverless architectures.

These are far from complete. What you can see here is a greater focus on picking standard architecture practices like APIs, CI/CD, containers etc. and less on engineering perfect designs. It's a mindset. 

1 comment:

  1. Thannks for such an amazing guidance! Keep sharing more!


Comments on this blog are moderated and we do not accept comments that have links to other websites.


About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld,, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.