Back in 2021, I interviewed for a job in Model Based systems Engineering. During the interview, one of the interviewers hit me with the question:

What is system Architecture?

He clarified by asking what distinguishes architecture from design. A daunting question, especially as the interviewer was the author of a well known primer on systems architecture that I’d not long ago read. I got the job, but I was unhappy with my answer to the question. Three years and a lot of self research into cybernetics later, I think I’m ready to give an answer that I’m happy with. On the way to answer this question we’ll meet a mad major who could build snowmobiles and the Architect (of buildings) whose work paved the way for MBSE.

Risk [noun]—A potential scenario in a project that is recorded in a risk management plan and forgotten about until it manifests as an issue.

I’m being facetious but this doesn’t seem too off the mark as a definition in many engineering organisations. Risk and risk management are fundamental to systems engineering–after all, Risk Management is one of the ISO 15288 processes which defines its purpose as:

… to identify, analyse, treat and monitor the risks continually.

Risk management as usually practiced certainly fails this definition. This proposes the question: what is risk and how should it be managed? Although following ISO 15288 and the SE handbook will get you through a project’s risk management adequately, I believe treating risk this way alienates the concept from the engineering process.

In this blog post, I’d like to explore the idea of risk and to Make the point that risk is not just something to be managed on the side of an engineering project but a fundamental part of engineering that provides a motive, measure and direction for an engineering project itself in a way that other measures cannot.

On the way, we’ll explore concepts from the scrum framework and a contender for the philosophical definition of life itself.

This post is a short one about another antipattern that I’ve observed while working. Its technically an instance of a common antipattern of how locally optimised systems often don’t combine into systems that are optimised for the larger-scale goal. The particularly insidious part of this antipattern is that not only does it increase the risk of project failure, it also hurts team morale and individual’s mental health.

This post describes a phenomenon that I and some other systems engineers that I’ve spoken too have noticed about our discipline. This phenomenon is entirely anecdotal so I could be working in outlier companies or completely wrong. If this post rings true or false for you, however, I’d love to hear from you in the comments to help understand whether my experience is universal in this respect.

My null hypothesis is this: compared to other disciplines of engineering, there are proportionally far fewer vocational systems engineers. By vocational, I am referring to the idea of engineers who see the subject of their job as more than just what they do 9-5 to pay the bills.

This post is a short one to start the year and is about an anti-pattern that I have observed within systems engineering projects. I sincerely hope that this pattern is not endemic, though I suspect its more prevalent in the discipline than we’d like to admit. This anti-pattern is a possible mechanism to the prevalence of project cost & time overruns and complex systems often being a disappointment to their customers. I call this anti-pattern Validation Through Intimidation.

In this post, I will describe a pattern that I have identified in numerous places during my time as a systems engineer. This pattern sits somewhere between the traditional double-loop learning system and a viable system. I call this pattern the Desiring Machine as a nod to Deleuze as I feel that this pattern feels somewhat like a Deleuzian desiring machine. This post focusses mainly on the derivation of the pattern but I hope to expand on its uses as a framework for understanding and enquiry in future posts. I will add that I do not believe that this pattern is anything new; I have seen aspects of it expressed in various systems thinking texts. However, I don’t think the pattern has been addressed by name or given the recognition as a useful pattern in the way I believe it deserves.

This post is not here to share a solution to a problem in the same way as my others. Instead, I would like to pose a question around agile and traditional systems architecture and hopefully spark a discussion on a concept that is almost fundamental to modern systems thinking—the systems hierarchy.

What follows is a paper that I submitted for INCOSE UK’s ASEC 2021 Conference. Unfortunately, the paper was not accepted which is fair enough as the presentations that made it into the conference were all incredibly interesting, useful and well presented. However, despite my presentation skills, this method brought a lot of benefit when used at Jaguar Land Rover and I present it here so that others can benefit from it too.

In the grand tradition of computer science bloggers, started by Edsgar Dijkstra himself with Go To statement considered harmful, it is time to critique a commonly used language feature. This time in UML & SysML (this also applies to simulink, but this is by no means the limits of my quibbles with Matlab). SysML has a few behavioural diagram types: the use case diagram (allegedly), the sequence diagram, the activity diagram, the parametrics diagram (though they’re considered different for some reason?) and the state machine diagram. After the sequence diagram, the state machine diagram is probably the most used diagram for behavioural specification. In this blog post, I’m going to tell you why that’s bad.

This post is a response to a flurry of activity in systems engineering academia around using category theory as a theoretical basis for SysML. A number of papers exploring this idea have appeared in th literature recently and as someone who is passionate about category theory and systems engineeering, I can’t help but contribute my thoughts on the matter. In this post I’d like to explore the basics of category theory and the closely related type theory and explain the power that this theoretical basis could bring to model based systems engineering.

In my last post, I showed how, with a little additional syntax, Data Types can be given a lot more power within a UML/SysML model. In this post I’d like to dial up the power one step further and talk about how we can spot patterns in the usage of certain Data Types and encode this as an addition to UML/SysML that will give us better insight into the correctness of our models and allow us to define patterns we use again and again in an abstract way. This pattern is sometimes called the “trait” (in the Rust language) or the “type class” (in Haskell/Scala/Idris).

This post is an introduction to an incredibly powerful pattern that is quite well established in the functional programming world but doesn’t seem to have percolated back to the OOP world, let alone modelling. Interestingly enough this pattern is all about abstracting from the way computers handle data values and bringing data description up to a more human friendly level. This pattern is known as the Algebraic Data Type.

This is the second in a quasi-series of posts in which I moan about bits that I don’t like in SysML/UML. This time, I’m taking a look at the use case diagram and arguing for a different way of modelling the concept to the UML and SysML specs.

Classes (or Blocks as they are known in SysML) are a useful and almost unavoidable concept in UML. They are the modelling concept that allows for object-oriented inheritance in the language and its dialects. In fact it is impossible to utilise inheritance as a pattern for reuse without it. However, classes are not as crucial to object oriented design as you may think. In this post I will make the case for a different form of object orientation which does away with classes altogether.