Is Your Architecture Evolution Friendly?

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

Overall, the session was very informative, useful and something every solution architect could try to put in practice.  Good job Patrick!