System ‘Essence’ balances Features and Capabilities
Definitely we distinguish, or should between systems features and systems capabilities.
In what I said for the Systems Schema there must be something like an essence which I call here the “nucleus”.
The nucleus is about the internal relations within the whole of the System Schema just like the schema itself is about External Relations. Among these Internal Relations are the ones relating features, which are like attributes, to capabilities which are internal infrastructural functionality of the system.
Since Russell rejected Bradley’s Hegelian Internal Relations Analytic Philosophy has only been concerned with External Relations and Internal Relations have been Taboo. And this shows up in the fact that all our modeling with UML/SysML are about binary external relations. The weakness of UML/SysML is the fact that it does not comprehend multi-relations. This causes design descriptions to be overly verbose. But what is completely missing is any notion of Internal Relations.
When you think about it Designs must be a balance of internal and external relations. So half the design representation is missing. This is another blindspot in our thinking, like the forgetting of Mass and over concentration on Sets. Or the ignoring of Meta-system and the over emphasis on Systems. Whenever we find a blindspot in our thinking then we find a resource that is relevant that we are not using. Internal Relations are a resource for thinking about designs of Systems Syntheses. Essentially the Internal Relations is what makes the synthesis and binds it together. All current modeling methods are extensional. We do not even try to produce intensional design representations which would lead to possible worlds approaches. And we have not even conceived of hyper-intensional aproaches. [n.b, https://www.wikiwand.com/en/Transparent_Intensional_Logic]. The design element must have relations with other design elements that are external relations. And other systems which are also external relations. But each of those design elements needs to have internal relations within itself that responds to where it is in the system as a whole and defines the essence of the particular design element. We might argue that this might be approximated by nested patterns (patterns within components within patterns of components) but this is still an external way of looking at essence, attempting to reduce it to external relations which is the Analytic philosophical traditions approach which only concedes that intension is necessary when reduction to extension fails, just like admitting the necessity of hyperintension is only admitted after intensional possible world approaches fail. This is a limit progression which will never reach meaning. On the contrary Husserlian Phenomenology starts with meaning as a first class object and works out from meaning to understand everything else. And at the heart of Phenomenology is essence perception, the idea that essences are fundamentally different from abstractions (general or universal) or ideas (illusory continuities based on infinity). Since we are reinventing the wheel we should at least be aware of the route that Analytical Philosophy has gone before us from extension to intension, to hyper-intension and still not being able to account for meaning. Essences are the meanings of things. Better to start with attempting to understand the meaning of designs and working out from there rather than to start with extensional approaches which will never arrive at meaning as Analytical Philosophy has done.
You will notice that patterns only talk about external relations between pattern components. Pattern components are described but their internal relations are not specified.
Pattern Languages are patterns of forms. We use these patterns of forms to give slices through a system that contains these forms. A system might be structured based on a number of patterns. Patterns are supposed to capture what has worked, what has been invented to solve specific problems in actual systems. A system might encompass a whole set of Pattern Language constructs which have worked previously to solve problems. However, this approach to defining Systems is more or less like Klir’s Architecture of Systems Problem Solving that reduces Form and System to the Structure of Patterns. It is an excellent approach but it does not tell us anything about the essences of the forms (components) of the system, nor anything about the nucleus of the system itself. In other words in a pattern which is a relation among forms, the essence of the form is described but not explained, similarly the system is built up by an aggregation of patterns but the nucleus (essence) of the system is approximated but not explained. We are taking explanation here to be a stronger specification than a description, i.e. an explanation says how something works and perhaps why it works. A description just says what something is on the outside, or superficially in terms of its appearances.
Answering the question what is a principle. Principles are powers of essences. With a principle we say what something must be. It is a command to make it so. But principles are general and have exceptions. Beyond Principles at higher powers of constraint we have Laws. Laws are universal and necessary, like Physical Laws. Design Principles are heuristics about how to use patterns of forms to make systems. They say things like simplify as much as possible. Or always consider performance. Patterns are solutions to problems that have worked well in the past and have been captured by practitioners.
In my previous post I was alluding to the fact that in Chinese there is a concept LI that combines principle and pattern with each other in an interesting way that we do not have in the Western tradition which might be relevant. One of the things that considering LI leads to in the context of Schemas Theory is that we would have to distinguish between form and essence of form with respect to each schema and thus consider the relations between what Hegel would call Internal Relations and what we all know as External Relations. It turns out that in our tradition now Internal Relations is a blindspot. We don’t talk about them and we have no way of representing them. Yet we know that everything has a What, a Kind, specified by its essence. We talk about designs as if they were composed entirely of external relations between components and minimal methods (UML profiles). This suggests that we are not capturing the essence of designs.
Let me suggest that the difference between features of a system and the capabilities of a system are controlled by its nucleus, i.e. its essence at the system schema level. We talk about features and capabilities but we do not talk about what connects them which surely is the essence of the system, its nucleus. Features are like a superstructure built on the infrastructure of capabilities. Work on a system must be split between adding features that the user sees and the capabilities that make those features possible. And both Features and Capabilities may be based on patterns, known solutions to problems that work. But what constrains all features to be based on capabilities is the essence of the system being built. Unless there are capabilities in the infrastructure we will not be able to express features in the superstructure of the application, or system. The set of constraints that makes it necessary for features to be grounded in capabilities are the essence of the system. And that is made up of a set of internal relations that govern the use of external relations among the components of the system (internally) and other systems (externally).
This should give a basis to consider the importance of Internal Relations to Design.
A book that makes these distinctions clear is Harris, Errol E. Formal, Transcendental, and Dialectical Thinking: Logic and Reality. Albany: State University of New York Press, 1987
https://thinknet.quora.com/System-%E2%80%98Essence%E2%80%99-balances-Features-and-Capabilities