EPISODE 1 - From Objects via Processes to Systems - Socio-Digital-Systems

Hello. Great you're here. I'd like to take you on a journey. A journey towards a digital twin of the world we live in. This article will just be the initial episode. Bear with me, if you like, and let's see, where we end up. I am curious myself. Please help me, if you think I'm going to get stuck in this journey.

The beginning is: I started programming.

I was in 7th grade, it was 1975. And I was blown away by this "Computer" (64kB, 1 MhZ, by the way). It was a new world for me where I could create "something" out of "nothing". Then, in 1982, I got paid the first time for what I loved to do most (that's on what turned out to be my professional side of life). Heaven!

The 1980s came and went and it now was "Object Orientation" everywhere in Software Engineering. After having mastered "Assembler" and "FORTRAN" everybody turned from "Turbo Pascal" to "Delphi" and from "C" to "C++". And "Object Orientation" is still one of the major patterns in software engineering today. Other's were added, but at the core it's much the same - after 40 years.

We're now doing Java, TypeScript or some other hot stuff but still model "classes" and create "objects" based on them. There are basically no rules for "classes" - we can give them any attribute and any capability we want. We may derive classes from other classes and make them more special - i.e. a class "New Beetle" may be based on a class "car" which in turn may be based on "vehicle". Most of the time we end up with something we call "domain" specific class models. Cars, for instance.

At this point of the journey, I should mention, that one of the larger pieces of software I created was something I called "Ground Support Equipment Operating System" (GSEOS) - a software platform for testing and operating scientific experiments on satellites. The property of being "reusable" is what made an impact and influenced my thinking a lot towards abstraction of problems. To create something, which can solve multiple problems of the same kind (and it did - was used on many missions and my successors still seem to be working on it).

When I face a challenge today, I have a tendency to first think: hey, what's the more general problem here? And what tools and methods exist, to solve this kind of problems? And then apply that abstraction in the environment I am in, here and now. That, for example, led to applying principles of lean production (continuous improvement approach) in youth welfare office organizations. Which was amazing.

Now the '90s took me away from being a software engineer and I tried to become a manager and a leader. It was "Peopleware" now, and the term "Software" all of a sudden had a second meaning. I struggled, iterated and finally succeeded - that's my humble view, you need to ask the people I lead. And in some silent corners of my office, I still used my technical software skills to create the tools I needed to get the data I needed for my management job. And some were making jokes about the "programming manager".

Then came Manfred.

And with Manfred, it was about "Processes".

"Business Processes", that is. It's 1994 or 1995 at Dr?ger Medical and my colleague Manfred taught my into "process thinking" while collaborating on introducing a new medical sensor into series production. "Business Process" thinking was a great thing to integrate my management job ("Business") with my software skills (all software is a flow, a "Process"). In the years to come, I digged very deep into all knowledge I could pick up about "Process Orientation". After a career in two larger enterprises - Dr?ger Medical and Volkswagen Group - I even built my own business around this and became founder of the "Process Manufactury" in Braunschweig, Germany.

Another ingredient of what I am getting to was "Organization". As a senior manager, of course, I needed to get my act together and my people organized. Who's responsible for what? Who's authorized to make which kind of decisions? What's the effort of a piece of work? I learned a lot - to differentiate between "line organization" and "project organization", between "process management" and "case management" and changed my mindset from "hierarchical" to "lean" - becoming iterative and explorative. Agile, as we tend to say today.

I didn't know it when I started, but I think it's fair to say that some of my organizational ideas turned out to be pretty successful and even a blueprint for some others. At Volkswagen, my team standardized and stabilized the platform for factory control systems worldwide. Part of the success, I think, was the right way to team up with the factories and to team up with our suppliers. Not to mention our internal organization, which I changed from function to process orientation (of course). It seemed I found a talent, and it stuck with me. For 10 years, I consulted others around business process management, project management and general organization.

Now I had "Business Processes". I had "Organization". I knew to differentiate these from "Projects". And I wanted to create a reusable platform - I had done it before, and I wanted to do it again. Something which would SAP make look small. Yes!

Business Processes and Organization rule the world - that's what I thought. So, I became a fan of things like "Enterprise Architecture" (which is not Enterprise Architecture, but a view of software people on enterprises). I was a true believer that it should be possible to build a platform, by which we could configure IT systems to support any business process. And the major idea at the time was that everything could be modeled as a process with some pre-defined general properties - not just a plain "object".

Then came Ruth.

And with Ruth came "Systems".

"Have you read this article on 'Viable Systems'?", she asked me one day. I hadn't, so I took a glance - and put it on the side. But Ruth followed on and - to make a long story short - the "Viable Systems Model" created by Stafford Beer became the center of our thinking around effective organizations. And, with some additional references in one or two papers I read, I even stuck my nose into "social systems theory" - heavy stuff.

It was then I finally realized the idea of putting "processes" and "organization" at the center of my thinking had failed. And that only "systems thinking" might be the path which lets us succeed with digitalizing our environment and keep ourselves on par with the complexity we face on that way.

So, let's look at examples of "systems".

My body is a system. Not hard to agree on that. And components of that system are sometimes fighting each other and seem to have different objectives (my head vs. my stomach, as an example).

My family is a system. I am sure you agree. And we probably agree it's a social system. Multiple bodies. A system of systems.

My team at work is a system - again, a social system. I am a member of two social systems at the same time (actually way more than two).

My laptop and its software are a system. A technical system. And sometimes it freaks out, creates misunderstandings while my team and I are in a MS Teams session. Now we are talking about a Socio-Digital-System.

Based on "artificial intelligence" (they just call it that way, it's actually not, at least not yet, intelligent) chatbots start to mimic some sort of social behavior. Can they be members of a social system? Maybe the borders between "social" and "digital" become blurry.

In a nutshell, "systems" seem to have certain predefined attributes and behaviors - different to objects of freely definable classes, as described above. They may act on each other. They may be members of other systems, multiple at the same time. Likewise, they may be a component of another system.

It feels interesting and challenging to explore further on the "nature" of "systems". Let's do that in the next episode. If you want to get a sneak preview, read Günter Ropohls book about socio-technial systems - I will come back to that. It covers part of what I aim to get to.

Conclusion

If we can find common types of properties and capabilities of "systems", then may be the notion of "systems" can replace the notion of "objects". And with their common properties and capabilities we might be able to compose and model systems of systems which in turn can be used as members and components in other systems.

So my first conclusion is: lets change our mind set from domain specific "object orientation" to cross-domain cutting "system orientation". Let's replace something conceptually very simple - objects - with something a little more complex - systems - to conquer complexity (an impressive thought which was first realized by Ross Ashby: "only complexity absorbs complexity").

Let's accept that thought for some episodes of our yourney and see where that takes us to.

See you next time.