What is Evolutionary Architecture?
An evolutionary architecture supports incremental, guided change as a first principle along multiple dimensions.
In other words, the architecture accepts technical and domain changes as inevitable and makes it easy to accommodate these changes.
Some notes from the Presentation
- Any product or solution undergoes two types of changes over time
- Technical – due to ever-changing technical landscape
- Domain – due to business needs and market changes
- An essential question to ask => How many cycles (delivery to production) does your architecture support?
- In other words, how many times architectural changes are needed over the life of a product
- Here are some common Architectural models that are used by organizations around the world
- Big ball of mud – Everyone talks to everyone else
- Layered – 3-tier or 4-tier architecture
- Microkernel – Core system extended by plugins or adapters
- Microservices – Loosely coupled services that work with each other
- All these models have some benefits and drawbacks – but they are NOT ideal for change
- Hexagonal Architecture – change friendly
- A variation of Microkernel, but systems are decoupled using Ports and Adapters
- Participating systems use adapters to interact with core model
- This way core changes are kept to minimum and often other parties aren’t impacted
- ESB (Enterprise Service Bus) with smart end-points follow this architectural principle
- Architects must use a principle-driven approach (what to do is decided based on context) rather than rule-driven (what to do is fixed)
- Also, Architects must create self-organized teams who can take minor or internal decisions by themselves
- Architects are enablers and those who see the big picture – like a “town planner”
- Architecture briefings is a nice way to build a collaborative culture
- Some development practices that can further help evolutionary architecture
- Feature toggles
- Continuous delivery
- Architectural spikes
- Cross-functional teams
- Identifying and reviewing fitness functions
- Build vs Buy decision making
- Must consider the functionality required and the ability to change
- For instance, core business/strategic functions change frequently and they are critical for the product. They are better build rather than COTS/customization
Overall, the session was very informative, useful and something every solution architect could try to put in practice. Good job Patrick!