Architecture Decision RecordAWS ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਾ ਰਿਕਾਰਡ ਪ੍ਰਕਿਰਿਆ
ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਾ ਰਿਕਾਰਡ (ADR) ਇੱਕ ਅਜਿਹਾ ਦਸਤਾਵੇਜ਼ ਹੈ ਜੋ ਉਸ ਚੋਣ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਟੀਮ ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ ਦੇ ਕਿਸੇ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲੂ ਬਾਰੇ ਕਰਦੀ ਹੈ, ਜਿਸ ਨੂੰ ਉਹ ਬਣਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੀ ਹੈ। ਹਰ ADR ਆਰਕੀਟੈਕਚਰ ਫੈਸਲੇ, ਉਸ ਦੇ ਪ੍ਰਸੰਗ ਅਤੇ ਉਸ ਦੇ ਨਤੀਜਿਆਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ADR ਦੀਆਂ ਅਵਸਥਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਇਸ ਲਈ ਉਹ ਇੱਕ ਜੀਵਨ-ਚੱਕਰ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। ADR ਦੀ ਉਦਾਹਰਨ ਲਈ, ਪਰਿਸ਼ਿਸ਼ਟ ਵੇਖੋ।
ADR ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਤੀਜਾ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲਾ ਰਿਕਾਰਡਾਂ ਦਾ ਇੱਕ ਸੰਗ੍ਰਹਿ ਹੁੰਦਾ ਹੈ। ਇਹ ਸੰਗ੍ਰਹਿ ਫੈਸਲਾ ਲੌਗ ਬਣਾਉਂਦਾ ਹੈ। ਫੈਸਲਾ ਲੌਗ ਪ੍ਰੋਜੈਕਟ ਦਾ ਪ੍ਰਸੰਗ ਅਤੇ ਨਾਲ ਹੀ ਲਾਗੂ ਕਰਨ ਅਤੇ ਡਿਜ਼ਾਈਨ ਦੀ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਦਿੰਦਾ ਹੈ। ਪ੍ਰੋਜੈਕਟ ਦੇ ਮੈਂਬਰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਪ੍ਰਸੰਗ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਲਈ ਹਰ ADR ਦੀਆਂ ਸੁਰਖੀਆਂ ਉੱਤੇ ਨਜ਼ਰ ਮਾਰਦੇ ਹਨ। ਪ੍ਰੋਜੈਕਟ ਦੇ ਲਾਗੂਕਰਨਾਂ ਅਤੇ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਵਿੱਚ ਡੂੰਘਾਈ ਨਾਲ ਜਾਣ ਲਈ ਉਹ ADR ਪੜ੍ਹਦੇ ਹਨ।
ਜਦੋਂ ਟੀਮ ਕਿਸੇ ADR ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਉਹ ਅਟੱਲ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇ ਨਵੀਂ ਸੂਝ ਕਿਸੇ ਵੱਖਰੇ ਫੈਸਲੇ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ, ਤਾਂ ਟੀਮ ਨਵਾਂ ADR ਪ੍ਰਸਤਾਵਿਤ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਟੀਮ ਨਵੇਂ ADR ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹ ਪਿਛਲੇ ADR ਦੀ ਥਾਂ ਲੈ ਲੈਂਦਾ ਹੈ।
ADR ਪ੍ਰਕਿਰਿਆ ਦਾ ਦਾਇਰਾ
ਪ੍ਰੋਜੈਕਟ ਦੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸਾਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟ ਜਾਂ ਉਤਪਾਦ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਹਰ ਆਰਕੀਟੈਕਚਰ ਪੱਖੋਂ ਮਹੱਤਵਪੂਰਨ ਫੈਸਲੇ ਲਈ ADR ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਹਨ (Richards and Ford 2020):
ਬਣਤਰ (ਉਦਾਹਰਨ ਲਈ, ਮਾਈਕਰੋਸਰਵਿਸ ਵਰਗੇ ਪੈਟਰਨ)
ਗੈਰ-ਕਾਰਜਾਤਮਕ ਲੋੜਾਂ (ਸੁਰੱਖਿਆ, ਉੱਚ ਉਪਲਬਧਤਾ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ)
ਨਿਰਭਰਤਾਵਾਂ (ਕੰਪੋਨੈਂਟਾਂ ਦੀ ਆਪਸੀ ਜੁੜਤ)
ਇੰਟਰਫੇਸ (API ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਇਕਰਾਰਨਾਮੇ)
ਨਿਰਮਾਣ ਤਕਨੀਕਾਂ (ਲਾਇਬ੍ਰੇਰੀਆਂ, ਫਰੇਮਵਰਕ, ਟੂਲ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ)
ਕਾਰਜਾਤਮਕ ਅਤੇ ਗੈਰ-ਕਾਰਜਾਤਮਕ ਲੋੜਾਂ ADR ਪ੍ਰਕਿਰਿਆ ਦੇ ਸਭ ਤੋਂ ਆਮ ਇਨਪੁੱਟ ਹਨ।
ADR ਦੀ ਸਮੱਗਰੀ
ਜਦੋਂ ਟੀਮ ਨੂੰ ADR ਦੀ ਲੋੜ ਦਾ ਪਤਾ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਟੀਮ ਦਾ ਇੱਕ ਮੈਂਬਰ ਪ੍ਰੋਜੈਕਟ-ਵਿਆਪੀ ਟੈਂਪਲੇਟ ਦੇ ਆਧਾਰ ਉੱਤੇ ADR ਲਿਖਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। (ਉਦਾਹਰਨ ਟੈਂਪਲੇਟਾਂ ਲਈ ADR GitHub ਸੰਸਥਾ ਵੇਖੋ।) ਟੈਂਪਲੇਟ ADR ਬਣਾਉਣਾ ਸੌਖਾ ਕਰਦਾ ਹੈ ਅਤੇ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ADR ਸਾਰੀ ਸੰਬੰਧਿਤ ਜਾਣਕਾਰੀ ਦਰਜ ਕਰੇ। ਘੱਟੋ-ਘੱਟ, ਹਰ ADR ਨੂੰ ਫੈਸਲੇ ਦਾ ਪ੍ਰਸੰਗ, ਫੈਸਲਾ ਆਪਣੇ-ਆਪ ਵਿੱਚ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਉਸ ਦੀਆਂ ਡਿਲੀਵਰੇਬਲ ਚੀਜ਼ਾਂ ਲਈ ਫੈਸਲੇ ਦੇ ਨਤੀਜੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। (ਇਨ੍ਹਾਂ ਭਾਗਾਂ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਲਈ, ਪਰਿਸ਼ਿਸ਼ਟ ਵੇਖੋ।) ADR ਬਣਤਰ ਦੇ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ ਪਹਿਲੂਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਇਹ ਫੈਸਲੇ ਦੇ ਕਾਰਨ ਉੱਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੀ ਹੈ, ਇਸ ਉੱਤੇ ਨਹੀਂ ਕਿ ਟੀਮ ਨੇ ਇਸ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ। ਇਹ ਸਮਝਣਾ ਕਿ ਟੀਮ ਨੇ ਫੈਸਲਾ ਕਿਉਂ ਲਿਆ, ਟੀਮ ਦੇ ਹੋਰ ਮੈਂਬਰਾਂ ਲਈ ਉਸ ਫੈਸਲੇ ਨੂੰ ਅਪਣਾਉਣਾ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਫੈਸਲਾ ਲੈਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਨਾ ਹੋਣ ਵਾਲੇ ਹੋਰ ਆਰਕੀਟੈਕਟਾਂ ਨੂੰ ਭਵਿੱਖ ਵਿੱਚ ਉਸ ਫੈਸਲੇ ਨੂੰ ਪਲਟਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ADR ਅਪਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ
ਟੀਮ ਦਾ ਹਰ ਮੈਂਬਰ ADR ਬਣਾ ਸਕਦਾ ਹੈ, ਪਰ ਟੀਮ ਨੂੰ ADR ਦੀ ਮਲਕੀਅਤ ਦੀ ਪਰਿਭਾਸ਼ਾ ਤੈਅ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਹਰ ਲੇਖਕ ਜੋ ADR ਦਾ ਮਾਲਕ ਹੈ, ਉਸ ਨੂੰ ADR ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਸੰਭਾਲਣਾ ਅਤੇ ਸੰਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਮਲਕੀਅਤ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ, ਇਹ ਗਾਈਡ ਅਗਲੇ ਭਾਗਾਂ ਵਿੱਚ ADR ਦੇ ਲੇਖਕਾਂ ਨੂੰ ADR ਮਾਲਕ ਕਹਿੰਦੀ ਹੈ। ਟੀਮ ਦੇ ਹੋਰ ਮੈਂਬਰ ਹਮੇਸ਼ਾ ADR ਵਿੱਚ ਯੋਗਦਾਨ ਪਾ ਸਕਦੇ ਹਨ। ਜੇ ਟੀਮ ਦੇ ADR ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ADR ਦੀ ਸਮੱਗਰੀ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਮਾਲਕ ਨੂੰ ਇਨ੍ਹਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਟੀਮ ਵੱਲੋਂ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲੇ ਅਤੇ ਉਸ ਦੇ ਮਾਲਕ ਦੀ ਪਛਾਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, ADR ਮਾਲਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ADR ਨੂੰ ਪ੍ਰਸਤਾਵਿਤ (Proposed) ਅਵਸਥਾ ਵਿੱਚ ਮੁਹੱਈਆ ਕਰਦਾ ਹੈ। ਪ੍ਰਸਤਾਵਿਤ ਅਵਸਥਾ ਵਿੱਚ ADR ਸਮੀਖਿਆ ਲਈ ਤਿਆਰ ਹੁੰਦੇ ਹਨ।
ਫਿਰ ADR ਮਾਲਕ ADR ਲਈ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ADR ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਦਾ ਟੀਚਾ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਹੈ ਕਿ ਟੀਮ ADR ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ, ਇਹ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਇਸ ਉੱਤੇ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਜਾਂ ADR ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ। ਮਾਲਕ ਸਮੇਤ ਪ੍ਰੋਜੈਕਟ ਟੀਮ ADR ਦੀ ਸਮੀਖਿਆ ਕਰਦੀ ਹੈ। ਸਮੀਖਿਆ ਮੀਟਿੰਗ ਦੀ ਸ਼ੁਰੂਆਤ ADR ਪੜ੍ਹਨ ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਸਮਾਂ-ਖੰਡ ਨਾਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਔਸਤਨ, 10 ਤੋਂ 15 ਮਿੰਟ ਕਾਫ਼ੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਟੀਮ ਦਾ ਹਰ ਮੈਂਬਰ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਅਸਪੱਸ਼ਟ ਵਿਸ਼ਿਆਂ ਉੱਤੇ ਨਿਸ਼ਾਨ ਲਾਉਣ ਲਈ ਟਿੱਪਣੀਆਂ ਅਤੇ ਸਵਾਲ ਜੋੜਦਾ ਹੈ। ਸਮੀਖਿਆ ਪੜਾਅ ਤੋਂ ਬਾਅਦ, ADR ਮਾਲਕ ਹਰ ਟਿੱਪਣੀ ਨੂੰ ਪੜ੍ਹ ਕੇ ਸੁਣਾਉਂਦਾ ਹੈ ਅਤੇ ਟੀਮ ਨਾਲ ਉਸ ਬਾਰੇ ਚਰਚਾ ਕਰਦਾ ਹੈ।
ਜੇ ਟੀਮ ਨੂੰ ADR ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਲਈ ਕਾਰਵਾਈ ਬਿੰਦੂ ਮਿਲਦੇ ਹਨ, ਤਾਂ ADR ਦੀ ਅਵਸਥਾ ਪ੍ਰਸਤਾਵਿਤ ਹੀ ਰਹਿੰਦੀ ਹੈ। ADR ਮਾਲਕ ਕਾਰਵਾਈਆਂ ਤੈਅ ਕਰਦਾ ਹੈ, ਅਤੇ ਟੀਮ ਦੇ ਸਹਿਯੋਗ ਨਾਲ ਹਰ ਕਾਰਵਾਈ ਲਈ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ ਨਿਯੁਕਤ ਕਰਦਾ ਹੈ। ਟੀਮ ਦਾ ਹਰ ਮੈਂਬਰ ਕਾਰਵਾਈ ਬਿੰਦੂਆਂ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾ ਸਕਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ। ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਦੁਬਾਰਾ ਤੈਅ ਕਰਨਾ ADR ਮਾਲਕ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ।
ਟੀਮ ADR ਨੂੰ ਰੱਦ ਕਰਨ ਦਾ ਫੈਸਲਾ ਵੀ ਕਰ ਸਕਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ADR ਮਾਲਕ ਭਵਿੱਖ ਵਿੱਚ ਉਸੇ ਵਿਸ਼ੇ ਉੱਤੇ ਚਰਚਾਵਾਂ ਰੋਕਣ ਲਈ ਰੱਦ ਕਰਨ ਦਾ ਕਾਰਨ ਜੋੜਦਾ ਹੈ। ਮਾਲਕ ADR ਦੀ ਅਵਸਥਾ ਨੂੰ ਰੱਦ (Rejected) ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਜੇ ਟੀਮ ADR ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਮਾਲਕ ਟਾਈਮਸਟੈਂਪ, ਸੰਸਕਰਨ ਅਤੇ ਹਿੱਸੇਦਾਰਾਂ ਦੀ ਸੂਚੀ ਜੋੜਦਾ ਹੈ। ਫਿਰ ਮਾਲਕ ਅਵਸਥਾ ਨੂੰ ਸਵੀਕਾਰ (Accepted) ਵਿੱਚ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ।
ADR ਅਤੇ ਉਨ੍ਹਾਂ ਵੱਲੋਂ ਬਣਾਇਆ ਫੈਸਲਾ ਲੌਗ ਟੀਮ ਵੱਲੋਂ ਲਏ ਗਏ ਫੈਸਲਿਆਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ ਅਤੇ ਸਾਰੇ ਫੈਸਲਿਆਂ ਦਾ ਇਤਿਹਾਸ ਦਿੰਦੇ ਹਨ। ਟੀਮ ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਕੋਡ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਸਮੀਖਿਆਵਾਂ ਦੌਰਾਨ ADR ਨੂੰ ਹਵਾਲੇ ਵਜੋਂ ਵਰਤਦੀ ਹੈ। ਕੋਡ ਸਮੀਖਿਆਵਾਂ, ਡਿਜ਼ਾਈਨ ਕਾਰਜਾਂ ਅਤੇ ਲਾਗੂਕਰਨ ਕਾਰਜਾਂ ਤੋਂ ਇਲਾਵਾ, ਟੀਮ ਦੇ ਮੈਂਬਰਾਂ ਨੂੰ ਉਤਪਾਦ ਲਈ ਰਣਨੀਤਕ ਫੈਸਲਿਆਂ ਵਾਸਤੇ ADR ਵੇਖਣੇ ਚਾਹੀਦੇ ਹਨ।
ਚੰਗੇ ਅਭਿਆਸ ਵਜੋਂ, ਹਰ ਸਾਫਟਵੇਅਰ ਤਬਦੀਲੀ ਨੂੰ ਸਾਥੀਆਂ ਦੀ ਸਮੀਖਿਆ ਵਿੱਚੋਂ ਲੰਘਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਕੋਡ ਸਮੀਖਿਆ ਦੌਰਾਨ, ਕੋਡ ਸਮੀਖਿਅਕ ਨੂੰ ਅਜਿਹੀਆਂ ਤਬਦੀਲੀਆਂ ਮਿਲ ਸਕਦੀਆਂ ਹਨ ਜੋ ਇੱਕ ਜਾਂ ਵੱਧ ADR ਦੀ ਉਲੰਘਣਾ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਮੀਖਿਅਕ ਕੋਡ ਤਬਦੀਲੀ ਦੇ ਲੇਖਕ ਨੂੰ ਕੋਡ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਅਤੇ ADR ਦਾ ਲਿੰਕ ਸਾਂਝਾ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਲੇਖਕ ਕੋਡ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਾਥੀ ਸਮੀਖਿਅਕ ਉਸ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹਨ ਅਤੇ ਉਹ ਮੁੱਖ ਕੋਡ ਅਧਾਰ ਵਿੱਚ ਮਿਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ADR ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ
ਟੀਮ ਨੂੰ ADR ਨੂੰ ਸਵੀਕਾਰ ਜਾਂ ਰੱਦ ਕਰਨ ਤੋਂ ਬਾਅਦ ਅਟੱਲ ਦਸਤਾਵੇਜ਼ ਮੰਨਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੌਜੂਦਾ ADR ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਲਈ ਨਵਾਂ ADR ਬਣਾਉਣਾ, ਨਵੇਂ ADR ਲਈ ਸਮੀਖਿਆ ਪ੍ਰਕਿਰਿਆ ਸਥਾਪਿਤ ਕਰਨਾ ਅਤੇ ADR ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਜੇ ਟੀਮ ਨਵੇਂ ADR ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਮਾਲਕ ਨੂੰ ਪੁਰਾਣੇ ADR ਦੀ ਅਵਸਥਾ ਬਦਲਿਆ ਗਿਆ (Superseded) ਵਿੱਚ ਬਦਲ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।