This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:10_portability:06_replace [2020/11/13 18:50] nick [About] |
dido:public:ra:1.4_req:2_nonfunc:10_portability:06_replace [2021/08/17 15:15] (current) murphy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 4.2.1.3 Replaceability ====== | + | ====== 4.3.1.3 Replaceability ====== |
| [[dido:public:ra:1.4_req:2_nonfunc:10_portability | Return to Portability ]] | [[dido:public:ra:1.4_req:2_nonfunc:10_portability | Return to Portability ]] | ||
| - | |||
| - | * **<color darkblue><todo @nick #char:2020-10-22>Char's review completed -- </todo></color>** | ||
| ===== About ===== | ===== About ===== | ||
| - | [[dido:public:ra:1.4_req:2_nonfunc:10_portability:06_replace | Return to the Top]] | + | [[dido:public:ra:xapend:xapend.a_glossary:r:replaceability]] occurs when software components are developed using open, well written, standard specifications, usually captured as an [[dido:public:ra:xapend:xapend.a_glossary:a:api]]. The standards can be either technical (i.e., developed by a [[dido:public:ra:xapend:xapend.a_glossary:s:stdorg]]) or [[dido:public:ra:xapend:xapend.a_glossary:d:defactostd| de facto]] (i.e., developed by a for-profit or [[dido:public:ra:xapend:xapend.a_glossary:n:non-profit]] corporation). Replaceability is also a key factor in preventing [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin]]. |
| - | + | ||
| - | [[dido:public:ra:xapend:xapend.a_glossary:r:replaceability]] occurs when software components are developed using open, well written, standard specifications, usually captured as an [[dido:public:ra:xapend:xapend.a_glossary:a:api]]. The standards can be either technical (i.e., developed by a [[dido:public:ra:xapend:xapend.a_glossary:s:stdorg]]) or [[dido:public:ra:xapend:xapend.a_glossary:d:defactostd| de facto]] (i.e., developed by a for-profit or not-for-profit corporation). Replaceability is also a key factor in preventing [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin]]. | + | |
| - | Replaceability is not just about the ability to switch suppliers and avoid [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin]]((**Note:** Vendors are not just proprietary corporations; Open Source projects produce and sell products also. The software might be "free", but the producers are competitors that have the same drive to lock-in customers as the corporations)) of the components, it's also about managing risk to the target system. This is especially true because each component can have its own [[dido:public:ra:xapend:xapend.a_glossary:s:syslifecycle| Lifecycle]] with its own [[dido:public:ra:xapend:xapend.a_glossary:e:eol]] timelines, independent of the target system. In addition to the components' lifecycle, many components are now [[dido:public:ra:xapend:xapend.a_glossary:o: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" [[dido:public:ra:xapend:xapend.a_glossary:m:mq]] [[dido:public:ra:xapend:xapend.a_glossary:m:mom]] software products.(( | + | Replaceability is not just about the ability to [[dido:public:ra:xapend:xapend.a_glossary:s:switch|switch]] suppliers and avoid [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin]]((**Note:** Vendors are not just proprietary corporations; Open Source projects produce and sell products also. The software might be "free", but the producers are competitors that have the same drive to lock-in customers as the corporations)) of the components, it's also about managing risk to the target system. This is especially true because each component can have its own [[dido:public:ra:xapend:xapend.a_glossary:s:syslifecycle| Lifecycle]] with its own [[dido:public:ra:xapend:xapend.a_glossary:e:eol]] timelines, independent of the target system. In addition to the components' lifecycle, many components are now [[dido:public:ra:xapend:xapend.a_glossary:o: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" [[dido:public:ra:xapend:xapend.a_glossary:m:mq]] [[dido:public:ra:xapend:xapend.a_glossary:m:mom]] software products.(( |
| __Best Message Queue (MQ) Software__, [[https://www.g2.com/]], | __Best Message Queue (MQ) Software__, [[https://www.g2.com/]], | ||
| )): | )): | ||
| Line 44: | Line 40: | ||
| - IBM Cloud Pak for Integration | - IBM Cloud Pak for Integration | ||
| - | Obviously, not all these products have the same API. They definitely do not have the same [[dido:public:ra:xapend:xapend.a_glossary:w:wireproro]], so it is very difficult to "mix and match" [[dido:public:ra:xapend:xapend.a_glossary:p:publisher| Publishers]] and [[dido:public:ra:xapend:xapend.a_glossary:s:subscriber| 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 "[[dido:public:ra:xapend:xapend.a_glossary:r:rebootworld]]". And when the upgrades occur, each part of the system requires complete [[dido:public:ra:xapend:xapend.a_glossary:r:regressiontesting]] to make sure that all the parts of the system continue to operate and function according to the specifications. | + | Obviously, not all these products have the same API. They definitely do not have the same [[dido:public:ra:xapend:xapend.a_glossary:w:wireprotocol]], so it is very difficult to "mix and match" [[dido:public:ra:xapend:xapend.a_glossary:p:publisher| Publishers]] and [[dido:public:ra:xapend:xapend.a_glossary:s:subscriber| Subscribers]]. In a [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed system]], this would require all the components within the system to upgrade at the same time, sometimes referred to as a "[[dido:public:ra:xapend:xapend.a_glossary:r:rebootworld]]". And when the upgrades occur, each part of the system requires complete [[dido:public:ra:xapend:xapend.a_glossary:r: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 [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:10_portability:01_adapt | Adaptability]] and the kinds of Installers /* the rest of this sentence makes no sense. I have no idea how to fix. There's some words missing but I can't guess what they'd be */ [[dido:public:ra:xapend:xapend.a_glossary:a:archdaptability| Architecture]] and [[dido:public:ra:xapend:xapend.a_glossary:s:swadapt]]. Whenever there is an architecture or software adaptability issue, there is probably a Replaceability issue as well. Additionally, the concepts of [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:10_portability:04_install | 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. | Replaceability is closely related to [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:10_portability:01_adapt | Adaptability]] and the kinds of Installers /* the rest of this sentence makes no sense. I have no idea how to fix. There's some words missing but I can't guess what they'd be */ [[dido:public:ra:xapend:xapend.a_glossary:a:archdaptability| Architecture]] and [[dido:public:ra:xapend:xapend.a_glossary:s:swadapt]]. Whenever there is an architecture or software adaptability issue, there is probably a Replaceability issue as well. Additionally, the concepts of [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:10_portability:04_install | 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. | ||
| Line 53: | Line 49: | ||
| - | ===== DDS Specifics ===== | + | ===== DIDO Specifics ===== |
| [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:10_portability:01_adapt | Return to the Top]] | [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:10_portability:01_adapt | Return to the Top]] | ||
| - | The [[dido:public:ra:xapend:xapend.glossary:d: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 [[dido:public:ra:xapend:xapend.a_glossary:s:sdo]] overseeing the [[ddsf:private:cookbook:06_append:01_family_of_standards | DDS Family of Standards]] is the [[dido:public:ra:xapend:xapend.glossary:o: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: | + | : <wrap hi><color red> To be added/expanded in future revisions of the DIDO RA </color></wrap> |
| - | + | ||
| - | * [[ddsf:private:cookbook:06_append:01_family_of_standards:01_core]] | + | |
| - | * [[ddsf:private:cookbook:06_append:01_family_of_standards:02_api]] | + | |
| - | * [[ddsf:private:cookbook:06_append:01_family_of_standards:03_ext]] | + | |
| - | * [[ddsf:private:cookbook:06_append:01_family_of_standards:04_gate]] | + | |
| - | * [[ddsf:private:cookbook:06_append:01_family_of_standards:05_wip]] | + | |
| - | + | ||
| - | These standards allow for components to be replaced at either the [[dido:public:ra:xapend:xapend.a_glossary:a:archdaptability| Architecture]] or [[dido:public:ra:xapend:xapend.a_glossary:s:swadapt| Software]] level (see [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional:10_portability:01_adapt]]); | + | |
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||