The aim of the Caminao project is to provide a comprehensive framework dedicated to systems engineering, from enterprise architecture to software design and development. From a fully and directly available on-line documentation, the objective is now to build a broad community of interest (LinkedIn group) around a set of unambiguous and coherent concepts and principles that could be accepted independently of specific methods.
Given a consensus on a small and closed set of core definitions and representations, different concerns should be considered:
- Consolidation of concepts: from a closely knitted set of concepts the objective is to correct possible blind spots or flaws, flesh out definitions, and set bridges towards other approaches.
- Resources: benefits of the Caminao framework are first to be found in the way development assets can be defined, capitalized, and reused. That can be illustrated by patterns, case studies, profiles, and documentation templates.
- Organization: the Caminao framework is meant to be neutral with regard to organization and methods; for that purpose tasks are to be defined by context (business or systems) and concerns (shared assets, processes, or support).
- Ecosystem: studies, practices, links with other methods, implementations with other tools, etc.
Core Concepts and Representations
The first step is to agree on a common understanding of domain and objectives. Such a shared footprint should be both compact (as few definitions as possible) and with maximum expressiveness (answers obtained through logical deductions). That is the objective of the Caminao’s layered view of systems architectures:
- The enterprise layer deals with business objectives on one hand, enterprise organization and resources on the other hand. Description of organizations, objects and processes are based on Caminao eight core concepts for logical and physical containers, symbolic and physical objects, roles, events, processes, and activities.
- The system layer deals with symbolic representations of domains and applications based on existing stereotypes with consolidated semantics.
- The platform layer deals with implementations using standard qualifiers.
Likewise, elements descriptions are based upon a small set of constructs to be applied uniformly:
- Objects or activities: persistent or transient representationsidentified on their own or as parts of a whole.
- Power-types describing variants of objects (classifications) and activities (extension points).
- Features (attributes or operation).
- Strong and weak structural connectors between instances (composition or aggregation) and types (inheritance)
- Functional connectors between physical objects (channels), symbolic objects (references), activities (flows), and execution states (transitions).
From that closed set of concepts and constructs, the objective is to logically derive all additional definitions.
Given a consistent, compact, and unambiguous conceptual framework, the next step would be to develop libraries of reusable development assets. That should be guided by three criteria:
- Use of standards when they are available, principally UML.
- Model based engineering: resources should be set according the OMG’s MDA distinction between computation independent (CIM), platform independent (PIM), and platform specific (PSM) models.
- Agile principles: resources should be defined as to support users’ driven, iterative, and lean development processes.
From that perspective the first step should deal with models and, taking widely accepted design patterns as a reference, the focus should be put on analysis (aka representation) patterns and functional architectures.
Based upon core Caminao constructs and stereotypes, reusable artifacts can be organized according three criteria:
- Architecture layer: enterprise (CIMs), systems (PIMs), platforms (PSMs).
- Description level: models, functional units set at architecture level, features set at object level.
- Semantics: Actual or symbolic, objects or behaviors.
Given patterns of targeted functionalities and reference architectures, some project profiles could also be considered depending on their footprint:
In order to support any kind of organization or method, tasks must be first defined by context (business or systems) and concerns (shared assets, processes, or support) independently of labels.
That provides a compact, versatile, clear and comprehensive reference for tasks and skills:
- Organization: How to align the use of resources to business objectives.
- Architectures: Systems functional architectures and their role within enterprise architecture.
- Requirements: How to align systems functionalities with users’ value.
- Projects: How to develop applications
- Maturity: How to assess and improve the capability and maturity of business and development processes.
- Quality: How to assess and improve the efficiency and quality of development processes.
Besides comments, corrections, and resources libraries, a framework is best served when set within an ecosystem of studies and practices.
With regard to studies, examples of topics may include:
- Logical foundations of the extensional/extensional mapping of model contents
- Model falsification (shadow models)
- Application of the Liskov Substitution Principle to analysis models
- Functional metrics.
With regard to frameworks, methods, or languages:
Of particular interest would be:
- A conceptual bridge of shared understandings between enterprise and system architects.
- Pilot projects with core Caminao requirements stereotypes set in standard UML modeling tools.
- A Collaborative environment for requirements capture, analysis, measurement, and verification.
- The development of an UML# engine.
- A model based approach to software modernization.
- A model based approach to function points.
- A mock-up application for EA framework requirements
- A review of Archimate business layer.
- Possible advances for formal assessment of requirements.
- Possible advances for formal assessment of functional architectures.
All comments and contributions can also be discussed through the Caminao LinkedIn Group