InfoQ Software Architecture & Design Trends 2022

Transcript

Introductions [00:29]

Thomas Betts: Hello, and welcome to a special episode of the InfoQ podcast, because it's time for our annual architectural trends report. I'm Thomas Betts, and joining me today in discussion are InfoQ editors and QCon committee members. First up, Eran Stiller. Can you please introduce yourself?

Eran Stiller: Hi Thomas, hi everyone. My name is Eran Stiller, I'm the Chief Software Architect at badook AI.

Thomas Betts: Next, another editor is Vasco Veloso.

Vasco Veloso: Hello everybody. Yes, I'm Vasco and I'm currently doing software engineering and design at ING Netherlands.

Thomas Betts: And Daniel Bryant will sound familiar to other people on the podcast.

Daniel Bryant: Hi everyone. Daniel Bryant, head of DevRel, previous architect and also a co-host of the podcast too.

Thomas Betts: And joining us from outside InfoQ, but a QCon committee member, Sarah Wells.

Sarah Wells: Hi, yes I'm Sarah, I'm delighted to be here. I am former Tech Director at the Financial Times. I'm currently taking a bit of a break, and about to start writing a book on microservices.

Written Trends Report + Podcast [01:19]

Thomas Betts: Great to introduce everybody. Each year InfoQ editors discuss what have been observing across the entire software development landscape, and we create several trends reports, each with its own graph of the adoption curve. This helps the editorial team focus it's reporting on innovative technologies and ideas, and also provides our readers with a high-level overview of topics they may want to keep an eye on. There are two major components of these reports. The written report is available on the InfoQ website and contains the trends graph and goes into detail on individual items that have been added or changed in the past year. The second part of the report is this podcast, a chance for you to listen in on part of the conversation we've had, and hear some anecdotal examples from our panel of expert practitioners.

Data + Architecture [01:57]

Thomas Betts: So today I'd really like to cover some of the bigger concepts that are not easily expressed with a single line on that trends graph. And the first of those is idea of data plus architecture. We discussed this briefly last year, we added data mesh and data gateways, and the subject of good architecture for data keeps expanding. I was reminded a few months ago, when I interviewed Neil Ford and Mark Richards on the podcast, and Neil said he firmly believes that data plus architecture is going to be one of the major themes over the next few years.

Thomas Betts: Eran, I know one aspect that's really in your wheelhouse with your work at Badook is data quality. Can you give us an overview of how you define data quality, and why it's something that architects are increasingly focusing on?

Eran Stiller: A lot of companies today rely on data for their business. So they collect data from various systems, whether it's external systems like their CRM systems, their ARP systems, or maybe their own system-generated data, or maybe they create IOT devices which send a lot of data, or they use logs. And this really piles up. And typically today we use the data to drive business decisions. So it could start from simple BI tools and dashboards, but it can go all the way up to creating machine learning models and building forecasts and training artificial intelligence models. In some cases, we eventually use these models to make business decisions: To buy something, to offer customers sort of service, and so on. Like in the software world, where if we catch the bugs early it costs less, so we started realizing that's also true in the data space. Because if we have a bug in our data, meaning the data doesn't conform to what we expect, and we only discover it when we made the business decision, six months later, it will cost us a lot of money to fix it.

And so I think today, many companies realize that they need to catch these problems at a much earlier phase of the data pipeline. That phase can be, one of the steps where it can take place, is when they ingest it or when they start working on data and they need to test, like we test our code, they need to test that data conforms to what they expect.

So for example, there's a famous case where there's a US company called Zillow, they're a real estate company, and they wanted to start buying houses and flipping them up and selling them fast to make money. And said, okay, we have a lot of data from users. Those who don't know, they have these online boards where people can look at properties, and they say, okay, we have a lot of data. Let's try and use the data to check where the prices are going to go up. We're going to buy those houses, and then sell them for a profit. But unfortunately, as the time goes, by the reality changed, their data changed. But the model trend hadn't yet updated and they didn't notice it, and they wound up eventually writing off, I think around half a billion dollars and they lost 10% of the company value because of this. It was not that the data was wrong, it's just that the data changed over time and they didn't see it.

I think one last point about this entire area is that today regulators are starting to regulate the use of AI models. So for example, in the European Union, there's now legislation going forward for regulating the use of artificial intelligence models in various, they call it high risk areas, such as health, finance, and so on. And also in the US Congress there is now a bill, it was introduced this year, it's called the Algorithmic Accountability Act. Which says that if you're using artificial intelligence models to decide if you can give a loan to someone, or how you treat someone, you need to be able to explain and be accountable how that model achieved that decision, and what data was that model trained on. So it gives us architects, it puts a lot more responsibility on us to make sure that we're doing the right thing in an area where it's still not common practice. Like in software, we have QA.

Thomas Betts: Yeah. I think that idea of understanding your data and being able to know that it's not the same assumptions you had. And one of the things we've talked about in architecture is it's constantly evolving. And if you don't keep checking your assumptions that they're still valid a year later, or two years later, you can't still use those same models, necessarily. There's also the problems of some of the neural nets, they're like, how did you come up with this model? I don't know, it just did. Being able to trace back is very important.

Eran Stiller: And there are other problems with this area. For example, a lot times there's a bias towards some population. So a lot of times women and minority groups are underrepresented in the test data. And with these bills, with this regulation, we need to start checking that the data actually represents what we expect it to.

Daniel Bryant: I've always got to do book recommendations, and I learned a lot from Cathy O'Neil, Weapons of Math Destruction. I know Charles, a fellow podcaster host, talked about this. And if people want a bit more insight into this space, that book is fantastic. I think Charles even did a podcast with her on InfoQ, and all the things you mentioned, bias, collection of data, totally as an architect, that's got to be on your radar now, right?

Eran Stiller: It could be much simple than that. For example, with one customer we heard that they built a data pipeline, they're training models, and then at a certain point in time, the data that comes in changed. They didn't generate it, it generated on an external source. And what happened is the format of one of the data columns changed, and what that cause further down the line is that their system started thinking that customers were late on their payments and they started acting upon it. It took a team of about 50 people for a month to fix it. Again, this is something if you catch early on, it will have an update to work. There are other tools coming out today to handle these kinds of scenarios. I work for badook AI company and that's one. But also other tools like Great Expectations, DQ. There also tools that work more towards observability side of things. So they run in production related to see that everything works as expecting. I can name Monte Carlo and Bigeye, there are others as well, to look after this space.

I think the key thing here for architects is to think about your data pipeline. Because we often rely on data that comes in, or we generate data out of our systems for data engineers to use, but we never think about making sure that the data conforms to what we expect. Unlike for software engineering, we have QA. For data, we still don't have anything yet. It's a best effort thing. This is an area, especially with the regulations coming in, and they will come in the next few years, this is something that we should really take note and look at the architecture of data pipelines.

Thomas Betts: Daniel also made a comment that the whole idea of data needs beyond the radar of an architect. That's now inside the architect's wheelhouse. It used to be, oh, that's the data engineering team gets to handle that. You have to be involved in those decisions, because the data flows through that whole pipeline, it's part of the whole system and they all integrate together. It's garbage in, garbage out. You have something comes in at one place, it's not going to suddenly resolve itself and get better later on unless you have something to go and check for it.

Thomas Betts: Vasco, did you have something you were about to say earlier?

Vasco Veloso: Actually I was thinking about the whole definition and the whole concept behind data meshes that you have previously described. And when I was hearing that we need to have some sort of quality assurance, like we have for software, also for data, that concept that we can apply this identical rules as we apply today for APIs, for contracts, for actual contract validation is also something that could, well naturally not in every single scenario, but could eventually also be applied to data input. Well, obviously it's going to be easier if it is data being transferred between systems in the same organization, but also from data coming from the outside.

Thomas Betts: And I'm glad you brought up data mesh. It's been on the innovators part of the graph, I think we're going to keep it there, because it really hasn't gotten enough adoption yet. But data mesh, if you read Zhamak's original article, she talks about being a paradigm shift, and that it's a new way of thinking about data. And it's also been described as DDD but for data, and so you organize your teams around these individual data models. To your point, Vasco, the idea of having QA, if the team is responsible for the data, they're the team that knows that data's domain better than anyone else. So rather than slap the QA layer on, or whatever the data quality layer is, across everything and then don't know what you're looking at, you try and make it more focused. So I can see that data quality being part of data mesh working really well together.

Daniel Bryant: I think it's a product mindset as well, right? That's one thing I learned from Zhamak when I did an interview with her a while back, fantastic wide-ranging discussion on the InfoQ podcast. And she was bringing design thinking and product ownership. And I think as architects, now we need to embrace both those things. Like product ownership, we own a platform, we own a data mesh, we own these things and we have that design thinking. We're empathizing with our users. Whether that's internal developers, whether that's external folks. I think empathy is a big thing. And I've got another book drop, Zhamak's got a new book on O'Reilly, I haven't read it yet but I promised you Zhamak I will, if you're listening. By all accounts, it's an amazing book. So if folks are looking to get more into the data mesh concept, that book is a good jumping off point, I think.

Architects & Architecture [11:21]

Thomas Betts: All right, so I'd like to turn the conversation from software architecture to software architects. Now the InfoQ trends graphs are great at tangible things, AsyncAPI, serverless, CQRS, that type of line item. Where I think it's struggled in the past is to highlight how architects do their job, and how architecture happens. So last year we had Architect Elevator because Daniel, you brought it up, Gregor Hohpe's work. The idea of the architect needs to be able to communicate up and down at the different levels of the building. From the boiler room with the engineers, all the way up to the CTO and CEO, and you need to be able to ride that elevator. And before that we had architect as technical leader, which sounds great, but it's kind of vague in what it is. We never moved any of those past the early adopter category. Cause it's kind of that, well, we think people are doing this, but it was a gut instinct. It wasn't necessarily innovative, but it's also not widely adopted, so that's kind of where we stuck it. But that one line on the graph doesn't tell a good story.

So I wanted to keep this open-ended, but I'd like to hear some of the good stories of how are architects changing how we do architecture? How do teams learn architecture? How do you mentor younger up-and-coming developers so they become architects or understand concepts? Is it just the ivory tower architects? Have we completely gone away from that? Lots of different things to go into? So Sarah, I'm going to ask you to start this off.

Sarah Wells: What's interesting for me is that for the last four or five years at the Financial Times, we didn't really have architects as a role. So architecture was a thing you did, along with other things normally, rather than a role that you had. So we went from having a group of architects who would do quite a lot of definition of the way that we should approach stuff, to it being a thing that you did and within your team. And also, as part of that move to having autonomous empowered teams, actually you may not be talking to other people about what their approach to architecture is. So I think there's a couple of challenges with this. One is how do you become a good architect if you're in a team with five or six people and you're not working closely with other people to learn about it? Do you just end up with, everyone has a stab at it in architecture, but really it could be a lot better.

This is similar to how do you do accessibility in every team? How do you do security in every team? You have to have developers with lots of broad skills, but you presumably want to have people with expertise in these areas. And then related to that, separate teams making their own decisions, you're going to lose out on something there. Maybe you're going to solve the same problem in different ways. Maybe you just don't have a consistency in how you're approaching it. So I see it as being quite similar to a challenge that I had in terms of looking at reliability. Which is you're going to want to define, here's a good way to approach this. Maybe here's some tools for how you can do it. I think trying to work out some sort of structure of some guardrails for people in doing architecture. Some support if they need something to be looked at, say is this a sensible approach in our team to architecture? I think that's something that I see as a need because you want your teams to be pretty autonomous.

I don't think that many successful companies have architects in an ivory tower defining here is the database that you can use. But how do you avoid it being actually there are 12 different databases that people are using and some of them aren't the best, they're just the one that the person in the team found. I'm really interested to hear any of your thoughts on this.

Thomas Betts: Anyone else want to jump in? Go ahead.

Vasco Veloso: I can jump in and say that in my opinion, we abuse the term a bit, but let's stick with it. Architecture happens at different levels, and also at different levels of detail, right? And it is also, of course, very much dependent on the organization itself. As organizations grow bigger and bigger and learn that they cannot have 12 different databases in production serving 2,000 applications, then eventually they set standards. So someone at some level is talking within a team with different product owners, with different engineers, from different places in the company, gathering requirements, the whole process, and coming up with a subset of those databases that make sense for the company, and that therefore reduce cognitive load could use maintainability effort.

And then, if we drill down to the team level, we see people doing also a different kind of architecture at a component level. Then we have all those different skills being thrown in together to come up with a good design. Naturally a good team has persons with different maturity levels, and therefore there's always some coaching involved. And in between these two, there can be a myriad of different levels with conversations going up and down. Sometimes the same person going up and down, and sometimes connecting people at different levels.

I have the feeling I'm starting to become extremely vague, but I think that sometimes so is our line of work.

Sarah Wells: I think this is really interesting. Something that I thought of when you were saying that is the need to work out how much the standards are a guide versus a mandate. Because something that I spent the last couple of years working on at the FT was how do we come up with a paved road or a golden path for people in doing work? And I think you have to have a mechanism for people to say, I know that you've decided this is what we use as our document store, but there are good reasons for us not do that. I think as architects, one thing you can do is say, okay, but here's actually all of the things you have to have an answer for if you're going to choose a different data store.

I think that can work really well. But then the next thing that comes in is how do you make sure that people all know that this is even being thought about? How do you make sure that there isn't a team that's actually just gone and used their credit cards to pay for trying out a new piece of software and you're not even aware of it?

Daniel Bryant: It's something I totally struggled with, Sarah, when I was an architect as well. And what has helped me recently is Andrew Harmel-Law. And Thomas, I know you chatted to him recently and he's just fantastic, right? That was a fantastic podcast, by the way, you and Andrew just covered so many things. You said Sarah always struggled with, who do I consult here? Andrew's broad recommend was the folks that are impacted, and the experts. Even in big enterprises, you can kind of make that happen, cause the folks are impacted. You can almost turn something off and see who complains, they're the folks that are going to be impacted. And the experts, if you start going on Slack or Zoom and saying bad things, usually the experts jump in and correct you, right? So you're like, ah, those are my experts, those are my affected people, let's get them in a room or chat to them.

And Andrew did, with the whole blog post he's got on the Martin Fowler blog, just breaks down in detail some of the stuff that I never quite got when I was doing it as a consultant. I think I did a reasonable job, but Andrew and team have really gone into the detail of how you put this together as a process. And that podcast was just an awesome listen.

Sarah Wells: I haven't heard that, I'll have to check that one out.

Eran Stiller: One thing I'd like to add is that someone mentioned earlier the architect in an ivory tower, and I think that if someone thought that this method actually works, I think COVID came in and slapped them in the face. Because once COVID started and we started going to lockdown and remote work, if you were that architect in the ivory tower, you had zero power once that happened. Because you weren't in the room, you weren't in the next room, you could be in another city. And if all the developers in the company had to go to the architect and ask, okay, what do I do now? What do I do next? How do you do this? Then I think there are two options. Either no one did anything because everyone were waiting, or they did something but you just didn't know about it and made bad decisions because you never gave them the tools to make the right decision themselves.

I think one of the key things in this, I call it the distributed era, where we have both the distributed software systems but you have to have distributive teams. One of the key aspects of this distributed era is that as architects we need to find new ways to influence, to guide others. Cause, like Andrew said in his article about the advice process, architecture is being done, and everyone's doing it, and I think it's a fact. It's not just something that we want to do, it's a fact, it's happening. But as architects, we have to figure out how do we drive that towards a place that's good? That aligns everyone with the vision that we as architects want to have for the system, for the company, whatever. And I think in that regard the advice process, also find it's a very fascinating read and I encourage our listeners to go and read it.

But there are also other methods around how to empower others to make the right decision. I think standards is one thing, and they won't work alone because you need to make sure that everyone understands the standards. But there are a lot of methods around it, and I think that as architects this is something that we need to address in our own organizations.

Thomas Betts: I just talked to Andrew, piqued my interest, his idea of having an architecture guild. That's where you go to get the decisions made, that's where you go to discuss the decisions. Using ADRs, or there's some other three-letter acronyms for other terms, but that's the way you capture your decisions, and that anyone can write one of those, In my career, I'd say two thirds of it, there were no architects around. There's always an architecture, it's whether you took the time to think about it beforehand. And I worked on plenty of systems where that was the architecture that we had, because that's what we had, but no one made a conscious decision. It was like, these are the tools we're going to use, because we've always used them, or that's all I know how to use. Whatever it is.

So I think some engineers gravitate towards, I want to make those decisions, I like being in that nebulous area of, I don't understand, there's not one right way to answer this question. Let me figure out what those options are. How do I do trade off analysis? And you said that COVID knocked down the ivory towers, having those get passed down to the individual teams, that people are sometimes forced because they can't just run over and ask the person like, Hey, this is on your shoulders. They now have to make the decision.

Daniel Bryant: Just referring for the listeners, the ADRs you talked about is architecture decision records, right? And Mike Nygard is always my go-to reference, that blog post he wrote about ADRs, awesome.

Thomas Betts: I think that also goes to the idea that, we've talked so much about DevOps, DevOps is not even a thing anymore, it's just kind of assumed. But that was the idea of we're going to break down developer and operations, instead of those two teams where you throw it over the fence and someone else is responsible for operating your software. Are we going to see that architecture is no longer this thing because we're not doing big upfront design and it's not that you have to have these decisions made? Are we going to have, I don't know, DevArchOps? Shove a word in there and we're going to make a new term. But is that the thing, that architecture is now just part of the teams? Sarah, to your point, that's where the architecture is happening. Do we want to call it out and say, Hey, you are also responsible not just for doing software development, but also for doing architecture?

Sarah Wells: I think you have to at least talk about the importance of architecture. You've got to think about how it's functioning and how it meets all of your requirements, and that is architecture. So I do think you expect everyone to do it, but you ought to be able to provide expert input.

Just going back to the ADR idea, something that really worked for us at the Financial Times, and in fact worked better for us once we were all working from home as well, was we introduced this regular meeting called the tech governance group. And the idea was that anything that was going to affect more than just your team, so decisions that would affect everybody in the technology department, or a big decision like we are about to start using a new programming language, something like that. The idea was that you did a one-pager, effectively about what is the need? What have we considered? What is the impact on the cost? It was my colleague, Rob Godfrey, who came up with a format and it worked very well. The aim was that by the time you had the meeting, you'd spoken to all the people who should have had an opinion. So this was definitely a meeting as a sign-off and communication tool, more than the point where you're really discussing it. Forced people to have those conversations and make sure people were happy with it.

Also, it was great for communication, and for teaching people what are the things people consider about architecture? When we started working from home it was always open to everybody, but there's obviously a limit in terms of room size, but we often had 40 or 50 people turn up to it once we were working from home. And that would be a mix of people who were there to comment and had read it and thought about beforehand, and people who were there to learn more about how you make those decisions. And I really like it as an approach.

Thomas Betts: Yeah, I think that's one thing that Andrew mentioned in the article, and then in the podcast, was that architecture guild was one of the most highly attended meetings. That they'd have 80 people in the room because so many people wanted to hear what was being discussed. And anyone who was invited, from junior developers up to the CTO, could sit in there and just get a sense of what's going on.

Architects and Remote Work [23:52]

Thomas Betts: I also think that's a great segue, because I wanted our next topic to cover that subset of how to do architecture, and that's the current state of remote work as it pertains to architects. So it's a subject that we briefly touched on a year ago, and now we just passed a two year anniversary of the COVID pandemic. So we've had a couple years of seeing how teams have adapted, and where we've come out maybe with some better practices.

I personally love to say that every problem is fundamentally a communications problem, and that the main role of an architect comes down to communication. And the pandemic drastically adjusted communication patterns for everyone. So it has to have an impact on architecture decisions and practices.

So that might be a good time to actually call out that on this call right now we're very distributed. We're spanning four countries and I think 18 time zones. So I'd love to hear some personal stories of how architecture has changed for each of you in terms of the things that you've seen in the last year or two. Sarah's example was great, since she just talked, I'm going to say Vasco, why don't you tell us some of the things you've seen. What's gotten better? What's gotten more challenging because of all remote work?

Vasco Veloso: In my personal experience, I can say for sure that the phenomena of knowing that someone with an architect title was nearby actually changed things. Because I can confirm that also in my personal experience, it was no longer possible to just run down to the floor below, pop in a conference room or wherever, and just say, can I have five minutes of your time to just ask this tiny little thing? That is gone, and I fully agree, Thomas, even in the previous section, I think all of us pretty much said that communication is essential. It's communication, communication, communication. And Sarah brought up the feedback loop that is absolutely essential. And we had to adjust.

In the teams I've worked with in the past two years, one thing has been constant is that people not only went remote to their homes in whatever city that the offices were, but many of them took this opportunity to go and meet their families, sometimes time zones apart. So we also had to learn how to deal with that. And I believe that one of the consequences was that decisions were better thought through, they were better communicated and even documented, because people had to actually start writing them, often in emails, for someone that was going to wake up two hours from now. And it also got people in the habit of actually planning discussions on architecture and design. That's what I have seen, indeed.

Daniel Bryant: I'll piggyback on that, if I can, Vasco. Something Sarah said earlier on made me think about it. So I recently read, it's on my shelf here, Working Backwards, looking at the Amazon way of doing things. And Amazon, it's law now, they have a six-pager. Before you go into a meeting, you write a six-pager and you spend the first 10, 20 minutes of the meeting reading the document. And it's legit, I chat to Amazon folks that this happens, but we've started doing very similar, Vasco to your point. And it wasn't even on purpose, sometimes. It was exactly this async challenge of, the company I work at, Ambassador Labs, spans about 12 hours worth of time zones. Someone's going to sleep in India, someone else is picking out some other things, and the west coast of the US.

And we got really good at documenting things, say in Slack, and then we'd send email for certain things, and then Google Docs and we used Notion quite a bit as well. And gradually each tool became used for a certain purpose, if that makes sense. And we do assume that if you're rocking up to a quite complex discussion that yes, we've written the thing, we've circulated that, in Notion for example, we've all added our comments on as well, addressed the obvious comments and then the discussion is there for discussing purely the tricky stuff you can't do async. The stuff where we're going to go toe to toe and have a good discussion around these things. And from chatting to friends, seeing quite a few other companies doing this as well. Some it's been designed, like Amazon famously. And some it's emerged as a best practice. So I recommend reading Working Backwards, it's a fascinating insight. But I can't emphasize enough the value of actually going into a meeting to discuss stuff based on facts that were already established.

Thomas Betts: There was a really good presentation. I think I called it out on one of the previous podcasts, but Qcon Plus last year, on the spectrum of synchronousness. And it talked about, yes we swung the pendulum, we went from everybody's in an office and that's how you get stuff done you just walk down the hall and say, can I have five minutes your time, to I send everything on Slack and email and you're waiting for that asynchronous response. And both of those have advantages, but there's times when you need to meet in the middle and say, hey, what's the right approach for this situation? So asynchronous is great for capturing the decisions, capturing the documentation. But actually having the discussion doesn't work well if everyone's pinging back and forth over 17 emails.

Sarah Wells: I want to jump in there and say something that sounds kind of trivial, but I think is a real issue for me. Which is I really miss being able to stand next to a whiteboard with someone. And I haven't found a solution to that. So any online stuff just doesn't feel as simple. And people have tried various things. One thing that I've seen that actually worked, we had people who would just write something on a sheet of paper and hold it up to the camera. And actually that's quick because you're just writing it. And that whiteboard thing, the best thing about being in front of a whiteboard is it takes seconds to write something up and you can rub it out and put something else on it. I do think that is not as easy with any of the online tools. They all just feel like there's far more friction. So has anyone got better solutions to this?

Eran Stiller: I just want to relate that because I want to turn the spotlight to another area of the distributed work. And that's how do you transfer knowledge between architects and between developers and from architects to developers? And like Sarah said, nothing beats sitting next to a person with a whiteboard and explaining. And also not referring to the framed architecture that you think the system should have, but explain the principles behind them, and why do we want to make the decision?

This is something that every online tool I've used, you just can't beat seeing a person and gesturing with your hands and pointing in a whiteboard. I think this is probably an area that we haven't solved, yet. And I think this also relates to this podcast here about software conferences, and how architecture is continuously evolved through discussions for communication, like Thomas said. And specifically at conferences, you have all the sessions that you go and see, and the knowledge being transferred in a classic manner.

And I think we already solve that part in the online world, even though it is harder. But the thing about conferences that I like, and I think gets a lot of knowledge out, is all the hallway chats and sitting together at lunch and discussing the little problems, real issues. And both at conferences and at work, this is something that's a bit lost right now. It's starting to get back, we have QCon coming up in London finally, but also in other places in the world, we see in-person countries slowly coming back trickling in. I can only hope that this will progress as we continue throughout the year.

Thomas Betts: My last question was going to be who is going to be at QCon London. Because I think this podcast is going to be published the week Qcon London happens, or maybe it'll be right after. So everyone will have a chance to either see you if you're there, or not see you if you weren't there. But I'm guessing Daniel and Sarah you're both in London, so you're the obvious.

Sarah Wells: Yeah, I will be there. I'm hosting a track on microservices. Basically how do you make them successful? Cause I think that it's gone way beyond microservices being a leading edge thing. Now it's like, how do you actually do it properly? So I'm really looking forward to that.

Daniel Bryant: Yeah I'll be there too, covering for InfoQ and meeting folks and looking for people to join on podcast. Sarah's track totally caught my eye, Sarah, so I'm going to be hanging at your track quite a bit.

Sarah Wells: I just designed the track that I want to hear.

Daniel Bryant: That's what you should do. That's perfect.

Sarah Wells: One of the nice things about being a track host.

Thomas Betts: And that's what I liked when I was a track host is what do I want to know about this? And that's what QCon does great, better than the other conferences I've been to, is the emphasis on the hallway track. QCon Plus, of the virtual conferences I've attended, seemed to do that better by having the Zoom session after each talk. So you could still talk to people, it wasn't just six straight hours of talking heads. But I think people are looking forward to getting back because, that's again how the architects like to share the ideas. What are the big things you're thinking about that haven't made it into a blog post somewhere? You haven't read about, oh I'm doing this. That person's one little domain, that's their life. And all of a sudden it seems really, really fascinating. You would never have thought about it if you hadn't bumped into it at a conference.

Sarah Wells: The other point is people don't write blog posts about the things that have been really difficult and they haven't solved yet. But you talk to people about that in the hallway track. And actually that can really spark things off in your head about, oh, okay here's something. People generally don't tend to spend a lot of time talking about things that were a disaster, but they'll share those stories when you're chatting and they're fantastic.

Daniel Bryant: Over an adult beverage or two, Sarah, right?

Sarah Wells: Definitely.

Thomas Betts: I think that's about it for the conversation. As I said in the intro, we tried to keep this discussion to some of the higher level ideas that really benefited from a good conversation. I think it was actually a meta approach that some of the topics we talked about, that architects need to have these conversations sometimes because asynchronous communication isn't enough. We kind of exemplified that. That's also part of this two-part format to the trends report. So there's a lot more to read in the full Software Architecture and Design Trends report which is now available on infoq.com, as are all the past InfoQ trends reports, so be sure to follow the topic "InfoQ Trends Report." Huge thank you to everyone on the panel today. Daniel Bryant, Eran Stiller, Vasco Veloso, and Sarah Wells. It was a really great discussion. I hope you'll join us again soon on another episode of the InfoQ podcast.
 

Mentioned

• 2021 A&D Trends Report https://www.infoq.com/articles/architecture-trends-2022/
• Weapons of Math Destruction, by Cathy O’Neil 
• Data Mesh, by Zhamak Dehghani
• InfoQ Podcast - Neal Ford and Mark Richards - Software Architecture: the Hard Parts
• InfoQ Podcast - The Architecture Advice Process with Andrew Harmel-Law