Roof plan of the Paris Opera's Palais Garnier
Roof plan of the Paris Opera's Palais Garnier (source: Charles Garnier, architect).

In this episode of the Radar Podcast, O’Reilly’s Mac Slocum sits down with Neal Ford, a software architect and meme wrangler at ThoughtWorks, to talk about the changing role of software architects. They met up at our recent Software Architecture Conference in Boston — if you missed the event, you can sign up to be notified when the Complete Video Compilation of all sessions and talks is available.

Slocum started the conversation with the basics: what, exactly, does a software architect do. Ford noted that there’s not a straightforward answer, but that the role really is a “pastiche” of development, soft skills and negotiation, and solving business domain problems. He acknowledged that the role historically has been negatively perceived as a non-coding, post-useful, ivory tower deep thinker, but noted that has been changing over the past five to 10 years as the role has evolved into real-world problem solving, as opposed to operating in abstractions:

“One of the problems in software, I think, is that you build everything on towers of abstractions, and so it’s very easy to get to the point where all you’re doing is playing with abstractions, and you don’t reify that back to the real world, and I think that’s the danger of this kind of ivory-tower architect. When you start looking at things like continuous delivery and continuous deployment, you have to take those operational concerns into account, and I think that is making the role of architect a lot more relevant now, because they are becoming much more involved in the entire software development ecosystem, not just the front edge of it.”

Ford noted the growing relationship between software architecture and DevOps. The interdependence of the two disciplines is evident within Ford’s company: “One of the things that we’re really adamant about now,” he said, “is that someone from DevOps and operations should be a full-time member of a software development team … you cut way down on churn and other sorts of useless engineering activities.” Ford elaborated on how the “DevOps revolution” is informing the software architecture space:

“It used to be that those [DevOps and software architecture] were completely separate roles that almost never communicated with one another, lived in different silos within big enterprises. But we realized that’s kind of a naive perspective now, because things happen in operations that have an impact on architectural design. If some service pack comes out for a production operating system that is incompatible with the way you’ve written your code, that’s a feedback loop you need to be aware of as quickly as possible.

“Really, the DevOps revolution has taught us that architects need to be really up front about their concerns, about what is it going to take to make this architecture work in an operational space. That’s one of the reasons why there’s so much interest now in this microservice style of architecture, which is really the first post-DevOps revolution architecture — so, the first architecture that really fully embraces all the things that you need to operationalize at architecture as well.

“For a long time, the defining characteristic of architecture and software was, it’s hard to make changes to it. You had to make the right decisions up front because the cost was so high to make changes. If you look at the microservice-style architecture, change is built into the architecture because you have taken care of all the operational concerns at that really encapsulated level, at the microservice level, you can change those things out with relative ease.

“Now, suddenly, architecture is not the thing that makes change difficult. It’s an evolved way of thinking about architecture. I think that all architectures going forward are going to have to think about all those operational concerns, and really take that feedback loop into account, but microservices just happened to be the first one that nailed that.”

The influence of microservices in the software architecture space extends well beyond facilitating change. Ford notes that not only is it also helping to define and add promise to the software architect job, it’s exploding application architecture into integration architecture:

“What microservices is doing is making people realize what the software architect’s job is, because they’re the ones who ultimately have to figure out how to get these services to collaborate with one another. Another side effect of microservices is, it takes application architecture and explodes it into integration architecture. So, now there are a lot of architectural concerns about how things work that you really have to take into account to make sure things work correctly.

“It makes the software architecture job more interesting because it has to take a lot more into consideration now. There are more moving parts, and the interactions between the moving parts are complex. There are a lot of engineering practices in that space, like consumer driven contracts is a good example of an engineering practice that allows individual services to evolve at their own rate, but do not break the integration points that they’ve agreed on. There’s a lot of those kind of concerns that now move to the forefront in the role of software development, and the architect is kind of the chief of that, it’s just adding more promise to that role.”

Also in this Radar Podcast episode:

Following Ford’s interview, we have Three Questions with Sarah Novotny, an evangelist and community leader at NGINX. Novotny talks about why microservices is more than just buzzword bingo, how software architecture and DevOps is converging, and why she’s paying close attention to Elasticsearch and Docker.

You can listen to the podcast in the player embedded above or download it through TuneIn, SoundCloud, or iTunes.

Cropped image on article and category pages by seier+seier on Flickr, used under a Creative Commons license.

Article image: Roof plan of the Paris Opera's Palais Garnier (source: Charles Garnier, architect).