The invention described in this blog, arises as a response to the challenge of engineering, or simply modelling, complex systems, and addresses four characteristic issues of such systems.
Complex Systems
- Fitness for purpose: Such systems exist – or are intended to exist – within a context of intents and motivations which provide the criteria for their validity and adequacy.
- Degree of Definition: The quality and precision of specification vary widely among the domains of knowledge implied by the various components.
- Structural Diversity: The structure and dynamics of the components are diverse, and cannot be simply related to each other.
- Interoperability: Because of this internal diversity, explicit protocols must be specified to ensure joint operation of the components.
Example: Enterprise Architecture
A clear illustration of these issues is offered by the discipline of Enterprise Architecture, which was one of the starting points for the research which resulted in the present invention.
Fitness for purpose
The usefulness of IT systems depends crucially on how well IT investments are aligned with business strategies. As suppliers of information systems, the IT team of an enterprise are tasked with delivering technology support to make the business more efficient, and are measured by the quality of the systems that they provide to the business. To get an overall perspective of how the systems link and flow together, they create detailed charts, maps and diagrams which together comprise an Enterprise Architecture. The Enterprise Architecture is used to describe, govern and manage the automated systems.
The discipline of Enterprise Architecture, while not yet fully mature, has seen major progress over the past two decades. Theories have been elaborated, and methods developed to guide and support the work of practitioners. At the cost of some considerable effort, it is now possible to prepare and maintain effective models of the automated parts of an enterprise. Yet Enterprise Architecture still remains “headless”, inasmuch as the essential motivation for its existence is not established with adequate clarity and precision. The consumers of enterprise information systems are the business stakeholders, who are tasked with managing and executing initiatives that realise business goals, and are measured by their achievement of business outcomes. Business systems are simply tools to make them more efficient in the execution of their activities.
To fully realise its benefits, Enterprise Architecture must include a constituent Business Architecture, defined, governed and managed with a precision and clarity similar to those now available for the technical constituents. This is not currently the case. While several theories of business organisation are extant, there is no systematic approach to the discovery, analysis and definition of the architecture of a whole business endeavour.
ArchiMate, TOGAF and Enterprise Architect are examples, respectively, of a modelling language, a framework and a tool for Enterprise Architecture, in which some consideration is given to Business Architecture. In each, the elements associated with the definition of a business are little more than conceptual placeholders, lacking the clarity and precision of the more technical terms. The practitioner is left with little beyond a recourse to experience and intuition.
Degree of Definition
The major challenge to the construction of an adequate Business Architecture arises from the language practices within business. While business people mostly understand each other in everyday practice, difficulties arise when attempting to apply formal methods. This requires means of describing a business in a way which can be processed, using other tools, into IT specifications and – to be sufficiently ambitious – into executable artefacts (software, appliances, hardware devices, etc.) This objective of expressiveness and rigour has an obvious prerequisite: the notation must be adequate and precise. Since the notation adopted here is natural language, we are doomed to failure unless we introduce usage conventions in the form of a Controlled Vocabulary, i.e., a set of chosen words associated with an agreement to use the words of the set according to specific semantic rules controlling their denotation. For example, the term “domain” occurs quite frequently in the discussion of business activities. In spite of this common usage, there appears to be no formal definition of this term, nor even a precise understanding of its import.
At present, the practice of business modelling is primarily based on UML and BPMN. Of these, UML (Unified Modelling Language) is a general-purpose modelling language originally designed to model software. It is suitable for business modelling only by reason of its generality. In fact, practitioners must resort to the stereotype device to specialise the application of UML concepts. But there are no directing principles for this specialisation, with the consequence of incompatibility among the work of different individual practitioners.
As to BPMN (Business Process Modelling Notation), its name itself indicates that it is specialised for a narrow aspect of a business endeavour. Processes modelled using BPMN treat other aspects (e.g., the objects of the business and their lifecycles, or the groupings of such objects and functions by affinity) as peripheral or incidental.
Structural Diversity
Enterprises are typically made up of very diverse components. This is due to the fact that most have grown by accretion, and that the interactions between the parts have been set up on an ad hoc basis. This situation raises a serious challenge to the modeller: in order to be applicable to this diversity of fact, the modelling artefacts must exhibit three kinds of invariance.
Content invariance
The modelling artefacts must not depend on the content of the components, since the subject matter of each is indefinitely variable. For example, an enterprise manufacturing widgets will also have a finance department dealing in budgets. While it makes sense to have a model for budgets and another for widgets, the means used in modelling must be uniform.
As mentioned above, UML provides the stereotype device, which is a mechanism for extending or altering the meaning, display and syntax of a model element. In other words, a stereotype allows the modeller to assign special features to a model element while at the same time assigning it to one of a few fundamental categories. As a result, the commonalities are carried by static categories, while the stereotypes allow indefinite variation in the syntax of dynamic interaction. By contrast, the present invention provides a uniform syntax for interactions, thereby making them invariant with respect to content.
Scale invariance
Typically the analysis leading to a model will proceed by progressive decomposition. To return to the term “domain” discussed earlier, its applications range from narrow scopes (e.g., “the domain of stationery purchasing”) to the full extent of an industry (e.g., “the utilities domain”); also, some “domains” can be contained within other “domains”. Accordingly, any definition of the term is likely to be scale-invariant, and as a consequence have a recursive structure.
Among the existing notations, BPMN supports recursion in the specific mechanism of subprocess. On the other hand, given that its application is restricted to processes, it has nothing to offer for scale invariance in other aspects (e.g., objects or capabilities). As to UML, it allows recursion and scale invariance by default, inasmuch as the syntax of model elements is at the discretion of stereotype builders. The language itself has nothing specific to offer to guarantee scale invariance.
In contrast, the present invention identifies three types of models: the Object models relate to atomic structural elements, and the Universe models define maximum extents. In between, component models provide the syntactic support for recursive decomposition.
Coupling invariance
For the same reason, the way in which components of a modelling unit (e.g., a “domain”) interact with each other (how they are coupled) must be describable using the same concepts and artefacts, regardless of the identity of the components. This kind of invariance applies to issues of governance and management mechanisms, composition mechanisms, scope and boundary specifications, etc.
In BMPN coupling of objects or functions is an incidental consequence of the defined processes. The only explicitly defined interactions are among processes themselves, either by virtue of shared objects of by intermediary events. In UML, any number of modelling constructs can induce some coupling.
By contrast, the present invention offers a single coupling mechanism, linking the lifecycles of two objects by rules which declare the states in which their interaction is possible and/or required.
Interoperability
System failures have often been traced to a failure of communication between the business agencies expressing their need for functionality and the Information technologists who were charged with supplying that need.
Necessarily, the structure and dynamics of automation and those of business systems evolve independently. It is not possible to find isomorphisms between those two worlds. In other words, when mapping business function to automation, there will appear discrepancies which must be reconciled by means of appropriate artefacts: recipes (or, to be more ambitious, algorithms) for the translation of expressed business needs to IT requirements. The formulation of such discrepancy-bridging recipes requires a suitable language.
While UML notation can be adapted by means of stereotypes, there is no provision for expressing complex mappings between models. This requires the introduction of a new notation. Proponents of Model-driven Architecture have introduced Mappings with the QVT formalism, and Marks to parameterise the mappings. However, these ideas are still at the conceptual stage, and much R&D is required to bring them to a point where their effectiveness can be assessed.
By contrast, the present invention offers the bridge mechanism. A bridge is an ontology dedicated to expressing the mapping between two sets of propositions in a semantic notation.
An approach to synthesis
Reactive systems (Harel)
In the late 1980’s, David Harel introduced statecharts, a very powerful means of describing reactive systems, that is, systems whose behaviour is sensitive to external events (as distinct from transformational systems, whose behaviour can be fully characterised by a fixed transfer function from input to output). He characterised statecharts as being an extension of state diagrams, in the following formula:
statecharts = state-diagrams + depth + orthogonality + broadcast-communication
In this formula, state-diagrams introduces the event-driven nature of such systems, depth provides for a hierarchical decomposition, orthogonality allows the coexistence of several parts which evolve independently of each other, while broadcast-communicationprovides for some degree of mutual influence between the parts.
These properties of statecharts go a long way towards addressing the challenges outlined above. Specifically, depth provides for recognising that systems are made up of parts organised at several scales, orthogonality deals with the diversity and quasi-independence of such parts, and broadcast-communicationaddresses the fact that parts typically do not know which other parts will be affected by their behaviour (and therefore cannot direct their messages).
Several refinements are possible, as outlined below.
Recursion
The intuitive notion of domain is used generally in discussion of enterprise systems. Its “degree of definition”, as observed above, is generally vague. For the sake of a precise descriptive theory, we must either do without it or specify it adequately. Two considerations bear on a possible specification. First, the use of this term ranges from quite narrow cases (e.g., “the domain of stationery purchasing”) to the full extent of an industry (e.g., “the utilities domain”); therefore there cannot be any limitation of subject matter (“content invariance”).
Second, some “domains” can be contained within other “domains”: this implies a hierarchical structure. Harel’s statecharts provide the mechanism for hierarchical decomposition, but further refinement is needed. If distinct layers of the hierarchy are to be structured differently, it becomes necessary to identify “levels” and to assign a particular structural description to each of these levels. This fallacy has trapped many attempts at defining “domains”. (For example, many process decomposition models claim to distinguish, say, three levels of process definition). The alternative is to accept that a given domain and its constituent subdomains are amenable to the same structural description. In other words, domain structure is self-similar, or scale-invariant, and the descriptive framework must be recursive.
The present invention embodies the second approach. “Domains” are taken to be properly embedded, and this hierarchy is modelled by the recursion of Component models, between the lower limit of atomic Object models and the upper limit of Universe models. The composition of models is uniformly ruled by a single mechanism (SPOP).
Limits of recursion: Bridges
Strict self-similarity entails infinite detail at small scales: this clearly is not compatible with what we know of the components of the real world (water molecules, grains of sand, cells, etc.). So a fractal description of a natural object cannot be the whole picture. Regularities stated in a descriptive theory must be associated with a scope, that is, their applicability is limited to a range of scale or resolution in the phenomena under study.
For instance, a model of a cloud may invoke self-similarity, but this will cease to be applicable below the scale of water droplets. From the point of view of the cloud, water droplets are “atomic”, or to put it another way, they are “black boxes”: their internal structure is not accessible to the regularity that defines the cloud. This is not to say that such internal structure is not susceptible of description. Therefore, a water droplet participates in two kinds of regularity, one internal, in terms, say, of water molecules, the other external, in terms of its relation to the cloud. The constraint of fitting this dual structure is what we call a bridge.
From the above two observations we can construct a precise and stable concept of domain. A domain is any aggregation of subject matter which is amenable to a uniform descriptive rule. This rule may be “flat” – applying only to objects of a single scale, or recursive – applying self-similarly to a range of scales, in which case its scope will be contained between two bridges.
Event-based integration
The stricture of recursion has implications for the mechanism of communication. Harel’s broadcast-communication is too general, in that it would allow some event in a deeply embedded subdomain to affect any part of the system directly. This is a well-known conundrum in information systems or computer science, manifested in “spaghetti code” and highlighted in such publications as Dijkstra’s letter “Go To Statement Considered Harmful”. More formally, this kind of undifferentiated messaging has been hemmed in by the principle of information-hiding. Communication of events can be structured by such mechanisms as hierarchical exception-handling (to climb the domain hierarchy), peer-to-peer messaging (for management of interfaces among “siblings”) and delegation (whereby a construct passes an event “down” for handling by one of its children).
In the present invention, objects are “black boxes” which only expose their current state: any communication or coupling is restricted to that information. The SPOP mechanism is activated by an event and applies to whichever constructs are selected by rules.
Manifestation & discrepancies
All of the above discussion is confined to one fold of modelling of a system.
Typically, the approach to the modelling is threefold. One may focus on the conceptual, in which a system is view in terms of intents, motivations and capabilities. Or one may consider the logical organisation, addressing the sequencing, dependencies and collaborations. Finally one may address the issues of implementation, whether through manual processes or automation.
The relationship between these folds is called manifestation. Thus logical structure manifests conceptual intent, and implementation manifests logical structure. Clearly there would not be a need for three folds if the structures were isomorphic. But the fact is that each of these folds has its own dynamics, is organised differently at any one time and evolves at different rates and in different directions. There is therefore a need to spell out the manifestation mappings. It goes without saying that only the non-isomorphic parts need to be specified. There are two aspects to those. On the one hand there are many-to-many mappings between elements in each fold.
On the other, and more intricate, there are atomic elements in one fold manifesting, or manifested by non-atomic structures in another. Such cases are called discrepancies, and are the source of much of the systems’ complexity.