Return to Portability

• [nick][✓ char, 2020-10-22]Char's review completed --

Return to the Top

replaceability occurs when software components are developed using open, well written, standard specifications, usually captured as an api. The standards can be either technical (i.e., developed by a stdorg) or de facto (i.e., developed by a for-profit or not-for-profit corporation). Replaceability is also a key factor in preventing vendorlockin.

Replaceability is not just about the ability to switch suppliers and avoid vendorlockin¹⁾ of the components, it's also about managing risk to the target system. This is especially true because each component can have its own Lifecycle with its own eol timelines, independent of the target system. In addition to the components' lifecycle, many components are now oss, which can often have forks spawning newer and competing products with similar, but not identical APIs. A recent article describes the Best Message Queue (MQ) Software of 2020. It describes 30 of the “top” mq mom software products.²⁾:

1. MuleSoft Anypoint Platform
2. IBM MQ
3. Azure Scheduler
4. Apache Kafka
5. Google Cloud Pub/Sub
6. Amazon MQ
7. RabbitMQ
8. Apache ActiveMQ
9. KubeMQ
10. IBM MQ on Cloud
11. Azure Queue Storage
12. Alibaba Message Queue
13. Alibaba Message Service
14. CloudAMQP
15. Intel MPI Library
16. ZeroMQ
17. Apache Qpid
18. Apache RocketMQ
19. IBM Compose for RabbitMQ
20. IronMQ
21. PubSub+
22. Red Hat AMQ
23. TIBCO Enterprise Message Service
24. Bottomline GTBridge
25. CloudMQTT
26. Compose Hosted RabbitMQ
27. deepestream.io
28. Enduro/Z
29. EnMasse
30. IBM Cloud Pak for Integration

Obviously, not all these products have the same API. They definitely do not have the same wireproro, so it is very difficult to “mix and match” Publishers and Subscribers. In a distributed system, this would require all the components within the system to upgrade at the same time, sometimes referred to as a “rebootworld”. And when the upgrades occur, each part of the system requires complete regressiontesting to make sure that all the parts of the system continue to operate and function according to the specifications.

Replaceability is closely related to Adaptability and the kinds of Installers Architecture and swadapt. Whenever there is an architecture or software adaptability issue, there is probably a Replaceability issue as well. Additionally, the concepts of Installability and Replaceability overlap. The harder a system or a product is to install, the greater the probability it will also be hard to replace.

Competitive products within the same domain are ideal candidates for Replaceability. However, replacing products should not just be driven by the cost of acquisition (i.e., purchase price) but also on the totalcostown, which considers the cost throughout the lifecycle of the target system or component including maintenance (see 20_maintainability). This cost can be tied to other tangential products such as debuggers, performance monitors, loggers, or any of the Non-Functional Requirements.³⁾

Return to the Top

The data_distribution_service_dds ecosystem is built around the idea of technical standards. The technical standard specifications are open, transparent and readily available to all. The sdo overseeing the DDS Family of Standards is the omg. The OMG has strict policies and procedures to govern and maintain the specifications to ensure the standards remain open and vendor neutral. As a result, the standards cover a wide range of issues that allow for the products to be Replaceable. The standards cover:

• 01_core
• 02_api
• 03_ext
• 04_gate
• 05_wip

These standards allow for components to be replaced at either the Architecture or Software level (see Adaptability);