In the previous two posts, I discussed some of the issues affecting the choice of integration solutions for organizations adopting Model-Based Systems Engineering (MBSE) practices, particularly objectives and technical approaches. My assumption is that the ultimate goal of MBSE, to specify the system with a single digital model, requires the enterprise at some stage to unify or integrate system data in some fashion. An increasing number of solutions are being proposed and my purpose in this series is to clarify some of the ways in which they differ and how a user might identify the best solution fit to purpose.

Figure 1 Spider plot coordinate system, Other Requirements for  Integration

In this part, I describe several of the requirements that have not been treated, at least directly, in the previous post. I use a similar approach to Part 2, where the issues are scored along the seven radii in Figure 1.

Range of Tools

Clearly, the choice of integration solution will depend very strongly on whether it supports the software tools that are the immediate objective for the integration effort. It is important to delve beyond the top level, “The solution integrates tools X and Y.” The follow-up questions should cover, “Which versions of X and Y are supported?”, and “What use cases are supported, i.e. what is the integration supposed to accomplish?”.

Beyond these immediate questions, the user should also look to future expansion. The organization may have tools that are not an immediate target, but may have potential. With a larger view, the tools used by suppliers, customers and other stakeholders are integration targets. This larger view should also include extension beyond system development to manufacturing, quality and field operation data.

The ability to add new tool interfaces to the target platform is important in many cases. The integration solution may have toolkits or other utilities that enable the end-user to integrate new tools, even custom tools, but these may be limited in the use cases or interface types (e.g. APIs, file-based) they support. The willingness and ability of the integration solution supplier to add new tools is worth considering; such interfaces typically require both conceptual and detailed technical knowledge of the tools to be integrated.

Data Governance

Most integration solutions require intentional choices about where the “master” copy of each kind of data resides and how data may be changed, especially when there are multiple copies of the same data within the Digital Thread. An IS may impose its own rules on such changes and incorporate an engineering change process. Alternatively, it may respect the existing EC processes for each of the individual repositories. In either case, it should allow the enterprise to maintain its current policies wherever possible.

Data Protection

A major issue in any integration solution is balancing the need to share information across the team with the need to protect data that should not be shared. This is particularly important when different organizations are involved. Optimally, the information should be shared selectively, allowing, for example, high-level structure and properties to be available, while lower-level detailed design is hidden. The IS may support shared common models, updated from source models where the source models and the updating are controlled by the source model owners.

Version Management

The Digital Thread is constantly changing as the individual models and the connections between them change. In addition to specifying the current state of the model, the IS may also keep track of previous states of the model and allow them to be reconstructed.  Further extensions of this capability could include branching and merging so that alternate design spaces could be employed.

Scaleability

Major engineering projects can have many millions of data elements and relationships between them. A useful integration solution must be able to support this. In practice, this implies that the time to create, update or query the integrated data must be acceptable to the end-user. Where a central database is involved, it should be modular and expandable and optimized for the type of data it contains. Where distributed data is involved, transmission latency and interface efficiency should be considered.

Configurability

Enterprises routinely customize their engineering tools, adding custom data types and relationships.  The integration solution should be able to recognize and accommodate these custom elements as much as possible.  When data is transformed between domains, the mapping between them may also be a user-specific decision. The ability of the end-user to configure the IS in these cases and to deploy those configurations across the team, rather than relying on the IS provider to customize its platform, can play a major role in the ultimate usability of the solution.

Standards-Based

Some integration solutions emphasize their adherence to standards in the industry. These can include

• System architecture languages, such as SysML and UAF
• Application Programming Interface (API) standards, such as REST and OSLC
• Data format standards, such as XML and JSON

These can be useful, because compliance with standards can expand the number of other tools that might be added easily to the IS.  However, standards can also limit the available options when capabilities to support tools and use cases beyond the standard are not included.

Evaluation Criteria for Integration Solutions (IS): Other Requirements

below, I extend the list of criteria, begun in Parts 1 and 2, that an organization might use to evaluate or differentiate between integration solutions.

In the first three posts in this blog series, I have attempted to outline some of the issues that organizations might consider in evaluating integration solutions. In the three final posts, I will use our Syndeia interoperability platform as a demonstration of how an evaluation might look. I will also include a download link to the consolidated evaluation checklist in MS Word format.

Related Posts:

• MBSE and Integration | Part 1
• MBSE and Integration | Part 2
• MBSE and Integration | Part 3 (this post)
• MBSE and Integration | Part 4
• MBSE and Integration | Part 5
• MBSE and Integration | Part 6