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
References
Presentation deck used could be downloaded here.Video of the session is available on Youtube and can be accessed here.
Overall, the session was very informative, useful and something every solution architect could try to put in practice. Good job Patrick!
Leave a Reply