In this interview, Neal Ford, a director and software architect at ThoughtWorks, explains why software architecture has traditionally been so difficult to change later on in the process and how you can adapt your modern architecture to be much more evolvable.
Josiah Renaudin: Welcome back to another TechWell interview. Today I am joined by Neal Ford, a director and software architect at ThoughtWorks, as well as a keynote speaker at this year's Agile, Better Software & DevOps West conference. Neal, thank you so much for joining us today.
Neal Ford: My pleasure.
Josiah Renaudin: Before we actually get into the keynote, can you tell us a bit about your experience in the industry?
Neal Ford: Yes, so most of my professional work now is sort of in the intersection of software architecture and the engineering practices espoused by things like continuous delivery, which includes all the DevOps revolution. I've been a software architect for twenty-ish years or so in various different aspects of the role, and I also work closely with the publisher O'Reilly. I'm sort of the mascot for their software architecture series, kind of subject matter expert that advises them on software architecture titles.
So I've been sort of immersed in the software architecture world for a while, and I'm just finishing up a book on building evolutionary architectures, which is also in that realm.
Josiah Renaudin: And so much of your keynote is about software architecture. It kind of covers the different aspects of it. So for you to kind of kick things off here, why has software architecture traditionally been so difficult to change later on in the process?
Neal Ford: Well, a bunch of reasons go into that, and we touch on a few of those in the book. But one of the reasons was that was never a big motivation for software. That was one of the important kind of "-ilities" that you wanted to support, which is "evolveability." So, when you think about software architecture, you're thinking about implementing both the requirements from a business or domain standpoint but also all of these architectural characteristics, what architects frequently refer to as the "-ilities," like scalability and resiliency and security and all those meta-characteristics of architecture.
And traditionally it's been really hard to build, for example, say, an architecture that you plan to be scalable. It's really hard to evolve that architecture and maintain that scalability. And so, one of the things that we're touching on in both the keynote that I'm going to do and then our book, is how can you build an architectural system in software but make sure that the characteristics you chose that architecture software for don't degrade over time. It turns out that's the same problem as, how can I freely make changes to this architecture over time and make sure that I'm not degrading some aspect the architecture's idea?
Josiah Renaudin: Yeah, and let's dig a little bit more into evolvability, because that's a word that stuck out when I read through your abstract. Can you kind of touch on a few ways you can build evolvability in your architecture, ways that you can build something that allows you to change and advance your architecture over time?
Neal Ford: Sure. That's the essence of what we're talking about with an evolvable architecture, is one that you can make changes to over time without damaging their architecture or degrading it somehow and not adding a lot of technical debt to the architecture as well, as you make changes to it over time. For a long time, the actual kind of tongue-in-cheek definition of software architecture was "the stuff that's hard to change later."
Then over the last four or five years, we've seen a big interest in this microservice style of architecture, and the idea of easy changeability is actually built into the architecture as a first-class concern, and we realized, hey, if you build changeability into the architecture, it's suddenly not so difficult anymore.