Why the Software Industry Doesn't Run Restaurants


July 11, 2006

Click ARCast: Why the Software Industry Doesn't Run Restaurants to listen to this ARCast.

Ron Jacobs:   Let's try that again, shall we? [Laughs] Good morning, friends! And welcome to ARCast. I am the host, Ron Jacobs, your host for architecture information, coming to you live from Eilat, Israel, on the shores of the Red Sea, where I am casually dressed today in my shorts and sandals, you know, kind of soaking up the atmosphere. It is a wonderful place, isn't it?

Beat Schwegler:   It is, indeed [laughs]. Already had a swim this morning.

Ron:   Yes, yes, and you are a very brave man for swimming in the ocean, which is not exactly really warm water, is it?

Beat: Yeah, and don't forget the sharks. [Laughter]

Ron:   No sharks, or well maybe there are some. OK, but today we are going to talk about a very unique topic, and that is why restaurants or why the soft... What is it, Beat? I forgot. Software, business, and restaurants. Sorry!

Beat: Yeah, I think why it's better we in the software industry doesn't run restaurants.

Ron:   OK, let's welcome Beat Schwegler. [Applause] OK. So, Beat, we were thinking about, we were talking about this yesterday, and I said, "What on earth is this? Why is it good that the restaurant business isn't run by the software companies," or whatever I am thinking? Where did you come up with this?

Beat: OK, let me give you the context. I am actually running something that's called architect boot camp across Amia, and this year we actually have the connoisseurs' edition. [Ron: OK.] So, we—which is the cook and… We go to great restaurants and getting some cooking lessons. And then… That was actually in Denmark, and we went to a restaurant, and we finally realized that, two weeks after we cook there, they got the Michelin star, and I was so impressed how organized they actually can do stuff. I mean, you know, as you can imagine, we're 12 architects… We were three groups of four, they gave us some tasks, and at the end we had a beautiful dish.

Ron:   Well, so, you actually went back in the kitchen and supervise... They supervise your cooking and you made there your dinner.

Beat: Exactly. And then I was starting to think what will happen, you know, if we—the software industry—would actually run restaurants. Because they were so well-organized, they were so well-prepared, the structure they have is just amazing, and I realized that the… Lots of their principles they have in place can actually be tied back to software factories.

Ron:   OK, so [you're] going to have to help me to make that leap. Now, let's talk about if I were coming into a restaurant run by the software business, and... What would that be like? How would it happen?

Beat: So, I assume your first experience would be, you are looking for a waiter [Ron: Mm-hmm.] There is none.

Ron:   [Laughs] OK.

Beat: Because, you know, the guy is just cooking [Ron: Ah.] for table number five [Ron: Yeah.]. So, I think one of the big issues you are going to have is… You are going to have a pretty poor experience, because there is a guy with us new to everything [Ron: Yeah.]. So, just imagine, after maybe 15 or 20 minutes, he comes to you and asks you what do you want, and you are going to say, "Do you have a menu?" And he says, "Menu! Why should I have a menu? You can just order whatever you want."

Ron:   Ah! OK!

Beat: And I am going to say, "OK, so I am actually up for a… Let's say steak sirloin with red-wine sauce. And then he asks, "How would you like your steak?" You are thinking, How would you like your steak? Ah! You mean how I would like my steak! Oh! I would like to have it good! [Ron: laughs] So, you soon are going to realize that we have some serious issues with terminology. [Ron: Mm-hmm.] So I, for instance, I love the potato de foie. You, as a waiter, I am pretty sure you're not gonna know what this actually is. So, we are going to have serious issues with terminologies, with … many ways with recipes.

Ron:   A-ha.

Beat: What are the recipes we have in the software industry that we can actually align and we all agree…? I mean, we've got a couple of patterns, do we, but we are not that far, especially if you look from an end-to-end process. So, the patterns are more the stuff we use if we cook something, so… But it's not how you run the restaurant from an end-to-end experience. And then I realized that now we were in that kitchen, and I was responsible for cutting the carrots, and after a while he came to me and said, "Are they all the same size?" I said, "Why! You didn't tell me!" [Ron: laughs] So, he got all the carrots back, he aligned them, took the smallest one, and said, "Now, cut it then to that size." So, they even have some great quality insurance just built into the process. [Ron: Ah.] So, what I was talking about so far was the menu. It was a little bit about the recipes, but the most important thing is they, as a restaurant, you just… You agree on certain types of dishes you're gonna offer. So, it's very difficult going to an Indian restaurant and then actually asking for a pizza. It's just not going to work, because they don't have the tools. They don't have the knowledge how to do that. So, another thing I realized there was that they have to prepare a lot of stuff. So, he told me the stock they have for the red-wine sauce is actually cooked so 110 liters of water put together [with] 10 kilos of bones, then boil it down to 7 liters of stock.

Ron:   Wow!

Beat: So, how can you do this, if you don't know you actually have this on your menu?

Ron:   I don't have a pot that big.

Beat: That's anyway a big issue.

Ron:   Yeah, you know, I have the same kind of experience when... I didn't go and actually get the cooking lesson, but there is a restaurant in Seattle that my wife and I like a lot, and they serve Mexican food, and they had a cookbook, you know. So, I thought "Oh, this would be great!" because the food is so good, you know. So, we get the cookbook, and then we found that it says like, you know, cook a huge part of this kind of sauce and go buy, you know, 10 chickens and you now cook them. Oh, man! You know, it's a kind of thing... The way you cook in a restaurant is very different than you will cook for yourself at home, of course.

But they have a requirement that you don't have, that they have to be able to reproduce very high-quality food, very quickly, when [a] customer wants it.

Beat: And on time and in budget.

Ron:   Right.

Beat: So, which actually is pretty close [to] what professional software development is all about. Isn't it?

Ron:   Yeah, I guess. So yeah, so you mentioned patterns, and I think a recipe is a good way to think about a pattern. In fact, there is a guy that we both know, Wojtek Kozaczynski, who is an architect on the patterns & practices team. And Wojtek, when he was creating the Guidance-Automation Toolkit, started calling these things patterns--I mean, excuse me, recipes--because it was, is like, well you know, if you want to take and build some software, we can just have a recipe for the thing you are building, and [that's] kind of what you are saying.

Beat: Yeah, that's exactly… I mean, if you look at software factories and the four important areas. So, you just mentioned recipes. Recipes is actually something we call "guidance in context." And you just need to have… If you want to have something very reproducible, if you want to be very accurate, and you want to make sure not everyone is the chef—the top chef within your restaurant—you actually have to be able to delegate certain tasks. And one of the kinds of things we do there is actually, we have a recipe which is very accurate, tells you very precisely what you have to do with that meat, what you have to do to actually get to that stock. But they go even one step further, they actually go to the point that there is a description, an accurate description of how you, how you decorate the plate—how much sauce you actually put on the plates, and so on—just to guarantee that the experience for the customers is always the same, always on the same level of quality.

Ron:   Well, you know, that's a very good point that you mentioned about the chef, right, is because these very nice restaurants, they have a head chef, and that person is like the architect of the meal. Right? They say, "This is how we are going to cook it, this is what it is going to look like," the kind of ingredients and the whole instructions for preparing.

Now, if you get some guy right out of cooking school, you know, brand-new in the kitchen, he's not going to go just make up whatever he wants, right? And he's not going to ignore the recipe that's coming down. He's going have to do [it] the way they said. But yet in the software business, so many times everybody wants to be the head chef and kind of create their own way of doing it.

Beat: Yeah, and if you look at what a head chef really is, he actually takes the responsibility from the restaurant actually to guarantee that level of quality. So, to give you an example that the consistency of a restaurant visit has to be good; otherwise, you are not going to get your Michelin star or even two stars. And I think that's something we really lack in our industries, it's this kind of reproducibility and consistency of the whole life cycle. And if I am saying the whole life cycle, it really starts with ordering the menu. How many times have you actually been disappointed just because you couldn't order in time, or you are actually asking for the bill and it just doesn't arrive? [Ron Jacobs: Mm-hmm.] So, it's really the end-to-end experience. So, if I tie this time to the software, it actually starts with the requirements-gathering and it actually ends with the de-provisioning of the software. So, not just deployment operation, but actually how do you get rid of this software, as well.

Ron:   You know, that's a very good point, because so many times we think about... our job is done when we finish that last build, and we say, "There it is! It's done!" You know, and we go walk away, go on to the next thing, and but it's not done.

Beat: Exactly, I mean, it's really… So what we were talking about now, this was actually that we need an end-to-end description of what we are doing, and in software factory we call it the "software-factory schema." So, if I am talking about the description, it actually means that you have different viewpoints of that process, and not only of the process of just the way you develop, deploy, and operate software.

Ron:   OK, can we back up just a second? Because we've been mentioning software factories, and I am sure there are some people who may have heard about this, but really don't know much about what it is, and probably people have heard about it as a concept, but it's actually become very real now. So, tell me little bit about what are software factories.

Beat: I would say software factories is an approach or an idea that wants to make or wants to move a software development, an operation to the next level. So, software factory actually takes a very holistic approach around the problems we have in our industry. So, it's not solely tied to development. It really tries to align operation with development. It really tries to come up with solutions that brings us to that next step of accuracy, consistency, and actually efficiency at the end. And, as I said, it consists of four different areas, so I think it makes sense quickly [to] walk through these four different areas now. As I said, as a restaurant you can't just offer anything… everything, so you actually have to make some choices, and the same applies to software factories. We actually talk about the software product lines, where we are going to say, you know, we have a common side of functionality, and then there are assets we can configure and assets we can customize. So, this is really that the whole concept around the economy of scope, how we can get more efficient.

Ron:   OK. So that's like, you know, there is a seafood restaurant over here, there is an Asian restaurant over here. These are... They have a scope to the kind of foods they offer. Software factories are similar, you know, that one factory doesn't build anything. They have a scope.

Beat: Yeah. I mean if you look at… If you buy, for instance here, a new car, you actually… You decide on the base model, and you can't argue with the car vendor that you want to have your car 10 centimeter shorter, because your garage is too small. Then you would actually go for another base model, but within that base model you then actually can configure that car. But, even more importantly, you can also customize certain assets. So, customization really means, for instance, if you tune your car. So, you have certain extensibility or customization points within that product line. That would be maybe if I am ordering the dish not fried but maybe just slowly cooked, or the configuration which we… I can actually have that curry, that curry madras with lamb or with chicken.

Ron:   Hmm. Hmm. OK! Alright! Gotcha!

Beat: So, the second piece in that whole initiative is really the, as I said, the formal description of what you are doing, which is the software-factory schema. So, it defines different viewpoints. Just to give you an example, one viewpoint could be you deal with service orientation, another viewpoint could be you deal with manageability of that system. And for every viewpoint you than actually tie back to tools, the patterns, even the processes that allow you to describe that viewpoint very accurately. And also we actually link these different viewpoints together. To give you an example, if you actually take an order in a restaurant, you have a name for that menu and, actually, once you give that order to the kitchen, it's actually tied to a recipe. They know exactly what to do. But also this is actually tied to a price. So, once you check out, they can calculate the cost that accumulated during your stay. Another thing is… The third pillar is really the model-driven development. And to describe this in the context of the restaurant, it's like you have a visual menu that allows you to see what you actually get. So, it's a description of certain artifacts that you then actually leverage within your software-factory schema. So, if you look, you can define or you describe with a model your distributed application diagram, or another thing you could describe is, for instance, the capabilities within the business architecture. And I think we already talked about the last pillar, which is actually the guidance in context, where we have for instance a recipe framework.

Ron:   OK, and in fact... So, my old team, patterns & practices, has started... has now kind of become part of the same team that build the software-factory concept back in Redmond, and so now we are seeing... they are producing software factories actually, and they have the first couple of them in development right now.

Beat: Exactly! And one of the things is, we really want to start small. So, I mean small in a sense of… As I said, the software factory is really this end-to-end thinking, and pretty obviously thinking end-to end-is really… [Ron: Oh, sure.] Yeah, it's really something you have to know what you are doing. So, what we do is actually we start some factories that deal [with] certain viewpoints. So, for instance, service factory that actually got released, the first public drop a couple of weeks ago, that just deals with how you develop a service with tools, with technologies like asmx and Windows Communication Foundation. But in the future, pretty obvious, this also has to be tied to the fact how you operate them, how you manage them, how you deploy them, or more importantly how do you actually move from the requirements-gathering to the development process.

Ron:   So, let me think about that for a minute, because... Alright, so we know that people are concerned about manageability of services, you know. And it's one thing, you know, where I create 5 to 10 Web services and we put them out on a server. OK, that's fine. But when we get a thousand Web services that are running mission-critical things all throughout the company and we have no strategy for managing them, we get really nervous about where that leaves us. And so the first thing you are going to do is, you are going to come up with a strategy. You are going to think about, well, here is what we have to do. We have to tie into this management product, maybe it's Microsoft Operations Manager or some other product like that. We are going to have to instrument the services so we know what they are doing, how they are performing, how healthy they are. We have to understand the control surfaces of our services, like, how do you stop them, how do you start them, how do you pause them, disable them, these kinds of things. Right? And manage the security of them. So, alright! Everybody understands, I think, those steps that you have to come up with this list of things, and once you have answers to those questions, the hard part is getting the development teams all over the company to consistently do the things you ask them to do. And is this how the factories are going to help?

Beat: I mean… Factory is really help in a way that you actually can describe different viewpoints. So, manageability is actually nothing else than one viewpoint you could add to your software-factory schema. So, how you could actually describe how you want to manage your services, and then having that crosscutting concern actually in your factory would allow you to then create, generate, or whatever kind of technology you want to use, services that are perceived and are manageable. So, it's really what we want to do is… We want to create viewpoints that are clearly understandable, that are not too complex, add tools to these viewpoints, add patterns to these viewpoints, add framework to these viewpoints. So, to give you an example, if it comes down to manageability, for instance, we actually can then create certain health models that would allow you then getting information about your service. And in addition to this, if you realize something goes wrong, you could also attach certain actions you can take. And, again, this would then tie back into MOM, where that allows you to see how healthy your services are.

Ron:   OK. So, you know, it's like if you describe in the factory... I think of it this way, it's like, when you, you know... going out of the restaurant for a minute to go to the car factory, because you were talking about cars for a while. In the car factory, there are parts made at many factories around the world, right, but they all are made to precise specifications, so it's repeatable every time, you know. Somebody stamps out the metal for the door frame, for example, you get the same thing. And it meets the requirement exactly, which is exactly what we want to achieve here, that when people are building services and a lot of different business, you know, it's a lot of different developers, that they meet the requirements for a viewpoint like manageability or security exactly. So, that's, I mean, that's where we want to go with this.

Beat: Exactly! If you look, I really like the car manufacturing, because it really nicely explains the concept of the pro software product lines. Because if you look at that, you have certain base… just to take the example, for instance… some of the German cars, they have numbers from 2 to 8. So, you actually decide what kind of base model you want, and depending on that base model, you can actually configure it, and pretty obviously if you go for one of these called 8, you have more options, because it's a high-end car. Where, if you go for the model that has a 2 at the end, for instance, maybe you even have in addition to pay for your air conditioning. So, the whole way you can structure your product offerings among the stuff that is common across all the models, the stuff that is just tied to a specific model, the way you then actually can pick and choose based on a configuration and ultimately even you can customize. To give you an example about customization is, really, if you start to get into the tuning, where you just have your very own engine that maybe has three times more powerful than anything you would get from the manufacturer itself.

Ron:   OK, but is this software factory something that, you know... Microsoft builds the software factory and hands it to you, and that's it? You're stuck with it, and if you don't like it, too bad, it's just what it is, what it is? Or do I create my own software factory, does somebody else create them? How do you... Where do you get these from?

Beat: I think that's a very good point, because… If you look at a software factory—and I described with the schema—this pretty obviously implies you need to know what you are going to do. And since we, as Microsoft, we don't know what kind of problems our customers are… I mean, we have an idea, but not accurately solution to the problems they have. So, what we as Microsoft can offer you is actually a factory to create [easily] other factories. So, we can come up with tools that allow you to create the schema, we can come up with tools that allow you to create visual languages like the DSL toolkit, we can actually create a tool that allows you to implement recipes like the recipe framework, and so on. So, Microsoft's role is really that we want to create the factory to build the factory, and supporting therefore that thinking.

Ron:   OK. Yeah, as a matter of fact, the DSL tools... I did an ARCast with couple of the engineers who work on the DSL toolkit from Cambridge, when I was at the U.K. Architecture Insight Conference, so if you want to hear a lot more about that, you can listen to that ARCast. And in effect they mentioned that they used their own tools to generate the code that built their tool. It's kind of a recursive process. [Beat Schwegler: Absolutely.]

Which is terrific, but so not only a rebuilding this kind of this factory that helps you to build factories, so to speak, but then if you said, "Well, you know, I don't have a lot of very specific requirements, I just want kind of a general-purpose factory," then that's the stuff like patterns & practices building, like, the service factory. So, if you don't know where to begin and you just say, well, I want to know the right way or the recommended way they build services, you can pick up the service factory. It's going to guide you through. At least, what the patterns & practices team's opinion about the right way they build it. If you say, "Well I disagree, I think I like this better or that better," could you change it?

Beat: Yeah, that's actually a very important asset of factories it's, really this customization. So, as I said, it's not only configuring. Configuring implies someone thought about it up-front. So, he knows what are the different options. But factories should be actually open for customization. Because this is… I just thought that you have an idea what the problems are going to be that will arise if you, for instance, use a factory or what kind of specific outcome you want to create. So, there is this kind of area of customization, and that's a very important aspect there. But let me say something around the service factory, as well. It's very important to see that what we see at the moment as factory, these are really the first steps, and there is this long-term vision, and the long-term vision really is that end-to-end story. So, the experience from the entering the restaurant, the eating… the ordering, the eating, and actually the paying: This is really what we want to achieve. At the moment, if you look at the service factory, it's really about the development. So, it's about the cooking of the recipe or the cooking of the dish that is actually at the moment covered, so it is just important to keep this in mind if you have a look at the service factory.

Ron:   OK. So, I am curious about how... I am trying to imagine how, say, the process of ordering from the menu... When you first come in, you sit down, you talk to the waiter, they hand me the menu and then you select what you want. I am curious about, how does that relate to a factory? With the software factory maybe, say, here are the five things you need to know from your customer before you start filling out this, you know, running this factory, or something like that?

Beat: Exactly, so you would actually… You would create a tool, maybe. I mean, a tool could be a language, a visual language that allows the customer to formally express his requirements. And because it's formally expressed, you then actually can transform that into other artifacts, which in that case then would be, maybe development artifacts.

Ron:   Oh, OK. So, this is where the DSL tools come in, so we might draw a diagram of the thing we want, it can be visual in any number of ways, right, and then we can say, "Let's turn that diagram into something that works." The diagram helps us to capture the information we need to drive the factory, to build the thing.

Beat: Exactly. So, that's really the whole point is, we want to get an end-to-end story, we… Because we want to step up to next level, want to get more predictable, more efficient, and at the end actually deliver on our promises.

Ron:   OK, and so then once we build something with a factory, we have some metadata about the thing we built, and that metadata could then live beyond the building of it, and be input into, say, like a management tool like Microsoft Operations Manager. So we, in the process of building the factory, we captured metadata about how we want to manage it, how we want to secure it, and so forth. All that information can go right on into the next phase of the life cycle.

Beat: Exactly, and if you look at what the DSI initiative does. So, the domain… the Dynamic System Initiative, this is exactly how we want to align actually the development of the system with the operation of the system, that we actually have models that we can then leverage while we operate the system, so models that we create during the development time of the system that allow us actually to better understand how they are operated on one side. But also, if something goes wrong, that we can tie back to who actually caused that issue.

Ron:   Ah, OK! And, in fact, if you want to know more about DSI, we have a couple of ARCasts about that. So, Beat, thank you so much for joining me here today on ARCast from Eilat, and we will have much more. We have another ARCast here this afternoon, and then I will be headed off to Egypt, later today. So, couple of days in Cairo and then back home on Sunday. Wow! Two long weeks on the road, I am ready to go home. [Laughter] Thanks a lot, everybody.

Beat Schwegler, ladies and gentleman! Beat is a colleague of mine from Switzerland and a smart guy, enjoying the restaurant cuisine and thinking about architecture. And that's what we do. We think about the stuff, day and night, looking for how we can bring you the best information from all over the world, because that's our work about here on ARCast.