Grady Booch on Architecture

I have been fortunate enough to know Grady Booch for almost 20 years and I have always remained a fan. Without his advice Im not sure how far Iasa would have come. This interview was as great a conversation as always. In it we cover a lot of territory. We start out with understanding architecture, software and engineering. And in a very candid way get to know what it is like to be an industry leader at the top of his game in 'A day in the life of Grady', we dicuss AI and ethics, and what Grady calls embodied AI which is a term I think will catch on as we edge nearer and nearer to general AI. We also discuss engineering techniques, and Grady's coming book on Software Architecture. Pattern languages applied to all sorts of scenarios. This is a MUST listen episode for anyone wanting to be a modern architect. 

Grady Booch is an American software engineer, best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh. He is recognized internationally for his innovative work in software architecture, software engineering, and collaborative development environments.

Transcript

Paul Preiss: 0:12

I have an unbelievably Well, a very special guest to me. I Grady booch, who is the chief scientist for software engineering and an IBM fellow, and a position of IBM fellow. He's led everything from IBM's AI strategy to just about to inventing UML. to, to doing archaeology are archaic architecture digs in, in some of the greatest and most well known software in the world. I mean, there's nothing that Grady hasn't touched. So I probably don't need to be. I'm a bit of a fanboy. But you've known that, you know, forever. But one of the coolest is just just an icy history fact. I was a member of a thing called wisa, which is the worldwide Institute of software architects was one of the first associations for architects in the world. And Grady was also a member. So when I started eisah, Grady was one of the first thought leaders that I called to say, Is this a good idea? And so I've had the honor of being able to sort of check my silly ideas with with Grady for 30 years. And, and so just kind of a big, you know, for me, this is a really big deal. So thank you for joining us today. Great.

Unknown: 1:33

Thanks for having me. One small correction, Paul. I don't lead IBM strategy and AI, one of the troublemakers who are working down in the trenches to try to make it manifest. I got involved with IBM's AI efforts way back in the Jeopardy days, where my work in architecture intersected with the AI work, because David Ferrucci, who was leading at the time basically said Grady, would you do this talk? And I said, Yes, only if only we've allowed freedom to do what I want to talk about. So I chose to meet with him and the team for over several months to document the as built architecture of Watson. And so that's where I came into it these days, on the IBM architecture side, or AI side, I'm working in an area of what you'd call embodied cognition, which also leads me back to my AI, my architecture, roots will talk about this more, but basically have been pioneering and neuro symbolic architecture that combines classic symbolic reasoning together with neural reasoning. It my heart, I'm an architect, and I just happened to do it in multiple domains.

Paul Preiss: 2:42

You know, I, you and I have always agreed on this, there's, it's almost a few, it almost feels like a calling, as opposed to a profession or whatnot. I, you know, my sister wanted to be a civil engineer since she was 14. And I, the moment I heard the word architect, I went, this is the this is who I want to be for. And it's almost like it's, it's I don't know if to motive thoughts. But why don't we actually ask that question? What's the, you know, what's the creative view of past, present and future of architecture? You've seen so many of these things, from your position? And, and, you know, you're quoted so often on this space. So. So what's the the changes that you've seen through the years? And where do you see architecture itself and architecture as a practice going?

Unknown: 3:36

So let's go back in time first, I first intersected with computing at age 12, when I built my first computer and wrote my first program. And that was the era of the rise of the programming priesthood, the very beginning of the first golden age of software engineering, namely Structured Analysis and Design. So the term architect, was really not in formal practice. Although it was around that time that Fred Brooks, with his work on the IBM 360, was basically saying, we need to distinguish what we're doing from all the hardware stuff, would it be okay to call this engineering? So Fred, I think could be the one who, who coined the term architect, relativity, software architecture. But you know, our legacy goes even way back if you go to the 27th century BCE, a little bit before my time, a lot longer from your time, there was the architect in hotep. And it was pretty cool because he was sort of the chief architect for Egypt. And not only was there he was he the architect, he was also the high priest of the sun, God rah. So if you think about it, we as architects, man, we have an incredible legacy behind us. We were derived from sun gods. Now how cool is that?

Paul Preiss: 4:58

But obviously I think most of us actually believe that about ourselves anyway. So

Unknown: 5:05

it's true. Yeah, some of them believe it. And it's a false god that they all zoom forward to the 19th century and BCE. And you've got the the code of Hammurabi, I hope I pronounced that right, which basically says, if you're an architect and you build something and somebody dies, we're going to kill you to a lot of architects these days, sort of enjoy the first part, but ignore the second part. Because for me, and this gets to the heart of your question. And an architect is someone who has both the authority and the responsibility to make significant design decisions, as you've often heard me say, all architecture design, but not all design is architecture, architecture represents the significant design decisions that shape the form or function of a system. So to that end, one must have authority, ultimately, there are going to be competing decisions, and you've got to make a decision. And for as systems grow in their cost and risk, we'll talk about scale in a moment, someone's got to say, do it this way. And that's what an architect must do. But at the same time, they also should not be an astronaut architect, they have to have skin in the game, they have to take some authority and some responsibility for it. And that's the issue of accountability. So the best architects I've caught I work with, have both responsibility and authority. And if you're lacking each of either one of those, then you're pretty much screwed.

Paul Preiss: 6:38

No responsibility, though, is often reflected in it often takes decades. For it to be reflected in a culture, in, in, in society, etc. So because, you know, you know, I'm in violent agreement about the responsibility and even potentially liability. So do you see that as a future element, reflected that in, in, in law in, in court rulings and expert testimony in, in corporate to corporate suits? I mean, how do you see that, that that becoming a more formalized role, at least for some classes of systems?

Unknown: 7:26

happily, I'm not a lawyer, nor do I ever aspire to be like, yes. But there's something to be said that we may move in that trajectory. But remember that our field, the field of software, architecture, is an astonishingly young field. And so we ourselves are even beginning to understand what it means and what it does not mean. And so while there is great controversy and great uncertainty, what you're describing will likely be inevitable, there will be times of regulation. We are we as a computing community, are building things upon which not just individual lives depend, but upon which civilization lives. And that's the ultimate responsibility that we have, whether or not one knows it, to my dear colleagues who are laboring at organizations, such as Facebook, and I point you out, because I do this often on my Twitter feed. Remember the things you do have consequences, far beyond the lines of code you're writing today. And you may not accept responsibility, but ultimately, you live in a society, they will give you that responsibility. Every line of code has some moral and ethical implementation relationship to it. And you may not see it, obviously at first, but it does.

Paul Preiss: 8:51

I knew that that is a a wonderful and very quotable statement, that every line of code has an output potential ethical or more

Unknown: 9:00

cost implication. Yeah, I would add one other quote, and I'm going to quote the the famous status with regards to the issues of, of legal issues, legal intrusion upon this is inevitable. I certainly see it happening. Well, we, we as developers, therefore, have the responsibility to educate the lawyers and the politicians.

Paul Preiss: 9:26

And that was what I was gonna ask because and again, I have so many questions for you. So I mean, you know, if we run long, we'll we'll break this into a couple of episodes. But but the obviously there are there's obvious differences in our profession. Number one, being that it is absolutely and and because of COVID, even more so truly global, in a way that the vast majority of professionals that we interact with, aren't I mean, the vast you know, I it's very difficult for me, I can do it. I can do a video call doctor even with a doctor. But I'm not a doctor in France in the United States at the same time, I have to start over effectively. There's there's legal treaties, there's binding agreements, there's, you know, I can, there's a huge volume of sort of legislative aspects to the historic professions, which are then primarily local, again, you know, I work with a plumber, who's licensed by the state that I live in, you know, I don't work with a plumber from India, or at or from South America or from even a different state. So there's some I see some real challenges in in this, but we also see politicians picking up on this now and realizing that technology is the one of the top debate topics for who gets voted in. Yeah, you're talking about with Facebook and the red green in the red feed and the blue feet?

Unknown: 10:58

Yeah, yeah. Ours, most engineering professions are what are called an operational closure, occupational closure, meaning you've got to go from an accredited university, get a degree, you got to get licensed, you go through an apprenticeship, we don't do any of that stuff in software. And that's both exhilarating as well as frightening. it's exhilarating in the sense that it gives us some incredible degrees of freedom. But it's frightening in the sense that as we build systems upon which human lives and civilization depends, there has to be accountability. That's why I say it's inevitable. But the fact we are such a young young industry means it's it, there's going to be time for it. That being said, though, and this is a whole nother thread. You have politicians who are making laws based upon ill understood implications and the meaning of software itself, which is why we professionals in the space have to help educate them. I'm delighted to see people like Ted lieu of Congress person from from California, he's one of the few people with a computer science degree that's in Congress.

Paul Preiss: 12:03

Yeah, and I, you know, there was a, there was a great book about about boards of directors that are getting more ex CTO CIOs on them. More More. But But you're right, the legislative mindset is the sort of, I have somebody to turn my computer on for me. And yet, there's these horribly complicated and unbelievably intricate relationships between technology and society. You know, I think that we we talk a lot about synthon and, or canfin, or however you want to pronounce what and complexity and you know, you look at the kind of attack on the Russian attack on the crane brings down, you know, the Royal shipping yards in the UK, and B and P, you know, the the ransomware attacks and all of these things that are that were we're we're starting to realize that the technology infrastructure is actually fundamental to our lives. So we're getting regulated, or we're going to help teach them to what regulation should look like one way or another. And it's a little scary when you think about it, just being sort of the, you know, the the average senator and or Congress person, making those rules, without us as a profession, being able to inform them. But but but I want to come back to this one point that you made, which is, we don't follow any of those rules, which is terribly freeing. But we'd love to I mean, we'd love to call people, we love to call ourselves architect, and we love to call ourselves engineers. And I've a good I've a number of good friends who are real engineers, that actual professionally licensed professionally certified engineers, they've been through the penny they've been they've been through the licensure procedures. Many of them followed, and they almost all follow the same, the same path. But how do you see that playing out? I mean, how do you what do you do? How do you see us? Do we do that only for a certain class of system? Or do you know, because I mean, does the average kind of putting up a Facebook page for the local restaurant? Do they really need a permit for that and a licensed architect or how do you you know, how do you see as a that implementation occurring?

Unknown: 14:31

Great question. And it's an implementation that will take a few generations to get there. In many ways. our profession today is akin to the periods of guilds in the Middle Ages, and the Renaissance time, where a lot of information is passed down through tribal memory. I go into a Google and Google's a legacy, a legacy software organization, and I don't necessarily build New architectures. But there's exactly one repo. And there's a specific architecture for how advertising and how AdWords works, how search works. And that's what you work in, and you, you grow into it over time. So the new folks that come in, they're in effect, brought into the guild and they learn that way. There are architects that have risen Jeff Dean is one of the most extraordinary computing folks that I've ever encountered, and architect as well, he architected so many important pieces of it. But even he himself got there because he just built stuff in an unconstrained world. So we're a long way off. And I think it again, is a reflection of the the innocence and naivety and newness of our industry, that we can't even describe what an architect should be. For while I was involved with the Sui Bock activities, this software body of knowledge, engineering, a body of knowledge. And what fascinated me is that that group, couldn't even come to agreement upon some basic concepts across across various threads, we would says to me that we're still very much in our innocence. And that's great, because there's a great opportunity then to establish those foundations. That being said, All is not doom and gloom because I see a growing maturation from the engineering side of us, that we as a community are beginning to understand what works and what doesn't, we can begin to identify best practices. Now I know there's a colleague of mine who doesn't like the term best practices. That's another story. I think there are best practices that represent what history has shown us what works and what doesn't. And those are indeed best practices, we're still developing them as well. The rise of pattern languages is one such example where I see that maturation, right, what excites me about the AI world is that we, it's wonderful, we're beginning to see them rediscover the things we in software architecture have known for about a decade. And that's the rise of patterns, transformer pattern. transformer architecture is a common pattern that you see among GPT, three and even alpha fold. And the fact that it's even recognized as such as an architect, architecture tells me, hey, that community is growing and B, we're going to see some AI architects as well.

Paul Preiss: 17:22

Well, and you know, this is a great transition to talking about your you're working on a book in architecture tech can What can you tell us about? About your your book, what your what, you know, well, what can you tell us about your book? Well,

Unknown: 17:44

drive for two books. But first, a shout out to my long suffering editor at Pearson slash Addison Wesley. This book has been under contract for about a decade now. And they have been astonishingly patient with me. So thank you, Pearson slash Addison Wesley, you're, you're just wonderful to me. So thank you. The guy who wrote Hitchhiker's Guide, shoot, his name escapes me, he had the greatest phrase that he says he loves deadlines that he loves the sound they make is a whizzed past him in the same place. In a way, I'm very glad I did not write that book 10 years ago, because I A did not know as much as I do now. And B, the world is in a very different place. When I began that work, agile was just sort of starting. And an architecture was still cool. But then agile came along. And you know, the general philosophy was we don't need no stinking architecture, rise to pick out and evolve. But it's delicious to see architecture coming back into the forefront. Go to Google, IBM, Microsoft websites, and you will find every one of them has a major site dealing with cloud architecture. Wow, isn't it? So what they're recognizing is there are indeed common architectural patterns that exist. What's also delicious Lee wonderfully ironic, is it every one of them is developing its own notation for clouds. So there's an AWS common notation for expressing clouds Yeah, they reinvented component diagrams from the UML so

Paul Preiss: 19:23

oh, god I probably right. They've got they've gotten a lot better but they're first ones that you know, the everything from the router icons through there through Yeah, those things that those orange and blue ones just made my head hurt really bad. The you know, the the zero well architected, I'm not saying that the well architected from AWS is any better or worse than the well Arctic architect from a zero but but I will say I like their diagrams a lot better because I get a headache. Now, I know that this is I know that notation is a passion for you, obviously as as kind of one of the fathers of architectural notation. Your I I'm highly interested in that is that something you're going to address in the book is how to how do we describe architectures is,

Unknown: 20:12

it is, it is, and I saw I said, I've learned a lot in the last 10 years. And I really, really have a lot of what I do in the world is go help organizations with the architecture of their large systems. We'll, we'll talk about this when I sort of tell you what a typical day of my life is. But I'm involved in some really, really large software intensive systems, some of the largest will one of the largest I've ever been involved with, down to a bunch of interesting AI, things that are much, much smaller. When I first started the book, I began my research by saying, I know that there's so much I don't know. So I began to study the architecture, I set out to study and understand the architecture of 100 different systems. And in my hubris, I said, I'm going to write a book that describes the architecture of all 100 of these. Well, that was pretty stupid. And what I will learn in the way though, there are a few of them that represent certain canonical kinds of architectures. One of the things I love about my my dear other architecture, colleagues who are writing books and talking in the world, is that they're doing some great things and offering some great stories. But most of them are talking about the cloud. And that's fine. But the world of software, the world of computing, and the world of architecture is a lot bigger than a cloud centric, web centric system of scale. There are systems we're putting inside human bodies, there are, there are things like Photoshop, there's stuff we're putting into space, there are things we put on on HPC clusters for doing climate modeling, and the like, every one of those has some architectural lessons. So while I've certainly gone deep in the whole space of cloud, and it looks like Kubernetes is dominating there. I see the pendulum swinging, that we see the swing, everybody's rushing to the cloud, which is great. But I think some folks are discovering well wait a minute, my monolith was pretty good as well, too. And all this extra complexity of Kubernetes is not buying anything. In addition, when you see devices, like what Nvidia produces the Jetson nano and, and all that sitting on the edge running basically the equivalent of 10 Cray ones at 10 watts, then all of a sudden you start moving processing from the cloud to the edge because of the physics of data itself. So anyway, back to the book itself. Here's basically what I'm covering, you know, what is an architect? What is what is architecture and what is it not? What are some of the best slash effective practices? What do we know what works and what doesn't, one of the ways we represent architecture, I still use the UML. To this day, I use sis ml as well. And its effect, but it's got its problems. bookmark that because I'd like to talk about what I think went wrong with UML, architecturally. And then the next element I'm going to talk about is basically architectural styles. Mary Shaw started this with her classic book, yeah, for architecture. And she got most of them. But there are others that we have found, that I want to talk about as well. We'll talk about process because architecture itself as an artifact, and the process to get there are intimately well later well with one another. And then what does it mean to be an architect? And then I've got a dozen different systems that I've documented the architecture that I'm describing, Wikipedia, Netflix visa, the NASA curiosity NIMS, which is the weather modeling system, alpha fold. So basically looking across. Yeah, so one, and this is actually in conjunction with the documentary project we'll talk about in a bit. But I've, I've done a lot in software architecture, and modeling and the like, but I've also in the last decade, kind of lifted myself up to look at the whole of computing. And that's given me a way to examine the many different ways that computing has entered its way into humanity. And it's given me the appreciation to all these systems that exist, not everything is a cloud system of scale. And there are other things we must operate.

Paul Preiss: 24:26

Well, and and yet, you're there, there's some really interesting overlaps. They're related to cloud feasibility in a regulated world, meaning if I if if you know, let's just say that, that the state of the United States, if every city passes regulation that the date of their citizens needs to stay in their city, it makes the it makes the cloud and all of a sudden makes the cloud look really unprofitable for every vendor out there. I mean, it takes one minute One minor set of, of regulations, not minor, I'm sure it would take a major major act to get that done, given the amount of lobbying that would happen against it. But you can imagine the set of regulations that would make, you know, I mean, your per transaction profitability as a cloud provider can't is not that high.

Unknown: 25:22

All technology is political. And this is one of the elements where politics plays a force upon it, as we look at the potential fragmentation of the internet from what Russia is doing, from what China is doing, right? Yeah, you can't ignore these kinds of things. And this is, I think, one of my learnings about architecture over the years. And that is just, it's not just technical, but it is incredibly organizational, economic and political in many ways. And it's fun to talk about this the technology, and we have to do that and get it right. But architects with systems at scale have to deal with these other issues as well.

Paul Preiss: 25:58

Well, and that brings me to this, this question, and we come at it, you know, that, we come back to this question time and time again, which is an end and it's a conversation you, you and I've had, there's wonderful book systems thinking. And that is, the question is, does an organization considering it has some rational boundaries on it? Like we don't, we don't, you know, maybe not the Uber conglomerates, but let's just assume a average large company, and also a steel manufacturer, or you know, and one that isn't in a very particular space, like Microsoft, or Google or Amazon, but let's look but just talking about your average International Bank, it has certain boundaries, does it have one system with multiple parts of that system? Meaning Is there a Is there a, you know, a nationwide system software system that is one entity, and it has cells and an organelles? And, you know, I mean, heck, I you and you figure figure, it is something like 90% of the cells in human body are actually not human? They're actually bacteria are, you know, that are helpful in many ways, or neutral in many ways? I mean, what does that we, you know, as an architect, as a chief architect with as a large group of practice of architects, how do you think of the systems we build and the way they interrelate in, in sort of the modern architecture world?

Unknown: 27:40

Great question. And it's not just banks, which is the obvious one, but it's also telcos in Lima and telco that provides service throughout Europe, let's say, I've got astonishingly different and very detailed regulations, about how I handle data and things like that. So from an architect's perspective, it is, it is mind bolt mind blowingly challenging. So the reason I like to speak of us as an engineering profession, is because we as developers are responsible for not building the perfect system. But for building reasonably optimal systems. That way, slash balance the static and dynamic forces around us, their economic, their legal, their political, their ethical ones, all these kinds of things. And so as an architect, what you just described are a set of political and, and legislative constraints that lay upon me that I have absolutely no control over. But on the other hand, I want to build a company that actually can make some business so I make money so I can keep doing this kind of thing. So it is always in forever a balance. And in those cases, you can't just create your perfect architecture, let's say let's put this out in the world. But now you have to consider those implications, those forces upon you, as you build the system, and therefore it, I'll make it even worse, because in general, these modest to larger size companies, they aren't just doing an intrinsically, organically, they're doing it by acquisition. So they're bolting on all the other pieces around it as well too, but which makes it more difficult. So the architect in that place has an incredibly important job for that organization, because they must strive towards some commonality, but also offer sufficient degrees of freedom that I can attend to those different pressures. It therefore leads to, in general, said architect being a politician of great technical stature, who was able to have conversations with each one of those groups and help them understand. Look, here's how we're going to at least pass messages back and forth. Here are our policies and patterns for data management and privacy. And as best I can try to find Common infrastructures, they can all use, let's all use Kafka in a certain way, you're not there yet. Let's move to it. And here's how I will do so he will forever be able to forever be in moving mass. And that's what the nature of the large system architect is. It's not just saying, Oh, I'm going to go spin up an AWS thing and put these frameworks on it, and boom, I'm done as an architect. That's the easy stuff.

Paul Preiss: 30:27

Yeah, yeah, obviously, to the large systems architecture. And yet there is that sort of Icarus problem, and which you mentioned earlier, which is, you know, your flights, if you fly high enough, you stop being an architect, and you start being something else. I have a city planner, you know, I in many cases, you start becoming a, an inspection agent, you know, and I'm just inspecting things, and not the lender, not creating things anymore.

Unknown: 30:56

You use the word that I often do these days that modern software development is an awful lot like urban planning. You've heard my story, you know, some buildings, some things like building dog houses, you don't need no stinking blueprints, you just grab some thunder, if it fails, you do it again, if it really fails, you get another dog. On the other hand, if it's your own money, like you're building a house, then you by gosh, you're going to get an architect, and you're gonna have a good relationship with them. On the other hand, if you're Ilan, and you want to put Hyperloop through, around around the Eiffel Tower, then you're going to have a few forces that stand up and say, I do not think so. Ilan.

Paul Preiss: 31:34

I'm just glad that I've gotten to hear your French accent now.

Unknown: 31:37

Oh, it's very bad. My French accent. It's very, very bad. So well, my, my apologies to all my French listeners.

Paul Preiss: 31:48

Trust me, there's nothing we as Americans can say in French that our French listeners would approve of, because we will always sound like Americans, no matter how good we study French.

Unknown: 31:59

French is really good, though. It's like you're being insulted. But it's such a kind way.

Paul Preiss: 32:05

I think that was such a it was a wonderful line in the matrix about that it was they said something like it was it's like wiping your ass with silk or something. That's

Unknown: 32:16

right. Right. Right.