• Skip to primary navigation
  • Skip to content

Breathe Agile

Agility, Cloud and DevOps

  • What is Agility?
  • Agile Library
  • Videos
  • Podcast
  • Roundups
    • Agile Experts
    • Best Books on Agile
    • #Agile2016 Highlights
  • Subscribe
  • About
    • Contact
You are here: Home / Agile Architecture / Is Your Architecture Evolution Friendly?

Is Your Architecture Evolution Friendly?

By Ashwin Chandrasekaran Leave a Comment

Evolutionary Architecture.  That’s the topic of last week’s presentation by Patrick Kua in ThoughtWorks Singapore.  Taking cues from biological evolution, Patrick shared the current state of software architecture and remedies which most of the attendees could relate to.  I am sharing some of those in this post.

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!

Love this post? Please consider sharing it...
  • Facebook
  • Twitter
  • Google+
  • Pinterest
  • LinkedIn
  • StumbleUpon
  • Reddit
  • Buffer
  • Pocket

Related

Filed Under: Agile Architecture

About Ashwin Chandrasekaran

Written by Ashwin Chandrasekaran, author, and founder at Breathe Agile. For any queries, comments or suggestions, drop a note to [email protected]

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Copyright © Breathe Agile 2019. Powered by Wordpress.