dido:public:ra:1.4_req:2_nonfunc:10_portability:06_replace
Differences
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:30] 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. | ||
| - | 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 [[dido:public:ra:xapend:xapend.a_glossary:t:totalcostown]], which considers the cost throughout the lifecycle of the target system or component including maintenance (see [[dido:public:ra:1.4_req:2_nonfunc]]). This cost can be tied to other tangential products such as debuggers, [[dido:public:ra:xapend:xapend.a_glossary:p:performance|performance]] monitors, loggers, or any of the [[ddsf:private:cookbook:02_body:02_projreq:nonfunctional | Non-Functional Requirements]].(( | + | 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 [[dido:public:ra:xapend:xapend.a_glossary:t:totalcostown]], which considers the cost throughout the lifecycle of the target system or component including maintenance (see [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability]]). This cost can be tied to other tangential products such as debuggers, [[dido:public:ra:xapend:xapend.a_glossary:p:performance|performance]] monitors, loggers, or any of the [[dido:public:ra:1.4_req:2_nonfunc | Non-Functional Requirements]].(( |
| __Portability Testing Guide with Practical Examples__, Software Testing Help, 30 June 2020, Accessed 31 July 2020, [[https://www.softwaretestinghelp.com/what-is-portability-testing/]] | __Portability Testing Guide with Practical Examples__, Software Testing Help, 30 June 2020, Accessed 31 July 2020, [[https://www.softwaretestinghelp.com/what-is-portability-testing/]] | ||
| )) | )) | ||
| - | ===== 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]]); | + | |
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||
dido/public/ra/1.4_req/2_nonfunc/10_portability/06_replace.1605310252.txt.gz · Last modified: 2020/11/13 18:30 by nick
