Objective
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.
Seven Pillars
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.
- Roles.
- Events.
- Activities.
- Execution states.
They are to identified independently of the labels used by the different methods.
Container
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.
Physical entity
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.
Symbolic description
Used to describe how objects and activities are to be represented as system surrogates.
Variants:
Role
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).
Variants:
Event
Used to represent changes in the state of business objects, processes, or users’ expectations.
Activity
Used to describe business logic (operations and flows) independently of supporting systems. Equivalent to UML and BPM terms.
Variants:
Execution state (aka mode)
Used to describe processes’ control and execution.
Variants:
Connectors
Constructs
The same structural constructs can be applied to all artifacts:
Structural unit
Used to indicate that instances of the artifact (objects or activities) can be directly identified at architecture level. Aspects are non structural units.
Feature
Used to describe an attribute or an operation. Features have no instances of their own.
Composition
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.
Aggregation
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.
Connector
Used to associate structural units: communication channel, reference, data or control flow, transition.
Partition
Used to define subsets of instances (objects or activities). Depending on modeling context, it corresponds to power-types, extension points, gateways, branch and joins.
Inheritance
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).
Four Lanes
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.
Actual Contexts
Used to describe physical entities (people, devices, systems), locations, and communication channels.
Symbolic Surrogates
Used to define how entities and behaviors are represented as symbolic surrogates, regrouped in domains, and how they are related.
Business Logic
Used to define activities and business rules and their relationships.
Business Operations
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.
Further Reading
- 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
- Traceability
Putcha,
Generally speaking an architecture describes a set of functions, resources, and mechanisms.
That can be applied at different levels: enterprise, system, or software components.
http://caminao.wordpress.com/how-to-implement-symbolic-representations/architectures/
Remy:
What definition of “architecture” are you using? If you state that one can examine if the concepts and constructs satisfy “architecting”.
Physical and spatial aspects dominate most architecture definitions and practices but they are NOT relevant to conceptual subjects, typically software. Yet we find vertical and horizontal boxes, layers describing software architectures. I found DSM Design Structure Matrix better suited for non-physical systems. You may like to refer to them in the development of your new proposals / discussion.
Best wishes,