ਇੱਕ ਜੁੜਿਆ ਹੋਇਆ ਉਤਪਾਦ ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਪੂਰਾ ਹੋਇਆ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਟੋਟਾਈਪ ਸਥਿਰ ਹੈ, ਡੇਟਾ ਕਲਾਉਡ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਐਪ ਸਹੀ ਮੁੱਲ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਡਿਵਾਈਸਾਂ ਦਾ ਪਹਿਲਾ ਬੈਚ ਪਹਿਲਾਂ ਹੀ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਹੱਥਾਂ ਵਿੱਚ ਹੈ। ਉਸ ਸਮੇਂ, ਬੈਕਐਂਡ ਅਜੇ ਵੀ ਇੰਨਾ ਸਰਲ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਟੀਮ ਲਗਭਗ ਹਰ ਡਿਵਾਈਸ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਣਦੀ ਹੈ। ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਨੂੰ ਇੱਕ ਸਕ੍ਰਿਪਟ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਕੌਂਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਹੱਥੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਜੇਕਰ ਕੁਝ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਇੰਜੀਨੀਅਰ ਆਮ ਤੌਰ 'ਤੇ ਸਮੱਸਿਆ ਨੂੰ ਸਿੱਧਾ ਟਰੇਸ ਕਰ ਸਕਦਾ ਹੈ।
ਫਿਰ ਇਸਨੂੰ ਅਸਲ ਦੁਨੀਆਂ ਵਿੱਚ ਰਹਿਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇੱਕ ਦੂਜਾ ਹਾਰਡਵੇਅਰ ਸੰਸ਼ੋਧਨ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਗਾਹਕ ਅਜੇ ਵੀ ਪਹਿਲੇ ਸੰਸ਼ੋਧਨ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ। ਫਰਮਵੇਅਰ ਸੰਸਕਰਣ ਵੱਖ-ਵੱਖ ਹੋਣੇ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਵੱਖਰੇ ਗਾਹਕ ਜਾਂ ਬਾਜ਼ਾਰ ਲਈ ਇੱਕ ਨਵੀਂ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਪੁਰਾਣੇ ਡਿਵਾਈਸਾਂ ਨੂੰ ਅਜੇ ਵੀ ਅੱਪਡੇਟ ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਕੁਝ ਵੀ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਟੁੱਟਿਆ ਹੋਵੇ। ਇਸ ਡਿਵਾਈਸ ਦੇ ਪਿੱਛੇ ਸਾਫਟਵੇਅਰ ਨੇ ਬਸ ਆਪਣਾ ਇੱਕ ਜੀਵਨ ਚੱਕਰ ਪ੍ਰਾਪਤ ਕਰ ਲਿਆ ਹੈ।
ਉਸ ਤਬਦੀਲੀ ਨੂੰ ਗੁਆਉਣਾ ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰੋਟੋਟਾਈਪ ਪੂਰੀ ਤਰ੍ਹਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ। ਪਰ ਇੱਕ ਵਾਰ ਜਦੋਂ ਇੱਕੋ ਭੌਤਿਕ ਉਤਪਾਦ ਦੇ ਕਈ ਸੰਸਕਰਣਾਂ ਨੂੰ ਖੇਤਰ ਵਿੱਚ ਇਕੱਠੇ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਬੈਕਐਂਡ ਹੁਣ ਸਿਰਫ਼ ਹਾਰਡਵੇਅਰ ਦੇ ਪਿੱਛੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਨਹੀਂ ਰਹਿੰਦਾ। ਇਹ ਉਤਪਾਦ ਆਰਕੀਟੈਕਚਰ ਦਾ ਹੀ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਜੁੜਿਆ ਹੋਇਆ ਪ੍ਰੋਟੋਟਾਈਪ ਅਜੇ ਤੱਕ ਇੱਕ ਸਕੇਲੇਬਲ ਉਤਪਾਦ ਨਹੀਂ ਹੈ।
ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਕੰਮ ਹੁੰਦਾ ਹੈ: ਇਹ ਸਾਬਤ ਕਰਨਾ ਕਿ ਸਿਸਟਮ ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ। ਡਿਵਾਈਸ ਆਪਣਾ ਮੁੱਖ ਕਾਰਜ ਕਰਦੀ ਹੈ, ਫਰਮਵੇਅਰ ਬੈਕਐਂਡ ਨਾਲ ਸੰਚਾਰ ਕਰਦਾ ਹੈ, ਟੈਲੀਮੈਟਰੀ ਉੱਥੇ ਪਹੁੰਚਦੀ ਹੈ ਜਿੱਥੇ ਇਸਨੂੰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਮਾਂਡਾਂ ਵਾਪਸੀ ਦੀ ਯਾਤਰਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਮੋਬਾਈਲ ਜਾਂ ਵੈੱਬ ਇੰਟਰਫੇਸ ਉਪਭੋਗਤਾ ਨੂੰ ਕਾਰਜਸ਼ੀਲਤਾ ਦਾ ਖੁਲਾਸਾ ਕਰਦਾ ਹੈ।
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਉਹੀ ਸਿਸਟਮ ਵਿਭਿੰਨਤਾ ਨੂੰ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦਾ ਹੈ।
ਪਹਿਲੇ ਵੀਹ ਡਿਵਾਈਸ ਸਾਰੇ ਇੱਕੋ ਫਰਮਵੇਅਰ ਚਲਾ ਸਕਦੇ ਹਨ, ਇੱਕੋ ਹਾਰਡਵੇਅਰ ਰੀਵਿਜ਼ਨ ਲਈ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਇੱਕੋ ਇੰਜੀਨੀਅਰਾਂ ਦੁਆਰਾ ਕੌਂਫਿਗਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਉਸ ਪੜਾਅ 'ਤੇ, ਮੈਨੂਅਲ ਰਜਿਸਟ੍ਰੇਸ਼ਨ, ਸਿੱਧੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਤਬਦੀਲੀਆਂ, ਜਾਂ ਇੱਕ ਛੋਟੀ ਆਨਬੋਰਡਿੰਗ ਸਕ੍ਰਿਪਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਝਦਾਰੀ ਵਾਲੀ ਹੋ ਸਕਦੀ ਹੈ। ਉਤਪਾਦ ਦੇ ਆਪਣੇ ਆਪ ਨੂੰ ਸਾਬਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਤਪਾਦਨ-ਗ੍ਰੇਡ ਟੂਲਿੰਗ ਬਣਾਉਣਾ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਹੋ ਸਕਦਾ ਹੈ।
ਸਕੇਲ ਸਮੱਸਿਆ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਡਿਵਾਈਸਾਂ ਔਫਲਾਈਨ ਰਹਿੰਦੀਆਂ ਹਨ, ਬਦਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਵੱਖ-ਵੱਖ ਫਰਮਵੇਅਰ ਚਲਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਵੱਖ-ਵੱਖ ਗਾਹਕ ਸੰਰਚਨਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਹਾਇਤਾ ਨੂੰ ਇੱਕ ਅਜਿਹੀ ਇਕਾਈ ਨੂੰ ਵੱਖਰਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜਿਸਨੂੰ ਕਦੇ ਵੀ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਉਸ ਤੋਂ ਜੋ ਗਲਤ ਸੰਰਚਿਤ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੈ।
ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਜ਼ਾ ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਕਿਸੇ ਮਾੜੇ ਫੈਸਲੇ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਅਸਥਾਈ ਫੈਸਲੇ ਨਾਲ ਜੋ ਉਤਪਾਦ ਦੇ ਅੱਗੇ ਵਧਣ ਤੋਂ ਬਾਅਦ ਵੀ ਆਪਣੀ ਜਗ੍ਹਾ 'ਤੇ ਰਹਿੰਦਾ ਹੈ। ਅਤੇ ਪਹਿਲੀਆਂ ਚੀਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜੋ ਉਸ ਤਬਦੀਲੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ ਉਹ ਹੈ ਹਾਰਡਵੇਅਰ। ਇੱਕ ਨਵਾਂ ਸੰਸ਼ੋਧਨ ਸਿਰਫ਼ ਪੁਰਾਣੇ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ; ਇਸਨੂੰ ਇਸਦੇ ਨਾਲ ਹੀ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ।
ਹਰ ਹਾਰਡਵੇਅਰ ਸੋਧ ਇੱਕ ਸਾਫਟਵੇਅਰ ਜੀਵਨ ਚੱਕਰ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦੀ ਹੈ।
ਇੱਕ ਨਵਾਂ ਹਾਰਡਵੇਅਰ ਸੰਸ਼ੋਧਨ ਪੁਰਾਣੇ ਦੇ ਸਾਫ਼ ਬਦਲ ਵਜੋਂ ਘੱਟ ਹੀ ਆਉਂਦਾ ਹੈ। ਅਭਿਆਸ ਵਿੱਚ, ਦੋਵੇਂ ਸੰਸਕਰਣ ਖੇਤਰ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਕਈ ਵਾਰ ਸਾਲਾਂ ਲਈ। ਇੱਕ ਪਰਿਵਰਤਨ ਬੈਚ, ਕੁਝ ਫਰਮਵੇਅਰ ਸ਼ਾਖਾਵਾਂ, ਅਤੇ ਗਾਹਕ-ਵਿਸ਼ੇਸ਼ ਸੰਰਚਨਾਵਾਂ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਫਲੀਟ ਤੇਜ਼ੀ ਨਾਲ ਅਸਲ ਉਤਪਾਦ ਮਾਡਲ ਦੇ ਸੁਝਾਏ ਨਾਲੋਂ ਵਧੇਰੇ ਵਿਭਿੰਨ ਬਣ ਜਾਂਦਾ ਹੈ।
ਸਾਫਟਵੇਅਰ ਪਰਤ ਹੁਣ ਹਰ ਇਕਾਈ ਨੂੰ ਇੱਕ ਅਮੂਰਤ "ਡਿਵਾਈਸ" ਨਹੀਂ ਮੰਨ ਸਕਦੀ। ਇਸਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਉਹ ਖਾਸ ਇਕਾਈ ਕੀ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੈ।
ਇੱਕ ਸੋਧਿਆ ਹੋਇਆ ਬੋਰਡ ਇੱਕ ਵੱਖਰੇ ਸੈਂਸਰ, ਸੰਚਾਰ ਮੋਡੀਊਲ, ਜਾਂ ਕੰਟਰੋਲਰ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਕਮਾਂਡ ਜੋ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਲਈ ਵੈਧ ਹੈ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਵਾਲੇ ਦੁਆਰਾ ਸਮਰਥਿਤ ਨਾ ਹੋਵੇ। ਕੈਲੀਬ੍ਰੇਸ਼ਨ ਮੁੱਲ ਬਦਲ ਸਕਦੇ ਹਨ। ਸੰਰਚਨਾ ਸੀਮਾਵਾਂ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਪੀੜ੍ਹੀ ਲਈ ਢੁਕਵਾਂ ਫਰਮਵੇਅਰ ਪੈਕੇਜ ਦੂਜੀ ਪੀੜ੍ਹੀ ਲਈ ਅਸੁਰੱਖਿਅਤ ਹੋ ਸਕਦਾ ਹੈ।
ਭੌਤਿਕ ਉਤਪਾਦ ਇੰਜੀਨੀਅਰ ਪਹਿਲਾਂ ਹੀ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ। ਦੋ ਹਿੱਸੇ ਜੋ ਲਗਭਗ ਇੱਕੋ ਜਿਹੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਜੇਕਰ ਉਹਨਾਂ ਦੇ ਸੰਸ਼ੋਧਨ, ਸਹਿਣਸ਼ੀਲਤਾ, ਜਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵੱਖਰੀਆਂ ਹਨ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। ਜੁੜੇ ਉਤਪਾਦ ਸਾਫਟਵੇਅਰ ਵਾਲੇ ਪਾਸੇ ਇੱਕੋ ਜਿਹੀ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦੇ ਹਨ: ਪਲੇਟਫਾਰਮ ਨੂੰ ਇਹ ਸਮਝਣ ਲਈ ਇੱਕ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਇਹ ਭੌਤਿਕ ਉਤਪਾਦ ਦੇ ਕਿਸ ਸੰਸਕਰਣ ਨਾਲ ਗੱਲ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸ 'ਤੇ ਕਿਹੜੇ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਅਜਿਹੇ ਉਤਪਾਦ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜਿਸਦਾ ਪਹਿਲਾ ਸੰਸ਼ੋਧਨ ਇੱਕ ਕੈਲੀਬ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜਾ ਇੱਕ ਨਵਾਂ ਸੈਂਸਰ ਅਤੇ ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਇੱਕ ਵੱਖਰਾ ਸੈੱਟ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਗਾਹਕ ਲਈ, ਦੋਵੇਂ ਯੂਨਿਟ ਅਜੇ ਵੀ ਇੱਕੋ ਉਤਪਾਦ ਹੋ ਸਕਦੇ ਹਨ। ਪਲੇਟਫਾਰਮ ਲਈ, ਉਹ ਨਹੀਂ ਹੋ ਸਕਦੇ।
ਜੇਕਰ ਉਹਨਾਂ ਅੰਤਰਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਵਿਸ਼ੇਸ਼ ਮਾਮਲਿਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਲਾਜਿਕ ਵਿੱਚ ਲੀਕ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਵਰਕਫਲੋ ਇੱਕ ਸੀਰੀਅਲ-ਨੰਬਰ ਰੇਂਜ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਦੂਜਾ ਹਾਰਡਵੇਅਰ ਜਨਰੇਸ਼ਨ ਲਈ ਇੱਕ ਪ੍ਰੌਕਸੀ ਵਜੋਂ ਇੱਕ ਫਰਮਵੇਅਰ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਤੀਜੇ ਵਿੱਚ ਇੱਕ ਅਪਵਾਦ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਹਾਇਤਾ ਦੁਆਰਾ ਖੇਤਰ ਵਿੱਚ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਵਿਵਹਾਰ ਕਰਨ ਵਾਲੇ ਇੱਕ ਪੁਰਾਣੇ ਬੈਚ ਦੀ ਖੋਜ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਫਿਕਸ ਆਪਣੇ ਆਪ ਵਿੱਚ ਖਾਸ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਨਹੀਂ ਲੱਗਦਾ, ਪਰ ਇਕੱਠੇ ਮਿਲ ਕੇ ਇਹ ਹਰ ਭਵਿੱਖੀ ਤਬਦੀਲੀ ਬਾਰੇ ਤਰਕ ਕਰਨਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ।
ਪੁਰਾਣਾ ਹਾਰਡਵੇਅਰ ਘੱਟ ਹੀ ਸਮੇਂ ਸਿਰ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਤਪਾਦ ਟੀਮਾਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਨਵੀਨਤਮ ਸੰਸ਼ੋਧਨ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਤ ਕਰਦੀਆਂ ਹਨ, ਜਦੋਂ ਕਿ ਗਾਹਕ ਅਕਸਰ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਉਮੀਦ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਰੱਖਦੇ ਹਨ। ਇਸ ਲਈ ਪਲੇਟਫਾਰਮ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਕਈ ਪੀੜ੍ਹੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਨਾ ਕਿ ਇਹ ਮੰਨ ਕੇ ਕਿ ਸਥਾਪਿਤ ਅਧਾਰ ਕਦੇ ਵੀ ਇੱਕ ਸਿੰਗਲ ਮੌਜੂਦਾ ਸਥਿਤੀ 'ਤੇ ਇਕੱਠਾ ਹੋ ਜਾਵੇਗਾ।
ਇੱਕ ਵਾਰ ਅਜਿਹਾ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਹਾਰਡਵੇਅਰ ਵਿਕਾਸ ਅਤੇ ਸਾਫਟਵੇਅਰ ਜੀਵਨ ਚੱਕਰ ਪ੍ਰਬੰਧਨ ਅਟੁੱਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਪਲੇਟਫਾਰਮ ਨੂੰ ਨਾ ਸਿਰਫ਼ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਇੱਕ ਡਿਵਾਈਸ ਕਿੱਥੇ ਹੈ ਅਤੇ ਕੀ ਇਹ ਔਨਲਾਈਨ ਹੈ, ਸਗੋਂ ਇਹ ਕੀ ਹੈ, ਇਹ ਕੀ ਚੱਲ ਸਕਦਾ ਹੈ, ਇਸਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਬਦਲਾਅ ਲਾਗੂ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹਨ।
ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਸਵਾਲ ਦਾ ਭਰੋਸੇਯੋਗ ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ, ਹਰੇਕ ਡਿਵਾਈਸ ਨੂੰ ਸਿਸਟਮ ਵਿੱਚ ਇੱਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਦਾਖਲ ਹੋਣਾ ਪੈਂਦਾ ਹੈ।
ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਮੈਨੂਅਲ ਇੰਜੀਨੀਅਰਿੰਗ ਸਕੇਲਿੰਗ ਨੂੰ ਰੋਕਦੀ ਹੈ।
ਜਦੋਂ ਫਲੀਟ ਛੋਟਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਸਧਾਰਨ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ: ਇੱਕ ਡਿਵਾਈਸ ਰਿਕਾਰਡ ਬਣਾਓ, ਇੱਕ ਸੀਰੀਅਲ ਨੰਬਰ ਦਰਜ ਕਰੋ, ਪ੍ਰਮਾਣ ਪੱਤਰ ਤਿਆਰ ਕਰੋ, ਇੱਕ ਗਾਹਕ ਨੂੰ ਯੂਨਿਟ ਨਿਰਧਾਰਤ ਕਰੋ, ਇੱਕ ਸੰਰਚਨਾ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਅੱਗੇ ਵਧੋ। ਕੁਝ ਦਰਜਨ ਡਿਵਾਈਸਾਂ ਲਈ, ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਨੂੰ ਹੱਥੀਂ ਸੰਭਾਲਣਾ ਅਜੇ ਵੀ ਸਹੀ ਵਿਕਲਪ ਹੋ ਸਕਦਾ ਹੈ।
ਹਾਲਾਂਕਿ, ਉਤਪਾਦਨ ਦੇ ਪੈਮਾਨੇ 'ਤੇ, ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਡਿਵਾਈਸ ਪਛਾਣ, ਪ੍ਰਮਾਣ ਪੱਤਰ, ਮਾਲਕੀ, ਸੰਰਚਨਾ, ਅਤੇ ਜੀਵਨਚੱਕਰ ਸਥਿਤੀ ਦੇ ਲਾਂਘੇ 'ਤੇ ਬੈਠਦੀ ਹੈ। ਆਨਬੋਰਡਿੰਗ ਦੌਰਾਨ ਕੀਤੀ ਗਈ ਇੱਕ ਗਲਤੀ ਇਸ ਗੱਲ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ ਕਿ ਯੂਨਿਟ ਫੈਕਟਰੀ ਛੱਡਣ ਤੋਂ ਬਾਅਦ ਕਿਵੇਂ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਮਰਥਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਪ੍ਰੈਡਸ਼ੀਟ ਹੁਣ ਅਸਲ ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤੇ ਗਏ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ ਬਦਲਵੇਂ ਡਿਵਾਈਸ ਨੂੰ ਗਲਤ ਪਛਾਣ ਪ੍ਰਾਪਤ ਕੀਤੇ ਬਿਨਾਂ ਸਹੀ ਗਾਹਕ ਐਸੋਸੀਏਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਫੈਕਟਰੀ ਰੀਸੈਟ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਇੱਕ ਹੋਰ ਰਸਤਾ ਬਣਾਉਂਦੇ ਹਨ। ਇੱਕ ਇੰਸਟਾਲਰ ਇੱਕ ਯੂਨਿਟ ਨੂੰ ਗਲਤ ਖਾਤੇ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ, ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਸਹਾਇਤਾ ਛੱਡਦਾ ਹੈ ਕਿ ਇਹ ਔਫਲਾਈਨ ਹੈ, ਗਲਤ ਢੰਗ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਹੈ, ਜਾਂ ਸਿਰਫ਼ ਗਲਤ ਸੰਰਚਨਾ ਲੈ ਰਿਹਾ ਹੈ।
ਇੱਕ ਵਾਰ ਜਦੋਂ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਲਈ ਇੱਕ ਡਿਵੈਲਪਰ ਨੂੰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਇੱਕ ਡੇਟਾਬੇਸ ਦਾ ਨਿਰੀਖਣ ਕਰਨ ਜਾਂ ਇੱਕ ਅੰਦਰੂਨੀ ਸਕ੍ਰਿਪਟ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਨੇ ਉਤਪਾਦ ਦੇ ਨਾਲ ਸਕੇਲਿੰਗ ਬੰਦ ਕਰ ਦਿੱਤੀ ਹੈ।
ਡੁਪਲੀਕੇਸ਼ਨ ਇੱਕ ਹੋਰ ਚੇਤਾਵਨੀ ਸੰਕੇਤ ਹੈ। ਹਰੇਕ ਉਤਪਾਦ ਰੂਪ ਆਪਣੀ ਖੁਦ ਦੀ ਔਨਬੋਰਡਿੰਗ ਸਕ੍ਰਿਪਟ, ਕੌਂਫਿਗਰੇਸ਼ਨ ਟੂਲ, ਜਾਂ ਇੰਸਟਾਲਰ ਵਰਕਫਲੋ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ। ਉਹ ਅੰਤਰ ਛੋਟੇ ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਅੰਤਰੀਵ ਜ਼ਿੰਮੇਵਾਰੀ ਇੱਕੋ ਜਿਹੀ ਹੈ। ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਕਿਸੇ ਖਾਸ ਡਿਵਾਈਸ ਨਾਲ ਜੁੜੇ ਸੈੱਟਅੱਪ ਕਾਰਜ ਦੀ ਬਜਾਏ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਪਲੇਟਫਾਰਮ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣ ਗਿਆ ਹੈ।
ਅਤੇ ਇਹ ਸ਼ਾਇਦ ਹੀ ਇੱਕੋ ਇੱਕ ਸਮਰੱਥਾ ਹੈ ਜਿਸਨੂੰ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ।
ਪਲੇਟਫਾਰਮ ਪਰਤ ਨੂੰ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਵਾਰ ਜਦੋਂ ਕਈ ਉਤਪਾਦ ਜਾਂ ਹਾਰਡਵੇਅਰ ਸੋਧਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਬੁਨਿਆਦੀ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਕੁਝ ਸਾਫਟਵੇਅਰ ਸਮਰੱਥਾਵਾਂ ਉਤਪਾਦ-ਵਿਸ਼ੇਸ਼ ਹੋਣੀਆਂ ਬੰਦ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਡਿਵਾਈਸ ਪਛਾਣ, ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ, ਕਨੈਕਟੀਵਿਟੀ, ਟੈਲੀਮੈਟਰੀ, ਫਰਮਵੇਅਰ ਡਿਲੀਵਰੀ, ਲਾਈਫਸਾਈਕਲ ਸਟੇਟ, ਫਲੀਟ ਵਿਜ਼ੀਬਿਲਟੀ, ਅਤੇ ਡਾਇਗਨੌਸਟਿਕਸ ਚੰਗੀਆਂ ਉਦਾਹਰਣਾਂ ਹਨ। ਹਰੇਕ ਨਵੇਂ ਵੇਰੀਐਂਟ ਲਈ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਨਾਲ ਉਤਪਾਦ ਨੂੰ ਹੋਰ ਵਿਲੱਖਣ ਬਣਾਏ ਬਿਨਾਂ ਬਣਾਈ ਰੱਖਣ ਲਈ ਵਧੇਰੇ ਕੋਡ ਅਤੇ ਵਧੇਰੇ ਕਾਰਜਸ਼ੀਲ ਮਾਰਗ ਬਣਦੇ ਹਨ।
ਟੀਮਾਂ ਇਸ ਡੁਪਲੀਕੇਸ਼ਨ ਨੂੰ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਘੱਟ ਹੀ ਨਿਕਲਦੀਆਂ ਹਨ। ਹਰੇਕ ਉਤਪਾਦ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਛੋਟੇ-ਛੋਟੇ ਅੰਤਰ ਇਕੱਠੇ ਹੁੰਦੇ ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਟੀਮ ਇੱਕੋ ਇੰਜੀਨੀਅਰਿੰਗ ਜ਼ਿੰਮੇਵਾਰੀ ਦੇ ਕਈ ਲਾਗੂਕਰਨਾਂ ਨੂੰ ਬਣਾਈ ਨਹੀਂ ਰੱਖਦੀ।
ਇੱਕ ਸਾਫ਼ ਸੀਮਾ ਉਤਪਾਦ ਪਰਤ ਨੂੰ ਪਲੇਟਫਾਰਮ ਪਰਤ ਤੋਂ ਵੱਖ ਕਰਨਾ ਹੈ। ਉਤਪਾਦ ਪਰਤ ਵਿੱਚ ਵਿਵਹਾਰ, ਵਰਕਫਲੋ, ਇੰਟਰਫੇਸ, ਏਕੀਕਰਣ ਅਤੇ ਡੋਮੇਨ ਤਰਕ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਜੋ ਇੱਕ ਖਾਸ ਡਿਵਾਈਸ ਨੂੰ ਕੀਮਤੀ ਬਣਾਉਂਦੇ ਹਨ। ਪਲੇਟਫਾਰਮ ਪਰਤ ਮਕੈਨਿਕਸ ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ ਜੋ ਹਾਰਡਵੇਅਰ ਬਦਲਣ ਦੇ ਬਾਵਜੂਦ ਵੀ ਇਕਸਾਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਜੁੜੇ ਉਤਪਾਦ ਆਪਣੀ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਤੋਂ ਅੱਗੇ ਵਧਦੇ ਹਨ, ਡਿਵਾਈਸ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ, ਡਿਵਾਈਸ ਲਾਈਫਸਾਈਕਲ ਮੈਨੇਜਮੈਂਟ, ਫਲੀਟ ਮੈਨੇਜਮੈਂਟ, ਅਤੇ ਸਪੋਰਟ ਟੂਲਿੰਗ ਇੱਕ-ਵਾਰੀ ਪ੍ਰੋਜੈਕਟ ਵੇਰਵਿਆਂ ਦੀ ਬਜਾਏ ਸਾਂਝਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣ ਜਾਂਦੇ ਹਨ। ਉੱਦਮਾਂ ਲਈ ਇੱਕ IoT PaaS ਕਈ ਉਤਪਾਦਾਂ ਜਾਂ ਉਤਪਾਦ ਰੂਪਾਂ ਵਿੱਚ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਪਲੇਟਫਾਰਮ ਪਰਤ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ, ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਰਾਹੀਂ ਮਿਆਰੀ ਡਿਵਾਈਸ ਅਤੇ ਡੇਟਾ ਪ੍ਰਬੰਧਨ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਆਪਣੇ ਕਸਟਮ ਯਤਨਾਂ ਨੂੰ ਹਾਰਡਵੇਅਰ, ਵਰਕਫਲੋ ਅਤੇ ਉਪਭੋਗਤਾ ਅਨੁਭਵ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦੀਆਂ ਹਨ।
ਇੱਕ ਸਾਂਝੇ ਆਧਾਰ ਨੂੰ ਅਜੇ ਵੀ ਅਸਲ ਉਤਪਾਦ ਅੰਤਰਾਂ ਲਈ ਜਗ੍ਹਾ ਛੱਡਣੀ ਪੈਂਦੀ ਹੈ। ਇੱਕ ਨਵੇਂ ਡਿਵਾਈਸ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਡੇਟਾ ਮਾਡਲ, ਸੰਰਚਨਾ ਪ੍ਰਵਾਹ, ਏਕੀਕਰਣ, ਜਾਂ ਨਿਯੰਤਰਣ ਤਰਕ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਅੰਤਰਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨਾ ਆਸਾਨ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਟੀਚਾ ਸਿਰਫ਼ ਇਹ ਹੈ ਕਿ ਹਰ ਅੰਤਰ ਨੂੰ ਕਿਸੇ ਹੋਰ ਡਿਵਾਈਸ ਰਜਿਸਟਰੀ, ਟੈਲੀਮੈਟਰੀ ਪਾਈਪਲਾਈਨ, ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਵਿਧੀ, ਜਾਂ ਫਲੀਟ-ਪ੍ਰਬੰਧਨ ਸਾਧਨਾਂ ਦੇ ਸੈੱਟ ਨਾਲ ਖਿੱਚਣ ਤੋਂ ਬਚਿਆ ਜਾਵੇ।
ਜਦੋਂ ਟੀਮ ਪਹਿਲਾ ਉਤਪਾਦ ਬਣਾ ਰਹੀ ਹੋਵੇ ਤਾਂ ਪਲੇਟਫਾਰਮ ਓਵਰਹੈੱਡ ਵਰਗਾ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਜਾਂ ਤੀਜੇ ਦੁਆਰਾ ਇੱਕ ਸੰਪਤੀ ਵਾਂਗ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਆਮ ਸੰਚਾਲਨ ਮਕੈਨਿਕਸ ਸਥਾਪਤ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਨਵਾਂ ਰੂਪ ਇੱਕ ਹੋਰ ਬੈਕਐਂਡ ਦੇ ਨਾਲ ਆਉਣ ਦੀ ਬਜਾਏ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਨੀਂਹ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਟੀਮ ਨੂੰ ਉਸ ਉਤਪਾਦ ਦੇ ਬਾਕੀ ਜੀਵਨ ਲਈ ਬਣਾਈ ਰੱਖਣਾ ਪਵੇਗਾ।
ਜਿੱਥੇ ਉਤਪਾਦ ਅਸਲ ਵਿੱਚ ਵੱਖਰਾ ਹੋਵੇ, ਉੱਥੇ ਕਸਟਮ ਇੰਜੀਨੀਅਰਿੰਗ ਰੱਖੋ।
ਇੱਕ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਪਲੇਟਫਾਰਮ ਨੂੰ ਜੁੜੇ ਉਤਪਾਦਾਂ ਨੂੰ ਵਧੇਰੇ ਆਮ ਨਹੀਂ ਬਣਾਉਣਾ ਚਾਹੀਦਾ। ਇਸਦਾ ਕੰਮ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਤੋਂ ਵਾਰ-ਵਾਰ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਹਟਾਉਣਾ ਹੈ ਜੋ ਵਿਭਿੰਨਤਾ ਪੈਦਾ ਨਹੀਂ ਕਰਦੇ।
ਕਸਟਮ ਯਤਨ ਅਜੇ ਵੀ ਡਿਵਾਈਸ ਵਿਵਹਾਰ, ਡੋਮੇਨ-ਵਿਸ਼ੇਸ਼ ਤਰਕ, ਵਰਕਫਲੋ, ਉਪਭੋਗਤਾ ਅਨੁਭਵ, ਵਿਸ਼ੇਸ਼ ਏਕੀਕਰਨ, ਅਤੇ ਇੱਕ ਖਾਸ ਉਤਪਾਦ ਦੇ ਭੌਤਿਕ ਸੰਸਾਰ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨਾਲ ਸਬੰਧਤ ਹਨ। ਇਹ ਬਿਲਕੁਲ ਉਹ ਖੇਤਰ ਹਨ ਜਿੱਥੇ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿਕਲਪ ਇੱਕ ਉਤਪਾਦ ਨੂੰ ਦੂਜੇ ਨਾਲੋਂ ਅਰਥਪੂਰਨ ਤੌਰ 'ਤੇ ਬਿਹਤਰ ਬਣਾ ਸਕਦੇ ਹਨ।
ਜੋ ਚੀਜ਼ ਘੱਟ ਹੀ ਇੱਕੋ ਜਿਹੇ ਇਲਾਜ ਦੇ ਹੱਕਦਾਰ ਹੈ ਉਹ ਹੈ ਆਲੇ ਦੁਆਲੇ ਦੀ ਕਾਰਜਸ਼ੀਲ ਪਲੰਬਿੰਗ। ਇੱਕੋ ਮਸ਼ੀਨ ਦੇ ਇੱਕ ਮੁੱਢਲੇ ਸੰਸਕਰਣ ਅਤੇ ਇੱਕ ਉਦਯੋਗਿਕ ਸੰਸਕਰਣ ਨੂੰ ਵੱਖ-ਵੱਖ ਸੈਂਸਰਾਂ, ਨਿਯੰਤਰਣਾਂ ਅਤੇ ਇੰਟਰਫੇਸਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਡਿਵਾਈਸਾਂ ਦੀ ਪਛਾਣ ਕਰਨ, ਫਰਮਵੇਅਰ ਸੰਸਕਰਣਾਂ ਨੂੰ ਟਰੈਕ ਕਰਨ, ਜਾਂ ਫਲੀਟ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
ਮੈਂ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਇਹ ਦੇਖਣਾ ਪਸੰਦ ਕਰਾਂਗਾ ਕਿ ਉਹ ਉਸ ਸਮੇਂ ਨੂੰ ਖੇਤਰ ਵਿੱਚ ਉਤਪਾਦ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਸੁਧਾਰਨ ਵਿੱਚ ਬਿਤਾਉਣ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਟੀਮ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਕਿਸੇ ਹੋਰ ਉਤਪਾਦ ਲਈ ਮੌਜੂਦ ਮਕੈਨਿਕਸ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਇਆ ਜਾਵੇ। ਇੱਕ ਸਾਂਝੀ ਨੀਂਹ ਕਸਟਮ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਦਾਇਰੇ ਨੂੰ ਘੱਟ ਨਹੀਂ ਕਰਦੀ; ਇਹ ਉਸ ਯਤਨ ਨੂੰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੁਆਰਾ ਖਪਤ ਹੋਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
ਅਸਲ ਪ੍ਰੀਖਿਆ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਟੀਮ ਉਤਪਾਦ ਨੰਬਰ ਦੋ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ।
ਇੱਕ ਚੰਗਾ ਪਲੇਟਫਾਰਮ ਅਗਲੇ ਉਤਪਾਦ ਨੂੰ ਪਹਿਲੇ ਨਾਲੋਂ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ
ਜੇਕਰ ਉਤਪਾਦ ਨੰਬਰ ਦੋ ਨੂੰ ਉਤਪਾਦ ਨੰਬਰ ਇੱਕ ਵਾਂਗ ਹੀ ਪਲੇਟਫਾਰਮ ਕੰਮ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਅਸਲ ਵਿੱਚ ਬਹੁਤ ਘੱਟ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਹੈ।
ਇੱਕ ਨਵਾਂ ਰੂਪ ਓਪਰੇਟਿੰਗ ਮਾਡਲ ਦੇ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਬਦਲੇ ਨਹੀਂ ਹਨ: ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਫਲੋ, ਪਛਾਣ, ਜੀਵਨ ਚੱਕਰ ਮਕੈਨਿਕਸ, ਫਲੀਟ ਟੂਲ, ਫਰਮਵੇਅਰ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਸਹਾਇਤਾ ਦ੍ਰਿਸ਼ਟੀ, ਅਤੇ ਆਮ ਏਕੀਕਰਣ। ਇੰਜੀਨੀਅਰਿੰਗ ਕੋਸ਼ਿਸ਼ ਫਿਰ ਅੰਤਰਾਂ ਵਿੱਚ ਜਾਂਦੀ ਹੈ - ਸ਼ਾਇਦ ਇੱਕ ਨਵਾਂ ਸੈਂਸਰ ਪੈਕੇਜ, ਇੱਕ ਹੋਰ ਨਿਯੰਤਰਣ ਵਰਕਫਲੋ, ਜਾਂ ਇੱਕ ਗਾਹਕ-ਵਿਸ਼ੇਸ਼ ਏਕੀਕਰਣ - ਬੁਨਿਆਦ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਬਜਾਏ।
ਇੱਕ ਨਵੀਂ ਹਾਰਡਵੇਅਰ ਪੀੜ੍ਹੀ ਉਸੇ ਵਿਚਾਰ ਨੂੰ ਹੋਰ ਦਬਾਅ ਵਿੱਚ ਪਾਉਂਦੀ ਹੈ। ਇਸਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਕਾਫ਼ੀ ਹੱਦ ਤੱਕ ਬਦਲ ਸਕਦੀਆਂ ਹਨ ਜਦੋਂ ਕਿ ਪੁਰਾਣੀਆਂ ਇਕਾਈਆਂ ਖੇਤਰ ਵਿੱਚ ਸਰਗਰਮ ਰਹਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਪਰਿਪੱਕ ਪਲੇਟਫਾਰਮ ਟੀਮ ਨੂੰ ਦੋ ਵੱਖਰੇ ਪਲੇਟਫਾਰਮ ਸਟੈਕਾਂ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਮਜਬੂਰ ਕੀਤੇ ਬਿਨਾਂ ਦੋਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਗਾਹਕ ਅਜੇ ਵੀ ਇੱਕ ਉਤਪਾਦ ਪਰਿਵਾਰ ਵਜੋਂ ਸਮਝਦੇ ਹਨ।
ਇਸ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ ਇੱਕ ਮੋਨੋਲਿਥਿਕ ਬੈਕਐਂਡ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਵੱਖ-ਵੱਖ ਉਤਪਾਦਾਂ ਨੂੰ ਅਜੇ ਵੀ ਸਪੱਸ਼ਟ ਆਰਕੀਟੈਕਚਰਲ ਸੀਮਾਵਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਬਿਨਾਂ ਕਿਸੇ ਚੰਗੇ ਕਾਰਨ ਦੇ ਇੱਕੋ ਇੰਜੀਨੀਅਰਿੰਗ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਦੂਜੀ ਵਾਰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਚਣਾ।
ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਪਲੇਟਫਾਰਮ ਇਕੱਠਾ ਹੋਇਆ ਓਵਰਹੈੱਡ ਹੋਣ ਦੀ ਬਜਾਏ ਇੱਕ ਸੰਪਤੀ ਬਣ ਜਾਂਦਾ ਹੈ। ਸਹਾਇਤਾ ਕੋਲ ਸਮਝਣ ਲਈ ਘੱਟ ਸਮਾਨਾਂਤਰ ਟੂਲ ਹਨ, ਰੀਲੀਜ਼ਾਂ ਵਧੇਰੇ ਇਕਸਾਰ ਮਾਰਗਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਹੋਰ ਉਤਪਾਦ ਜੋੜਨਾ ਇੱਕ ਹੋਰ ਬੈਕਐਂਡ ਦੀ ਬਜਾਏ ਇੱਕ ਨਿਯੰਤਰਿਤ ਐਕਸਟੈਂਸ਼ਨ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਕੰਪਨੀ ਨੂੰ ਅਣਮਿੱਥੇ ਸਮੇਂ ਲਈ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ।
ਪਲੇਟਫਾਰਮ ਨੂੰ ਉਤਪਾਦ ਆਰਕੀਟੈਕਚਰ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਮਝੋ
ਭੌਤਿਕ ਉਤਪਾਦਾਂ ਨੂੰ ਸੋਧਾਂ, ਸੇਵਾਯੋਗਤਾ, ਨਿਰਮਾਣਯੋਗਤਾ ਅਤੇ ਭਵਿੱਖੀ ਤਬਦੀਲੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜੁੜੇ ਉਤਪਾਦਾਂ ਨੂੰ ਸਾਫਟਵੇਅਰ ਵਾਲੇ ਪਾਸੇ ਵੀ ਉਹੀ ਅਨੁਸ਼ਾਸਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਪਹਿਲਾ ਬੈਕਐਂਡ ਅਸਥਾਈ ਹੋ ਸਕਦਾ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ ਪਹਿਲੀ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਸਕ੍ਰਿਪਟ ਜਾਂ ਸਹਾਇਤਾ ਟੂਲ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ। ਸਮੱਸਿਆਵਾਂ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਅਸਥਾਈ ਮਕੈਨਿਕਸ ਚੁੱਪਚਾਪ ਸਥਾਈ ਆਰਕੀਟੈਕਚਰ ਬਣ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਕਿ ਉਤਪਾਦ ਖੁਦ ਵਿਕਸਤ ਹੁੰਦਾ ਰਹਿੰਦਾ ਹੈ।
ਉਦੋਂ ਤੱਕ, ਜੁੜਿਆ ਹੋਇਆ ਉਤਪਾਦ ਹੁਣ ਸਿਰਫ਼ ਹਾਰਡਵੇਅਰ, ਫਰਮਵੇਅਰ ਅਤੇ ਇੱਕ ਐਪ ਨਹੀਂ ਰਹਿੰਦਾ। ਇਹ ਉਸ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਵੀ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਹਰੇਕ ਡਿਵਾਈਸ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਇਸਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਸਮਝਦਾ ਹੈ, ਸਹੀ ਸੰਰਚਨਾ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅੱਪਡੇਟਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਸ਼ਿਪਮੈਂਟ ਤੋਂ ਸਾਲਾਂ ਬਾਅਦ ਟੀਮਾਂ ਨੂੰ ਸਮੱਸਿਆਵਾਂ ਦਾ ਨਿਦਾਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਇੱਕ ਵਾਰ ਜਦੋਂ ਉਸ ਪਰਤ ਨੂੰ ਉਤਪਾਦ ਆਰਕੀਟੈਕਚਰ ਵਜੋਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਵੰਡ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦੀ ਹੈ: ਮਿਆਰੀ ਮਕੈਨਿਕਸ ਮੁੜ ਵਰਤੋਂ ਯੋਗ ਰਹਿੰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਕਸਟਮ ਕੰਮ ਉਸ ਵਿੱਚ ਜਾਂਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਇੱਕ ਉਤਪਾਦ ਜਾਂ ਉਤਪਾਦ ਪਰਿਵਾਰ ਨੂੰ ਦੂਜੇ ਤੋਂ ਵੱਖਰਾ ਕਰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਪਲੇਟਫਾਰਮ ਸਿਰਫ਼ ਉਹ ਨਹੀਂ ਹੈ ਜੋ ਪਹਿਲੇ ਜੁੜੇ ਉਤਪਾਦ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਉਹ ਹੈ ਜੋ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਨੂੰ ਹਰ ਵਾਰ ਨਵਾਂ ਬੈਕਐਂਡ ਪ੍ਰਾਪਤ ਕੀਤੇ ਬਿਨਾਂ ਦੂਜਾ, ਤੀਜਾ ਅਤੇ ਚੌਥਾ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ।
