Agility and the essence of software architecture
The video from my talk at Craft Conf 2014 in Budapest
I had the pleasure of attending and speaking at the first ever Craft Conference, which took place in Budapest last month. To say that it was an awesome few days is an understatement and, fortunately for those who weren't able to attend, videos of the talks are available to watch online via the Craft Conference website. Here's mine about agility and the essence of software architecture.
If you're interested in other software architecture related talks, I recommend watching Implementing Continuous Delivery: Adjusting your Architecture by Rachel Laycock and Conway's Law and You: How to Organize your Organization for Optimal Development by Michael Feathers. A huge thanks to everybody for a very fun few days in Budapest.
About the author
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.
You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.
Re: Agility and the essence of software architecture
What I was missing, though, was a thourough "manifestation" of Agility in the architecture.
Developers experience Aglility as a different process, I´d say. The process focuses on small increments manufactured in short iterations.
Software architecture in this context then should exhibit two properties:
a. make adhering to the process easy
b. mirror the focus of the approach
To me a. means, software structures need to be malleable, fluid, soft, the opposite of monolithic. Because otherwise the frequent "unforseen", "unplanned" changes cannot be accustomed. Microservice and "component thinking" sure help in this regard. But I don´t believe that´s enough.
That´s why I find b. so important. To me it means, increments should be structural elements of software. Increments should be part of the thinking process of the software architect. They should be tangible for the user/customer as well as for the developers.
If increments get dissolved into a mesh of classes/libraries/components/services then the resulting architecture will be hard to understand. Increments should be first class structural elements of software.
This aspect of Agile Architecture I was missing from your presentation.