This is a very preliminary draft. My hope is to collect comments and do a revision. If anyone is so inclined, please let me know what you think.
There is much talk about how our programs are (or should be) thought of in terms of systems, and quite a bit of progress is being made toward that end. But there is a difference between:
- evaluating programs in terms of systems, and
- evaluating the systems themselves, i.e. abstracting the system structure from the details of a program.
The purpose of this document is to take a stab at the latter. Why bother? For two reasons. First, Understanding the system that underlies a program will help us understand the program. Second, similar systems structures may indicate similarities across seemingly disparate programs.
Evaluation Uncertainty 
Kia ora Jonny
I’ve given the paper a quick scan, and will give it a more detailed read later. I gave it a quick scan because I wanted to see how you conceptualised a system.
Essentially, you frame things in the way that I would generally fit into the hard systems tradition.
The distinction between hard and soft is much debated and is not totally relevant here. However, it is not irrelevant because it determines the kind of questions you can ask and the kind of answers you receive.
The main distinction for me, between hard and soft systems, can be best highlighted by the following defintions of a system:
A system is:
A collection of entities [That are perceived by someone as] Interacting together [To achieve something]
Hard systems are those described by the first and third lines. Soft systems include the entire phrase. Ontologically and especially epistemologically, the differences are critical. In soft systems, a system has to have an identified (but not necessarily intended) purpose. How the entities interact and what purpose they express is entirely in the eye of the beholder. You and I will look at the same situation and may ’see’ a different set of entities, a different set of interactions, and a different purpose. We will literally see different systems. In contrast a hard system approach will tend to display a single set of entities and a specific set of interactions, that interact according to a specific set of rules. You and I would ‘see’ the same system. This is the basis of classic system dynamics and to a large extent, classic CAS.
I know you’re familiar with all this, but it means that the distinction you’re making between seeing a program as a system and a systems view of a program is not especially important to me, as someone who tends to engage with the systems field from a soft systems perspective. It is just two different ways of understanding, in systems terms, the situation you are observing.
I am definitely not saying that my approach to systems is right and yours is wrong. But your puzzle reflects more the constraints of hard systems approaches than soft systems approaches. For you, the distinction you are making is important (which is why you are writing about it); for me, it is just another distinction that may be useful depending on what I want to know.
Okay, having said that, I can now put on my hard systems glasses and look at what you have written in those terms.
>
Happy to look at this! What is your timeline?
Best,
Meg
Mid-August or so. If you have problems downloading the document let me know. When it comes to critique, do not by shy.