Transcript

Thomas Betts: Hello. Thank you for joining us for another episode of the InfoQ Podcast. I'm Thomas Betts, co-host of the podcast, lead editor for architecture and design at InfoQ, and a senior principal software engineer at Blackbaud. Today, I'm speaking with Neal Ford and Mark Richards, two of the coauthors of the upcoming book Architecture: the Hard Parts. In addition to teaching an O'Reilly training course by the same name, you may know Neal and Mark for their earlier books, including Fundamentals of Software Architecture. I'm looking forward to finding out why they think architecture is so hard and how we can make it easier. Neal and Mark, welcome to the InfoQ Podcast.

Neal Ford: Thank you. Good morning, where we are as we're making this recording. This is Neal. So, you will associate this voice with my name and if you could see me, you would also associate the color red with my name for reasons. If you see any of my headshot, you will understand.

Mark Richards: And my name is Mark Richards, and you'll recognize me because I don't have an accent, different from Neal.

Thomas Betts: Again, your book is titled Software Architecture: the Hard Parts. So, why is software architecture so hard? Has it always been hard or did the hard parts of architecture show up when distributed systems became common? And it's just evolved over time.

Neal Ford: Well, we both have reasons why we ended up with this book, but you mentioned our previous book Fundamentals of Software Architecture. As we were writing that book, that was actually a multi-year process because we didn't really know, when we started, what would go into a Fundamentals of Software Architecture book because it's such a broad field with so many facets and part of the process was narrowing down, what do you really need to know from a fundamental standpoint versus all the immense extraneous information there is out in the world about software architecture. And so, as we were building that book, we would run across problems where it's like, "Okay, there's a lot of nuance there and a whole lot of different things that need to be addressed." And that's just too much for a fundamentals book because it's going to make the fundamentals book way too long.

And so, we kind of put those over into a pile that we started calling the hard parts. And early in the fundamentals process, we actually realized – it was Mark's inspiration, actually – that, "Hey, our next book should be called Architecture: the Hard Parts, because we've got all these examples of hard stuff." And so, when we finished the fundamentals book, we went and started addressing that pile of difficult things and not all those things made it into Software Architecture: the Hard Parts, but it allowed us to see, "Okay, what are the really difficult things that people are struggling with in distributed architectures?" And you build a big enough set of those things and start doing pattern matching across them. And you see things like, well, one of the great revelations of microservices and moving data into the service boundary, but that also means transactionality is part of architecture decisions now and can't be relegated to the database.

And when you mix that in with communication and all the other factors, it makes it a really difficult decision. Granularity is another really difficult decision. So, the hard parts book became rather than a giant catalog of difficult things, rather, how do you do trade-off analysis when you're faced with a difficult problem, because they seem to never go away. When you're faced with a difficult problem, how do you do trade-off analysis? And we used a lot of these difficult problems we've identified to illustrate the ways to do trade-off analysis.

Mark Richards: As a matter of fact, it's interesting. We kind of gave somewhat of a hint in terms of why architecture is so hard in our first book, then because Neal and I coined two laws of software architecture in the Fundamentals of Software Architecture book. And that first law of software architecture is that everything in software architecture is a trade-off. And in fact, at least in my humble opinion, that's really what makes software architecture so hard. You can't Google your answers and identifying what the trade-offs are and then correspondingly analyzing those trade-offs is rather difficult. And as Neal said, there were a lot of parts within our first book, the Fundamentals of Software Architecture that we actually deferred over to this book because we realized we wanted to go so deep on some of these things that that would have been, what do you think Neal, maybe a thousand page book?

Neal Ford: Oh, easily. Yeah, or more. I mean, just think about how much communication stuff on microservices. If we'd included all that in the fundamentals book, it would have been at least another 200, 300 pages.

Mark Richards: But this book allowed us to actually go deep on various hard decisions. As Neal said. Things about workflow, choreography, orchestration, contracts, service granularity, breaking apart data, assigning bounded context. These are all really hard aspects of software architecture. The reason they're hard is because of all the trade-offs associated with these questions. And so, that was really kind of the real premise of what makes the software architecture so difficult.

Thomas Betts: Yeah. I think it's somewhat of a joke, but it's very true that every architect's favorite words are, "it depends." And the challenge is always figuring out, well, it depends on what. What does it take to make this decision and trade-offs always surface and it's not as simple as, I can go to school and learn how to write an algorithm. And it's not a typical CS level problem. It is looking at your domain, understanding different viewpoints, taking all that in. So, how do you handle the communication? So, when you do have different viewpoints and you're gathering all that information, how do you take in the different things that help you make the decision? Who do you talk to? What do you look at? Do you look at the code itself? Do you look at the design? Do you look at what's around you? What all factors into making those trade-off decisions?

Mark Richards: Most trade-offs, again, Neal and I try to avoid the word always and never, but most trade-offs involve what we call architectural characteristics. As a matter of fact, I usually maintain... By the way, architectural characteristics are like those -ilities – scalability, performance – those characteristics that are orthogonal to the actual domain functionality. And it's my belief that, well, I'll go out on a limb and say, "You can't make an architectural decision without knowing those architectural characteristics." In most cases, those characteristics that we extract from the business, from business stakeholders, from product owners, from the domain itself, and then validate those with stakeholders really form the basis and the grounding for making a decision. But it's a two-step process though, because it's knowing what those characteristics are.

Let's say that we have to achieve certain levels of scalability and elasticity, and those are the most important things that we have in our application that we need to address. That's one half of it. The other half is really identifying what the trade-offs are of a given situation. And once you identify those trade-offs and you see the pros and cons, the next step is to say, "Well, okay, I see those, but now, how do I make a decision between those?" And it really is those foundational aspects of architecture characteristics that help make the trade-off decision.

Neal Ford: Yeah. To Mark's point, those are necessary but not complete, because you also have to think about domain and operational and all the security, et cetera. But architects are often the only ones who really focus on those nonfunctional requirements or architectural characteristics. So, those are the bread and butter of trade-off analysis for architects. But you made an interesting point in your question. And in fact, one of the things we've struggled with for a long time is how do we define a software architecture decision versus a design decision. And we actually think we have done that by just this idea that everything in software architecture is a trade-off because architecture decisions are ones that have significant trade-offs on all attached to each one of the decisions. In other words, there are no easy decisions in software architecture, which is where "it depends" comes from and why software architects are often so grumpy, because we don't have the luxury of living in a binary world where we can fight senseless battles about IDEs versus editors versus which message platform is the best one, because our attitude about everything is it depends.

It's a bunch of trade-offs, but directly to your question that you ask, how do you find those trade-offs that Mark was talking about? Well, one of the things that we do and show a lot of illustrations of this, one of the things that we're trying to encourage is to think about very simple definitions of fundamental architectural concepts and not get tangled up too much in design. Every architecture diagram I see in my client work is drowning in design details, so that it's hard to see the fundamentals of the architecture underneath. And so, one of the things that we're doing is trying to pick very, very simple definitions for things in our book that you could describe to your grandmother and she would understand. For example, our definition of coupling. You literally could, and people have written entire books about software architecture coupling, but this is only one small facet of our book. And so, our definition of coupling is I'm coupled to something, if that thing changes, if I might have to change because of that, we are coupled to one another. As simple as can be, but then, that is a good definition of coupling.

So now, I need to make a trade-off decision in architecture. I want to see how two things are coupled together. Mark mentioned scalability and security for example. Let's see if I change one of those. Does it affect the other? If it does, they are coupled together and they are part of my trade-off analysis. So, the first thing you have to do to identify trade-offs is find what the relevant dimensions are and each one of those are things that may have an impact on the other dimensions where architecture characteristics of a domain are important. But it's important to identify those things because only when you can create that kind of multidimensional space where you can analyze qualitatively, because it's very hard to do quantitatively. Can I qualitatively measure? If we greatly increase scalability here, what impact will that have on these four or five different aspects of our architecture? And now, I can actually do some reasonable objective-ish trade-off analysis.

Mark Richards: And to further Neal's point, there's something very important in what Neal just said. And that is we may collect all of the important architecture characteristics that form those trade-offs, but it's not as simple as that because a lot of the architectural characteristics are opposing forces. And a good example is just what Neal said, security and performance. In general, the more secure we make systems, the less performant they are and vice versa. The less security, the more performance we get. And that's mostly due to that security latency of going out to a provider, generating tokens, et cetera. So, here's the problem. Both are important. And this is what makes architecture hard. Both are important to the stakeholders in this application. And so, it's not as clear cut to say, "Oh, well, we have a now a trade-off. Do we make this higher performance or higher security?" And this come back finally to your question, actually, Thomas, is this involves a really tight collaboration with the business stakeholder, the product owner, the business owner, who's responsible for this application or this system, because the architect can't generally make that choice.

And this becomes difficult. And one are the roles of an architect is to be able to analyze those trade-offs to bring those trade-offs more to a business question to that stakeholder, rather than a technical question to the stakeholder. And this is rather challenging, as a matter of fact, in our book, Software Architecture: the Hard Parts, and we draw out a lot of scenarios, which I'm sure Neal is going to talk about in a little bit. And through those real-world examples, we actually show ways of really bringing those technical trade-offs to more business-related trade-offs that a product owner can say, is it more important that we be able to always accept a credit application regardless, or that the credit application process is guaranteed to be started, pick one. And boiling it down to that is really one of those roles of an architect in analyzing all of these trade-offs..

Neal Ford: Yeah, one of the points that we make early in the book is something that a quote is actually attributed to Mark, which is software architectures and the stuff, you can't Google. Because as developers, that's one of those skills that you hone, is your ability to Google for solutions to things. And chances are pretty good that somebody has written a reasonably good post or some combination of posts. You can kind of piece together and solve some sort of problem. But the problem with any kind of generic solution in architecture is that there are no generic architectures. Every architecture is this magical snowflake of choices we like, and choices we don't like, and legacy crap, and stuff that we are still having to use and all the awful stuff. And what are the chances somebody else in the world has that exact same architecture?

So, it's really important to understand the forces at work within your organization. And so, Googling for advice and giving generic advice. So, we're very careful not to try to give generic advice in architecture. This is why we avoid always and never because it's always "it depends" because there are so many different unique facets to every bit of architecture you see. To that end, one of the things that we did in our book is we realized that talking about architecture in the abstract, you have to do that if you want to try to describe problems. But we also built a very extensive set of examples throughout the book. And this was actually based on the O'Reilly class that we've been doing called Software Architecture: the Hard Part scenarios, where we invent this little organization called the Sysops Squad. And they have a big architecture problem that we present at the beginning part of the book.

And as we describe things in the book, we talk about how that general problem in architecture will apply specifically to Sysops Squad and their ecosystem. And so, this gives us a way to make concrete some of these architecture ideas that because they're generic, we can't make them concrete for everybody, but we can for very specific cases. And so, doing the O'Reilly class was actually nice because it allowed us to iterate through a lot of these examples and build finer examples of them. And of course, the interesting challenge when writing the book is we actually had to write dialogue, which is not something that we are normally used to doing, but we did. And so, the Sysops Squad permeates the entire book and has some interesting side effects along the way.

Thomas Betts: That's interesting because I think, you said, it's not something you can Google. Software architecture is saying you just kind of learn. And I think, there's also a little bit that, like what's the career path for a lot of people go from being an engineer to a senior engineer and some people have an interest in architecture or become the accidental architect because someone has to make the decision. You always have an architecture. It's whether you actually consciously make the decision. So, whether you look at the trade-offs and decide what to do, or you just accept, here's what we ended up with. So, I was wondering about how do you train someone to be an architect and learning, like take this generic scenario, use it in this specific example, model through it, seems like a good way to teach the concepts of how do you evaluate the trade-offs and come up with a decision for that case.

Mark Richards: Actually, Thomas, it really is. There are two main facets to learning or starting to become a software architect. And that, first aspect is, in fact, learning to do trade-off analysis. This is what I call architectural thinking. It's thinking with an architect's eye, an architect's point of view, and even as a developer, senior developer, tech lead, it really doesn't matter the role. But starting to identify trade-offs, really understanding those characteristics and being able to effectively analyze the trade-off, therefore removing opinion, or feel like, "This feels right," or, "It's my opinion that Kafka is a better solution here." It removes that subjectivity and allows you to really start seeing that kind of thinking as an architect. But this also has a second aspect to it, and that also is gaining that technical breadth of knowledge.

Developers have very high technical depth, and that's an incredible amount of expertise in a small segments of technology platforms, languages, tools, et cetera. The other aspect of architectural thinking is to maintain some level of technical depth and expertise in something, but to rather broaden your technical knowledge to stuff that you know, you really don't know. And those two are really key aspects that are part of being on that architect track, really.

Neal Ford: And related to your first question, it's really key, I think, for architects to stop being evangelists for things. A lot of tech leads and developers love to evangelize things. And there are little mini cults that grew up within the technology world around technologies or approaches or whatever. I try to instruct young architects that your job is not to find silver bullets because they just don't exist and you waste a lot of time trying to chase them. Your job instead, because everything's trade-off, so your job as an architect is, when presented with a novel situation and the asterisk says, pretty much every situation is a novel situation. Your job is can I identify the trade-offs and give objective trade-off analysis for either side, not provide silver bullets. If a tech leader, developer or another architect brings me a solution that's all pros, I push back and say, "Oh, so this is perfect. Wow, you've done it. You found the perfect solution. That's awesome."

But then, you say, "Okay, where are the cons?" And another important aspect of that, that Mark touched on is you will occasionally, as an architect, have someone try to force you into evangelizing the other side of the thing they're promoting. This happened recently on a project I was on where someone was heavily promoting this one approach and they were trying to force me to pick up the other side. And I refused to do that. I said, "No, neither of these is perfect. Let's do a real trade-off analysis, and it turned out that what they were doing was kind of disregarding the bad parts and over-amplifying the good parts. And of course, when you start pointing that out, then it becomes much more obvious that this is a nuanced decision that you have to put some effort into coming up with the trade-offs and making the decision, but then, documenting that. And then moving forward, knowing that you've put those constraints in place purposefully, and then, being able to address them in the future if you need to.

Thomas Betts: The last point you made was documenting your decisions. So, we started talking about taking in all the stakeholder viewpoints, analyzing like what's important to the business and being able to present to them. It's like, here's the scenario. You have to choose between these two, which is more important for the scenario. When you get down to making the decision, how do you document it? How do you present it to the design teams, the other stakeholders to say, "I want you to go forth and follow this pattern. These are the decisions we've made." What do you use? You mentioned diagrams that sometimes get too into the technical design and get cluttered up and they lose that clarity of what the architectural decision was.

Mark Richards: This actually, Thomas, points to our second law of software architecture that we coined in our book, which is that why is more important than how. As Neal mentioned, we can have diagrams and stuff and those diagrams show me how something works, but I don't understand why you made that decision. And so, when talk about architecture decisions, there's really three aspects that need to be recorded and documented. It's certainly decision itself, but also the justifications of that decision. This was my epiphany back in 2011. As a matter of fact, as an architect was I found I was focusing so much on how things work that I realized it was something missing. And that missing piece was wait, I can look at an architecture diagram and it doesn't take much to understand what you're trying to convey, but why didn't you do it this way?

Why did you have these two services communicate through async that looks like that should be synchronous? Why did you choose to break up this database right here because it looks like it should be one? I'm not understanding why you did that. So, the justifications are the second piece and in addition to the actual decision, but then, there's a third aspect and that's the consequences, coupled with the trade-off analysis. You see, all these conversations happen behind the scenes. I may make a decision or propose a decision. I may have a meeting with several business stakeholders or the product owner. We discussed the trade-offs back and forth and weigh those trade-offs and make a decision. But when I make a certain decision based on trade-offs, there's other trade-offs that, well, are trade-offs. And so, the point is no one else is familiar with those conversations except myself and maybe the product owner.

And so, documenting that trade-off analysis is another aspect of the why, but also the consequences, which matched those pretty well. If we choose performance over security for a certain aspect of the processing flow, that will get challenged and because people will say, "Yeah, but this area here is unsecure now." And that's really important. Having those three pieces collectively in a document is really necessary in order to fully complete an architecture decision. And that's where both Neal and I use architecture decision records, ADRs, to really gather all of that information into one collective, cohesive, short document.

Neal Ford: Yeah, We talked about ADRs in our fundamentals book, but I was talking about the Sysops Squad stories and Architecture: the Hard Parts. Every Sysops Squad story ends with an ADR because there are all these conversations about how do we make this decision or architecture and discovering and discussing the trade-offs, and they all end with an ADR because you want to document that context. This is one of those things that, I think, a lot of architects have a little bit of blind spot for because they were the ones in all the meetings and they're the ones who gathered all that context. So well, it's obvious why we made that, but then, when you go back to that diagram, later, it's like, "Well, this is not at all obvious for other people." Mark and I kind of re-realized this epiphany, because one of the things that we do when we teach classes is we have people create diagrams as exercise, as part of the class, just drawing lines of pictures for this collection of Architectural Katas that we have on the fundamentalsofsoftwarearchitecture.com website.

Somebody wants to see these little puzzles that we present for people. And at one point, we thought, "Oh, we should keep all these diagrams that people build during the class as a catalog of all these solutions. And then, we collected a good dozen of them and realized that they were useless because we weren't forcing the teams to do ADRs. We're having them describe them in front of the group, but they weren't formally documenting those things. And if you don't have that, then all you have is some lines and boxes with no rationale. Why is that line there? And why is it dotted or not solid? And so, those two things together really are critical. And so, we encourage architects strongly to think about not just someone else consuming this, but have mercy on yourself in nine months, because you're going to come back and say, "Who is the idiot that made this?" "Oh, I made that. Oh yeah, that's right. I'm sorry." It's a good self-defense and being a good citizen at the same time.

Mark Richards: As a matter of fact, this really is one of the unique differentiators of our upcoming book, in Software Architecture: the Hard Parts. We talk a lot about the abstract. This is not a book to say, "Oh, if I read this, they're going to give me the answer about contracts or service granularity or workflow." No, we talk about the various options and the trade-offs of those, and that's very abstract. However, what makes this book unique in the market is that we then take, as Neal said, a real-world example, in Sysops Squad. We have conversations, real-world actual conversations that are somewhat modeled after experiences Neal and I have had at client sites. And then, those characters analyze the trade-offs of their particular situation, and then summarize it in an ADR. And so, you're really getting all four aspects of how to do architecture, understanding it, and then analyzing and making a decision. And that's through every chapter in the book.

Neal Ford: Names were changed to protect the innocent and sometimes guilty parties.

Thomas Betts: I wanted to go back to something you talked about earlier about high coupling, because I think architects and designers and software engineers always hear the term, "I want to have low coupling and high cohesion." And they think about that in terms of, "I have two services that are talking to each other and if this service changes, then this service has to change." And there's that coupling idea. But you've talked about coupling between architectural capabilities and architectural characteristics that security and performance are coupled together in different ways. Is that little mantra of high cohesion still applicable to this? Do you try and find places where one thing gets improved and the other aspect also gets improved? Or is it always a give-and-take? You can't have both.

Neal Ford: Well, the overall point is they're always synergistic. The architectural characteristics with each other and with your domain. And so, if I make a change in my domain, it may have an impact on security or performance or scale. And so, you have to think about those things holistically. You can't really pick them a la carte. So, one of the exercises that people do when doing either a migration or Greenfield architecture is try to come up with the list of desired architecture characteristics or non-functional requirements. And you go through there are several different ways to do that exercise, but then you come up with a list, and then some people further go along and try to do a strict rank prioritization of those things, which is, from a design standpoint, is useless, because you can't choose them a la carte. If you could, every solution would have high security, high performance, high scalability, high elasticity, and you just push all the sliders up to the top and be done.

But you can't because as you push this slider up, it pulls this one down. And so, you really have to think about these things holistically and not as an a la carte kind of a thing. So, prioritization can be a useful exercise to determine what the business people or the operations people view as the most important thing. But from a design standpoint, you really have to look at them as a collection, and those really sort of guides you toward a particular kind of solution. And then, you have to accept that you have a snowflake and the generic style only gets you started toward modeling your exact architecture snowflake for all of its unique bins and turns and odd spots.

Mark Richards: Your phrase really resonated with me, Thomas. Always strive for loose coupling and tight cohesion. And this was always just ingrained in most of us since, well, for me, the mid '80s, but we've always tried to strive for loose coupling and systems, and what I really love in what you'll actually learn in our book is, well, maybe, it depends, because I show an example of a tightly coupled system. And then, an example of that same system, loosely coupled leveraging asynchronous behavior, eventual consistency, and such. And then, what we do is analyze the trade-offs of each of those. And we start to see, so should we always strive for loosely coupled systems? Because what we see is a lack of work flow control.

What we see is eventual consistency, what we see is X and Y and Z and error handling. And we just keep going on and on and saying, "Oh, yeah." If I need really strong control over my workflows and can't afford eventual consistency, but rather have to have atomic transactions within my distributed architecture, that necessarily has to be tightly coupled. And it's really interesting when you start to look at everything. I mean, everything as a trade-off. You start to question these mantras that were kind of the Sages always would tell us. And that's very interesting aspect that hopefully, Neal and I's goal was to change a lot of people's minds about some of these things that were wrote back about 10 or 20, even 30 years ago, when we failed to see the trade-offs of loosely coupled systems.

Neal Ford: One of the distinctions we make is between what we call semantic coupling versus implementation coupling. So, semantic coupling is just the inherent natural coupling of a workflow. So, if you're ordering a book, for example, there has to be some sort of catalog. There has to be some sort of user. There has to be some sort of inventory and warehouse. So, that is the semantic coupling of that workflow. And you can model that a whole bunch of different ways in software, but what you can't do is make the semantic coupling less by implementing it. You can only make it worse. One of our insights about this loosely couple and always use choreography. This is another terrible piece of advice I heard from somebody recently is you should always use choreography. And it's like, "Yeah, but if you have a really complicated workflow with a lot of possible error conditions, that complexity has to go somewhere."

And if you don't have an orchestrator, then you can spread out through all of your services. So, there's a pretty strong correlation to complexity of workflow and need for orchestration. And so, that's really one of the trade-offs is. If I have a simple point to point or pipes and filters kind of system that doesn't have a lot of interactivity or boundary conditions, it's much easier to model that. But as the complexity of the semantics ramp up then the need for architectural elements, like orchestrators become higher. And so, that's really where the trade-off lies.

Thomas Betts: Right. And that's something that you can go back to the business decision and say, "We need to be able to handle this because this is how complex our business scenario is." There's ways I know people that can introduce unnecessary complexity because of design decisions that then they have to counteract, but you can kind of go back to the fundamentals of what were we trying to solve. Should it be this complex? Did we get the design wrong? And we can go back to hear the architecture decisions that we really want to fall back on.

Neal Ford: Well, a great example of that is because transactionality was so easy in monolithic systems, we spoiled our business users into thinking that the universe acts transactionally, and it does not. And it's really hard to model transactional behavior in distributed architecture. So, I think, this is part of the responsibility of an architect is not blindly take constraints from business people around things like transactions when they don't really make domain sense. You should push back and say, okay, but if we do that transactionally, it massively ramps up the complexity of our design and our solution. But if we can do it with eventual consistency, with this guaranteed level of consistency and update rate, et cetera, and related to costs, it's going to cost this much to build and maintain this very complex, transactional architecture and this much to build and maintain. And so, having an interactive dialogue with the domain owners and operations, I think is critical for an architect and with developers, as well.

I mean, the architect is unique in a lot of projects in that they're the nexus of a whole lot of interesting decisions because the domain and the operations and developers, all those things kind of come together. And so, it's really important for an architect to act as a communication hub in that situation. Heard a great piece of advice from Pat Qua. He does a lot of great stuff about tech leads. And he said, "Some people think their goal should be don't repeat yourself, but the goal for an architect and a manager should be repeat yourself as often as you need to, for people to understand what you're doing. You should not be a one and done. You need to be able to talk to all these stakeholders and make sure they understand what's going on. So, you need to be overly gregarious, not just one and done."

Thomas Betts: Yeah. The way I always like to summarize that is you can have anything you want, you just can't have everything you want. So, I think, we're just about out of time. I know there's a couple of co-authors whose names on your book. I wanted to give you a chance to mention who they are, just they get a little bit of credit.

Neal Ford: Absolutely, more than happy to. So, one is Pramod Sadalage. You may recognize his name from many books, including Refactoring Databases book. He wrote NoSQL Distilled with Martin Fowler. One of the things that Mark and I definitely wanted to do as we were getting into the Hard Parts book is we realized that so many of the difficult parts in software architecture were these intersection with data and transactionality and who can read that, who can update that. And so, we wanted real expertise in that area. And so, we drafted Pramod to be one of our co-authors. So, he built a lot of interesting material, including we think unique in the world. He really goes through all the different styles of database, relational, key value, graph, et cetera. And does trade-off analysis for each one, for which one is better for this scenario versus the other. So, the entire book is modeled on trade-off analysis.

The other one of our co-authors is Zhamak Dehghani, who is best known out of the world for her research and development of this idea of data mesh. And there's a chapter about data mesh in our book. And so, one of the things that we wanted to do, we do a fair amount of definitional things in our book about how to define coupling and communication. But we wanted to show how you could use those same techniques, not in reflectively looking at something you already have, but in planning and designing future capabilities like data mesh. And so, the data mesh material there is really just an introduction to the concept, but it uses all the terminology that we've established throughout the book. And of course, Sysops Squad builds a data mesh as part of their solution, because that was a problem. They ended up with was this separation between operational and analytical data.

And so, that was the solution to that problem. So, we drafted the two of them to really augment the places where we thought that there was a lot of perspectives that Mark and I don't bump into enough in our travels and our work with clients. And so, we wanted to make sure that we have a more complete picture because we firmly believe that data plus architecture is going to be one of the themes over the next few years. And it is very much the theme of a lot of our professional work that we're doing right now is untangling that relationship and getting that to be a smooth working relationship is a collaboration again, between DBAs, architects, and getting those practices into the same kind of practices we're getting accustomed to in architecture and design.

Thomas Betts: Yeah, the whole trend of, I think, data ops is the new thing on top of dev ops and data meshes. One of those trends we're tracking at InfoQ. I've spoken to Zhamak before and has amazing ideas of where we should be looking in the future with how to change things around. So, last little question, when does the book come out? Where can people get it? Any last things people need to know.

Neal Ford: Could get it at any fine bookseller anywhere. It is already available on Amazon for pre-order. It will be out in late October. It is in the copy editing phase right now. So, it is feature complete. Everything is done. We just need to put a final polish on it. We do have a companion website at architecturethehardparts.com. If you want to see the outline and a book cover and that kind of stuff, but it's going to be an O'Reilly book. So, everywhere you can get an O'Reilly book, it will be available. And like I tell people, nothing says loving to your spouse like an O'Reilly book. These make great Christmas and birthday gifts and anniversary gifts. I always recommend that people buy two in case you lose one, even for the electronic book because you can misplace those things easily. So, having several of them on every device, I think, is a good idea.

Thomas Betts: Take it on vacation. Accidentally leave it at the hotel for the next person to read.

Neal Ford: Exactly, and what could be wrong with that?

Thomas Betts: Built-in redundancy. Well, thank you Neal Ford and Mark Richards for joining me. This is a very insightful conversation. I love talking about architecture trade-offs and all of those things. Really got some good insights. And thank you for joining me today on the InfoQ podcast.

Mark Richards: Okay. My pleasure and thank you.

Neal Ford: It was great to be here and had a great time.

Mentions

• Architecture: The Hard Parts website 
• Software Architecture: The Hard Parts book
• Co-authors:
  • Zhamak Dehghani 
  • Pramod Sadalage 
• Fundamentals of Software Architecture