Joy Clark: Hello and welcome to a new conversation about software engineering. This is Joy Clark. Today on The Case Podcast we will talk about software architecture. My guest today is Stefan Tilkov, who is a software architect and co-founder at innoQ. Welcome to the show, Stefan.
Stefan Tilkov: Hi, Joy. Nice to be here.
Joy Clark: It's nice to have you. Today we want to talk about software architecture, and the first question that I have when I think of 'software architecture' is what is it?
Stefan Tilkov: That's a very valid question. Most people think it's some weird, esoteric thing that nobody really knows how to define, but it has a pretty clear definition. Like all technical term, it has lots of them, but there's an agreement about what it means - essentially, it's the sum of the most critical decisions that you make in any software development effort. Some people define it as the sum of the components that you have, the connections between those components and the rules those components and connections follow.
Stefan Tilkov: Some people say it's the kind of decision that's expensive to change afterwards. Some people say it's a hard decision, some people say the decisions that you have to make early on... There are a few hundred definitions, and we'll put a link into the show notes to a website of the Software Engineering Institute that collects all of them, and you can have your own try and add some more of them. Essentially, they all capture the same essence, the same idea that software architecture is the most important, the sum of the structural decisions that you make about your software system.
Joy Clark: But we have something like agile now, so do we still need these architectural decisions? Because all should be agile, it should be able to change frequently.
Stefan Tilkov: That's also a very good question. It's very easy to conflate a number of things here. On the one hand, there's this idea of software architecture as a distinct discipline, something different from software engineering or software development, where somebody comes up with a great architecture and once it's done and bound into several heavy leather volumes, it becomes polished and finalized and is given over to a team to execute. That's one view that's clearly very off and always has been wrong.
Stefan Tilkov: The other thing is that many people conflate documentation with the actual system and think architecture is something that's only embodied by a number of pieces of paper or diagrams or posters or something like that. To my view, this is all very misleading. Actually, software architecture is an aspect of the thing that you're building. If you build a system, it will have an architecture. Whether you've created it intentionally or whether it just happened to you because you didn't think about it doesn't really matter. Your system will have a certain architecture. A good architecture or a bad architecture, a well-defined or ill-defined - whatever... It has an architecture. You can either accept that fact, embrace it and say, "Let's think about it and make conscious decisions", as opposed to just letting things happen by accident. Most people would agree that that is probably a good idea.
Stefan Tilkov: It doesn't at all mean that you have to do this at the very beginning, in a big upfront effort where you have a hundred people sitting in a room, thinking about this. There are many ways, many roads that lead to a good architecture as an end result, but which one is the right one depends of course on your circumstance and your project. It's kind of a weird thing to say that you don't want to have that because you are following a particular methodology, like for example agile software development. I don't think agile development and software architecture have any conflict whatsoever. It matches perfectly well.
Joy Clark: So the architecture can change over time.
Stefan Tilkov: Well, of course there is a problem, because as I said in the beginning, architecture is sometimes defined as the sum of the things that are hard to change, so it's not as if it's easy to change. If it's an architectural aspect and architectural decision, that is by definition not something that you can change in the spur of the moment just because you fancy doing something different today. If you could change it that easily, it's probably not an architecturally relevant decision.
Stefan Tilkov: If you have a system of significant size, then you can't change things all the time, but it doesn't mean that it's set in stone. You can evolve it, you can add new things; you can, in fact, have an architecture that supports this, as opposed to having one that doesn't. You're probably going to end up with a system that embodies many different architectural decisions, some of which are harder, some of which are easier to change. One of your goals is to find out where to apply which rule and which strategy to make things workable in the long run as well.
Joy Clark: How much is the technology that we're using and the software, where we have a lot of different kinds of technologies - how much does that determine the architecture that we end up having in our system?
Stefan Tilkov: There are many answers to that. If you think of the core domain architecture of your system, if you think of the things that make up the business logic of your system, this is to a large degree independent of any particular technology. Many people refer to that when they say that architecture should be completely independent of technology. This kind of architecture clearly is.
Stefan Tilkov: Let's say you're building a medical system that has a rule engine that interprets some business rules as to when to turn on which device and when to apply which therapy (I have no idea; I'm talking about a domain I don't know much about). If you have something like that, then there are clearly a lot of rules that just apply to this abstract model that you have embodied in your software, so it doesn't really matter whether that is connected to a simulator or to the actual device, whether it's a device with hardware of this generation or the next generation... It's just sort of the business core; it's what you would arrive at if you did something like domain-driven design and came up with a good business model maybe in various contexts, but a good business model that just has business objects with rules and methods and events - this kind of architecture is largely technology-independent.
Stefan Tilkov: That is not really useful if that's all you have. At some point in time you have to do something; you have to have some side-effects, you have to maybe create some entries in the database, do some queries, do some output formatting, draw some pictures of a screen, create virtual 3D models - I have no idea... Lots of different things that become very device-dependent. So that would be one thing where part of your architecture deals with abstracting those things away, and part of your architecture deals exactly with making them very tangible and very accessible, and giving them interfaces, connecting them and plugging them together. So the technical aspects of the architecture are important as well, if you're talking about that thing, if that is the domain you're actually viewing, the domain you're actually talking about.
Stefan Tilkov: Then there's a third related area, which is all of the (I hate that term) non-functional things - these are not the functional requirements, or the results of applying functional or fulfilling functional requirements, it's the sum of the decisions that you have to make to support the quality attributes of your system.
Stefan Tilkov: If I'm building a system that runs on my laptop, obviously you have different requirements than when I'm building something that's supposed to run as a service serving 250 million users. If I have to have 250 million users (who wouldn't want to have them?), I will end up caring about scalability and robustness and fault-tolerance and availability and all those things, and they also require architectural decisions, a lot of them
Stefan Tilkov: You could argue these are different perspectives; you're looking at a whole system, and I've not at all addressed all of the potential perspectives. There's the systems perspective, the hardware, the networking and whatever - lots of different views of that system as a whole, and each of them requires considering a different thing your core domain, and a different thing part of the declaration around it. If I'm only considering how to replicate my data so that I get maximum availability, I don't really care that much about the domain objects that I'm storing in that database.
Stefan Tilkov: If I'm talking about the data itself or about the business object itself, I obviously care about this. And if the two connect and if I have only this database technology available to turn this domain model into something persistent, I obviously have to consider both of them.
Stefan Tilkov: That was a long-winded answer, but the essential thing is it's not easy to say how much is technology part of your architecture. Clearly, one of the ideas is that you build a modular systems that contains parts that are as loosely coupled as possible, so very often you will not look at certain aspects, abstract them away, ignore them and focus on something else. Then, obviously, this other part is at that point in time irrelevant, so you continue working with the thing that's currently in your focus, and then you care mostly about that.
Joy Clark: If the technology does play a role in the architecture, should the software architect then be able to code, be able to do these technologies that we're dealing with?
Stefan Tilkov: You could maybe use the analogy to an architect who doesn't know how to build a house - that seems like a weird idea, right? You have to have some knowledge about the whole thing, so at the very least, at the absolute minimum, you should at least in theory be able to do that. I cannot imagine a software architect who was never a programmer; I have no idea how that could possibly work, because this is a very technical task, you make very important decisions. We're going to talk about the role probably later, how to enforce decisions or how to get people to agree to decisions - that also plays a very important role.
Stefan Tilkov: At the very least, you have to be able to in theory. Now we can start arguing. Some people say that if you were a coder a decade ago, that's still good enough; you still know how to do it and things don't change that much. To a certain degree that's correct - things don't change that fundamentally. If you know functional programming from the '60s, you're still pretty good to go in 2017. On the other hand, if it's too long ago, if you're out of practice, if you don't really know how things work, then it's a very valid question to ask whether you're the right person to make those important decisions if you cannot judge the consequence that they have.
Stefan Tilkov: Ideally, the architect would be a full-time coder, absolutely involved in all of the codebase. Ideally, they'd also be a system administrator, a network engineer and a scalability engineer...
Joy Clark: All at the same time.
Joy Clark: Stefan Tilkov:[00:11:42.28] Yes, everything at the same time. Especially in a project that has a certain size, that's simply not a strategy that you can actually apply in practice. You have to give up something. If it's a large project - let's say it's a military thing or a large industrial thing with 200 or 500 people, then there will be architects who are only architects, and I think that's okay. If you have a team with five people and one of them says, "I no longer want to work. I no longer want to do the coding stuff. Now I'm something better, I'm an architect", something's very clearly wrong.
Joy Clark: In a smaller team, this actually becomes a role that people assume, that multiple people could assume at various points in time. If you have a small team that works very well together, then the people will make architectural decisions all the time. Very probably there won't be any one person who is called the architect, but still, your system has an architecture and you're making lots of architectural decisions all the time. You're making them even if you're programming on your own. The important stuff is the architecture. That's something you do.
Joy Clark: So I don't need to have a special certification.
Joy Clark: Stefan Tilkov:[00:12:53.26] Yes, you don't need a certain certification - I completely agree with that. That said, the company I'm with does some trainings and they end with some sort of certification; it's even an architect certification. Now, I share the views that many people have about certification, which is that in itself it doesn't prove anything. Nevertheless, there is a market for this thing and people ask for it as part of their personal career path, and it makes things comparable, so I don't object to it in principle.
Joy Clark: I would never assume that you can only be a good architect if you have a certain certification. On the other hand, it doesn't hurt to have a certain kind of training, and if that's certified, then that's fine with me as well.
Joy Clark: The general assumption is generally true, that you don't have to fulfill some sort of exam to do architectural work, because that's not how our industry works, and I think that's probably for the better - most of the time, at least. Well, sometimes I do wish people would learn a bit about this - it would actually help them - but I don't think it has to be enforced, that it should be required or mandated by anybody. It's a good idea to consider these things and to spend some time talking or reading up on architecture as a specific topic, as opposed to something that just happens on the fly.
Joy Clark: I don't think it's a bad word. I know this feeling, that some people -- and that's probably our industry's fault... In the past decades, sometimes architects went completely overboard. All that people did was talk about fancy architecture or meta-architecture stuff without ever doing any actual work, and that creates a certain backlash that's completely understandable. I sympathize with people who think that architects are just people who draw up pretty pictures that can’t crash and never have problems, so they live in this happy world. I sympathize with that feeling.
Joy Clark: On the other hand, I think it's a little extreme. Sometimes those things are very useful, and it's a useful thing to talk about, and consider architecture an explicit topic.
Joy Clark: If I am just a normal software developer and I'm just working in those projects, how much is it my responsibility to ensure that the architecture is actually carried out? If there's some software architect who has decided how our software product is going to be structured, how much is it my responsibility to follow those rules?
Stefan Tilkov: I'd like to question that split between roles, but we can do that later on. Let's just assume that this is the case... Somebody has made some architectural decisions for you, and you're the junior person in the project and now you're just wondering "How much do I have to care about this? Do I have to care about this at all?"
Stefan Tilkov: If it's a traditional project that's run this way, where there's a clear responsibility for some person to make the architectural decisions and for you to not do that and just to follow stuff, then one of the things that you'd have to do is to be aware of what the architectural rules are for this particular system. Let's assume you're building a typical kind of enterprise system, and some of those rules might be "How do we persist stuff to the database? How do we query it? How do we serialize things across the network? What is our typical pattern to implement a service or a command? How do we visualize things on the screen or in some web view (or whatever the view technology is)?" Those things will likely follow a certain set of predescribed stereotypical solutions, so that if I look at the system, various things done by different people will look similar. That's one of the typical goals that an architect would have. They find common solutions, so that things become easier to build, easier to maintain, easier to recognize, easier to evolve in the future.
Stefan Tilkov: As a developer, your goal will be to look at those things and maybe know those patterns and apply them. Of course, this all seems very wrong to me, the way that I'm phrasing it, because I don't think anybody these days likes having coding monkeys who just follow predescribed things... So at the very least, one of the things that you would have to do is to question those rules. "Well, this is how I'm supposed to do it. I understood the rule and I know how to apply it, but it feels wrong to me. This is how I would suggest doing it, because then it will be better", and then hopefully you convince somebody that that's a good idea, and maybe either they'll change the rule or extend the rule to say, "This is the rule for the 80/20 case, but in this 20% case we have this better way of doing things." So that would be one thing - evolve the rule set. That is one of the most important things from the other side.
Stefan Tilkov: If you are an architect, if you are the person who wants to enforce an architecture, then I again would say first of all you should reconsider whether that's a good way of thinking about things, because the terminology is all wrong. But let's just assume that that is your role and you want to enforce things - then the very first thing that you have to do is to convince people that it's a good idea. You can do that by ordering them, and if you have some power invested in you that allows you to do that, maybe you can get by. But even then, even if you have the formal power to enforce a rule, that in general does not at all mean that it's gonna be applied. For example, it just may not work.
Stefan Tilkov: That's one of the harsh realities of being an architect - something sounds very cool and really nice, and it also looks absolutely awesome on your CV, and it matches exactly what you saw by that person in that conference, but it just doesn't work. The developers who actually have to apply that rule find out that it doesn't work and they just circumvented somehow because they have to find a solution to get the thing running. So now nobody has won. The people are unhappy because they have to follow stupid rules and circumvent them, you're not happy because you're not seeing the architecture that you wanted to have, so this whole idea of isolating those things too strongly is completely brain-dead, you shouldn't be doing that. It has to be a continuous loop of self-improvement, whether it's two people, one person, a team, two teams or several teams - it doesn't really matter; you have to have this feedback loop of improving your own rule set.
Joy Clark: So there should not be two separate roles, in your opinion. Developer/architect...
Stefan Tilkov: Again, ideally. Ideally, they should not be separate.
Joy Clark: In a perfect world.
Stefan Tilkov: In a perfect world. It's just a matter of the organization size. If the organization becomes too large, it's pretty hard to have everyone do everything. Sometimes you start specializing in some fashion. Let's say you start with a team of five people - then maybe you can get five people to agree on something.
Joy Clark: Possibly.
Stefan Tilkov: If they know each other well, if they like each other, if they respect each other, if they have lunch and dinner together, if they are friends and get by, they will find a way. In this ideal world, one of them will know more about networking, one of them would know more about databases, one of them will know more about UI programming... Each will have their own expertise and they will agree, and the one with the best rationale, the one with the best arguments will win, and then they will actually always build the perfect system. That's awesome. That's the best kind of scenario that you could have, with no dedicated architect.
Stefan Tilkov: If it's ten people, maybe it's still possible. With 50 people, it's kind of hard, because it's pretty hard to get 50 people to agree on anything. Even with five people it's pretty hard to agree on where to have lunch, so if it's 50 people making a fundamentally important decision like "What programming language do we use?" - do you think they'd agree? I don't know 50 programmers who would agree on a programming language to use. I no longer know those kinds of people anymore.
Stefan Tilkov: There'd be some people who want to do Erlang, some would want to do Clojure, some would want to do Node, some Java, some C#, Haskell, OCaml and whatever. They'd all want something different, and somebody has to make that decision. Maybe that decision is very forward-looking and they pick Clojure or Haskell, or maybe it's very conservative and they pick something like Java. Whatever it is, somebody has to make that decision.
Stefan Tilkov: In the end, it comes down to explicit or implicit seniority; at some point in time, somebody has the authority to make that decision. Ideally, that is not a manager, because that is the wrong authority. Ideally, it would be somebody who has technical authority, who has experience and who has seen this thing work, and who's seen other things fail, and who knows when to take risks and when to avoid it, and how many battles to fight at one particular point in time. That is actually an excellent definition of an architect - somebody with at least some experience (I don't think it's ever a good idea to have an architect with zero experience; I think everybody will agree on that) who will make a decision.
Stefan Tilkov: Next thing, try to get things to agree and to buy into that decision, to actually make it their own. Because if it's something that you continually disagree with, that's the worst kind of programmer you can have on your team - somebody who hates all the decision that you make. They want to program X, but you make them program Y. They will find a way to do X in Y somehow, and that's not going to be fun.
Joy Clark: It sounds like communication is also very important.
Stefan Tilkov: Extremely important. Having a solid technical background is one very important thing. This is something that helps you make good decisions, because you understand what it is that you're deciding. But at least equally important is to be able to communicate them well. You can make the best decisions; if everybody thinks they are stupid decisions, nobody's going to respect them. It's kind of a mixture. You have to have those communication skills, I think they are very important. That is a matter of being able to convince people. Like, "Let me explain this idea to you", and maybe you grab a napkin or you draw on some flip chart, you make a quick drawing. It doesn't have to be perfect UML - that's another thing we can talk about; it doesn't have to be a perfect picture, it has to be a picture that's clear enough to communicate your idea and convince the other party that it's a good idea to do that. So that will be one thing.
Stefan Tilkov: That's also a view that is very restricted on the relationship between the software architect or the person assuming the software architect role right now, and a software developer. There are other people around those two that are equally important. One good example would be the person making the decisions about what to build - not how to build it, but what to build. That is somebody the architect needs to talk to, because if you're, say, a product manager and you come up with this awesome idea for a fantastic product, who's going to tell you that this is not something you can build?
Stefan Tilkov: If one of the programmers has a limited view of the thing - they're just tasked with maybe building a fancy UI or maybe building the fancy database lookup table, whatever it is... Maybe they won't see that the whole thing is a bad idea. So I would say it's the architect's role to question those things as well.
Stefan Tilkov: If we start this from the beginning, the very first thing as an architect that you would have to do is be very skeptical and very demanding about the requirements that your domain expert gives to you. Somebody wants to have something built, you're responsible for helping build that. It's not as if you're the project manager; that could be another role. It's just that somebody has to look for the feasibility, the viability of the whole thing. So looking at requirements would be the first thing to look at. That's where you should start from.
Stefan Tilkov: If you look at that, then the obvious next question is, "What are those requirements" and "Will you get all of them?" As an architect who talks to a business expert or a domain expert, you're going to get lots of domain requirements, like "This is the functional thing that I wanna do. This is the business rule that has to apply." But as an architect, you also have to care about the things that are not in the business requirements. You want to have something that, for example, you can build with the team that you have, or with the resources of other kind at your disposal. Hopefully you're taking care about building something that lasts for the lifetime of the system. Probably the domain expert doesn't even know what you're talking about. You're saying, "I have to build it in a way so that I can evolve to a new version of the database or the operating system or the internet", or whatever it is that is going to grow over the course of time. It's also your role as an architect to consider those things and to build the long-term viability into the system... Not into the project - that would be another distinct effect.
Stefan Tilkov: The horizon you're looking at is not the project lifetime, but hopefully the system's lifetime, so that you'll make some decisions that will be reasonable now for something that you want to achieve in the long run. Those are all things that are a responsibility for the technical overall shape of the system that you're building.
Joy Clark: You said before that it's better if the management doesn't make software architecture decisions. If you are working for a company where they have made those decisions, what's the best way to deal with that?
Stefan Tilkov: There are certain things that you just can't change, for whatever reason... Maybe somebody would lose face if you changed it, maybe it's some business decision because you're a partner with company X and they provide this technology so you have to use it... Sometimes there are things you can't change. As a software developer or software architect, you have to be comfortable enough with accepting some things that are not changeable, unless you're willing to change jobs, which is fine as well. If it's not something of that kind, then you simply have to work hard to get those things changed.
Stefan Tilkov: Let's say somebody picked a technology because a vendor told them that this is the best technology to have, and the vendor played excellent golf and provided a perfect dinner, so they're likely to believe them. Then you're only goal can be to slowly and persistently convince them that something else - maybe that open source solution of yours - is a better one than this commercial product, or the other way around. That's entirely possible, if sometimes very, very hard work.
Stefan Tilkov: Like in every organization - especially large organization - it's sometimes really hard and can be very tedious to do that. You have to make a note for yourself whether you have the stamina to do that and whether you want to invest all of that time. But even as an architect, even if you're within your team and you just have assumed that role because somebody said, "Can you make the architectural decisions?", even then there will be things that you can't change, even though it's your colleague sitting next to you who made that decision. They may just be wrong, or misguided, or in a bad mood. You have to convince people all the time.
Joy Clark: What tools do you have, what can you use as a software architect?
Stefan Tilkov: First of all, you can always use code, because in the end, the most important thing is the system that you're building. If that is the right level of abstraction, then by all means build some code. That would be my first tool and the first thing in many cases - not in all of them, but in many cases. If you want to show something, you demonstrate it by building a small prototype, you build a little reference application that shows "This is how the architecture is supposed to work." You address some doubts about your architecture by building a proof of concept.
Stefan Tilkov: If your idea for this new architecture is to use that fancy NoSQL database, but you know that one of your team members is an old-school relational database guru and they're gonna question whether this is actually usable for anything real, so maybe you build something that shows how to insert a few billion records and query them. Those are things that actually show things at various levels of abstractions, using just code. Sometimes that's the right way to do things.
Stefan Tilkov: Sometimes the tools that you have at your disposal are just a pen and paper, because you just draw a diagram, and sometimes a sketch is the right level of abstraction, not a formally correct case tool model in UML or something like that, but rather a quick drawing that illustrates some point. But of course, there are also tools that you can use that have a more formal background. Maybe it’s because I'm an old person, but I don't necessarily object to UML. I've used it in the past, 20 years ago, and I've used it throughout my career over and over again. For those who don't know, the Unified Modeling Language is a standardized language for visualizing object-oriented and other software; it's a useful thing. Granted, it's completely over-engineered and bloated, and every tool that allows you to produce UML sucks, there's no question about that at all. But that's not necessarily a reason to never use it at all.
Stefan Tilkov: If you have good tooling, if you have one of those UML tools that are at least almost usable, you can use that to produce diagrams, and that's fine as well. They offer some additional benefits, like they know that you're not drawing a picture, they know that you're drawing a model, so they can apply some rules. That is both a benefit and a curse, depending on what you want to do. It's perfectly fine to do that.
Stefan Tilkov: Using one of those tools does not necessarily mean that you subscribe to the idea that everything has to be modeled upfront and then generated one hundred percent, although we can talk about that, too.
Stefan Tilkov: The tools would be code, sketches, formal diagrams... Another one that I also like is prose; it's a nice way to sometimes just write something down in clear words, where somebody can read them and know what you mean. I like sketches and little post-it notes - that's all fine with me, I don't object to that at all, but sometimes I like to read something that actually has a certain logic and story, and a beginning and an end. That's fine as well. Ideally, you mix all of those and you come up with a set of ways to communicate what you want to do.
Stefan Tilkov: In the end, as I've said before, the most important thing is that you actually come up with something that works, that runs. Anything else that you've produced apart from that is just add-on stuff. It's really important as an architect not to view your job as being done once you've produced the concept or the documentation. It's really done once you've produced a system that actually fulfills the requirements that you came up with in the beginning.
Joy Clark: You're under the assumption that UML is easy to understand, or that your team has the capacity to understand it.
Stefan Tilkov: Yes. We can talk about UML. UML is not easy to understand, because it is so big. If you give somebody a test on UML, I practically guarantee that 98% of all existing software participants will fail if it's all of UML. But if I give you a class diagram, or a state chart, or a sequence diagram, then most people can sort of read it - maybe not draw it perfectly, but they can sort of read it. And it also has no downsides compared to whatever notation you just invented on the fly, because nobody knows that either.
Stefan Tilkov: Again, it's wrong to be religious about this. I'm not a big UML fan, as I said - I consider it bloated - and I would love for there to be something like a lightweight UML, that would be a cool thing. I think some people actually tried to do that. One of the people that I hope we're going to interview on the podcast sometimes in the future is Simon Brown, who talks a lot about visualizing software architectures and he has his own notation that is more lightweight than UML. He talks about it, people like it a lot, I like it a lot - I like everything he does, but still, I can't help but notice that it looks an awful lot like UML. Maybe the secret is to just not call it UML, and then it's fine... But that's okay.
Joy Clark: When we start a software project, is all the architecture always the same?
Stefan Tilkov: Of course not. You could say that no two architectures are the same, because every system is different, the requirements are different, the decisions that you've made are different... Maybe two systems are very similar if they started out with the same thing, or were maybe forked at some point in time, or maybe you have a product line approach where you have a little bit of variation... But in general, two systems will not be the same. There are some things that are shared; you can recognize patterns or architectural styles, as people like to call them, in different systems.
Joy Clark: What kind of styles are there?
Stefan Tilkov: If we talk about architectural style, you can envision that as something pretty similar to a design pattern; many people know that. It's a kind of a collaboration, a certain kind of constellation or coexistence of roles that certain elements play, and you recognize them again and again. An example would be something very obvious like client-server. A client-server architectural style is a system that's composed of two things. One is the server and one is the client. The client issues calls - typically remote calls to the server, and the business logic resides on the server, and then it does something, it computes the result and returns it to the client - that would be a client-server system. That would be an example of an architectural style.
Stefan Tilkov: There are many of those, they've been cataloged. As people like to do, they look for similar patterns in different areas and extract the commonalities and give them a name. Another example would be something like a pipes and filters architecture; people have noticed that this is something that occurs again and again, because when you have a pipes and filter architecture there is a dumb pipe and a smart filter. That's kind of the model where a filter can do something fancy, and just passes on the data along the pipe, and then another filter can do something else that's also fancy. You can connect and you can pluck together different filters to achieve a certain result that would be kind of what you know from the UNIX command line, where you have a pipe symbol connecting different commands, and you cat something into something that you sort and so on. This general pattern would be a pipes and filters architecture.
Stefan Tilkov: There are lots more, and this is a reference to literature that's out there that actually talks about those things and gives you some guidance as to what this particular architectural style is good for, what you could use it for. Then you can look at the abstract description of a problem, at this abstract solution, and then look at your concrete problem and check whether it maybe matches one of those abstract things, and if it does, then you can try applying that abstract solution. It's kind of giving you a number of tools or pre-composed, pre-defined ways of solving the problems in terms of architectural styles.
Joy Clark: I was listening to a podcast recently, and the word three-tier architecture popped up, and then went on assuming that I knew what it was.
Stefan Tilkov: Yes, that's a very good example.
Joy Clark: ... which I didn't, so maybe you can tell me what that is.
Stefan Tilkov: I can tell you what a three-tier architecture is, yes. A three-tier architecture would be one where you have - obviously - three tiers, typically referring to tiers as opposed to layers. We can get into more detail than that, but the three-tier architecture you're talking about are physical tiers. You would have a database server, an application server that hits the database server, and then some client system that talks to the application server. For example, you have an application running on your laptop that's written using Microsoft tooling to run on Windows, or maybe Apple tooling to run on the Mac, and that talks to a Java EE application server that in turn talks to an Oracle database - that would be a typical three-tier architecture.
Stefan Tilkov: Sometimes those terms carry some historical baggage. In this particular case it was a three-tier architecture because this third tier, this middle tier was introduced into the old client-server architecture. So it all started out a long time ago.
Joy Clark: So should we call it the sandwich architecture...?
Stefan Tilkov: I haven't heard that term, but it would be perfectly fitting.
Joy Clark: I just made it up, so...
Stefan Tilkov: [00:38:49.57]Yes, it would have been fitting, as well. Essentially, it started out with a client-server - that was the revolution after everybody just used the mainframe. Everybody connects to a mainframe from a dumb terminal - it's a little bit like a web browser, but it was green. It was a green text terminal that everybody used to connect to a mainframe. All the logic was in the mainframe, and then the client-server revolution started at the end of the '80s, beginning of the '90s where essentially there was suddenly computing power on the clients, on the PCs. So people has a PC that did some local computing, but it still needed to share data - you needed to share data with your colleague, who was next to you. What happened was you used a central database; that was the first client-server wave where there was a centralized DB2 or Oracle or Sybase database with PCs running FAT clients, FAT applications, hitting the database. All the SQL requests would go from your client to your database and talk directly.
Stefan Tilkov: At some point in time, that turned out not to be that great of an idea, because you didn't have that centralized logic that you had to roll out things, so people introduced this middle tier, and that was all the rage in the '90s and early 2000s, before the web stuff sort of evolved from it and became the dominant paradigm.
Joy Clark: So that's a new paradigm; or it's the same thing...?
Stefan Tilkov: Well, these days most of the systems that we have sort of evolved from the three-tiered architectural style. People have a client, which is typically a web browser (that would be the most dominant form) or maybe a native application (typically on a mobile device) and then they talk to some centralized service; then that centralized service talks to some backend system, for example a database or a legacy system. You could argue that's a three-tier thing, although typically the middle tier is way more complex than just a single box. Those days are long past. These days we have server forums with tons of stateless things.
Stefan Tilkov: For example, your middle tier or your service tier - or service layer; we can talk about the difference between layers and tiers... This terminology most often means that you have something more or less resembling a REST-based system. REST would be another of those architectural styles, although in contrast to the others, it has a pretty exact definition, but it's also derived from these other things. In fact, if you look at the original REST thesis, REST was originated by somebody (Roy Fielding) who wrote his PhD thesis about this topic. He defines this as an architectural style and he contrasts it to, for example, client-server and distributed objects as other well-known architectural styles.
Joy Clark: You said a couple times that we're going to talk about the difference between tiers and layers. What is the difference between tiers and layers?
Stefan Tilkov: It's not really that important, but if I mentioned it... A tier would be something physical - if you have a three-tier architecture, there at least three physical machines. A layer is just a software concept. In a layered architecture - and that's, again an architectural style - you actually group your software into layers that sit on top of each other; that would be the graphical model that I'm just showing by waving my hands around. You have a layer sitting on top of another layer, sitting on top of another layer, and in general, every layer is just allowed to access the layer below. That would be the rule.
Stefan Tilkov: In some layer styles you're allowed to skip a layer from the top to the bottom, but you're never allowed to go from the bottom to the top. You're never moving upward in terms of dependency.
Stefan Tilkov: For example, your database layer and your logic layer is allowed to make calls into the database layer. You're allowed to call a function that will persist something, but the function that accesses the database is never allowed to call back to the logic or to call into the logic layer. The same will be true for the UI.
Stefan Tilkov: In that layered architecture you might have something like three, five or seven layers - however complicated you want to make things - and then you can make a separate decision as to how to deploy that. It could be a single application that has seven layers; that would be a single-tier application. Or you can have three tiers, where maybe the persistency layer and the data access layer resides on machine one, and the logic layer and the process layer resides on machine two, and the dialogue and UI layer resides on machine three. So it's two separate decisions that you make, as opposed to the logical layers and the physical tiers.
Stefan Tilkov: That's one of the things architects talk about. If you have a bunch of architects talking to each other, they will brag about how many or how few layers their systems have.
Joy Clark: Which is better?
Stefan Tilkov: Well, of course, that's a ...
Joy Clark: ... subjective question. Which do you prefer?
Stefan Tilkov: I always have this pendulum swinging back and forth between extremes. In the past, a long time ago, I went completely crazy with this whole idea of layers. There were tons of layers, each doing just one tiny thing, which of course is a disaster, because specifically in a statically-typed language this also means a change of type system from one layer to the next, which means you're copying stuff.
Stefan Tilkov: If you look at one of those applications from the '90s, very often you can see that they spend 80% of their time just copying the same data from one layer to the other, at the expense of performance. You've hopefully, potentially improved your long-term maintainability because you can switch layers - that's one of the benefits; you can replace it by something else - at the cost of making the whole system way less efficient and performing, which is probably not a good idea. I think that's not good.
Stefan Tilkov: I've also seen systems that ignored this idea completely and just meshed everything into one, big, muddy thing, which of course is also not a good idea. The whole idea of layers is this separation, this idea of having separate things that address separate parts. You do that because you want to have this long-term maintainability. So it definitely makes sense to have some of that. That's just one example of things that you would consider as an architect. There are many others, as well.
Joy Clark: What's the most popular architectural style currently? Is there one?
Stefan Tilkov: I hesitate to call something like microservices an architectural style because it is so ill-defined, but most people these days when they build a modern system and want to do things in a state-of-the-art fashion, they're going to end up with something that is more or less service-oriented or microservice-driven, or has a microservice architectural style.
Stefan Tilkov: I'm a little reluctant to use the term architectural style with that, because that is actually a scientific term, and if you look for example at the REST paper, it uses very specific terminology and rules to define this thing, so we don't have any of that for the microservices world as yet.
Stefan Tilkov: If we're allowed to be a little lax with our terms, then in this typical newfangled style you try to build things so that they are small - that's one of the major goals; you build smaller things. It's correct to say that if the past two decades have told us something, it's that big systems are bad. So we try to build smaller systems, we try to isolate things, we try to apply the principle of separation of concerns to make things small and focused and modular.
Stefan Tilkov: In a microservices style, as opposed to any other modular style, one of the ideas is that you have small, independent modules that are independently deployable, so you end up with this system that is composed of a number of independently deployable, independently running services (typically pretty small services) that collaborate to fulfill the goal. That matches nicely the current infrastructure that we have, which is cloud-based and has these platforms that people can easily deploy things onto, as opposed to it being really hard. They have these typical data stores that allow for access by many concurrent services at the same time, possibly distributed across the world.
Stefan Tilkov: You typically end up with a service layer - the L-word again - that would then hopefully be something like REST-oriented or RESTful, to offer its services to any number of clients. That would be one of those popular styles. We are probably going to talk at some other point, on some other episode about alternatives to this... But that is probably right now the most important style for these kinds of systems. Again, it makes no sense at all to apply that kind of architectural style to a standalone iOS application that you're developing for your mobile device, or a command line tool that you build to convert some data form into something else. That would be the worst thing, for any architect to claim that they have one solution that applies to every problem, although sometimes people tend to evoke that feeling.
Joy Clark: But even a command line application that's really small - does that have an architecture?
Stefan Tilkov: Absolutely. Yes, of course. First of all, it's embedded into a larger-scale architecture. Your UNIX operating system, if that's what you're using, has its own architecture; your small program is just one of them. But internally, it very likely has some structure, unless it's a two-line program.
Stefan Tilkov: Let's say you have a program that does something very trivial; it counts some characters, or looks for a pattern... You're building the grep tool, you're counting the occurrence of a certain regex in an input stream - that would definitely have an architecture. That architecture would be the decisions that you make about how you cut apart this problem into modules, for example.
Stefan Tilkov: If you want to look at a very old paper - and we should definitely put that into the show notes as well - there is one from 1972, from David Parnas, who wrote about how to modularize things, how to build good modules. There are certain things that you can do. You have a ten-step program, so it's obviously got ten modules, because each step is one module - that's kind of a stupid way of doing things. The better way would be to build modules that hide certain decisions that you made. This is the module that accesses the input file, this is the module that accesses the output file; this is the module that takes whatever comes in from the input stream and puts it to the output stream; this is the module that you put in there that augments or decorates this behavior with something. [00:50:25.29] Now you have a set of modules that encapsulate a certain decision, and they can be changed without affecting the others, because they have an external interface and an internal implementation. Those are ideas exactly the same ideas that we have almost 50 years later in modern architectures, but it's still the same kind of decisions that you have, the same decisions that you make about how to structure things, what are the components and the connections and the rules that govern those components of connections.
Joy Clark: I think that the software architecture is very important, and as a software developer I want to learn software architecture so I can write better software.
Stefan Tilkov: That makes sense.
Joy Clark: That's my goal when I look into software architecture. I'm willing to do anything to become a better programmer.
Stefan Tilkov: There are people who really view architecture as a distinct discipline, as something very different from software development or software engineering. That's completely wrong. I'm utterly convinced that's not the way to do it. If you do software architecture that's not very closely related to the software, something is really wrong. That is something I feel extremely strongly about. It's a very good idea to view architecture as something that applies to any software developer as a role, as a certain set of responsibilities that you're going to have to address somehow, that you have to fulfill as part of your daily work. I completely agree with that.
Stefan Tilkov: There is a distinction to other architecture disciplines. There's a discipline called enterprise architecture, which is something quite different, and sometimes there is some confusion when people say they're an architect. When you talk to people and they say, "Well, I'm an architect at company XYZ", you really have to ask what they mean by that. There are certain people who have an active role in developing a system, and there are certain people who have a completely different role, which is to maintain the company's application portfolio decisions, like decide where to build software and where to apply commercial, off-the-shelf solutions.
Stefan Tilkov: That's possibly a very important thing for that company, that's perfectly fine, but it's a completely different kind of work, it's a different line of work. It has some connection to technology and you could argue that it should have more of a connection than it often has, but it's really not the discipline we're talking about. We're talking about software architecture, we're not talking about enterprise architecture or company-wide IT architecture. Those are really different things.
Stefan Tilkov: There are also people who work in larger companies who maintain architectural rules or rule sets or guidebooks for the organization as a whole. This is more the idea of standardization across different projects, different systems. Whenever this particular company builds a product, it builds it using Java 8 on top of product XYZ, using framework Z. That's also a different kind of architecture. I'm not ruling it out as something that's always bad. It can be a good thing to have some standardization... I think in the last few years we've seen less of that; we've seen fewer attempts to really standardize everything, down to, say, the position of the last curly brace, because that's kind of a wrong-headed approach, because it wastes so much effort and so much resources for something that's really clearly not valuable.
Stefan Tilkov: With these more service-oriented approaches, there is a certain tendency to leave decisions to the people who build the service and to only standardize on the outside, as opposed to standardizing everything inside, which I think is a good thing. So that would be a different kind of architecture.
Stefan Tilkov: Sometimes you have people in larger companies who do cross-cutting architecture work. They come up with good solutions that are supposed to fit into the company's overall strategy. Let's say you're a big company, you have this strategy of digitization, you want to become the Uber of whatever, so you spend a lot of effort doing that, and maybe you have some overarching architectural guideline that says, "This is the way we do single sign-on, and this is the way we maintain our multi-data center strategy." Then maybe those things will result in actual guidelines for architects. It's very important not to lose touch with the actual project if you do that. Similar to the architects, who cannot afford to lose touch with developers, if it's a separate architect, this company-wide architect can never afford to lose touch with the project. It's very risky thing. Better to not have them. Sometimes you have to have them, so address that risk.
Joy Clark: Is there anything else you would like to say about software architecture?
Stefan Tilkov: One of the things that I found is that -- and maybe you can see some of that in the discussion we had about UML... When we talked about UML, one of the things that I wanted to stress is that however bad it is, maybe it's good enough, and maybe it's better than something you invented yourself, because communication is so important. When I draw a class diagram with a line and I put a little arrow head on it, then you either do or do not know what it means. But if you do, that's clearly better. It's clearly better if we have the same understanding about those things. I think that is a common trait in all kinds of communication, in all kinds of diagrams, and also in all kinds of models and code that you share with people.
Stefan Tilkov: Having this idiomatic understanding, or having those common idioms and patterns and styles - it's all the same thing. It always boils down to, when I say "pipes and filters", this evokes some image in your mind. You think of something when I mention that - that's an important thing. It's the same thing with the design pattern, with all of those things. An art that's been a bit lost in the last few decades is this idea of establishing that as a language, as part of your architecture work.
Stefan Tilkov: There's another paper which we will also put into the show notes by Markus Völter, somebody I used to do podcasts with for a long time. We'll have to get him on the show, as well... He wrote a paper called "Architecture as a language", and that also has the same idea. It's this idea that if you're an architect, then you're not only creating a text, you're creating a language to write that text in. You're creating the rules and the construction patterns and the things that you can and can't do in this particular language.
Stefan Tilkov: I mentioned that when you're building a system that hits the database, you want to talk about how to do persistence, "How do I persist something?" If you want to talk about "How do I build a service?" then you're talking about "This is the way we go there, this is the way we serialize the data, this is the way we do XML or JSON or HTTP", or whatever it is that you're talking about. Every time you do that, you describe rules in this abstract fashion using those language terms.
Stefan Tilkov: If you write something like "Every service access its data access object by means of a RepositoryImpl that derives from the repository and gets injected by means of --whatever" - I have no idea, whatever it is that your architecture comes up with. This is actually the main task of the architect - to come up with the particular language for this system, so that every part of that system uses the same language. If I look at ten different kinds of entities in my system, they're written using the same language. You can see that in domain-driven design, which is exactly the same thing - we've got aggregates and entities...
Stefan Tilkov: My point is not that DDD is good or bad, but that there's an underlying idea under DDD which maybe makes it so popular because it makes it so easy and accessible ("Just take this, just make everything...") The more important thing is not that you need to have aggregates and entities and value objects and services, it's that you should think about whether it's these four or five or seven or eight concepts with those particular rules that you need to apply to your particular architecture.
Joy Clark: I have one more question as a wrap-up - another subjective question. You're a software architect, so what is your favorite architectural style.
Stefan Tilkov: My personal favorite architectural style... I like all things web; I'm a big web fan. I think that web is way underrated. People still haven't grasped what it's capable of, and I think we should build more that's in line with the web's architecture, or the web's architectural style, and that is this REST thing. There is great potential still in there, and even after 15 years of it being popular, or becoming more and more popular, I don't think this has still entered many people's brains. That's because it's easy to use it in a half-baked fashion.
Stefan Tilkov: As an overall architectural style, that to me is still a very interesting thing, that has tremendous implications even for the way we connect applications built by different people, across different organizations across the world. It's the only globally-relevant architectural style that I know of. That's why I'm still a big fan of it; I've had a long life and a long career in this industry, and this is the only thing that has been this constantly on my mind for all this time. I'm still a big fan.
Joy Clark: If I want to get started and become a software architect, how do I do that?
Stefan Tilkov: The very first thing is you gather some experience in working with actual systems. That's a good path that many people are on, including you. You start building things, you start making your own experiences about what works and what doesn't and what kind of solutions you applied in the past that you can apply now, and when some decision that you made early on in the project hurt you very badly later on, so you get a feeling for this whole thing.
Stefan Tilkov: After you have a solid groundwork of this - and that's definitely required; that's something you can do when you're fresh out of college, but if you're starting something based on some experience, you can start on looking at what other people have written about this, the talks people have given about this, the books people have written about this, and you can see that there's some connecting elements between a lot of the decisions in different scenarios.
Stefan Tilkov: Whether it's a small system you're building or a large one, whether it's a small team with three people or a big one with 300, there are certain things that you can recognize again and again, and you can actually learn from what other people have experienced with that and apply some of the solutions that they have found to their problems.
Joy Clark: What's your favorite book?
Stefan Tilkov: Favorite book on software architecture?
Joy Clark: Yes.
Stefan Tilkov: That's a really good question. Oddly enough, one of my absolute favorite books is one called "Release It", which is not explicitly about architecture, it's about stability patterns. It's by Mike Nygard, and I'm really continuously impressed by everything he's done in the past. He's written this book - we're definitely going to put that into the show notes - about things that went wrong in production, and it's amazing how much you can learn from that, as anybody who has had a system fail in production knows. He talks about those little things and what to do about it, what patterns to introduce to make systems more stable. That is one of my favorite things.
Stefan Tilkov: There is a number of very good books by Martin Fowler - not all of them - called Architecture-something or other, but I think pretty much all of them cover a lot of those topics. Patterns of Enterprise Architecture is not longer that new, but still a very good book in that regard. There is one by our colleague Gernot Starke, which is available in German - that's one to put in the show notes as well for those listeners of ours who can read German.
Stefan Tilkov: There is a series of books called The Various Patterns Books that touch on software architecture. Pattern-Oriented Software Architecture is one of them. Obviously, these days there are lots of blog posts and things, so we'll have a long list of things to point people to who want to read up on this.
Joy Clark: So we should get started with Release It and then go on from there? Because otherwise it sounds like it's...
Stefan Tilkov: Well, it's probably not the reading order I'd recommend... Or actually that's the one I recommend. It doesn't make a lot of logical sense, but it's definitely a fun book to start with, so I definitely recommend that one. We're probably going to think of a lot more, and we're going to add them to the show notes as well.
Stefan Tilkov: Joy Clark:Well I think that is all the time we have now. Thank you so much for taking the time to answer all of my questions.
Stefan Tilkov: Stefan Tilkov:Thanks for having me. It was great fun.
Stefan Tilkov: Joy Clark:Another thank you to all of our listeners. Until next time!