System modeling is all too often a flight for abstraction, when business analysts should instead look for the proper level of representation, ie the one with the best fit to business concerns.
Caminao’s blog (see Topics Guide) will try to set a path to Architecture Driven System Modelling. The guiding principle is to look at systems as sets of symbolic representations and identify the core archetypes defining how they must be coupled to their actual counterparts. That would provide for lean (need-to-know specs) and fit (architecture driven) models, architecture traceability, and built-in consistency checks.
This blog is meant to be a work in progress, with the basic concepts set open to suggestions or even refutation:
As every artifact, models can be defined by nature and function. With regard to nature, models are symbolic representations, descriptive (categories of actual instances) or prescriptive (blueprints of artifacts). With regard to function, models can be likened to currency, as they serve as means of exchange, instruments of measure, or repository.
Along that understanding, models can be neatly characterized by their intent:
No use of models, direct exchange (barter) can be achieved between business analysts and software engineers.
Models are needed as medium supporting exchange between organizational units with different business or technical concerns.
Models are used to assess contents with regard to size, complexity, quality, …
Models are kept and maintained for subsequent use or reuse.
Depending on organizations, providers and customers could then be identified, as well as modeling languages.
As it’s the case of every measurement, software engineering metrics must be defined by clear targets and purposes, and using them shouldn’t affect neither of them.
On that account, a clear distinction should be maintain between business value (set independently of supporting systems), the size and complexity of functionalities, and the work effort needed for their development. As far as systems are concerned, the Function Points approach can be defined with regard to the nature of requirements (business or system), and their scope (primary for artifact, adjustment for architecture):
Measures of business requirements are based on intrinsic domain complexity (domains function points, or DFP), adjusted for activities (adjustment function point, or AFP); they are set at artifact level independently of operational constraints or supporting systems.
Business requirements metrics are added up and adjusted for operational constraints.
Functional requirements measures target the subset of business requirements meant to be supported by systems. As such they are best defined at use case level (use case function points (UCFP).
Metrics for quality of service may be specific to functionalities or contingent on architectures and operational constraints.
Whatever the difficulties of implementation, function points remain the only principled approach to software and systems assessment, and consequently to reliable engineering costs/benefits analysis and planning.
The Agile development model should not be seen as a panacea or identified with specific methodologies. Instead it should be understood as a default option to be applied whenever phased solutions can be factored out.
Alternative: When conditions cannot be met, i.e when phased solutions are required, model-based system engineering frameworks should be used to integrate business-driven projects (agile) with architecture oriented ones (phased).
Whatever their nature, architectures can be defined as structured collections of assets and mechanisms shared by a set of active entities with common purposes: houses for dwelling, factories for manufacturing processes, office buildings for administrative ones, human beings for living, etc.
Along that reasoning enterprises architectures should be defined in terms of one distinction and three layers:
A distinction between specific and changing business contexts and opportunities on one hand, shared and stable capabilities on the other hand (represented with the Zachman’s framework above).
The enterprise layer deals with the representation of business environment and objectives (aka business model), organization and processes.
The system layer deals with the functionalities of supporting systems independently of platforms.
The platform layer deals with actual systems implementations.
It must be noted that while the layered perspective is widely agreed (names may differ), taxonomies often overlap.
To take advantage of their immersion into digital environments enterprises have to differentiate between data (environment’s facts), information (systems’ representations), and knowledge (enterprise behavior).
That cannot be achieved without ironing out the semantic discrepancies between corresponding representations.
Behind the various labels and modus operandi, maps can be defined on three basic layers:
Conceptual models, targeting enterprises organization and business independently of supporting systems.
Logical models, targeting the symbolic objects managed by supporting systems as surrogates of business objects and activities.
Physical models, targeting the actual implementation of symbolic surrogates as binary objects.
These maps can be aligned with commonly agreed enterprise architecture layers, respectively for organizations and processes, systems functionalities, and platforms, with a fourth added for analytical models of business environments.
Ideally, that alignment should pave the way to the integration of systems and knowledge architectures, as represented by the Pagoda blueprint:
Insofar as systems engineering is concerned, that would require two kinds of transformations: from conceptual to logical models (aka analysis), and from logical to physical models (aka design).
While the latter is just a matter of expertise (thank to the GoF), that’s not the case for the former which has to deal with a semantic gap between descriptions of specific and changing business domains and organizations on one side, generic and stable systems architectures on the other side.
As a result, what can be termed a conceptual debt has accumulated with the the number of logical models supporting physical ones without the backing of relevant ones for business or organization. The objective is therefore to bring all models into a broader knowledge architecture.
Models & Ontologies
As introduced by Greek philosophers, ontologies are systematic accounts of whatever is known about a domain of concern. From that point, three basic observations can be made:
Ontologies are made of categories of things, beings, or phenomena; as such they may range from lexicon or simple catalogs to philosophical doctrines.
Ontologies are driven by cognitive (i.e non empirical) purposes, namely the validity and consistency of symbolic representations.
Ontologies are meant to be directed at specific domains of concerns, whatever their epistemic nature: engineering, business, politics, religions, mythologies, astrology, etc.
With regard to models, only the second observation puts ontologies apart: compared to models, ontologies are about understanding and are not necessarily driven by empirical purposes.
On that account ontologies appear as an option of choice for the integration of symbolic representations:
Data: instances identified at territory level, associated with terms or labels; they are mapped to business intelligence (environments) and operational (systems) models.
Information: categories associated with sets of instances; categories can be used for requirements analysis or software design.
Knowledge: ideas or concepts connect changing and overlapping sets of terms and categories; documents can be associated to any kind of item.
As expounded by Davis, Shrobe, and Szolovits in their pivotal article, knowledge is made of five constituents:
Surrogates, used as symbolic counterparts of actual objects and phenomena.
Ontological commitments defining the categories of things that may exist in the domain under consideration.
Fragmentary theory of intelligent reasoning defining what things can do or can be done with.
Medium making knowledge understandable by computers.
Medium making knowledge understandable by humans.
Points 1 and 5 are not concerned by the conceptual gap, the former being dealt with through the anchoring of identified individuals to surrogates (see below), and the latter being with human interfaces. That leaves points 2-4 as the conceptual hub where information models have to be integrated into knowledge architecture.
Assuming RDF (Resource Description Framework) graphs are used for knowledge representation (point 4), and taking a restaurant for example, the contents of information models (point 2) will be denoted by:
Primary nodes (rectangles), for elements specific to cooking and customers relationship management, to be decorated with features (bottom right).
Connection nodes (circles and arrows), for semantically neutral (aka syntactic) associations to be uniformly implemented across domains, e.g with predicate calculus (bottom left).
Semantic connectors supporting both syntactic and semantic associations (bottom, middle).
Using ontologies to integrate models into knowledge architecture is to enable the restructuring of the conceptual debt.
Minding Semantic Gaps
Keeping with the financial metaphor, conceptual debts can be expressed in terms of spreads between models, and as such could be restructured through models transformation.
To begin with, all representations have to be anchored to environments through identified (#) instances.
Then, instances are to be associated to categories according to features (properties or relationships) :
Customers, reservations, tables, and waiters are identified individuals managed through symbolic surrogates.
Names of dishes and ingredients do not refer to symbolic surrogates representing business objects, but are just labels pointing to recipes (documents).
Idem for the names of wines, except for exceptional vintages with identified bottles to be managed through symbolic surrogates.
Aspects are structured sets of features meant to be valued through category instances.
Documents are contents to be accessed directly or through networks, (e.g preparations or wine reviews).
It must be noted that the distinction between neutral and specific contents is not meant to be universal but be justified by pragmatic concerns, for instance:
Addresses are not defined as aspects but as category instances so that surrogates of actual addresses can be used to optimize deliveries.
Links to customers and addresses, being self-explanatory, can be defined as non specific.
The relationship from dishes to ingredients is structured and specific.
Sorting out truth-preserving constructs from domain specific ones is a key success factor for models transformation, and consequently debt restructuring.
Restructuring The Debts
Restructuring financial debts means redefining assets and incomes; with regard to systems it would mean reassessing architectures with regard to value chains.
To begin with, the Pagoda blueprint central pillar is to support the integration of systems and knowledge architectures and consequently the dynamic alignment of systems capabilities, meant to be stable and shared, with business opportunities, by nature changing and specific.
Then, the pairing of systems and knowledge architectures, like a DNA double helix, is to be used to restructure both technical and conceptual debts.
With regard to technical debts, restructuring isn’t to present significant difficulties:
Pairing income flows (applications) to tangible assets (platforms) can be done at data level.
Model transformations between data (code) and information (models) levels can be achieved using homogeneous domain specific and programming languages.
Things are more complex with conceptual debts, for pairing as well as transformations:
There is no direct pairing because value chains (processes) are set across assets (organization).
Model transformations are to bridge the semantic gap between the symbolic representations of environments (knowledge) and systems (information) .
Nonetheless, these difficulties can be overcame combining integrated architectures and ontologies.
Regarding the structure of the conceptual debt, the income part is to be defined through business objectives (customers, products, channels, supply chain, etc.), and assets to be defined by corresponding enterprise architectures capabilities.
Regarding models transformations, ontologies will be used to mind the semantic gap between environments (knowledge) and systems (information) representations:
Power-types: describe instances of categories (age, income, education, …).
Knowledge based relationships (dashed line): used to describe objects and phenomena, actual, planned, or expected (face recognition of customers, influence of weather on dishes, association of wines and dishes, …
Concepts: introduced to relate information and knowledge: gourmet.
With the backbones of symbolic representations soundly anchored to environment, it would be possible to complement functional and logical models with their conceptual counterpart and by doing so to eliminate conceptual debts. A symmetric policy could be applied to refactoring in order to redeem the technical debt associated to legacy code.
Managing Conceptual Debt
Like financial ones, conceptual debts are facts of life that have to be managed on a continuous basis, which entails:
A separate management of models directly tied to systems, and ontologies with broader justification.
A distinction between a kernel (aka knowledge engine), environment profiles, and business domains.
UML Actors (aka Roles) are meant to provide a twofold description of interactions between systems and their environment: organization and business process on one hand, system and applications on the other hand.
That can only be achieved by maintaining a conceptual distinction between actual agents, able to physically interact with systems, and actors (aka roles), which are their symbolic avatars as perceived by applications.
As far as the purpose is to describe interactions, actors should be primary characterized by the nature of language (symbolic or not), and identification coupling (biological or managed):
Symbolic communication, no biological identification (systems)
Analog communication, no biological identification (active devices or equipments)
Analog communication, biological identification (live organisms)
While there has been some confusion between actors (or roles) and agents, a clear-cut distinction is now a necessity due to the centrality of privacy issues, whether it is from business or regulatory perspective.
States are used to describe relevant aspects in contexts and how the changes are to affect systems representations and behaviors.
On that account, events and states are complementary: the former are to notify relevant changes, the latter are to represent the partitions (²) that makes these changes relevant. Transitions are used to map the causes and effects of changes.
State of physical objects.
State of processes’ execution.
State of actors’ expectations.
State of symbolic representations.
Beside alignment with events, defining states consistently across objects, processes, and actors is to significantly enhance the traceability and transparency of architectures designs.