In evaluating the many available integration solutions, the technical approaches taken by each should be subordinate to the user functionality they provide. But, of course, the two are closely related and an understanding of the different approaches can enhance the overall ability to make the best choice. In this section of the blog series, we will consider a number of the technical differentiators and questions that solution evaluators might ask.
Figure 1 is one way to visualize the criteria. Each radial line represents one axis of technical differentiation. The labels on the axis correspond to extreme choices along that axis. In practice, these choices tend to fall on a spectrum rather than a binary choice. We will discuss each axis and some of the key strengths and weaknesses of each approach, starting from the top and proceeding clockwise.
Aggregation vs. Federation
In an aggregation approach, all system information is collected in a single model or database. With federation, data resides in the many tools or repositories where it is created and these models are linked together (or federated) in some organized fashion. In aggregation, all team members know exactly where to find the data they need and advantage can be taken of well-developed technology in the PLM domain. However, the wide heterogeneity of data from different disciplines and different tools make it difficult to determine a universal data model that satisfies all users. The size of the aggregated database may also make it difficult to search and maintain. Some approaches use a combination; a core architecture model or connection database provides a framework for unifying data while detailed information remains in confederated models.
File-based vs. Model-Based
Some integration solutions manage files and the relationships between files. In a sense, this is an extension of traditional document-based systems engineering, but it can provide sophisticated version-management capabilities with a relatively simple structure and allows users to find the data they need efficiently. However, the data within the files may not be exposed without human examination or customized parsing software. Model-based approaches, which connect data at the model element and relationship level, provide a finer-grained approach to maintaining data consistency and access across the entire development process.
Point-to-Point vs. Holistic
In some integration solutions, the focus is on connecting two specific tools to support a specific integration use case. This can provide the most user benefit for the least expenditure of time and resources. Multiple point-to-points can be combined into an ad-hoc larger integration strategy. A holistic approach puts all connectivity into a single repository with a single user interface. This makes it easier to expand the integration solution and to query, visualize and monitor the larger development effort.
Link vs. Sync
An ongoing debate in the MBSE community involves link, the ability to access data across a connection, vs sync, the ability to transform data across a connection so that the same data is duplicated in two different models. Sync raises issues of data governance (where is the “master” copy of the data?) and requires a mechanism for comparison and updating of the data across the connection. However, it also allows data to be shared selectively and placed in the context of a new model where it can be used efficiently. For example, a SysML modeler may not need full access to a CAD model’s detailed geometry but could use the CAD part’s mass as a SysML value property in a parametric analysis of the mass budget.
Methodology-Specific vs. Methodology-Neutral
Some integration solutions impose a specific engineering workflow, while others are configurable to some extent to meet the users’ preferences. Given the relatively new status of MBSE, some novice users welcome a proven methodology in the initial stages. Others wish to adapt the solution to their organization-specific requirements, but this requires a deeper conceptual understanding of the domains to be integrated and greater initial effort.
Vendor-Specific vs Vendor-Neutral
Recent consolidation among industrial engineering software vendors has produced several families of tools, where the large vendor works hard to provide an integration solution within the family. However, users wish to choose best-of-breed tools or retain legacy toolsets where integration solutions must cross vendor boundaries. Even organizations deploying a single vendor’s toolset must collaborate with customers and suppliers with different choices.
Enterprise Services vs Local Application
As part of the Digital Transformation of information technology, software is shifting from local applications to enterprise platforms that provide services through a variety of user portals. Integration solutions will follow the same pattern, since the need for scaleability, resilience and wide user access is often best served by an enterprise-wide platform. However, local applications resident on a user’s computer may be entirely adequate for some use cases, with greater local control/security and less IT infrastructure. The choice is frequently related to a decision between perpetual licenses and user subscriptions in acquiring the integration solution.
Evaluation Criteria for Integration Solutions (IS): Approaches
Below, I extend the list of criteria, begun in Part 1, that an organization might use to evaluate or differentiate between integration solutions.
In the third post in this blog series, I will complete the discussion and table for other requirements that organizations might consider in evaluating integration solutions. In the final three posts, I will use our Syndeia interoperability platform as a demonstration of how an evaluation might look.
Related Posts:
- MBSE and Integration | Part 1
- MBSE and Integration | Part 2 (this post)
- MBSE and Integration | Part 3
- MBSE and Integration | Part 4
- MBSE and Integration | Part 5
- MBSE and Integration | Part 6