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 are too many unknowns and 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 about 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 it separately?
- What are my options for shifting to a different infrastructure if required?
- Can multiple people work on the architecture collaboratively?
Architecture principles for nimble teams
- 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.
Leave a Reply