A practical MBSE development built on templates for clear architecture decisions

System architecture models are rarely challenged because they are wrong; they are challenged because they are hard to navigate, hard to scope, and hard to review consistently.
Reviews often fail not due to technical gaps, but due to unclear expectations: what should exist, in what order, and for whom.

The MBSE roadmap described below provides a lightweight, tool-compatible structure to:

• Define modelling scope early
• Prepare architecture work for formal and informal reviews
• Support efficient navigation of model artefacts
• Enable architects to defend architecture intent, not spend time searching for diagrams

The roadmap is intentionally pragmatic. It does not introduce heavy governance, nor does it prescribe a single method. Instead, it provides a shared reference for what will be looked at during a review, which modelling activities and artefacts are expected, and which stakeholder roles are involved at each stage.

System architecture activities and artefacts template

This template captures a catalogue of system architecture activities and artefacts that may be considered during a system architecture development.

It is not a checklist to be completed in full. Instead, it acts as a reusable baseline from which project-specific scope can be defined.

Purpose:

• Provide a common vocabulary of activities and artefacts
• Support reuse across projects and programmes
• Avoid re-inventing architecture scope for each development

Key characteristics:

• Covers activities across system definition, analysis, and architecture reasoning
• Tool-agnostic, but easily mapped to Capella or Cameo
• Designed to be sub-setted and reordered per project

Role involved:

• MBSE Lead: defines, captures, and maintains the template

Tool development template

From the system architecture activities and artefacts template it is then possible to create templates for tools and promote consistency when instantiating a new model within a team/project.

Diagrams validation rules

Diagram validation rules define project-specific conventions that complements a modelling language validation rules.

These rules are not intended to gate progress or enforce bureaucracy. Their purpose is to improve clarity, consistency, and review efficiency.

Purpose:

• Improve diagram readability and consistency
• Reduce review noise caused by stylistic or structural ambiguity
• Enable reviewers to focus on architecture decisions, not notation issues

Examples:

• Naming conventions
• Allowed diagram purposes per view
• Minimal content expectations for review-ready diagrams

Role involved:

• MBSE Lead: defines, captures, and maintains the rules

Modelling activities and artefacts planning

Using the activities and artefacts template as a baseline, a project-specific modelling plan is defined using a project adopted tool.

This step explicitly answers:

• What modelling activities will be performed?
• What artefacts will be produced?
• In what sequence?

Purpose:

• Make modelling intent explicit
• Align expectations before modelling starts
• Avoid late surprises during reviews

The plan typically represents a reordered and reduced subset of the full template, adapted to the project context.

Roles involved:

• System Architect (supporting role)
• Team Lead

System architecture modelling implementation

Architecture modelling is then performed following the agreed plan and the selected framework or method, for example:

• Arcadia method step-by-step
• A lightweight process using the MagicGrid framework

This step is where architecture intent is captured, analysed, and refined through modelling.

Purpose:

• Implement architecture decisions coherently
• Maintain traceability between activities and artefacts
• Prepare the model for structured navigation and review

Roles involved:

• Subject-Matter Experts (SMEs)
• System Architect

Model development with template

When implemented using dedicated templates for Capella or Cameo, the roadmap enables a structured and predictable way to find diagrams.

Rather than relying solely on the project explorer, diagrams are grouped and organised according to architecture intent and review needs, not file structure.

Purpose:

• Reduce time spent searching for diagrams
• Support demos and reviews
• Enable non-authors to navigate the model confidently

Role involved:

• System Architect

Sharing the model for review

The modelling tool can generate an HTML model export containing all relevant diagrams, ready for review by non-system engineers using the template index.

This allows reviewers to focus on rather than navigation mechanics.:

• Architecture reasoning
• Trade-offs and decisions
• Gaps and risks

Purpose:

• Enable wider stakeholder participation
• Reduce dependency on the modelling tool
• Improve review effectiveness

Roles involved:

• System Architect
• SMEs
• Data Manager (when shared libraries are used)

Try the VCCS HTML export

Modelling review and progress analysis

To support review preparation and progress awareness, the architecture owner can export structured tables (for example from Cameo) and analyse them externally.

This enables:

• Visibility of modelling status
• Awareness of review readiness
• Identification of gaps and priorities

Graphs and simple metrics can support decision-making, not compliance.

Roles involved:

• System Architect
• Peer System Architect Reviewers

When to use templates to define an MBSE roadmap

Projects and programmes that:

• Care about repeatability
• Care about review quality
• Care about consistency across teams
• Care about reducing delivery and review risk

Individuals who want to:

• Focus on architecture decisions, not artefact hunting
• Avoid unnecessary rework
• Avoid late review surprises
• Reduce personal exposure during reviews

Conclusions

Using structured templates and a lightweight roadmap provides a repeatable way to prepare, structure, navigate, and defend system architecture work at reviews and milestone checkpoints.

The value is not in the templates themselves, but in the clarity they create:

• What is expected
• What exists
• What will be reviewed