 Hello, Thomas. Hello, Thomas. And first of all, thank you very much for inviting me along to this. It's been a, it's a, it gives me great pleasure and it's great honour to be, to be invited. So I'm very pleased with that. I'll be sharing my screen in a moment and I will make sure that all the slides are available to people after the, after the presentation is finished. I'll also be drawing on some of the slides as well as we go through and the annotations that I make. So everything that I write onto the slides will also be saved. And at the end, this will be made available to everybody. But there we go. So first of all, I'm going to share my screen and here we go. I can find the right screen. That should be the right one. So hopefully you should see a screen. If someone can just confirm it says model based systems engineering part one complexity. Yes, yes. And it's the whole screen. Yep. Yep. Yeah. Perfect. That's absolutely perfect. So thank you very much for that. So thank you for the lovely introduction. So as Thomas said, my name is John Holt. That's what I normally look like at the moment you've caught me at home in my home office. I don't look quite like that. I look a bit messier. I've normally got the hat on. You'll be pleased to know I'm also joined today. I've got my cat on my lap. So if you hear any strange noises, that might be the cat that might not be me. So I would just warn you about that now. As Thomas said, I work for a company called Scarecrow consultants. I'm also a professor of systems engineering at Cranfield University. And I'm the current technical director of Incozy UK. So to get to begin with then when we when I was in asked to do this, this is actually the first of three presentations that Thomas has asked me to do. The problem that I have is whenever anybody asked me to do something, I immediately agree because it's months and months in the future. And then when the future arrives and the future becomes the present, I then think, oh no, I've just promised to do three presentations. This is the first of three presentations. And as such should be treated as almost like an introduction to what we're going to be doing in some of the others. So what I've been asked to talk about in the first one is the need for model based systems engineering. And, you know, to really sort of make the case for model based systems engineering. So that's going to be the topic of today. There's not going to be much MBS a technical content for today. We're going to be saving that for the other two presentations, but I am going to be going to be talking about why we need model based systems engineering and why it is a real need. Now, a little bit about my background. I've spent my whole career working in model based systems engineering. And so for the last 30 years, that's pretty much everything that I've done has been model based systems engineering. Although 30 years ago it wasn't called model based systems engineering. I was just applying modeling to different types of systems. And what I've seen is over those years is the questions that people would ask has changed significantly. So if I was to go back 20 or 25 years, I'd go to different conferences and different events. And some of you would have actually seen me at some of those if some of the older members of the audience like Andy is there for example would have seen me all these years ago. And I spent all of my life arguing with people about why modeling was a good idea and why we should model. And then about probably, let's say 10 or 15 years ago, the question changed. And people finally started to accept that modeling was a good idea and it was a good thing to do. But what people then wanted to know was actually how do we model effectively and efficiently. So the question had changed. And one of the reasons why the question has changed the main reason is because modeling became accepted. It became sort of popular wisdom rather than just a strange idea. And so that was very good. But the question changed. So the way that we deliver these presentations would change to reflect that. But what would what then happened probably about five years ago, the question changed again. And the question then became, well, how do we deploy model based systems engineering in our organizations? How do we implement this this modeling this MBC in our organizations. So as the years have gone on, I've seen this change in attitudes and opinions towards MBC and a far greater acceptance of MBC. And you can see this anybody that's been involved with in cozy for any number of years, just look at the papers that we have in the conferences. So, you know, 10 years ago, 15 years ago, papers on MBC would have a title something like using MBC to do this applying MBC to do this. They don't really do that anymore. They tend to just be titles like, you know, applying systems engineering to something. And most people now I think it's fair to say certainly in my experience, most people now are using to some level or another some level of modeling and some level of MBC. So I want to talk today about why that is and why we've seen this increasing need over the last few decades for model based systems engineering. And I'm going to illustrate that with a few examples. And then I'm going to finish off by just talking about this evolution of MBC as well and why it's become why it's become so important. Now I would say before we before we begin, people say, well, how is the need for model based systems engineering different from the need to systems engineering. And in my opinion, it isn't because in my opinion, model based systems engineering is systems engineering. There's nothing that we do in systems engineering that we can't do with model based systems engineering. If we can pair MBS T with a topic like requirements engineering requirements engineering is a sub discipline is a small part of systems engineering. MBC isn't MBC is systems engineering. And if we're going to be arrogant about it, I would argue that MBC is doing systems engineering in a more rigorous in a more repeatable and in a more demonstrable way. And that's one of the things that we're going to be talking about over the course of these are these three seminars. So let's let's move on and let's move on to the main subject of what we're going to talk about which is this idea of the need for model based systems engineering. And when we look at the need for model based systems engineering, we can look at the need for systems engineering as our main influence for that. And if we talk about why we need systems engineering. To me, the answer is quite simple. There's lots of books on the subject, but basically, we have system failures, we have system disasters, we have projects failures project overruns and so on. It's very easy in the real world. And I think that's one of the big qualifiers for systems engineering is in the real world. It's very easy for things to go wrong. Okay, if things didn't go wrong, I wouldn't have a job. Okay, or I wouldn't have the job that I have now. When we look at why things go wrong. If we start to do the literature work on system failures system disasters project overruns will find that most literature agrees that there's three fundamental causes for things going wrong. And these are complexity in our system. I'll talk about that in a moment. Communication problems so we can't talk to different stakeholders in a way that they can understand. Because different stakeholders speak different languages so communication is key to everything that we do, but also this lack of understanding across the entire life cycle. We have to remember that as systems engineers, we actually we deal across the whole life cycle at least we take into account the entire life cycle, even if we not directly involved with each stage we're aware of the bigger life cycle, and we work, bearing in mind that there are a number of stages in the life cycle. But what I want to focus on to begin with is this idea of complexity and that's going to be the main focus of discussion for today because we'll see that this is one of the big drivers for complexity. So when we talk about complexity in our system. First of all, you know what do we mean by complexity. And, you know, where does it occur. So, there's two broad categories of complexity. There's what we refer to as essential complexity, and what we refer to as accidental complexity. Now essential complexity is called essential because it lies in the essence of the system. Okay, it's naturally how complex something is, and we can't really reduce that. We can't lower that level of complexity. However, just because we, we can't reduce that it doesn't mean we can't manage it in some way. So we can actually manage the essential complexity, even if we can't reduce it. So for example, if we can identify this where this complexity lives, we can maybe minimize the way that we interact with that part of the system. So we find that one part of the system exhibits a lot of complexity. Then maybe we can limit the way that we interface with that part of the system or the behaviors associated with that part of the system. Although we can't lower or reduce the essential complexity, because it's naturally how complex something is, we can certainly try to manage it and cope with that complexity. Another type of complexity that we need to be aware of is what we refer to as accidental complexity. And accidental complexity is our fault. Accidental complexity is introduced by our people, our processes, and our tools. And that we certainly can reduce. We can lower accidental complexity. But again, a crucial part of that, an important part of that is being able to identify the complexity in the first place. So with essential complexity, we can't lower it, but we can manage it, but we need to identify it with accidental complexity. We can lower it. But again, we need to be able to identify where this complexity lives. And it would be good if we could spot or we could see or identify this complexity. And so what I'm going to do now I'm going to attempt to draw on my screen for the first time. And I'm going to draw three boxes, and I'm going to label them A, B, and C. Okay. And there's a couple of things I need to point out at this, this juncture in the presentation. So some of you may have spotted I'm wearing dark glasses. Now the reason I'm wearing dark glasses is because I'm quite badly dyslexic. And these helped me not be quite so badly dyslexic. I'm very confident that I can spell the words A, B, and C that we can see on here. But beyond that, there's no promises. So when I write words on the screen, if they're not in the traditional order that you're used to seeing them so maybe the letters are in the wrong order, or there's more syllables than is traditional, then you don't need to point it out to me. I know that I'm doing it. Okay. So that's the first thing if there's any peculiar spellings. That's my dyslexia. It's, it's kind of it is me, but it isn't me. That makes sense. So what we've got here then are three things that are going to form part of our overall system. And I'm just going to label these A, B, and C. Now these could be anything these could be systems or subsystems or processes or organizations, people, it doesn't really matter. So, for the sake of the example, let's imagine that A, B, and C, each one of those is a statement of need. It's a requirement. Okay, and let's imagine that each requirement is has been very well written. It's got some lovely text associated with it, and it's got a unique identifier and so on. And let's imagine that I read A and I understand A and I read B, and I understand B, and I read C, and I understand C. Now the assumption that is often made at this point is that because I understand A, B, and C, that is I understand the system as a whole, I understand the requirements set as a whole, because I understand each of the constituent parts. However, that's not actually the case. Okay. Because what we got here is an oversimplified representation of the true situation. So what I can do, I can actually start to introduce some complexity into this by just drawing some lines between these, because each time I draw a line between them, what I'm doing is identifying relationships. And every time I have a relationship between these three, in this case these three requirements, I've identified potential interactions between these elements. And this is one of the main ways that complexity manifests itself in the real world is on the interactions between things. So I need to make sure that I can identify these otherwise the complexity is hidden from me. If I draw some more lines again, this is becoming more complex. And if I take my red pen and draw lots more lines. This is absolutely horrible. Okay. So what people will say at this point very often is, well, hang on, you've just made this more complex, you've introduced all this complexity, you've made it more complex. I used to understand it, I understood A, B, and C. And now I've drawn all these lines on I made it more complex. I haven't made it more complex. What I've done, I'm a systems engineer. And one of the things that we apply in systems engineering is systems thinking. And one of the key tenets of systems thinking is we don't think about things in isolation. We think about them and the relationships between them. And that's key to our understanding of things. So what I've done, I haven't made this more complex. What I have done, I have highlighted the complexity that was previously hidden in my system. I've highlighted these relationships on here and therefore these potential interactions, therefore this complexity. I haven't introduced that complexity myself. It was always there that previously it has been hidden from me. So this is one of the ways, and a very good way that we can identify that we can see complexity in our system. And a very good way to do this is by applying modeling, because when we model, we think about things. And very importantly, we think about relationships between them, and we visualize them. One of the key parts of modeling is visualization. And by visualizing these lines, it allows me to visualize the complexity that's actually in my system, whether I realize it's there or not. So we need to identify complexity in order to cope with essential complexity, and in order to lower accidental complexity. And this is one of the ways that we can use, for example, modeling to do that. But what we now need to consider is the nature of this complexity, and very importantly, how this complexity has changed or how it's evolved over the last few decades. So we're going to consider a simple example. So this is an old car. Okay. So the system we're going to consider is that of a car or an automobile. This is one of the first cars that I ever owned. Okay, this is a 1969 Triumph Herald. Technically, it's a Vitesse, but it's a Herald. Okay. And Triumph, many, many years ago in the UK, we used to have a car industry. We don't really anymore. But Triumph was one of our one of our big companies. I didn't own this car from new, but it was a fabulous car. It was very, very beautiful. And I loved this car before it died on me. So this car as a system, we can ask ourselves a few important questions. So as we would for any sort of system, we can ask ourselves, what's the high level need for that system? What's the high level needs and the high level need for this system is to take me from A to B. Anybody that ever owned a car at this age, or maybe your parents owned a car at this age will realize that this system very rarely satisfied both of those requirements in any single journey. Okay. If we then ask ourselves, what are the, how do I interact with this car? What's the human machine interface? We say, well, for the car, it's the steering wheel. It's the gear control and it's some pedals that I press with my feet. So very high level, very simplistic view of my system. Now, what's the need is to get me from A to B? What's the human machine interface? It's the steering wheel, the gear control and the pedals. If I compare this system with its modern day counterpart, it might look something like this. Now, it doesn't matter what make this car is, you know, who the manufacturer is or anything like that. All we need to know is that this is representing a modern connected vehicle that might be autonomous or semi-autonomous, and it's an electric vehicle, for example. Okay. And if I ask myself the same questions concerning the modern vehicle, what's the basic need is to get me from A to B. And if I ask myself, what's the human machine interface? Well, it's a steering wheel. It's a gear control and it's pedals. Okay. If we had no domain knowledge regarding cars, regarding automobiles, if we just consider these as systems and we had no domain knowledge, and we looked at the overall need and the HMI for each of them, we might be fooled into thinking that we would realize them in the same way. Okay, because the basic needs the same, and the HMI is the same. What we need to appreciate is that is simply not the case that we're seeing here. And because if I was to say to you, which is more complex than modern vehicle that we can see on the right hand side, or the old vehicle from 50 years ago on the left hand side, almost everybody would say the modern vehicle. But it's not good enough just to say which is more complex. We have to consider the complexity and the way that that's changed or the way that that's evolved over the last few decades. And we're going to consider four ways that's changed. And the first way is to consider the system elements. And therefore, the interfaces between them. If we consider the system elements for this car on the left hand side, 95% of them are mechanical. Okay, there's a few electrical elements. There are headlights, there were windscreen wipers, there's a horn that goes beep beep, and there's the starter motor. That's it. The wiring diagram, the electrical wiring diagram for this vehicle fits on one side of a single sheet of paper. And there's still enough room around the edge to make notes. Okay, it's incredibly simple, the electrical system. Therefore, if we consider the interfaces on this system, the vast majority of interfaces are mechanical, there's a few electrical, and there's a very few electromechanical interfaces. So you can imagine the system elements has been like a B and C on the previous side, and the interfaces being like the lines between a B and C. Okay, if we move so, and that was what a car would be typically like in the 1970s. If we move into the 1980s, what we'll see is there's a brand new type of element starts to arise. And that's electronics. Okay, so we've now got more letters A, B and C, D, E, F and so on. But very importantly, because it's a new type of system element, it brings with it new interfaces. So now we've got electronic interfaces, we've got electronic to electrical interfaces, we've got electronic to mechanical interfaces. So the number of letters A, B and C is increasing, the number of lines is increasing, therefore the complexity is increasing. If we move into the 1990s, we start to see software being deployed around the car, individual pockets of software. Again, a new type of system element, therefore, new types of interfaces. If we go into the 2000s, we start to see networks, so control area networks and things like that, buses around the car system. So again, more elements, more interfaces, protocols, all these extra levels of complexity coming in. And if we look at a car, a modern day car, it's also connected. It's connected to the outside world, it's connected to GPS and all sorts of other things. So what we now start to see is this whole other level of interfaces. So what's happened is as time has gone on over the last few decades, the system elements, it's not just the number of them has increased. The nature of them has increased because of things like technology and therefore the number of interfaces has increased. So overall, the complexity of this system compared to this one is incredibly high. The second way that I want to look at is by considering the constraints that we have on this system. And by constraints here, I mean anything that's going to limit the way that I can realize my system in some way. So things like safety, reliability, maintainability and so on. Let's consider safety to begin with. So this car, it had seatbelts in it in the front, but not in the back. The seatbelts that it had in the front were like you get on an aeroplane. They were the ones you put over your lap. They were static. You had to adjust them manually each time you got into the car. They didn't go over the shoulder. And here's the kicker here. Here's the big thing. Up until 1983 in the UK, it wasn't the law. It wasn't mandatory to wear seatbelts in a car. It wasn't until 1991 that it became law in the UK to wear seatbelts in the back of a car. Now, if you compare that to today, if you got into a car today and there were no seatbelts, you'd get straight back out again. And what's changed here is our attitude towards safety, but also the constraints that we have. So things like the standards, the legislation. Okay, this system on the right-hand side here, not only does it have seatbelts, it's got airbags. It's got crumple zones. It's got side impact protection. It will stop you veering into the next lane on the motorway. It will stop you crashing into the car in front. And what's changed here is the constraints that we have there. And these constraints are driven by things like the different stakeholders' attitudes towards things. Think about the environmental aspects of this. It won't take you long because there aren't any environmental aspects of this. It's got an internal combustion engine. It's got leaded fuel. There's no concept of either using recycled parts or recycling the parts afterwards. All these are now enshrined in standards and legislation that we can now see. Look at the stakeholder expectations of these cars as well. Introducing more constraints, maybe not legal constraints, but customer constraints. Up until, let's say, five years ago, many cars, when you saw an advertisement on television, were sold on the basis that they went very fast and they went very fast very quickly. 0 to 60 in five seconds and so on. We don't sell cars like that anymore. We sell cars based on the user experience, based on the driver experience. So the whole attitude towards these constraints has changed enormously over the last few decades. And because of these, you know, far more constraints, it's increased the complexity of our systems. The third way that the complexity is increased is because the system that we see on the right-hand side is truly a system, part of a wider system of systems. We live in a connected world. Our entire world is connected. Everything we buy is connected to the Internet of Things, to the Internet, to the cloud, and so on and so forth. And cars are no different. What we're starting to see is now, so when I talk about the system of systems, it's not just a number of systems interacting with one another. It's a number of systems interacting with one another to deliver some sort of high-level behavior or capability that none of the constituent systems, what we refer to as constituent systems, can do by themselves. And so, for example, now in the UK, the wider system of systems for the car is the UK road network. Now, if you've ever driven in the UK, it may be difficult to believe that there's any sort of high-level intelligence that's monitoring and controlling the way that we drive our cars, but there is. So the traffic flow is monitored on motorways, the speeds will change, traffic lights will change, and so on. We've got this higher-level system of systems that's using information that's shared by our vehicles to give us a more seamless journey. I can take this up to the next level and say, well, what about the transport network in the UK? What we're able to do now, I can leave where I live and say, I live in Wales, on the left of England. If I want to travel to London, I can get an app and say, take me to London and do it in as green away as possible. And what will happen, the app will say, leave my flat where I live, get on a bicycle, cycle to the train station, get on this train, when I get to London, there'll be an electric taxi waiting for me, and that will take me to my destination. And now dealing with end-to-end capability here, rather than making these individual plans myself. So the car is truly part of a wider system of systems. And this leads us onto the fourth point I want to make, oops, spoiler alert, the fourth point I want to make, which is this, of a complexity shift. If we look at the elements that comprise our systems, now let's look at the motor in both of these. The motor in my old Triumph Herald is an internal combustion engine. It's entirely mechanical. If I look at the complexity of that motor, it's mechanical complexity. If I look at the modern-day counterpart, if I look at an electric motor, the mechanical complexity is almost trivial. There's basically this one moving part in an electric motor, and that's the rotor that whizzes around in the middle. The complexity comes in because of the software that's controlling it. So it's not fair to say, this is more complex than this. It's different types of complexity. We've seen a shift away from mechanical to electrical when it comes to engines, for example. But we're also seeing this shift, not just in the technology that we're using, but also relating back to system of systems. The responsibilities that I had as the driver in this old car, in the old Triumph, are now largely being taken up by the car, by the actual the system part of it. This system is now interacting with the outside world, whereas I used to have to use my eyes and ears. I don't have to quite as much anymore because we've seen this shift away from what we've got here into these automated systems, these cleaner systems that we're starting to see on the right-hand side. And just to really compound things, all of these things work together. I've got an electric vehicle. I would love to say it's a Tesla, but it isn't. I've got an electric, what we call in the UK, a moped. So if you know like a Vespa or a Lambretto or something like that, I've got an electric one of those, and it's fabulous. And it exhibits all of these things. There's a complexity shift. It's got a twisty grip that makes it go forwards. It's got a battery under the seat. It's got a Bosch washing machine motor on the back wheel, and it's got software. OK, we've seen this complete shift in complexity. It's truly part of a wider system of systems. I've got an app. So if I have a fleet of these, I can control the fleet of them. It connects to GPS and 4G. OK, it tells you where it is at any point in time. It runs diagnostics. It will tell me if it's moved, if it's fallen over, it will plot every route that I take and tell me the average speed and so on. The system elements and interfaces that we got on there now are completely different from what we used to have. The constraints, safety, it limits the speed. It won't let me go over a certain speed. It won't let me decelerate more than a particular rate of change. OK, it reclaims energy from when I put the brakes on and use it to charge a battery. It's got cruise control on it. This thing is crazy, but it's what we're seeing here is the manifestation of all these different types of complexity that have evolved over the last few days. Over the last few decades. So it's not good enough just to say the complexity is higher. We have to think about why it's higher and how this complexity is evolved over time. And complexity has a shape and the shape that complexity has is the shape of a brontosaurus. And this is what we refer to as the brontosaurus of complexity. The idea is that the magnitude of the complexity is analogous to the thickness of the brontosaurus. So there's a thing called the brontosaurus theory that was first coined in 1972. And the brontosaurus theory states that a brontosaurus is very thin at one end. It's much, much thicker in the middle and it's very thin at the other end. And the idea behind this is that whenever we start a project, this is a human eye. We look into the face of the brontosaurus. And when we look into the face of the brontosaurus, what we see is the we want to go from A to B. We see this is the human machine interface. We see the very simple high level representation of what our system is and the complexity as a consequence of that is very low. And we look into the smiley face of the brontosaurus and the brontosaurus smiles at us and we smile back and the brontosaurus winks at us and we wink back. And the world is a very happy place and we do all of our cost and time resource estimates based on the smiley face of the brontosaurus. But then we start to deploy our systems techniques. We start to model things. We start to do stakeholder analysis and the complexity starts to increase. We start to do contextual modeling. The complexity starts to increase. We start to scenario modeling the complexity increases. We look at different candidate solutions. We end up here in the belly of the brontosaurus where the complexity has got out of hand. There's different people using different software to do the same thing or even worse, different people using slightly different versions of the same software that are in no means by no means compatible. You go into a room, someone's drawn a diagram. This is big as a wall and they say, look at my diagram. It's as big as a wall. Aren't I clever? And the answer is you're very clever, but nobody can understand your diagram because it's as big as a wall. What we have here when we're in the belly of the brontosaurus is a solution to the problem that we got here, but it's overly verbose. It's overly complex. It's difficult to understand and we can't communicate it very effectively to the different stakeholders in a way that they can understand. And you say, well, what's wrong here? I've done everything right. I've done all the right things, but the complexity is now it's gone out of hand. But then something interesting happens, because if we continue with our modeling, if we continue with our NBSE, the complexity starts to go down and it goes down and down until we get to the tail until we get to that point. And what we have at this point is a concise, elegant solution to the problem that we had up here. It's as simple as necessary, not as simple as possible, as simple as necessary and no more so. We can understand it and very importantly, we can communicate it to the different stakeholders in a way that's meaningful to them. In order to go from the smiley face to the tail, we always have to go through the belly beforehand. It's impossible to make the transition from smiley face to tail without going through the belly. I've been doing NBSE for 30 years. I can't go from here to here without going through the belly. However, if we employ NBSE successfully, what NBSE will do, it will make the transition as short as possible. And crucially, it will make the belly as slim as possible as we're making this transition from smiley face to tail. So the complexity will always go up, but using NBSE will allow me to control and to manage that complexity and to make the whole transition as painless as possible. So just to deploying NBSE, the things, various things we need to consider. We mentioned accidental complexity and we mentioned this is because of our fault because of our people, our processes and our tools. This is what we can see here. By people, we mean competent people with the appropriate skills to do their job. By process, we mean approach. Do we have a good approach in place? And by tools, we mean anything that's going to enable us or make our lives easier. These lines are important. We mentioned how important the lines were. There's just two lines on here at the moment, and these are crucial. We need to make sure that the competencies of our people, the skills, the knowledge, the attitude of our people enables our approach that got to be very closely coupled. We also need to make sure that our approach drives the tools and not the other way around. As soon as we use any tool, it's going to constrain us in some way. We need to make sure that our approach drives it. We can control the way that the tool is being used. We shouldn't be changing the way that we work because that's what the tool wants us to do. That way lies madness. Okay. And this brings us on to the whole idea of the evolution of MBSC. As the complexity of our systems evolve over time, as the complexity evolves over time, so must our approach to systems engineering. And the main point that I want to make today is MBSC, we should consider has been a natural evolution of systems engineering. If we look at how MBSC evolves, if we're trying to deploy it in an organization, we've identified five stages here. Document-based systems engineering, document-centric systems engineering, model-enhanced, model-centric, and model-based systems engineering. A document-based approach. Obviously the graphics represent in the pile of documents, but crucially it's representing where the information and the knowledge that we need to develop our system lives. What owns it and where does it live? It's owned by the documents and it splits across this disparate set of documents across the whole organization. Usually hundreds, if not thousands of different documents across the whole organization. This is what we mean by a document-based approach to systems engineering. All of the knowledge or the information lives in and is owned by the documents. And I would say at this point, and I'm being very serious about that, there's nothing wrong with this. Because what people will often say to me is, we've been using the same approach, the document-based approach for the last 20 or 30 years. Why should I change to a model-based approach? There's nothing wrong whatsoever with a document-based approach. If you want to build Triumph Heralds, if you want to build a system of the level of complexity of a Triumph Herald, then this is perfectly acceptable. If you want to build a modern connected system where we see in those four different types of complexity, the system elements and interfaces, the constraints, the connectedness, the system of systems and the complexity shift, then the techniques that you use to realize that system are going to have to evolve as well. Model-based systems engineering, I would argue, is a natural evolution of document-based systems engineering. We go to document-centric where we see diagrams and pictures being used to enhance what's already there. That's why the pile of documents has got bigger. We start to see at stage three the model emerge from our documents. It's incomplete. It's very incomplete. It's emerging from our documents. Stage four, model-centric, we see the model is almost complete and stage five is complete. But people will say, what, so we're never going to have documents again? No, of course we're going to have documents. But the point here is our documents at this point are just different visualizations of my views. They're different manifestations of my model views. They're not entities in their own right. They don't own the information. They don't own the knowledge. It's just a way to visualize that information and knowledge using text, using graphics, using whatever. When we have a model-based approach to systems engineering, all of the information, all of that knowledge is brought together into a single conceptual place that we refer to as the model. And crucially, all of that information is consistent. Otherwise, it's not a model. When we talk about model-based, it doesn't mean we're getting rid of documents. It doesn't mean we're getting rid of text. It doesn't mean we're doing everything in SysML. We can use whatever notation, whether it's SysML, whether it's simulation, whether it's mathematical languages, whether it's text, whether it's tables. What MBSC is concerned about is all of that information is consistent with each other and we're presenting this single source of truth. That's what we're talking about with model-based systems engineering. So I introduce this by spoke about the reason there's a very real need for MBSC, and this is the point that I want to make now. MBSC, we're not just doing it because it sounds like a good idea or it's the latest technique or whatever. There's a need for that because the complexity of our system has evolved enormously over the last few decades. And as the complexity of our systems has evolved, so must our approach to systems engineering evolve to match that. That's where I see model-based systems engineering. In the next presentations, I'll be talking about more specific technical aspects of MBSC and how we can use MBSC to realize everything that I've spoken about today. Before we go, Christmas is just around the corner. Everybody loves Christmas presents. Buy your whole family some books. Buy all 17 of my books and get a free shrine. Thank you very much for allowing me to come in. Thanks to Thomas. Thanks to Amir. Thanks to Nkozi. Thanks to Nkozi German chapter and all the sponsors. Please follow us on LinkedIn. Join us for our silly puzzles that we do every Friday morning. And thank you very much. So many people for turning up and I'd be happy to answer any questions. Thank you. Thank you, John, for the great presentation. I will look now over the questions that have been posed from the audience. And the first one is from Mr. Goldman. So isn't MBSC just a tool approach to system engineering? No, I would argue it's not just a tool approach. And that's very important because this is going to be the main focus of the next presentation. MBSC is a lot more than the tool. The tool allows me to implement things. It will allow me to implement, for example, notations. Notation are very important. Things like system are very important, but they're a small part of it. We've also got to have an approach in place. We need processes in place. We need frameworks in place that allow us to control the model. The model itself is our abstract representation of the system. The goal of MBSC is not to produce a model. The goal of MBSC is to realize the system successfully. We just happen to be doing that by using a model. The tool itself is crucial, but it's one small part of the big picture that's MBSC. And so I would argue, no, it's not just a tool-based approach to doing it. Being tool-based is important, but that's a small part of the big picture that's MBSC. And as I said, that will be the main discussion for the next presentation. We will look forward to it. Thanks. The next one, surely, if the need for MBSC is no different from FE, there would be no motivation for the organization using document-based system engineering to model-based system engineering. Well, I think that's the point I was making. The reason is, if the complexity hadn't evolved so much over the last few decades, you'd be absolutely right. And there's still a lot of value in a document-based approach to systems engineering. But when you see just how complex our modern-day systems are, the approach that we take needs to evolve to match that. Because using a document-based approach, when we got literally tens of thousands of different elements interacting elements in our systems, is no longer good enough. And so I would argue that if the complexity hadn't evolved, I would agree with you 100%. And for some people, to be perfectly fair, you don't need to go to model-based if you're dealing with systems that you understand that are relatively straightforward. But as the complexity evolves, so there is this need to evolve into a model-based approach. Next question. Could you please elaborate on your statement about MBSC? It's like SE, because models are a part of SE, exactly like how you said requirements engineering is. I would like to understand more about your statement. Right, so if we look at requirements engineering, yes, models are part of that, but requirements engineering like design, like implementation, like test, they're a part of the big picture that systems engineering. Model-based systems engineering is not just a small part of the big picture of systems engineering, it allows us to realize the big picture of systems engineering. So yes, we can use MBSC to do our requirements, to do our analysis, to do our design, to do our implementation and our test and our support and our operations and retirement and so on. So that's what I mean by that is MBSC, we can apply across the entire lifecycle to all these different sub-disciplines of systems engineering that we would traditionally see. Okay. Do you have a concise, adequate definition of complexity as used in this presentation and how does it relate to complexity theory? Yeah, so I mean that's the point that we've been trying to make in this. I've deliberately avoided the whole issue of complexity theory when it comes to things like measuring complexity and the way that we analyze things like nodes and interactions between them, that's a whole other area again, that's a whole other presentation. I deliberately wanted to keep it very high, high level to what we got here. So that's why there wasn't any, you know, you could argue there wasn't much rigor to the definitions that I was using for complexity, but I was trying to aim at a very pragmatic reason and to make the point of why we need model-based systems engineering. All of the, if we look at complexity theory, all of the techniques, all of the sort of measurements, the metrics and so on that we can apply to there and the theories associated with it equally apply to what I've done. I was just deliberately trying to keep it at a very high level, rather than to get bogged down in a big debate about exactly what do we mean by complexity. So that's why I was trying to explain it through examples, rather than through, for example, mathematical formula. Okay, we have quite a few questions. We've already got 60 more comments and 30 more questions, so that's fine. Better than otherwise. Is modeling a system using MBSE tools and methodology, but not including executable models and simulations still accounted as MBSE application, or is it just called drawing? No, I would say MBSE encompasses the simulations and the mathematical side of the modelling. Absolutely definitely. When we talk about framework, so I'll talk about this in the next presentation. It's important to realise there's more to MBSE than there is just doing the CISML diagram, for example. We need to look at what I would call the model based engineering. So things like electrical modelling, heat transfer modelling, simulations, physical modelling, all these need to be represented within MBSE because what we're concerned about with the model is the consistency of all this information, regardless of whether it's visualised in CISML, in the CISML modelling tool, or whether it's done in MATLAB or Simulink, or DAWs, or the electrical wiring diagram, all of those things need to be consistent. And therefore, in my opinion, that's all under the umbrella of model based systems engineering. Okay, next question. Given that the reason for a car has not changed, aren't the majority of your described current complexity based on the implementation choices, whether than complexity introduced by the problem domain, hence are actually implementation complications introduced complexity, whether than actually complexity. Well, I think that's a very good point. And I would argue there that in some cases, yes, we're introducing complexity for the sake of it, particularly with some technologies. We're introducing it for convenience rather than that there's any dying need for it. But many of the aspects of complexity, particularly where the constraints come in, no, they're necessity. And that's because things like people's attitudes have changed over the years. And because people's attitudes have changed, things like standards and legislation have also changed over the years. You could argue that the function of a car isn't different because we've got seat belts. That's true. But actually, it's made it a lot safer and safety is a big concern. And it's a paramount concern now when it comes to the different stakeholders looking at it. So I would agree that in some instances, and particularly with some aspects of technology, there are convenience for us to make our lives more comfortable. But I would also argue that many of them, particularly things like constraints and the system of systems aspects are there for very real and very pragmatic reasons. And all of the aspects related to increase the complexity of today's vehicles seems to be to be related to the elitist, not to the functional aspects. Wouldn't you agree? I believe, at least in automotive incidentally, complexity is strongly coupled with our professional discipline. So shouldn't we blame ourselves for the increase of complexity? Could you please spell a few words on that? And I think this relates to the previous point. So the safety, the security, all the elitism and so on. Yes, the need for those, sorry, not the need for them, but the driving forces behind them have increased. And I think you can argue that we've introduced those, but we've introduced it for very practical reasons. We want our systems to be safer. We want them to be more secure. We want them to be greener. And you could argue, well, functionally, that doesn't make any difference. Yeah, but anybody that designs a system purely on function is not designing a real system. We need to take into account the constraints. And I would accept that, particularly in things like automotive, the non-functional aspects of our system have overtaken the functional aspects of our system. And if you look at autonomous vehicles, the actual technology to do the functional self-driving vehicles, for example, is there. And it's the non-functional things that are holding that up. It's the safety, it's the security and so on. So I would argue what it is, but I would also argue that as systems go on, we're listing more to stakeholders. Automotive is a good example. You could design a perfectly functional car, but nobody would buy it if it wasn't safe. Nobody would buy it if it wasn't green, for example. These are the things that are giving people a competitive edge, and this is how we're selling these systems now. So I would agree that, yes, functionally, maybe not a lot of change, similar to the last question, but because of things like these constraints and the stakeholder attitudes, things have changed beyond all recognition. And I think if anybody thinks that we're just delivering systems on function now, they're misguided. You know, it's not, it's all to do with the non-functional constraints and so on. And this is what's driving a lot of what we're doing now as systems engineers. Okay, now we have two questions. It seems quite similar. I take the last one. How would you sell it to general management? Well, the way that you sell NBSC is different depending on who you're talking to. One of the points about modeling is all modeling is context-based. It depends on your point of view. The arguments you make for selling NBSC to engineers are not the arguments you make for selling NBSC to the investors. Okay, so again, this is the subject of another presentation, but I'll try and kind of summarize now. Things like improved consistency, reuse, you know, automatic document generation. These are things that tool vendors use and I think quite rightly to sell tools to engineers. That's not how we're going to sell them to managers. The way that we sell these to managers and going up to board level is we need to say things. No, it's going to increase our return on investment. How is it going to return our increase on investment? Well, it's going to increase our market share because we're listening to things like the constraints. It's safer. It's more efficient and so on and so on. When we sell to managers, again, there's no point talking about the technical aspects to sell to a manager. You need to talk about how cost, time and resource can be lowered by applying model-based systems engineering. So there isn't a single argument for why you should, how you should sell model-based systems engineering. You need to look at the stakeholder you're talking to, whether that's an engineer, a manager, somebody at board level or anything like that. And you need to say from their point of view, what are they looking for? What's going to excite them? And what's going to, you know, what's going to make them take notice? That's what we need to capture and that's what we need to articulate using NBSE. And I think this is one of the big problems that we have is the selling of NBSE. So I think for too long, we've sold it on the technical aspects and we haven't moved up the chain up to the board level to say, no, this is going to improve our return on investment. This might stop a recall of a car, for example. This might improve the way that we meet the standards. This is going to allow us to meet the new government environmental standards that are coming in in five years time. All these sorts of issues, these are the things that are going to excite the board level people, certainly not telling them things like we can automatically generate documents or, you know, we can reuse some of these model things. They're very good and they're very powerful, but we need to pitch the arguments at the right level in the right context to the stakeholders that we're dealing with. So I think this is one of the big problems that we have with NBSE at the moment is the way that we sell it. So I think that's a really good question. So the answer is context-based, you need to change your argument depending on who you're talking to. Looking at the time, we take the last question. In the 1-2 hours analogy, is there some conflation of the complexity of the wheel systems challenge with the extent of its representation, in which case wouldn't great system engineers start to see the gulf of the beast from its smiling mouth? I think if you do NBSE properly, yes, you can because you're not having this short sightedness of just looking into the smiley face and you'd be able to sort of predict, yes, we can see the complexity is going to go up, but we can manage and control that. And that's one of the reasons why we do NBSE. So like I said, by applying NBSE properly, we can manage and control that complexity. We know it's coming and we can prepare ourselves for it. The problem that we get is people don't know it's coming. They look into the smiley face and they spend all their time smiling and winking at the Brontosaurus without realising that there's a big belly coming soon. Okay. Thank you again for the great talk and thank you for the audience for your questions and your time. Some last words. As mentioned earlier, you can now claim one PDU credit toward your system engineering professional recertification by attending this webinar. You may also claim this credit retrospectively for inclusive webinars that you have attended and where attendance meets the qualification requirements. I would like to express thanks again to Lockheed Martin Corporation for sponsoring the 2021 and Cozy webinar program. So my last words. Thank you very much, Ron. It was a pleasure and see you soon. Goodbye. See you at the next one. Everybody have a good Christmas. Stay safe. Bye-bye.