In the previous article, I discussed how model-based approaches can be used to capture engineering processes as connected structures of roles, activities, artefacts, responsibilities and information exchanges.
Traditional process documentation often describes what should happen. A model-based process architecture can go further by representing how the process works as a connected system: who performs the activities, which artefacts are produced or consumed, what information is exchanged, and where review or update loops occur.
However, once the process has been modelled, another question naturally appears: what toolchain or enabling system supports this process?
This is where the modelling can be extended. The process model captures the stakeholder roles expected way of working, the toolchain model captures the resources, repositories, platforms and system functions that enable that way of working.
This article shows how the same “Prepare for Modelling” process can be extended to capture a toolchain view using Arcadia/Capella. Other modelling languages can be used.
From process modelling to enabling resources
The initial process model described what are the stakeholder (aka roles) needs:
- the Server Admin prepares the model database;
- the Systems Engineering Manager defines the system engineering scope;
- the System Architect defines the modelling scope;
- the Subject Matter Expert reviews and agrees the scope;
- the System Architect updates the modelling scope if required.
This process view is useful as it clarifies responsibilities and interactions. However, it does not yet fully explain the toolchain that supports these activities.
For example, the process raises questions such as:
- Where is the model created?
- Where is the modelling scope captured?
- Which resource supports the project database?
- Which platform supports collaboration?
- Which exchanges are performed by people and which are enabled by tools?
- Which functions should the toolchain provide?
- Which repositories or resources support the flow of information?
These questions move the modelling from the process itself toward the system that enables the process.
Extending the process
In Arcadia, System Analysis helps define what the system must do and how it interacts with external actors or entities.
In this context, the “system” is not necessarily the product being engineered. It can be the enabling system or toolchain that supports the engineering process.
This is a useful modelling step because it allows us to ask:
- What capabilities must the toolchain provide?
- What interactions are required between roles and tool resources?
- Which information exchanges must be supported?
- Which parts of the process require repository, server or collaboration support?
- Which activities remain human responsibilities, and which are enabled by tools?
The System Analysis view can therefore be used to connect roles and activities, and enabling tools.
This view is valuable because it starts to make the enabling system visible. The process is no longer just about roles and activities, but now about the resources needed to support the process of those activities.
For more background on this Arcadia layer, see System Analysis
Understanding the digital thread behind the process
The next step is to understand the flow of information across the toolchain.
In the example, exchanges include:
- Login Request;
- Successful Login;
- Create Models;
- Acknowledges Model Database Ready;
- Requests Modelling Scope Definition;
- System Modelling Scope;
- Request Modelling Scope Update.
These exchanges represent the digital thread behind the process.
They show how information moves between activities, roles and resources. This is important because process gaps often appear where information exchanges are weak, implicit or manually managed.
For example:
the model database may be prepared, but the acknowledgement may not be formally communicated;
- the modelling scope may be defined, but not captured in a shared repository;
- the Subject Matter Expert may review the scope, but the update request may not be clearly linked to the artefact being updated;
- the toolchain may support model creation but not clearly support governance of the modelling scope.
By modelling these exchanges, the organisation can see where the process depends on tool support, communication, repositories or integration.
Moving into Logical Architecture
After identifying the required functions and exchanges, the next step is to organise them into logical resources.
The Logical Architecture layer helps answer:
- What logical resources are needed?
- Which logical resource performs which function?
- Where should information be captured?
- Which resource supports model creation?
- Which resource supports database login?
- Which resource supports collaboration around the modelling scope?
In the example, logical resources include:
- Project Database;
- Model Server.
The functions are then associated with these resources. For example:
- the Model Server supports creating the model and database login;
- the Project Database supports capturing the modelling scope;
At the logical level, the concern is not necessarily the vendor, product name or deployment configuration. The concern is the structure of the enabling resources and the functions they must perform.
This view helps define the architecture of the toolchain independently from specific physical products. It can support tool selection, integration planning, process improvement and digital engineering roadmap definition.
For more background on this Arcadia layer, see Logical Architecture
Moving into Physical Architecture
The Physical Architecture layer then represents the physical resources or real-world implementation choices that realise the logical architecture.
In the example, the physical view introduces resources such as:
- Tool Vendor Model Server;
- Web-based collaboration platform;
This view is useful because it connects the abstract process and logical toolchain to the actual environment used by the organisation.
For example:
- The Model Server may be realised by a vendor-provided model server;
- The physical implementation may reveal integration risks, access-control issues or repository ownership questions.
This is where process architecture becomes directly relevant to digital engineering implementation.
The model can help clarify not only what the process is, but also what resources are required to execute it consistently.
For more background on this Arcadia layer, see Physical Architecture
Why modelling processes and tools
Many organisations describe their processes in documents, while their toolchains evolve separately.
This can create a gap between:
- the defined process;
- the tools actually used;
- the artefacts produced;
- the repositories where information is stored;
- the roles responsible for creating, reviewing or maintaining that information.
A model-based approach can help close this gap.
By modelling both the process and the enabling toolchain, it becomes possible to understand:
- which tools support which process activities;
- which artefacts are produced or consumed;
- where information is stored;
- which exchanges are required;
- which handovers depend on tool support;
- which activities could be automated;
- where governance or review loops occur;
- where integration gaps may exist.
This is particularly useful for organisations adopting MBSE, because the effectiveness of MBSE does not depend only on modelling skills. It also depends on the way the modelling process is governed, supported, reviewed and connected to the wider engineering environment.
From process documentation to process and toolchain architecture
The previous article introduced the idea of moving from process documentation to process architecture.
This article extends that idea further.
The process architecture captures:
- roles;
- activities;
- responsibilities;
- artefacts;
- reviews;
- information exchanges.
The toolchain architecture captures:
- tool resources;
- logical and physical implementation structures.
Together, they provide a more complete view of how engineering work is performed and supported.
This is not only useful for documentation. It can support practical decision-making.
For example:
- Does the toolchain support the process we expect people to follow?
- Are the right artefacts captured in the right place?
- Are responsibilities clear across roles and tools?
- Is the same information being duplicated across multiple systems?
- Are review loops supported by the toolchain or handled informally?
- Can the process be reused across projects?
- Can the toolchain scale with the engineering process?
These are important questions for engineering governance, MBSE deployment and digital engineering transformation.
The value of modelling the enabling system
A toolchain is often described as a list of tools. However, a list of tools does not explain how the toolchain enables the process.
A model-based view can show:
- what each tool resource is expected to do;
- which process activity it supports;
- which information exchanges it enables;
- which artefacts it stores or manages;
- which roles interact with it;
- where integration is required.
This turns the toolchain into an enabling system.
That is the main value.
Conclusion
Engineering processes are often documented separately from the tools that support them. This can make it difficult to understand how the way of working is actually enabled by the engineering environment.
Using a modelling language, it is possible to model not only the process itself, but also the toolchain that supports it.
The “Prepare for Modelling” example shows how a process can be extended from roles, activities and artefacts into supporting functions, tool resources, logical architecture and physical implementation.
This provides a clearer view of the relationship between:
- the process being followed;
- the roles involved;
- the artefacts produced and consumed;
- the information exchanged;
- the tools and repositories required;
- the physical resources that realise the toolchain.
The value is building a connected representation of how engineering work is performed, supported and governed. That is the next step from process documentation to process and toolchain architecture.
