Community Building

Objective

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.

ccc
Work in Progress on Open Framework

Guidelines

Given a consensus on a small and closed set of core definitions and representations, different concerns should be considered:

  1. 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.
  2. 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.
  3. 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).
  4. 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.
Architecture Layers Stereotypes
Architecture Layers Stereotypes

Likewise, elements descriptions are based upon a small set of constructs to be applied uniformly:

How to describe elements and connections
How to describe elements and connections

From that closed set of concepts and constructs, the objective is to logically derive all additional definitions.

Development Assets

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.

Reusable development assets
Reusable development assets

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:

ccc
Project Footprint

 

Organization

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.

Tasks are best defined by contexts and concerns
Tasks are best defined by contexts and concerns

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.

Ecosystem

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:

All comments and contributions can also be discussed through  the Caminao LinkedIn Group

Further Reading

Leave a Reply