Civil Engineers should possess some level of systems thinking, though they may not realize it

I did Electrical/Electronic Engineering in the 60s/70s, then a Masters in Control Engineering at Sheffield University.

They differentiated between systems engineering (i.e. concerned with e system as a whole) and control engineering  (i.e. the dynamics of the system)

We had one lecturer (a mechanical engineer) who told us that civil engineers understood the static forces on a finished box girder bridge but not the dynamics of building one. This was at the time when box girder bridges were falling down during construction.

Teaching civil and other engineers the importance of understanding the system as a whole is worthwhile and probably achievable.

Teaching nonlinear dynamics a different ball game altogether.

My PhD was in mathematical modelling of interacting biological systems. There was no way the surgeons and biologists could be taught enough to do it themselves.This is why, when it comes to the dynamics of complex systems the preference is for multi-disciplinary teams

The danger is that civil (or any other discipline) engineers might not know what they don't know, but should know.

As the saying goes "It Ain’t What You Don’t Know That Gets You Into Trouble. It’s What You Know for Sure That Just Ain’t So"

quoteinvestigator.com/.../

Hello Bernard:-

I was very interested in your comment about doing your PhD in Mathematical modelling of interacting biological systems.

Was this taken before or after the discovery of the impact of the gut bacteria?

With the rapid rate of finding new biological (feedback) pathways -- According to the medical journals I read every day (JAMA, NEJM etc) they announce one new significant pathway nearly every week- I think that it must be an impossible task to keep modelling up-to-date.

Then there is the problem associated with long term effects of external factors (examples taking medicines) on biological systems. I try and keep up with the negative effects of commercial medicines (FDA black box warnings) which are sometimes very important (example a very highly requested drug which can result in thyroid cancers).

I would be very interested in knowing if you are currently employed in the medical field!

Peter Brooks

Palm Bay 

Bernard, 

I agree.

The issue I suspect is that they don't recognise it because they understand the concepts using different terminology. Therefore the way to explain the concepts is to use phrasing they recognise. My issue here is that I am not familiar with their phrasing since my background in definitely not Civils.

We were taught several aspects of maths using both mechanical and electrical terminology (sprung, mass damper, RCI circuit) to demonstrate the the maths was the same, just the application was different. I suspect its the same concept.

But beyond thinking as a whole system. I think that the Civils need to have a better grasp of why configuration control is useful (do you know what you were building that to), why requirements management when its done properly can add value, and why leaving it all the end (the right shift) is actually a bad thing.

Regards,

Mark

Peter Brooks said:

Was this taken before or after the discovery of the impact of the gut bacteria?

I started my PhD in 1970, which was well before any knowledge of the role of gut bacteria.

It was before much was known about large populations of interacting non-linear oscillators.

I modeled the electrical activity in the human small intestine which is created by ion activity across cell membranes.

My big finding was the way the oscillators would move into and out of phase and a cause a group of them to synchronise and move down the gut - a possible cause of peristalsis.

If you are interested, this is the paper that got published.

https://www.researchgate.net/publication/18699018_A_mathematical_model_of_the_slow-wave_electrical_activity_of_the_human_small_intestine

The whole area of intestinal dynamics is much more complex then we ever imagined and in now known as neurogastroenterology 

Peter Brooks said:

I would be very interested in knowing if you are currently employed in the medical field!

I never was. I've worked in a variety of engineering areas but I've always been interested in nonlinear dynamics. I am retired now but much of my latter work was on the dynamics of project and system development in government and large corporations.

Mark Tickner said:

The issue I suspect is that they don't recognise it because they understand the concepts using different terminology.

That's a common complaint.

 I worked in government IT for many years and they have a totally different approach and language from engineers.

I found that you have to learn their language, they won't learn yours. Unfortunately things get lost in translation and there''s also the problem of the tender process.

A tender has solution requirements, but what is really important is the problem. Many vendors I have worked for were not much interested in the problem, only what was written in the tender. If the solution didn't solve the problem, it was the client's responsibility.

Which is why, when I talk about the system as a whole, I include the problem requirements as well as the solution requirements, they are two different, but connected domains.

e.g. it doesn't matter how good a bridge is if it is in the wrong place.

which is why I wrote this:

www.researchgate.net/.../260624035_Beyond_the_Zachman_framework_Problem-oriented_system_architecture

Mark Tickner said:

The issue I suspect is that they don't recognise it because they understand the concepts using different terminology.

That's a common complaint.

 I worked in government IT for many years and they have a totally different approach and language from engineers.

I found that you have to learn their language, they won't learn yours. Unfortunately things get lost in translation and there''s also the problem of the tender process.

A tender has solution requirements, but what is really important is the problem. Many vendors I have worked for were not much interested in the problem, only what was written in the tender. If the solution didn't solve the problem, it was the client's responsibility.

Which is why, when I talk about the system as a whole, I include the problem requirements as well as the solution requirements, they are two different, but connected domains.

e.g. it doesn't matter how good a bridge is if it is in the wrong place.

which is why I wrote this:

www.researchgate.net/.../260624035_Beyond_the_Zachman_framework_Problem-oriented_system_architecture

Thanks for that paper, another one for me to add to my collection regarding architecture frameworks.

This comes into one of those requirements management concepts, the stakeholder requirements should be written in the language of the customer and in the problem domain. Systems Requirements should be elicited from those stakeholder requirements and should ideally be in the solution domain and written in the language of the company providing the solution.

But.... depending on the complexity of the problem there may be a few more levels of system requirements in the problem domain before you get to the solution domain. And yes, depending on the nature of the project, you can have more abstract needs in the business domain that led to the stakeholder requirements. Some of this is handled in newer frameworks, such as the OMG UAF and Magic/MBSE Grid.

Customers/Stakeholders don't always play fair - and many a time I've seen stakeholder requirements in the solution domain and even a specific implementation!

So yes, Systems Engineers are used to providing that translation between different groups. But it is a good point for me to consider that I should be using their language to explain the concepts rather then to teach them my language. Its a bit like a STEM presentation, you are always told to keep your language to what they (the children) will have experienced and understand. But its much harder to do in practice.