ಸಂಪರ್ಕಿತ ಉತ್ಪನ್ನವು ಅದರ ಸುತ್ತಲಿನ ಎಂಜಿನಿಯರಿಂಗ್ ಪೂರ್ಣಗೊಳ್ಳುವ ಮೊದಲೇ ಮುಗಿದಂತೆ ಕಾಣಿಸಬಹುದು. ಮೂಲಮಾದರಿಯು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ, ಡೇಟಾ ಕ್ಲೌಡ್ ಅನ್ನು ತಲುಪುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಸರಿಯಾದ ಮೌಲ್ಯಗಳನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಸಾಧನಗಳ ಮೊದಲ ಬ್ಯಾಚ್ ಈಗಾಗಲೇ ಬಳಕೆದಾರರ ಕೈಯಲ್ಲಿದೆ. ಆ ಸಮಯದಲ್ಲಿ, ಬ್ಯಾಕೆಂಡ್ ಇನ್ನೂ ಸರಳವಾಗಿರಬಹುದು, ತಂಡವು ಪ್ರತಿಯೊಂದು ಸಾಧನವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ತಿಳಿದಿರುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್‌ನೊಂದಿಗೆ ಪೂರೈಕೆಯನ್ನು ನಿರ್ವಹಿಸಬಹುದು, ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾಡಬಹುದು ಮತ್ತು ಏನಾದರೂ ವಿಫಲವಾದರೆ, ಎಂಜಿನಿಯರ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಮಸ್ಯೆಯನ್ನು ನೇರವಾಗಿ ಪತ್ತೆಹಚ್ಚಬಹುದು.
ನಂತರ ಅದು ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ ಬದುಕಲು ಪ್ರಾರಂಭಿಸಬೇಕು. ಎರಡನೇ ಹಾರ್ಡ್‌ವೇರ್ ಪರಿಷ್ಕರಣೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಕೆಲವು ಗ್ರಾಹಕರು ಇನ್ನೂ ಮೊದಲ ಪರಿಷ್ಕರಣೆಯನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ. ಫರ್ಮ್‌ವೇರ್ ಆವೃತ್ತಿಗಳು ಭಿನ್ನವಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಬೇರೆ ಗ್ರಾಹಕರು ಅಥವಾ ಮಾರುಕಟ್ಟೆಗೆ ಹೊಸ ಕಾನ್ಫಿಗರೇಶನ್ ಅಗತ್ಯವಿದೆ, ಆದರೆ ಹಳೆಯ ಸಾಧನಗಳಿಗೆ ಇನ್ನೂ ನವೀಕರಣಗಳು ಮತ್ತು ಬೆಂಬಲ ಬೇಕಾಗುತ್ತದೆ.
ಯಾವುದೂ ಮುರಿದುಹೋಗಲೇಬೇಕೆಂದಿಲ್ಲ. ಸಾಧನದ ಹಿಂದಿರುವ ಸಾಫ್ಟ್‌ವೇರ್ ತನ್ನದೇ ಆದ ಜೀವನಚಕ್ರವನ್ನು ಪಡೆದುಕೊಂಡಿದೆ.
ಮೂಲಮಾದರಿಯು ಸಂಪೂರ್ಣವಾಗಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದಾದ್ದರಿಂದ ಆ ಪರಿವರ್ತನೆಯನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದು ಸುಲಭ. ಆದರೆ ಒಂದೇ ಭೌತಿಕ ಉತ್ಪನ್ನದ ಬಹು ಆವೃತ್ತಿಗಳು ಕ್ಷೇತ್ರದಲ್ಲಿ ಸಹಬಾಳ್ವೆ ನಡೆಸಬೇಕಾದ ನಂತರ, ಬ್ಯಾಕೆಂಡ್ ಇನ್ನು ಮುಂದೆ ಹಾರ್ಡ್‌ವೇರ್‌ನ ಹಿಂದೆ ಕೇವಲ ಮೂಲಸೌಕರ್ಯವಾಗಿ ಉಳಿಯುವುದಿಲ್ಲ. ಇದು ಉತ್ಪನ್ನ ವಾಸ್ತುಶಿಲ್ಪದ ಭಾಗವಾಗುತ್ತದೆ.
ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಂಪರ್ಕಿತ ಮೂಲಮಾದರಿಯು ಇನ್ನೂ ಸ್ಕೇಲೆಬಲ್ ಉತ್ಪನ್ನವಾಗಿಲ್ಲ.
ಮೂಲಮಾದರಿಯು ಒಂದು ಪ್ರಮುಖ ಕೆಲಸವನ್ನು ಹೊಂದಿದೆ: ವ್ಯವಸ್ಥೆಯು ಕೊನೆಯಿಂದ ಕೊನೆಯವರೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ. ಸಾಧನವು ತನ್ನ ಪ್ರಮುಖ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಫರ್ಮ್‌ವೇರ್ ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ, ಟೆಲಿಮೆಟ್ರಿ ಅದು ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೋ ಅಲ್ಲಿಗೆ ತಲುಪುತ್ತದೆ, ಆಜ್ಞೆಗಳು ಹಿಂತಿರುಗುವ ಪ್ರವಾಸವನ್ನು ಮಾಡುತ್ತವೆ ಮತ್ತು ಮೊಬೈಲ್ ಅಥವಾ ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಬಳಕೆದಾರರಿಗೆ ಕಾರ್ಯವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.
ಒಂದೇ ವ್ಯವಸ್ಥೆಯು ವೈವಿಧ್ಯತೆಯನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಬೀತುಪಡಿಸಿಲ್ಲ.
ಮೊದಲ ಇಪ್ಪತ್ತು ಸಾಧನಗಳು ಒಂದೇ ರೀತಿಯ ಫರ್ಮ್‌ವೇರ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು, ಒಂದೇ ರೀತಿಯ ಹಾರ್ಡ್‌ವೇರ್ ಪರಿಷ್ಕರಣೆಗೆ ನಿರ್ಮಿಸಬಹುದು ಮತ್ತು ಅದೇ ಎಂಜಿನಿಯರ್‌ಗಳಿಂದ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಆ ಹಂತದಲ್ಲಿ, ಹಸ್ತಚಾಲಿತ ನೋಂದಣಿ, ನೇರ ಸಂರಚನಾ ಬದಲಾವಣೆಗಳು ಅಥವಾ ಸಣ್ಣ ಆನ್‌ಬೋರ್ಡಿಂಗ್ ಸ್ಕ್ರಿಪ್ಟ್ ಸಂಪೂರ್ಣವಾಗಿ ಸಮಂಜಸವಾಗಿರುತ್ತದೆ. ಉತ್ಪನ್ನವು ತನ್ನನ್ನು ತಾನು ಸಾಬೀತುಪಡಿಸುವ ಮೊದಲು ಉತ್ಪಾದನಾ ದರ್ಜೆಯ ಪರಿಕರಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಅಕಾಲಿಕವಾಗಿರಬಹುದು.
ಸ್ಕೇಲ್ ಸಮಸ್ಯೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಸಾಧನಗಳು ಆಫ್‌ಲೈನ್‌ನಲ್ಲಿ ಉಳಿಯುತ್ತವೆ, ಬದಲಾಯಿಸಲ್ಪಡುತ್ತವೆ, ವಿಭಿನ್ನ ಫರ್ಮ್‌ವೇರ್‌ಗಳನ್ನು ರನ್ ಮಾಡುತ್ತವೆ ಮತ್ತು ವಿಭಿನ್ನ ಗ್ರಾಹಕ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ಬೆಂಬಲವು ಎಂದಿಗೂ ಸರಿಯಾಗಿ ಒದಗಿಸದ ಮತ್ತು ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಅಥವಾ ಸರಳವಾಗಿ ತಲುಪಲಾಗದ ಘಟಕವನ್ನು ಪ್ರತ್ಯೇಕಿಸಬೇಕು.
ಮೂಲಮಾದರಿಯ ಸಾಲವು ಸಾಮಾನ್ಯವಾಗಿ ಈ ರೀತಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ಕೆಟ್ಟ ನಿರ್ಧಾರದಿಂದಲ್ಲ, ಆದರೆ ಉತ್ಪನ್ನವು ಸ್ಥಳಾಂತರಗೊಂಡ ನಂತರವೂ ಉಳಿಯುವ ತಾತ್ಕಾಲಿಕ ನಿರ್ಧಾರದಿಂದ. ಮತ್ತು ಆ ಪರಿವರ್ತನೆಯನ್ನು ವೀಕ್ಷಣೆಗೆ ಒತ್ತಾಯಿಸುವ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಹಾರ್ಡ್‌ವೇರ್. ಹೊಸ ಪರಿಷ್ಕರಣೆಯು ಹಳೆಯದನ್ನು ಸರಳವಾಗಿ ಬದಲಾಯಿಸುವುದಿಲ್ಲ; ಅದು ಅದರೊಂದಿಗೆ ಸಹಬಾಳ್ವೆ ನಡೆಸಬೇಕು.
ಪ್ರತಿಯೊಂದು ಹಾರ್ಡ್‌ವೇರ್ ಪರಿಷ್ಕರಣೆಯು ಸಾಫ್ಟ್‌ವೇರ್ ಜೀವನಚಕ್ರ ಸಮಸ್ಯೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಹಳೆಯದಕ್ಕೆ ಶುದ್ಧ ಬದಲಿಯಾಗಿ ಹೊಸ ಹಾರ್ಡ್‌ವೇರ್ ಪರಿಷ್ಕರಣೆ ವಿರಳವಾಗಿ ಬರುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಎರಡೂ ಆವೃತ್ತಿಗಳು ಕ್ಷೇತ್ರದಲ್ಲಿ ಉಳಿಯುತ್ತವೆ, ಕೆಲವೊಮ್ಮೆ ವರ್ಷಗಳವರೆಗೆ. ಪರಿವರ್ತನೆಯ ಬ್ಯಾಚ್, ಕೆಲವು ಫರ್ಮ್‌ವೇರ್ ಶಾಖೆಗಳು ಮತ್ತು ಗ್ರಾಹಕ-ನಿರ್ದಿಷ್ಟ ಸಂರಚನೆಗಳನ್ನು ಸೇರಿಸಿ, ಮತ್ತು ಫ್ಲೀಟ್ ಮೂಲ ಉತ್ಪನ್ನ ಮಾದರಿ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ತ್ವರಿತವಾಗಿ ಹೆಚ್ಚು ವೈವಿಧ್ಯಮಯವಾಗುತ್ತದೆ.
ಸಾಫ್ಟ್‌ವೇರ್ ಪದರವು ಇನ್ನು ಮುಂದೆ ಪ್ರತಿಯೊಂದು ಘಟಕವನ್ನು ಅಮೂರ್ತ "ಸಾಧನ" ಎಂದು ಪರಿಗಣಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆ ನಿರ್ದಿಷ್ಟ ಘಟಕವು ಏನು ಮಾಡಲು ಸಮರ್ಥವಾಗಿದೆ ಎಂಬುದನ್ನು ಅದು ತಿಳಿದುಕೊಳ್ಳಬೇಕು.
ಪರಿಷ್ಕೃತ ಬೋರ್ಡ್ ಬೇರೆ ಸೆನ್ಸರ್, ಸಂವಹನ ಮಾಡ್ಯೂಲ್ ಅಥವಾ ನಿಯಂತ್ರಕವನ್ನು ಬಳಸಬಹುದು. ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗೆ ಮಾನ್ಯವಾಗಿರುವ ಆಜ್ಞೆಯನ್ನು ಹಿಂದಿನದು ಬೆಂಬಲಿಸದೇ ಇರಬಹುದು. ಮಾಪನಾಂಕ ನಿರ್ಣಯ ಮೌಲ್ಯಗಳು ಬದಲಾಗಬಹುದು. ಸಂರಚನಾ ಮಿತಿಗಳು ಬದಲಾಗಬಹುದು. ಒಂದು ಪೀಳಿಗೆಗೆ ಸೂಕ್ತವಾದ ಫರ್ಮ್‌ವೇರ್ ಪ್ಯಾಕೇಜ್ ಮತ್ತೊಂದು ಪೀಳಿಗೆಗೆ ಅಸುರಕ್ಷಿತವಾಗಿರಬಹುದು.
ಭೌತಿಕ ಉತ್ಪನ್ನ ಎಂಜಿನಿಯರ್‌ಗಳು ಈಗಾಗಲೇ ಈ ರೀತಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಬಹುತೇಕ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ಘಟಕಗಳು ಅವುಗಳ ಪರಿಷ್ಕರಣೆಗಳು, ಸಹಿಷ್ಣುತೆಗಳು ಅಥವಾ ವಿಶೇಷಣಗಳು ಭಿನ್ನವಾಗಿದ್ದರೆ ಪರಸ್ಪರ ಬದಲಾಯಿಸಲಾಗುವುದಿಲ್ಲ. ಸಂಪರ್ಕಿತ ಉತ್ಪನ್ನಗಳು ಸಾಫ್ಟ್‌ವೇರ್ ಬದಿಯಲ್ಲಿ ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ: ಭೌತಿಕ ಉತ್ಪನ್ನದ ಯಾವ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದೆ ಮತ್ತು ಅದಕ್ಕೆ ಯಾವ ನಿಯಮಗಳು ಅನ್ವಯಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ವೇದಿಕೆಗೆ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗದ ಅಗತ್ಯವಿದೆ.
ಮೊದಲ ಪರಿಷ್ಕರಣೆಯು ಒಂದು ಮಾಪನಾಂಕ ನಿರ್ಣಯ ವಿಧಾನವನ್ನು ಬಳಸಿದರೆ, ಎರಡನೆಯದು ಹೊಸ ಸಂವೇದಕ ಮತ್ತು ವಿಭಿನ್ನ ನಿಯತಾಂಕಗಳನ್ನು ಪರಿಚಯಿಸುವ ಉತ್ಪನ್ನವನ್ನು ಪರಿಗಣಿಸಿ. ಗ್ರಾಹಕರಿಗೆ, ಎರಡೂ ಘಟಕಗಳು ಇನ್ನೂ ಒಂದೇ ಉತ್ಪನ್ನವಾಗಿರಬಹುದು. ವೇದಿಕೆಗೆ, ಅವು ಹಾಗೆ ಇರಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಆ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರತಿನಿಧಿಸದಿದ್ದರೆ, ಅವು ವಿಶೇಷ ಪ್ರಕರಣಗಳಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕಕ್ಕೆ ಸೋರಿಕೆಯಾಗುತ್ತವೆ. ಒಂದು ಕೆಲಸದ ಹರಿವು ಸರಣಿ-ಸಂಖ್ಯೆಯ ಶ್ರೇಣಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಇನ್ನೊಂದು ಹಾರ್ಡ್‌ವೇರ್ ಉತ್ಪಾದನೆಗೆ ಪ್ರಾಕ್ಸಿಯಾಗಿ ಫರ್ಮ್‌ವೇರ್ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತದೆ. ಬೆಂಬಲವು ಕ್ಷೇತ್ರದಲ್ಲಿ ಹಳೆಯ ಬ್ಯಾಚ್ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುವುದನ್ನು ಕಂಡುಹಿಡಿದ ನಂತರ ಸೇರಿಸಲಾದ ವಿನಾಯಿತಿಯನ್ನು ಮೂರನೇ ಒಂದು ಭಾಗ ಒಳಗೊಂಡಿದೆ. ಈ ಯಾವುದೇ ಪರಿಹಾರಗಳು ತನ್ನದೇ ಆದ ಮೇಲೆ ವಿಶೇಷವಾಗಿ ಅಪಾಯಕಾರಿಯಾಗಿ ಕಾಣುವುದಿಲ್ಲ, ಆದರೆ ಒಟ್ಟಿಗೆ ಅವು ಪ್ರತಿಯೊಂದು ಭವಿಷ್ಯದ ಬದಲಾವಣೆಯನ್ನು ತರ್ಕಿಸಲು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ.
ಹಳೆಯ ಹಾರ್ಡ್‌ವೇರ್ ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ವಿರಳವಾಗಿ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ಉತ್ಪನ್ನ ತಂಡಗಳು ಸ್ವಾಭಾವಿಕವಾಗಿ ಹೊಸ ಪರಿಷ್ಕರಣೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತವೆ, ಆದರೆ ಗ್ರಾಹಕರು ಹಿಂದಿನ ಆವೃತ್ತಿಗಳನ್ನು ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಇಟ್ಟುಕೊಳ್ಳುತ್ತಾರೆ. ಆದ್ದರಿಂದ, ಸ್ಥಾಪಿಸಲಾದ ಬೇಸ್ ಒಂದೇ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯಲ್ಲಿ ಒಮ್ಮುಖವಾಗುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು, ವೇದಿಕೆಯು ಹಲವಾರು ತಲೆಮಾರುಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಬೆಂಬಲಿಸಬೇಕಾಗುತ್ತದೆ.
ಅದು ಸಂಭವಿಸಿದ ನಂತರ, ಹಾರ್ಡ್‌ವೇರ್ ವಿಕಸನ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಜೀವನಚಕ್ರ ನಿರ್ವಹಣೆ ಬೇರ್ಪಡಿಸಲಾಗದಂತಾಗುತ್ತದೆ. ಸಾಧನ ಎಲ್ಲಿದೆ ಮತ್ತು ಅದು ಆನ್‌ಲೈನ್‌ನಲ್ಲಿದೆಯೇ ಎಂಬುದನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಅದು ಏನು, ಅದು ಏನು ಚಲಾಯಿಸಬಹುದು, ಅದನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು ಮತ್ತು ಯಾವ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುವುದು ಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂಬುದನ್ನು ವೇದಿಕೆಯು ತಿಳಿದುಕೊಳ್ಳಬೇಕು.
ಮತ್ತು ಆ ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳಿಗೆ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಉತ್ತರಿಸುವ ಮೊದಲು, ಪ್ರತಿಯೊಂದು ಸಾಧನವು ವ್ಯವಸ್ಥೆಯನ್ನು ಸ್ಥಿರವಾದ ರೀತಿಯಲ್ಲಿ ಪ್ರವೇಶಿಸಬೇಕು.
ಹಸ್ತಚಾಲಿತ ಎಂಜಿನಿಯರಿಂಗ್ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ನಿಲ್ಲಿಸುವ ಸ್ಥಳವೆಂದರೆ ಪ್ರಾವಿಷನಿಂಗ್.
ಫ್ಲೀಟ್ ಚಿಕ್ಕದಾಗಿದ್ದಾಗ ಪೂರೈಕೆ ಸರಳವಾಗಿ ಕಾಣುತ್ತದೆ: ಸಾಧನ ದಾಖಲೆಯನ್ನು ರಚಿಸಿ, ಸರಣಿ ಸಂಖ್ಯೆಯನ್ನು ನಮೂದಿಸಿ, ರುಜುವಾತುಗಳನ್ನು ರಚಿಸಿ, ಗ್ರಾಹಕರಿಗೆ ಘಟಕವನ್ನು ನಿಯೋಜಿಸಿ, ಸಂರಚನೆಯನ್ನು ಅನ್ವಯಿಸಿ ಮತ್ತು ಮುಂದುವರಿಯಿರಿ. ಕೆಲವು ಡಜನ್ ಸಾಧನಗಳಿಗೆ, ಇವುಗಳಲ್ಲಿ ಕೆಲವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸುವುದು ಇನ್ನೂ ಸರಿಯಾದ ಆಯ್ಕೆಯಾಗಿರಬಹುದು.
ಆದಾಗ್ಯೂ, ಉತ್ಪಾದನಾ ಪ್ರಮಾಣದಲ್ಲಿ, ಸರಬರಾಜು ಮಾಡುವಿಕೆಯು ಸಾಧನದ ಗುರುತು, ರುಜುವಾತುಗಳು, ಮಾಲೀಕತ್ವ, ಸಂರಚನೆ ಮತ್ತು ಜೀವನಚಕ್ರ ಸ್ಥಿತಿಯ ಛೇದಕದಲ್ಲಿದೆ. ಆನ್‌ಬೋರ್ಡಿಂಗ್ ಸಮಯದಲ್ಲಿ ಮಾಡಿದ ತಪ್ಪು, ಘಟಕವು ಕಾರ್ಖಾನೆಯನ್ನು ತೊರೆದ ನಂತರ ದೀರ್ಘಕಾಲದವರೆಗೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.
ಸ್ಪ್ರೆಡ್‌ಶೀಟ್ ಇನ್ನು ಮುಂದೆ ನಿಜವಾಗಿ ಸ್ಥಾಪಿಸಿದ್ದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದಿರಬಹುದು. ತಪ್ಪು ಗುರುತನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯದೆ ಬದಲಿ ಸಾಧನಕ್ಕೆ ಸರಿಯಾದ ಗ್ರಾಹಕ ಸಂಘದ ಅಗತ್ಯವಿದೆ. ಫ್ಯಾಕ್ಟರಿ ಮರುಹೊಂದಿಸುವಿಕೆಗಳು ಪ್ರಕ್ರಿಯೆಯ ಮೂಲಕ ಮತ್ತೊಂದು ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ. ಒಂದು ಸ್ಥಾಪಕವು ತಪ್ಪು ಖಾತೆಗೆ ಯೂನಿಟ್ ಅನ್ನು ನಿಯೋಜಿಸಬಹುದು, ಅದು ಆಫ್‌ಲೈನ್ ಆಗಿದೆಯೇ, ತಪ್ಪಾಗಿ ಒದಗಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಲು ಬೆಂಬಲವನ್ನು ಬಿಡಬಹುದು.
ಆ ಪ್ರಶ್ನೆಗಳಿಗೆ ನಿಯಮಿತವಾಗಿ ಉತ್ತರಿಸಲು ಡೆವಲಪರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬೇಕು ಅಥವಾ ಆಂತರಿಕ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಚಲಾಯಿಸಬೇಕು ಎಂದಾದರೆ, ಪ್ರಕ್ರಿಯೆಯು ಉತ್ಪನ್ನದೊಂದಿಗೆ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
ನಕಲು ಮಾಡುವುದು ಮತ್ತೊಂದು ಎಚ್ಚರಿಕೆಯ ಸಂಕೇತವಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನ ರೂಪಾಂತರವು ತನ್ನದೇ ಆದ ಆನ್‌ಬೋರ್ಡಿಂಗ್ ಸ್ಕ್ರಿಪ್ಟ್, ಕಾನ್ಫಿಗರೇಶನ್ ಟೂಲ್ ಅಥವಾ ಇನ್‌ಸ್ಟಾಲರ್ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆ ವ್ಯತ್ಯಾಸಗಳು ಚಿಕ್ಕದಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಆಧಾರವಾಗಿರುವ ಜವಾಬ್ದಾರಿ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ನಿರ್ದಿಷ್ಟ ಸಾಧನಕ್ಕೆ ಲಗತ್ತಿಸಲಾದ ಸೆಟಪ್ ಕಾರ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಪೂರೈಕೆಯು ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮೂಲಸೌಕರ್ಯವಾಗಿದೆ.
ಮತ್ತು ಇದು ವಿರಳವಾಗಿ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಏಕೈಕ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ.
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪದರವು ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಮೂಲಸೌಕರ್ಯವಾಗಬೇಕು.
ಹಲವಾರು ಉತ್ಪನ್ನಗಳು ಅಥವಾ ಹಾರ್ಡ್‌ವೇರ್ ಪರಿಷ್ಕರಣೆಗಳು ಒಂದೇ ರೀತಿಯ ಮೂಲಭೂತ ಅಗತ್ಯಗಳನ್ನು ಹಂಚಿಕೊಂಡ ನಂತರ, ಕೆಲವು ಸಾಫ್ಟ್‌ವೇರ್ ಸಾಮರ್ಥ್ಯಗಳು ಉತ್ಪನ್ನ-ನಿರ್ದಿಷ್ಟವಾಗಿರುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ. ಸಾಧನದ ಗುರುತು, ಪೂರೈಕೆ, ಸಂಪರ್ಕ, ಟೆಲಿಮೆಟ್ರಿ, ಫರ್ಮ್‌ವೇರ್ ವಿತರಣೆ, ಜೀವನಚಕ್ರ ಸ್ಥಿತಿ, ಫ್ಲೀಟ್ ಗೋಚರತೆ ಮತ್ತು ರೋಗನಿರ್ಣಯಗಳು ಉತ್ತಮ ಉದಾಹರಣೆಗಳಾಗಿವೆ. ಪ್ರತಿ ಹೊಸ ರೂಪಾಂತರಕ್ಕೂ ಅವುಗಳನ್ನು ಪುನರ್ನಿರ್ಮಿಸುವುದು ಉತ್ಪನ್ನವನ್ನು ಹೆಚ್ಚು ವಿಶಿಷ್ಟವಾಗಿಸದೆ ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚಿನ ಕೋಡ್ ಮತ್ತು ಹೆಚ್ಚು ಕಾರ್ಯಾಚರಣೆಯ ಮಾರ್ಗಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ತಂಡಗಳು ಈ ನಕಲನ್ನು ರಚಿಸಲು ವಿರಳವಾಗಿ ಹೊರಡುತ್ತವೆ. ತಂಡವು ಒಂದೇ ಎಂಜಿನಿಯರಿಂಗ್ ಜವಾಬ್ದಾರಿಯಾಗಿ ಮಾರ್ಪಟ್ಟಿರುವ ಹಲವಾರು ಅನುಷ್ಠಾನಗಳನ್ನು ನಿರ್ವಹಿಸುವವರೆಗೆ ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನದ ಸುತ್ತಲೂ ಸಣ್ಣ ವ್ಯತ್ಯಾಸಗಳು ಸಂಗ್ರಹವಾಗುತ್ತವೆ.
ಉತ್ಪನ್ನ ಪದರವನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪದರದಿಂದ ಬೇರ್ಪಡಿಸುವುದು ಒಂದು ಸ್ವಚ್ಛವಾದ ಗಡಿಯಾಗಿದೆ. ಉತ್ಪನ್ನ ಪದರವು ನಡವಳಿಕೆ, ಕೆಲಸದ ಹರಿವುಗಳು, ಇಂಟರ್ಫೇಸ್‌ಗಳು, ಏಕೀಕರಣಗಳು ಮತ್ತು ಡೊಮೇನ್ ತರ್ಕವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅದು ನಿರ್ದಿಷ್ಟ ಸಾಧನವನ್ನು ಮೌಲ್ಯಯುತವಾಗಿಸುತ್ತದೆ. ಹಾರ್ಡ್‌ವೇರ್ ಬದಲಾದಾಗಲೂ ಸ್ಥಿರವಾಗಿರಬೇಕಾದ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪದರವು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಸಂಪರ್ಕಿತ ಉತ್ಪನ್ನಗಳು ತಮ್ಮ ಮೊದಲ ಬಿಡುಗಡೆಯನ್ನು ಮೀರಿ ಹೋದಂತೆ, ಸಾಧನ ಪೂರೈಕೆ, ಸಾಧನ ಜೀವನಚಕ್ರ ನಿರ್ವಹಣೆ, ಫ್ಲೀಟ್ ನಿರ್ವಹಣೆ ಮತ್ತು ಬೆಂಬಲ ಪರಿಕರಗಳು ಒಂದೇ ಬಾರಿಗೆ ಯೋಜನೆಯ ವಿವರಗಳಿಗಿಂತ ಹಂಚಿಕೆಯ ಮೂಲಸೌಕರ್ಯವಾಗುತ್ತವೆ. ಉದ್ಯಮಗಳಿಗೆ IoT PaaS ಬಹು ಉತ್ಪನ್ನಗಳು ಅಥವಾ ಉತ್ಪನ್ನ ರೂಪಾಂತರಗಳಲ್ಲಿ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪದರವನ್ನು ಒದಗಿಸಬಹುದು, ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು ತಮ್ಮ ಕಸ್ಟಮ್ ಪ್ರಯತ್ನವನ್ನು ಹಾರ್ಡ್‌ವೇರ್, ಕೆಲಸದ ಹರಿವುಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ಅನುಭವದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವಾಗ ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳ ಮೂಲಕ ಪ್ರಮಾಣಿತ ಸಾಧನ ಮತ್ತು ಡೇಟಾ ನಿರ್ವಹಣೆಯನ್ನು ನಿರ್ವಹಿಸಬಹುದು.
ಒಂದು ಸಾಮಾನ್ಯ ಅಡಿಪಾಯವು ನಿಜವಾದ ಉತ್ಪನ್ನ ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಇನ್ನೂ ಅವಕಾಶ ನೀಡಬೇಕಾಗಿದೆ. ಹೊಸ ಸಾಧನಕ್ಕೆ ವಿಭಿನ್ನ ಡೇಟಾ ಮಾದರಿ, ಸಂರಚನಾ ಹರಿವು, ಏಕೀಕರಣ ಅಥವಾ ನಿಯಂತ್ರಣ ತರ್ಕದ ಅಗತ್ಯವಿರಬಹುದು ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಪರಿಚಯಿಸುವುದು ಸುಲಭವಾಗಿರಬೇಕು. ಪ್ರತಿಯೊಂದು ವ್ಯತ್ಯಾಸವನ್ನು ಮತ್ತೊಂದು ಸಾಧನ ನೋಂದಾವಣೆ, ಟೆಲಿಮೆಟ್ರಿ ಪೈಪ್‌ಲೈನ್, ಪೂರೈಕೆ ಕಾರ್ಯವಿಧಾನ ಅಥವಾ ಫ್ಲೀಟ್-ನಿರ್ವಹಣಾ ಪರಿಕರಗಳ ಸೆಟ್‌ನಲ್ಲಿ ಎಳೆಯುವುದನ್ನು ತಪ್ಪಿಸುವುದು ಗುರಿಯಾಗಿದೆ.
ತಂಡವು ಮೊದಲ ಉತ್ಪನ್ನವನ್ನು ನಿರ್ಮಿಸುವಾಗ ವೇದಿಕೆಯು ಓವರ್ಹೆಡ್‌ನಂತೆ ಕಾಣಿಸಬಹುದು ಮತ್ತು ಎರಡನೇ ಅಥವಾ ಮೂರನೇ ಉತ್ಪನ್ನದ ಹೊತ್ತಿಗೆ ಆಸ್ತಿಯಂತೆ ಕಾಣಿಸಬಹುದು. ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯವಿಧಾನಗಳು ಜಾರಿಗೆ ಬಂದ ನಂತರ, ಆ ಉತ್ಪನ್ನದ ಉಳಿದ ಅವಧಿಗೆ ತಂಡವು ನಿರ್ವಹಿಸಬೇಕಾದ ಮತ್ತೊಂದು ಬ್ಯಾಕೆಂಡ್‌ನೊಂದಿಗೆ ಬರುವ ಬದಲು ಹೊಸ ರೂಪಾಂತರವು ಕಾರ್ಯನಿರತ ಅಡಿಪಾಯವನ್ನು ಪಡೆದುಕೊಳ್ಳಬಹುದು.
ಉತ್ಪನ್ನವು ನಿಜವಾಗಿಯೂ ಭಿನ್ನವಾಗಿರುವಲ್ಲಿ ಕಸ್ಟಮ್ ಎಂಜಿನಿಯರಿಂಗ್ ಅನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ.
ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ವೇದಿಕೆಯು ಸಂಪರ್ಕಿತ ಉತ್ಪನ್ನಗಳನ್ನು ಹೆಚ್ಚು ಸಾರ್ವತ್ರಿಕವಾಗಿಸಬಾರದು. ವ್ಯತ್ಯಾಸವನ್ನು ಸೃಷ್ಟಿಸದ ಭಾಗಗಳಿಂದ ಪುನರಾವರ್ತಿತ ಎಂಜಿನಿಯರಿಂಗ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದು ಇದರ ಕೆಲಸ.
ಕಸ್ಟಮ್ ಪ್ರಯತ್ನವು ಇನ್ನೂ ಸಾಧನದ ನಡವಳಿಕೆ, ಡೊಮೇನ್-ನಿರ್ದಿಷ್ಟ ತರ್ಕ, ಕೆಲಸದ ಹರಿವುಗಳು, ಬಳಕೆದಾರ ಅನುಭವ, ವಿಶೇಷ ಏಕೀಕರಣಗಳು ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಉತ್ಪನ್ನವು ಭೌತಿಕ ಪ್ರಪಂಚದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ವಿಧಾನಕ್ಕೆ ಸೇರಿದೆ. ಎಂಜಿನಿಯರಿಂಗ್ ಆಯ್ಕೆಗಳು ಒಂದು ಉತ್ಪನ್ನವನ್ನು ಇನ್ನೊಂದಕ್ಕಿಂತ ಅರ್ಥಪೂರ್ಣವಾಗಿ ಉತ್ತಮಗೊಳಿಸುವ ಕ್ಷೇತ್ರಗಳು ಇವು.
ಸುತ್ತಮುತ್ತಲಿನ ಕಾರ್ಯಾಚರಣಾ ಪ್ಲಂಬಿಂಗ್‌ಗೆ ಒಂದೇ ರೀತಿಯ ಚಿಕಿತ್ಸೆ ಅಪರೂಪವಾಗಿ ಅರ್ಹವಾಗಿದೆ. ಒಂದೇ ಯಂತ್ರದ ಮೂಲ ಆವೃತ್ತಿ ಮತ್ತು ಕೈಗಾರಿಕಾ ಆವೃತ್ತಿಗೆ ವಿಭಿನ್ನ ಸಂವೇದಕಗಳು, ನಿಯಂತ್ರಣಗಳು ಮತ್ತು ಇಂಟರ್ಫೇಸ್‌ಗಳು ಬೇಕಾಗಬಹುದು, ಆದರೆ ಸಾಧನಗಳನ್ನು ಗುರುತಿಸಲು, ಫರ್ಮ್‌ವೇರ್ ಆವೃತ್ತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಅಥವಾ ಫ್ಲೀಟ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು ಅವುಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಮಾರ್ಗಗಳ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ತಂಡವು ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಮತ್ತೊಂದು ಉತ್ಪನ್ನಕ್ಕಾಗಿ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಪುನರ್ನಿರ್ಮಿಸುವ ಬದಲು, ಎಂಜಿನಿಯರ್‌ಗಳು ಆ ಸಮಯದಲ್ಲಿ ಉತ್ಪನ್ನವು ಕ್ಷೇತ್ರದಲ್ಲಿ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಷ್ಕರಿಸುವುದನ್ನು ನಾನು ನೋಡಲು ಬಯಸುತ್ತೇನೆ. ಹಂಚಿಕೆಯ ಅಡಿಪಾಯವು ಕಸ್ಟಮ್ ಎಂಜಿನಿಯರಿಂಗ್‌ನ ವ್ಯಾಪ್ತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ; ಅದು ಆ ಪ್ರಯತ್ನವನ್ನು ಮೂಲಸೌಕರ್ಯದಿಂದ ಬಳಸದಂತೆ ರಕ್ಷಿಸುತ್ತದೆ.
ತಂಡವು ಉತ್ಪನ್ನ ಸಂಖ್ಯೆ ಎರಡನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ನಿಜವಾದ ಪರೀಕ್ಷೆ ಬರುತ್ತದೆ.
ಉತ್ತಮ ವೇದಿಕೆಯು ಮುಂದಿನ ಉತ್ಪನ್ನವನ್ನು ಮೊದಲನೆಯದಕ್ಕಿಂತ ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
ಎರಡನೇ ಉತ್ಪನ್ನಕ್ಕೆ ಮೊದಲ ಉತ್ಪನ್ನದಂತೆಯೇ ಬಹುತೇಕ ಒಂದೇ ರೀತಿಯ ವೇದಿಕೆಯ ಕೆಲಸ ಬೇಕಾದರೆ, ವಾಸ್ತವವಾಗಿ ಮರುಬಳಕೆ ಮಾಡಿರುವುದು ಬಹಳ ಕಡಿಮೆ.
ಹೊಸ ರೂಪಾಂತರವು ಬದಲಾಗದ ಕಾರ್ಯಾಚರಣಾ ಮಾದರಿಯ ಭಾಗಗಳನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ: ಪೂರೈಕೆ ಹರಿವುಗಳು, ಗುರುತು, ಜೀವನಚಕ್ರ ಯಂತ್ರಶಾಸ್ತ್ರ, ಫ್ಲೀಟ್ ಪರಿಕರಗಳು, ಫರ್ಮ್‌ವೇರ್ ಪ್ರಕ್ರಿಯೆಗಳು, ಬೆಂಬಲ ಗೋಚರತೆ ಮತ್ತು ಸಾಮಾನ್ಯ ಏಕೀಕರಣಗಳು. ಎಂಜಿನಿಯರಿಂಗ್ ಪ್ರಯತ್ನವು ನಂತರ ಅಡಿಪಾಯವನ್ನು ಪುನರ್ನಿರ್ಮಿಸುವ ಬದಲು ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಹೋಗುತ್ತದೆ - ಬಹುಶಃ ಹೊಸ ಸಂವೇದಕ ಪ್ಯಾಕೇಜ್, ಮತ್ತೊಂದು ನಿಯಂತ್ರಣ ಕಾರ್ಯಪ್ರವಾಹ ಅಥವಾ ಗ್ರಾಹಕ-ನಿರ್ದಿಷ್ಟ ಏಕೀಕರಣ.
ಹೊಸ ಹಾರ್ಡ್‌ವೇರ್ ಪೀಳಿಗೆಯು ಅದೇ ಕಲ್ಪನೆಯನ್ನು ಹೆಚ್ಚಿನ ಒತ್ತಡಕ್ಕೆ ಒಳಪಡಿಸುತ್ತದೆ. ಹಳೆಯ ಘಟಕಗಳು ಕ್ಷೇತ್ರದಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಅದರ ಸಾಮರ್ಥ್ಯಗಳು ಗಣನೀಯವಾಗಿ ಬದಲಾಗಬಹುದು. ಗ್ರಾಹಕರು ಇನ್ನೂ ಒಂದೇ ಉತ್ಪನ್ನ ಕುಟುಂಬವೆಂದು ಗ್ರಹಿಸುವ ಎರಡು ಪ್ರತ್ಯೇಕ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸ್ಟ್ಯಾಕ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ತಂಡವನ್ನು ಒತ್ತಾಯಿಸದೆಯೇ ಪ್ರಬುದ್ಧ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಎರಡನ್ನೂ ಬೆಂಬಲಿಸಬಹುದು.
ಇವುಗಳಲ್ಲಿ ಯಾವುದಕ್ಕೂ ಒಂದೇ ಏಕಶಿಲೆಯ ಬ್ಯಾಕೆಂಡ್ ಅಗತ್ಯವಿಲ್ಲ. ವಿಭಿನ್ನ ಉತ್ಪನ್ನಗಳಿಗೆ ಇನ್ನೂ ಸ್ಪಷ್ಟ ವಾಸ್ತುಶಿಲ್ಪದ ಗಡಿಗಳು ಬೇಕಾಗಬಹುದು. ಒಳ್ಳೆಯ ಕಾರಣವಿಲ್ಲದೆ ಅದೇ ಎಂಜಿನಿಯರಿಂಗ್ ಜವಾಬ್ದಾರಿಯ ಎರಡನೇ ಅನುಷ್ಠಾನವನ್ನು ತಪ್ಪಿಸುವುದು ಮುಖ್ಯ.
ಆಗ ವೇದಿಕೆಯು ಸಂಗ್ರಹವಾದ ಓವರ್ಹೆಡ್ ಬದಲಿಗೆ ಆಸ್ತಿಯಾಗುತ್ತದೆ. ಬೆಂಬಲವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕಡಿಮೆ ಸಮಾನಾಂತರ ಪರಿಕರಗಳನ್ನು ಹೊಂದಿದೆ, ಬಿಡುಗಡೆಗಳು ಹೆಚ್ಚು ಸ್ಥಿರವಾದ ಮಾರ್ಗಗಳನ್ನು ಅನುಸರಿಸುತ್ತವೆ ಮತ್ತು ಮತ್ತೊಂದು ಉತ್ಪನ್ನವನ್ನು ಸೇರಿಸುವುದು ಕಂಪನಿಯು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವ ಮತ್ತೊಂದು ಬ್ಯಾಕೆಂಡ್ ಬದಲಿಗೆ ನಿಯಂತ್ರಿತ ವಿಸ್ತರಣೆಯಾಗುತ್ತದೆ.
ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಉತ್ಪನ್ನ ವಾಸ್ತುಶಿಲ್ಪದ ಭಾಗವಾಗಿ ಪರಿಗಣಿಸಿ.
ಭೌತಿಕ ಉತ್ಪನ್ನಗಳನ್ನು ಪರಿಷ್ಕರಣೆಗಳು, ಸೇವಾಶೀಲತೆ, ಉತ್ಪಾದನಾ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಭವಿಷ್ಯದ ಬದಲಾವಣೆಗಳನ್ನು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಂಡು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಸಂಪರ್ಕಿತ ಉತ್ಪನ್ನಗಳಿಗೆ ಸಾಫ್ಟ್‌ವೇರ್ ಬದಿಯಲ್ಲಿ ಅದೇ ಶಿಸ್ತಿನ ಅಗತ್ಯವಿದೆ.
ಮೊದಲ ಬ್ಯಾಕೆಂಡ್ ತಾತ್ಕಾಲಿಕವಾಗಿರಬಹುದು. ಮೊದಲ ಪೂರೈಕೆ ಸ್ಕ್ರಿಪ್ಟ್ ಅಥವಾ ಬೆಂಬಲ ಸಾಧನವೂ ಸಹ ತಾತ್ಕಾಲಿಕವಾಗಿರಬಹುದು. ಅದರಲ್ಲಿ ಅಂತರ್ಗತವಾಗಿ ಯಾವುದೇ ತಪ್ಪಿಲ್ಲ. ಆ ತಾತ್ಕಾಲಿಕ ಯಂತ್ರಶಾಸ್ತ್ರವು ಸದ್ದಿಲ್ಲದೆ ಶಾಶ್ವತ ವಾಸ್ತುಶಿಲ್ಪವಾದಾಗ ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ, ಆದರೆ ಉತ್ಪನ್ನವು ಸ್ವತಃ ವಿಕಸನಗೊಳ್ಳುತ್ತಲೇ ಇರುತ್ತದೆ.
ಆ ಹೊತ್ತಿಗೆ, ಸಂಪರ್ಕಿತ ಉತ್ಪನ್ನವು ಕೇವಲ ಹಾರ್ಡ್‌ವೇರ್, ಫರ್ಮ್‌ವೇರ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಆಗಿ ಉಳಿಯುವುದಿಲ್ಲ. ಇದು ಪ್ರತಿಯೊಂದು ಸಾಧನವನ್ನು ಗುರುತಿಸುವ, ಅದರ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ, ಸರಿಯಾದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅನ್ವಯಿಸುವ, ನವೀಕರಣಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಮತ್ತು ಸಾಗಣೆಯ ನಂತರ ವರ್ಷಗಳ ನಂತರ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ತಂಡಗಳಿಗೆ ಸಹಾಯ ಮಾಡುವ ಮೂಲಸೌಕರ್ಯವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.
ಆ ಪದರವನ್ನು ಉತ್ಪನ್ನ ವಾಸ್ತುಶಿಲ್ಪ ಎಂದು ಪರಿಗಣಿಸಿದ ನಂತರ, ವಿಭಾಗವು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ: ಪ್ರಮಾಣಿತ ಯಂತ್ರಶಾಸ್ತ್ರವು ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದದ್ದಾಗಿ ಉಳಿಯುತ್ತದೆ, ಆದರೆ ಕಸ್ಟಮ್ ಕೆಲಸವು ಒಂದು ಉತ್ಪನ್ನ ಅಥವಾ ಉತ್ಪನ್ನ ಕುಟುಂಬವನ್ನು ಇನ್ನೊಂದರಿಂದ ವಾಸ್ತವವಾಗಿ ಪ್ರತ್ಯೇಕಿಸುವದಕ್ಕೆ ಹೋಗುತ್ತದೆ.
ಅತ್ಯಂತ ಬಲಿಷ್ಠವಾದ ವೇದಿಕೆ ಎಂದರೆ ಮೊದಲ ಸಂಪರ್ಕಿತ ಉತ್ಪನ್ನವನ್ನು ಸಾಧ್ಯವಾಗಿಸುವ ವೇದಿಕೆ ಮಾತ್ರವಲ್ಲ. ಪ್ರತಿ ಬಾರಿಯೂ ಹೊಸ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯದೆ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ಎರಡನೇ, ಮೂರನೇ ಮತ್ತು ನಾಲ್ಕನೆಯದನ್ನು ನಿರ್ಮಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವ ವೇದಿಕೆಯಾಗಿದೆ.
