The objective here is to build a consensus about a small set of architecture concepts and constructs with unambiguous meanings common to business and system analysts.
The litmus test for selected concepts and constructs will be threefold:
- Concrete abstractions: the objective is not to build another meta-model but to define core concepts targeting actual instances identified (but not described) uniformly across enterprise and system architectures.
- Shared distinctions: the selected concepts and constructs must support the description of the critical distinctions common to both enterprise and system architectures.
- Occam’s Razor: the objective is to trim the set of definitions as to obtain the least possible number of concepts and constructs.
Caminao working hypothesis is that those objectives can be achieved with:
- Seven concepts to serve as pillars for the whole bridge.
- Five structural constructs that could be applied uniformly to pillars.
- Four lanes to be used to communicate models between enterprise and system architects and analysts.
This post is to be used as a blackboard for the contributions discussed in the LinkedIn Caminao group.
As a preliminary step, one should begin with architecture capabilities and look for a common understanding of seven basic artifacts:
- Containers (physical & symbolic).
- Physical entities.
- Symbolic descriptions.
- Execution states.
They are to identified independently of the labels used by the different methods.
Used to represent physical or symbolic holders, the former supporting the management of the locations and behaviors of their elements, the latter for the definition of semantics and structures.
Variants: physical location, system space, semantic domain, application domain.
Used to represent actual objects whose state and behavior is relevant for the business under consideration; not be confused with the description of their symbolic representation by systems.
Variants: humans, systems, devices, passive objects.
Used to describe how objects and activities are to be represented as system surrogates.
Used to represent the part played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors).
Used to represent changes in the state of business objects, processes, or users’ expectations.
Used to describe business logic (operations and flows) independently of supporting systems. Equivalent to UML and BPM terms.
Used to describe processes’ control and execution.
The same structural constructs can be applied to all artifacts:
Used to indicate that instances of the artifact (objects or activities) can be directly identified at architecture level. Aspects are non structural units.
Used to describe an attribute or an operation. Features have no instances of their own.
Used for instances (objects or activities) whose life-cycle is bound to the one of their owner, i.e they have no identity of their own.
Used for instances (objects or activities) which are identified independently but can only be used in the context of their owner; hence, while they can change owner, they are useless on their own.
Used to associate structural units: communication channel, reference, data or control flow, transition.
Used to define subsets of instances (objects or activities). Depending on modeling context, it corresponds to power-types, extension points, gateways, branch and joins.
Contrary to structure and functional connectors that deal with instances, inheritance connectors are used to describe relationships between descriptors. Strong inheritance is the counterpart of composition (inheritance of structural features), and weak inheritance the counterpart of aggregation (inheritance of non structural features).
Structural units can be combined in four types of models corresponding with widely accepted views or perspectives, whose associated diagrams can be build through the customization of leading modeling tools.
Used to describe physical entities (people, devices, systems), locations, and communication channels.
Used to define how entities and behaviors are represented as symbolic surrogates, regrouped in domains, and how they are related.
Used to define activities and business rules and their relationships.
Used to define how activities are executed, and their dependencies.
Across the bridge: Symbolic representations
One of the main pitfall in system modeling is the confusion between targets: while languages like UML can be used to describe business as well as systems objects and behaviors, that has to be done explicitly because the semantics differ. Hence the benefit of a distinction between concepts and documents, symbolic representations, and actual objects and processes. That would outline four basic concerns that may or may not be combined:
- Thesaurus: ontologies covering terms and concepts.
- Document Management: ontologies covering documents with regard to topics.
- Organization and Business: ontologies pertaining to enterprise organization, objects and activities.
- Engineering: ontologies pertaining to the symbolic representation of products and services.
It must be noted that those descriptions should not be seen in terms of abstraction levels but as the complementary descriptions of actual and symbolic objects whose mapping is to provide the backbone of enterprise architectures.
- The Book of Fallacies
- Modeling Paradigm
- Modeling languages: differences matter
- Caminao & Archimate
- Model Transformations
- Knowledge Based Model Transformation
- Legacy Refactoring
- Modernization & The Archaeology of Software
- EA & MDA