ఒక కనెక్టెడ్ ప్రొడక్ట్ చుట్టూ ఉన్న ఇంజనీరింగ్ పూర్తికాకముందే, అది పూర్తయినట్లుగా కనిపించవచ్చు. ప్రోటోటైప్ స్థిరంగా ఉంటుంది, డేటా క్లౌడ్కు చేరుకుంటుంది, యాప్ సరైన విలువలను చూపిస్తుంది, మరియు మొదటి విడత పరికరాలు అప్పటికే వినియోగదారుల చేతుల్లో ఉంటాయి. ఆ సమయంలో, బ్యాకెండ్ ఇంకా చాలా సరళంగా ఉండవచ్చు, దానివల్ల బృందానికి దాదాపు ప్రతి పరికరం గురించి విడివిడిగా తెలిసి ఉంటుంది. ప్రొవిజనింగ్ను ఒక స్క్రిప్ట్తో నిర్వహించవచ్చు, కాన్ఫిగరేషన్ మార్పులను మాన్యువల్గా చేయవచ్చు, మరియు ఏదైనా విఫలమైతే, ఒక ఇంజనీర్ సాధారణంగా సమస్యను నేరుగా గుర్తించగలడు.
అప్పుడు అది వాస్తవ ప్రపంచంలోకి అడుగుపెట్టాలి. రెండవ హార్డ్వేర్ సవరణ వస్తుంది. కొంతమంది వినియోగదారులు ఇంకా మొదటి సవరణనే ఉపయోగిస్తున్నారు. ఫర్మ్వేర్ వెర్షన్లు వేరుగా ఉండటం మొదలవుతుంది. వేరొక వినియోగదారుడికి లేదా మార్కెట్కు కొత్త కాన్ఫిగరేషన్ అవసరమవుతుంది, అయితే పాత పరికరాలకు ఇంకా అప్డేట్లు మరియు మద్దతు అవసరం ఉంటుంది.
వాస్తవానికి ఏదీ పాడైపోలేదు. పరికరం వెనుక ఉన్న సాఫ్ట్వేర్ కేవలం దానికంటూ ఒక జీవితచక్రాన్ని పొందింది.
ప్రోటోటైప్ ఎటువంటి లోపం లేకుండా పనిచేస్తూనే ఉండగలదు కాబట్టి, ఆ మార్పును గమనించకపోవడం సులభం. కానీ ఒకే భౌతిక ఉత్పత్తికి చెందిన అనేక వెర్షన్లు క్షేత్రస్థాయిలో కలిసి పనిచేయాల్సి వచ్చినప్పుడు, బ్యాకెండ్ అనేది కేవలం హార్డ్వేర్ వెనుక ఉండే మౌలిక సదుపాయంగా మాత్రమే ఉండదు. అది ఉత్పత్తి నిర్మాణంలోనే ఒక భాగంగా మారిపోతుంది.
పనిచేసే అనుసంధానిత నమూనా ఇంకా విస్తరించదగిన ఉత్పత్తి కాదు
ఒక ప్రోటోటైప్కు ఒక ముఖ్యమైన పని ఉంటుంది: సిస్టమ్ మొదటి నుండి చివరి వరకు పనిచేస్తుందని నిరూపించడం. పరికరం దాని ప్రధాన విధిని నిర్వర్తిస్తుంది, ఫర్మ్వేర్ బ్యాకెండ్తో సంభాషిస్తుంది, టెలిమెట్రీ చేరాల్సిన చోటికి చేరుతుంది, ఆదేశాలు తిరిగి వెళ్తాయి, మరియు ఒక మొబైల్ లేదా వెబ్ ఇంటర్ఫేస్ ఆ కార్యాచరణను వినియోగదారునికి అందిస్తుంది.
అదే వ్యవస్థ వైవిధ్యాన్ని ఎంత బాగా నిర్వహిస్తుందనేది ఇది సాధారణంగా నిరూపించలేదు.
మొదటి ఇరవై పరికరాలు అన్నీ ఒకే ఫర్మ్వేర్ను అమలు చేయవచ్చు, ఒకే హార్డ్వేర్ రివిజన్కు అనుగుణంగా నిర్మించబడవచ్చు మరియు ఒకే ఇంజనీర్లచే కాన్ఫిగర్ చేయబడవచ్చు. ఆ దశలో, మాన్యువల్ రిజిస్ట్రేషన్, ప్రత్యక్ష కాన్ఫిగరేషన్ మార్పులు లేదా ఒక చిన్న ఆన్బోర్డింగ్ స్క్రిప్ట్ పూర్తిగా సమంజసంగా ఉంటాయి. ఉత్పత్తి తనను తాను నిరూపించుకోకముందే ప్రొడక్షన్-గ్రేడ్ టూలింగ్ను నిర్మించడం తొందరపాటు చర్య కావచ్చు.
పరిమాణం సమస్యను మారుస్తుంది. పరికరాలు ఆఫ్లైన్లో ఉంటాయి, మార్చబడతాయి, విభిన్న ఫర్మ్వేర్ను అమలు చేస్తాయి మరియు విభిన్న కస్టమర్ కాన్ఫిగరేషన్లను కోరుతాయి. సరిగ్గా ప్రొవిజన్ చేయబడని యూనిట్ను, తప్పుగా కాన్ఫిగర్ చేయబడిన లేదా అందుబాటులో లేని యూనిట్ నుండి సపోర్ట్ వేరు చేసి గుర్తించాల్సి ఉంటుంది.
ప్రోటోటైప్ లోపం తరచుగా ఈ విధంగా మొదలవుతుంది: ఒక చెడ్డ నిర్ణయంతో కాదు, ఉత్పత్తి ముందుకు సాగిన తర్వాత కూడా అమలులో ఉండే ఒక తాత్కాలిక నిర్ణయంతో. మరియు ఆ మార్పును స్పష్టంగా కనబడేలా చేసే మొదటి విషయాలలో ఒకటి హార్డ్వేర్. ఒక కొత్త రివిజన్ కేవలం పాతదాని స్థానాన్ని భర్తీ చేయదు; అది దానితో పాటుగా సహజీవనం చేయాల్సి ఉంటుంది.
ప్రతి హార్డ్వేర్ సవరణ ఒక సాఫ్ట్వేర్ జీవితచక్ర సమస్యను సృష్టిస్తుంది
కొత్త హార్డ్వేర్ రివిజన్ పాతదానికి పూర్తి ప్రత్యామ్నాయంగా రావడం చాలా అరుదు. ఆచరణలో, రెండు వెర్షన్లు కొన్నిసార్లు సంవత్సరాల తరబడి వాడుకలో ఉంటాయి. వీటికి ఒక ట్రాన్సిషన్ బ్యాచ్, కొన్ని ఫర్మ్వేర్ బ్రాంచ్లు, మరియు కస్టమర్-నిర్దిష్ట కాన్ఫిగరేషన్లను జోడిస్తే, అసలు ఉత్పత్తి నమూనా సూచించిన దానికంటే ఈ పరికరాల సముదాయం త్వరగా మరింత వైవిధ్యభరితంగా మారుతుంది.
సాఫ్ట్వేర్ లేయర్ ఇకపై ప్రతి యూనిట్ను ఒక అమూర్తమైన “పరికరం”గా పరిగణించదు. ఆ నిర్దిష్ట యూనిట్ ఏమి చేయగలదో అది తెలుసుకోవాలి.
సవరించిన బోర్డు వేరే సెన్సార్, కమ్యూనికేషన్ మాడ్యూల్ లేదా కంట్రోలర్ను ఉపయోగించవచ్చు. తాజా వెర్షన్కు చెల్లుబాటు అయ్యే ఆదేశం పాత వెర్షన్లో మద్దతు ఇవ్వకపోవచ్చు. క్రమాంకన విలువలు మారవచ్చు. కాన్ఫిగరేషన్ పరిమితులు మారవచ్చు. ఒక తరానికి సరిపోయే ఫర్మ్వేర్ ప్యాకేజీ మరొక తరానికి సురక్షితం కాకపోవచ్చు.
భౌతిక ఉత్పత్తి ఇంజనీర్లు ఇప్పటికే ఈ పద్ధతిలో పనిచేస్తున్నారు. దాదాపు ఒకేలా కనిపించే రెండు భాగాల సవరణలు, టాలరెన్స్లు లేదా స్పెసిఫికేషన్లు భిన్నంగా ఉంటే, వాటిని పరస్పరం మార్చుకోలేము. అనుసంధానించబడిన ఉత్పత్తులు సాఫ్ట్వేర్ వైపున ఇదే సమస్యను సృష్టిస్తాయి: ప్లాట్ఫారమ్ తాను భౌతిక ఉత్పత్తి యొక్క ఏ వెర్షన్తో సంభాషిస్తుందో మరియు దానికి ఏ నియమాలు వర్తిస్తాయో అర్థం చేసుకోవడానికి ఒక నమ్మకమైన మార్గం అవసరం.
ఒక ఉత్పత్తిని పరిగణించండి, దాని మొదటి సవరణలో ఒక క్రమాంకన విధానాన్ని ఉపయోగిస్తుండగా, రెండవ సవరణలో ఒక కొత్త సెన్సార్ మరియు విభిన్న పారామితుల సమితిని ప్రవేశపెట్టారు. కస్టమర్కు, ఈ రెండు యూనిట్లు ఇప్పటికీ ఒకే ఉత్పత్తిగా అనిపించవచ్చు. కానీ ప్లాట్ఫారమ్కు, అవి అలా ఉండలేవు.
ఆ తేడాలను స్పష్టంగా సూచించకపోతే, అవి ప్రత్యేక సందర్భాలుగా అప్లికేషన్ లాజిక్లోకి చొచ్చుకుపోయే అవకాశం ఉంది. ఒక వర్క్ఫ్లో సీరియల్-నంబర్ పరిధిని తనిఖీ చేస్తుంది. మరొకటి హార్డ్వేర్ జనరేషన్కు బదులుగా ఫర్మ్వేర్ వెర్షన్ను ఉపయోగిస్తుంది. క్షేత్రస్థాయిలో ఒక పాత బ్యాచ్ భిన్నంగా ప్రవర్తిస్తోందని సపోర్ట్ బృందం కనుగొన్న తర్వాత జోడించిన ఒక మినహాయింపును మూడవది కలిగి ఉంటుంది. ఈ పరిష్కారాలలో ఏదీ విడిగా అంత ప్రమాదకరంగా కనిపించదు, కానీ అవన్నీ కలిసి భవిష్యత్తులో చేసే ప్రతి మార్పును అర్థం చేసుకోవడాన్ని మరింత కష్టతరం చేస్తాయి.
పాత హార్డ్వేర్ అనుకున్న సమయానికి అరుదుగా అదృశ్యమవుతుంది. ఉత్పత్తి బృందాలు సహజంగానే సరికొత్త రివిజన్పై దృష్టి పెడతాయి, అయితే వినియోగదారులు తరచుగా పాత వెర్షన్లను ఊహించిన దానికంటే చాలా కాలం పాటు ఉంచుకుంటారు. అందువల్ల, ఇప్పటికే ఇన్స్టాల్ చేయబడిన పరికరాలన్నీ ఎప్పటికీ ఒకే ప్రస్తుత స్థితికి చేరుకుంటాయని భావించకుండా, ప్లాట్ఫారమ్ ఒకేసారి అనేక తరాలకు మద్దతు ఇవ్వాల్సి ఉంటుంది.
అలా జరిగిన తర్వాత, హార్డ్వేర్ పరిణామం మరియు సాఫ్ట్వేర్ లైఫ్సైకిల్ నిర్వహణ విడదీయరానివిగా మారతాయి. ప్లాట్ఫారమ్కు ఒక పరికరం ఎక్కడ ఉంది మరియు అది ఆన్లైన్లో ఉందా లేదా అని మాత్రమే కాకుండా, అది ఏమిటి, అది ఏమి చేయగలదు, దానిని ఎలా కాన్ఫిగర్ చేయాలి మరియు ఏ మార్పులు వర్తింపజేయడం సురక్షితం అనే విషయాలు కూడా తెలియాలి.
మరియు ఆ ప్రశ్నలలో దేనికైనా విశ్వసనీయంగా సమాధానం చెప్పే ముందు, ప్రతి పరికరం ఒక స్థిరమైన పద్ధతిలో సిస్టమ్లోకి ప్రవేశించాలి.
ప్రొవిజనింగ్ వద్ద మాన్యువల్ ఇంజనీరింగ్ స్కేలింగ్ను ఆపివేస్తుంది
ఫ్లీట్ చిన్నదిగా ఉన్నప్పుడు ప్రొవిజనింగ్ సులభంగా కనిపిస్తుంది: ఒక పరికర రికార్డును సృష్టించడం, సీరియల్ నంబర్ను నమోదు చేయడం, క్రెడెన్షియల్స్ను రూపొందించడం, యూనిట్ను కస్టమర్కు కేటాయించడం, కాన్ఫిగరేషన్ను వర్తింపజేయడం, మరియు ముందుకు సాగడం. కొన్ని డజన్ల పరికరాల కోసం, వీటిలో కొన్నింటిని మాన్యువల్గా నిర్వహించడమే సరైన ఎంపిక కావచ్చు.
అయితే, ఉత్పత్తి స్థాయిలో, ప్రొవిజనింగ్ అనేది పరికర గుర్తింపు, ఆధారాలు, యాజమాన్యం, కాన్ఫిగరేషన్ మరియు జీవితచక్ర స్థితి వంటి అంశాల కూడలిలో ఉంటుంది. ఆన్బోర్డింగ్ సమయంలో చేసిన ఒక పొరపాటు, యూనిట్ ఫ్యాక్టరీ నుండి బయటకు వచ్చిన చాలా కాలం తర్వాత కూడా దాని నిర్వహణ మరియు మద్దతుపై ప్రభావం చూపుతుంది.
ఒక స్ప్రెడ్షీట్ వాస్తవంగా ఇన్స్టాల్ చేయబడిన దానితో ఇకపై సరిపోలకపోవచ్చు. ఒక రీప్లేస్మెంట్ పరికరానికి తప్పుడు గుర్తింపును పొందకుండా, సరైన కస్టమర్ అనుబంధం అవసరం. ఫ్యాక్టరీ రీసెట్లు ఈ ప్రక్రియలో మరొక మార్గాన్ని సృష్టిస్తాయి. ఒక ఇన్స్టాలర్ యూనిట్ను తప్పుడు ఖాతాకు కేటాయించవచ్చు, దానివల్ల అది ఆఫ్లైన్లో ఉందా, తప్పుగా ప్రొవిజన్ చేయబడిందా, లేదా కేవలం తప్పుడు కాన్ఫిగరేషన్ను కలిగి ఉందా అని నిర్ధారించే బాధ్యతను సపోర్ట్పై వదిలివేయవచ్చు.
ఆ ప్రశ్నలకు నిత్యం సమాధానం ఇవ్వడానికి ఒక డెవలపర్ డేటాబేస్ను తనిఖీ చేయడం లేదా అంతర్గత స్క్రిప్ట్ను అమలు చేయడం అవసరమైనప్పుడు, ఆ ప్రక్రియ ఉత్పత్తితో పాటుగా విస్తరించడం ఆగిపోతుంది.
పునరావృతం కావడం మరో హెచ్చరిక సంకేతం. ప్రతి ఉత్పత్తి వేరియంట్ దాని స్వంత ఆన్బోర్డింగ్ స్క్రిప్ట్, కాన్ఫిగరేషన్ టూల్ లేదా ఇన్స్టాలర్ వర్క్ఫ్లోను పొందడం ప్రారంభిస్తుంది. ఆ తేడాలు చిన్నవిగా కనిపించవచ్చు, కానీ అంతర్లీన బాధ్యత మాత్రం ఒకటే. ప్రొవిజనింగ్ అనేది ఒక నిర్దిష్ట పరికరానికి జోడించబడిన సెటప్ టాస్క్గా కాకుండా, పునర్వినియోగించదగిన ప్లాట్ఫారమ్ ఇన్ఫ్రాస్ట్రక్చర్గా మారింది.
మరియు పునర్వినియోగం కావాల్సిన అవసరం కేవలం ఆ ఒక్క సామర్థ్యానికే అరుదుగా ఉంటుంది.
ప్లాట్ఫారమ్ పొర పునర్వినియోగించదగిన మౌలిక సదుపాయంగా మారాలి
ఒకసారి అనేక ఉత్పత్తులు లేదా హార్డ్వేర్ సవరణలు ఒకే ప్రాథమిక అవసరాలను పంచుకున్నప్పుడు, కొన్ని సాఫ్ట్వేర్ సామర్థ్యాలు ఉత్పత్తి-నిర్దిష్టంగా ఉండవు. పరికర గుర్తింపు, ప్రొవిజనింగ్, కనెక్టివిటీ, టెలిమెట్రీ, ఫర్మ్వేర్ డెలివరీ, లైఫ్సైకిల్ స్థితి, ఫ్లీట్ విజిబిలిటీ మరియు డయాగ్నోస్టిక్స్ మంచి ఉదాహరణలు. ప్రతి కొత్త వేరియంట్ కోసం వాటిని తిరిగి నిర్మించడం వలన, ఉత్పత్తిని మరింత విలక్షణంగా మార్చకుండానే, నిర్వహించడానికి ఎక్కువ కోడ్ మరియు మరిన్ని కార్యాచరణ మార్గాలు ఏర్పడతాయి.
జట్లు ఈ నకలును ఉద్దేశపూర్వకంగా సృష్టించవు. ప్రతి ఉత్పత్తి చుట్టూ చిన్న చిన్న తేడాలు పేరుకుపోతాయి, చివరికి ఒకే ఇంజనీరింగ్ బాధ్యతగా మారిన దాని యొక్క అనేక అమలులను ఆ బృందం నిర్వహిస్తూ ఉంటుంది.
ఉత్పత్తి పొరను ప్లాట్ఫారమ్ పొర నుండి వేరు చేయడం ఒక స్పష్టమైన సరిహద్దు. ఉత్పత్తి పొరలో ఒక నిర్దిష్ట పరికరాన్ని విలువైనదిగా చేసే ప్రవర్తన, వర్క్ఫ్లోలు, ఇంటర్ఫేస్లు, ఇంటిగ్రేషన్లు మరియు డొమైన్ లాజిక్ ఉంటాయి. హార్డ్వేర్ మారినప్పటికీ స్థిరంగా ఉండవలసిన యాంత్రిక అంశాలను ప్లాట్ఫారమ్ పొర నిర్వహిస్తుంది.
కనెక్ట్ చేయబడిన ఉత్పత్తులు వాటి మొదటి విడుదలను దాటి ముందుకు సాగే కొద్దీ, పరికర కేటాయింపు, పరికర జీవితచక్ర నిర్వహణ, ఫ్లీట్ నిర్వహణ మరియు సహాయక సాధనాలు అనేవి ఒక్కో ప్రాజెక్ట్ వివరాలుగా కాకుండా ఉమ్మడి మౌలిక సదుపాయాలుగా మారతాయి. సంస్థల కోసం ఉద్దేశించిన ఒక IoT PaaS, బహుళ ఉత్పత్తులు లేదా ఉత్పత్తి వేరియంట్లలో ఆ పునర్వినియోగ ప్లాట్ఫారమ్ పొరను అందించగలదు. ఇది పునర్వినియోగ బిల్డింగ్ బ్లాక్ల ద్వారా ప్రామాణిక పరికర మరియు డేటా నిర్వహణను నిర్వహిస్తుండగా, ఇంజనీరింగ్ బృందాలు తమ ప్రత్యేక కృషిని హార్డ్వేర్, వర్క్ఫ్లోలు మరియు వినియోగదారు అనుభవంపై కేంద్రీకరిస్తాయి.
ఒక ఉమ్మడి పునాది ఉన్నప్పటికీ, నిజమైన ఉత్పత్తి వ్యత్యాసాలకు చోటు కల్పించాలి. ఒక కొత్త పరికరానికి భిన్నమైన డేటా మోడల్, కాన్ఫిగరేషన్ విధానం, అనుసంధానం లేదా నియంత్రణ తర్కం అవసరం కావచ్చు, మరియు ఆ వ్యత్యాసాలను ప్రవేశపెట్టడం సులభంగానే ఉండాలి. ప్రతి వ్యత్యాసం మరొక పరికర రిజిస్ట్రీ, టెలిమెట్రీ పైప్లైన్, ప్రొవిజనింగ్ యంత్రాంగం లేదా ఫ్లీట్-మేనేజ్మెంట్ సాధనాల సముదాయాన్ని అదనంగా చేర్చకుండా ఉండటమే ఇక్కడి లక్ష్యం.
బృందం మొదటి ఉత్పత్తిని రూపొందిస్తున్నప్పుడు ఈ ప్లాట్ఫారమ్ ఒక అదనపు భారంలా కనిపించవచ్చు, కానీ రెండవ లేదా మూడవ ఉత్పత్తికి వచ్చేసరికి ఒక ఆస్తిలా అనిపిస్తుంది. సాధారణ కార్యాచరణ విధానాలు ఒకసారి స్థిరపడిన తర్వాత, ఒక కొత్త వేరియంట్, ఆ ఉత్పత్తి జీవితకాలం మొత్తం బృందం నిర్వహించవలసిన మరో బ్యాకెండ్తో రాకుండా, అప్పటికే పనిచేస్తున్న పునాదిని వారసత్వంగా పొందగలదు.
ఉత్పత్తి వాస్తవంగా భిన్నంగా ఉన్న చోట కస్టమ్ ఇంజనీరింగ్ను కొనసాగించండి
పునర్వినియోగించదగిన ప్లాట్ఫారమ్ అనుసంధానించబడిన ఉత్పత్తులను మరింత సాధారణీకరించకూడదు. భేదాన్ని సృష్టించని భాగాల నుండి పునరావృతమయ్యే ఇంజనీరింగ్ను తొలగించడమే దాని పని.
పరికర ప్రవర్తన, డొమైన్-నిర్దిష్ట తర్కం, వర్క్ఫ్లోలు, వినియోగదారు అనుభవం, ప్రత్యేకమైన అనుసంధానాలు మరియు ఒక నిర్దిష్ట ఉత్పత్తి భౌతిక ప్రపంచంతో సంకర్షణ చెందే విధానం వంటి విషయాలలో ప్రత్యేక కృషి ఇప్పటికీ అవసరం. ఇంజనీరింగ్ ఎంపికలు ఒక ఉత్పత్తిని మరొకదాని కంటే అర్థవంతంగా మెరుగ్గా చేయగల రంగాలు ఇవే.
అదే విధమైన శ్రద్ధకు అరుదుగా అర్హత పొందేది చుట్టుపక్కల ఉన్న కార్యాచరణ వ్యవస్థ. ఒకే యంత్రం యొక్క ప్రాథమిక వెర్షన్ మరియు పారిశ్రామిక వెర్షన్కు వేర్వేరు సెన్సార్లు, నియంత్రణలు మరియు ఇంటర్ఫేస్లు అవసరం కావచ్చు, కానీ పరికరాలను గుర్తించడానికి, ఫర్మ్వేర్ వెర్షన్లను ట్రాక్ చేయడానికి లేదా ఒక ఫ్లీట్ను నిర్వహించడానికి వాటికి వేర్వేరు మార్గాలు అవసరం కాకూడదు.
ఇంజనీర్లు ఆ సమయాన్ని, బృందం ఇప్పటికే మరో ఉత్పత్తి కోసం ఏర్పాటు చేసిన యంత్రాంగాలను పునర్నిర్మించడం కంటే, క్షేత్రస్థాయిలో ఉత్పత్తి పనితీరును మెరుగుపరచడానికి వెచ్చించాలని నేను కోరుకుంటాను. ఒక ఉమ్మడి పునాది కస్టమ్ ఇంజనీరింగ్ పరిధిని తగ్గించదు; అది ఆ కృషిని మౌలిక సదుపాయాలకే పరిమితం కాకుండా కాపాడుతుంది.
బృందం రెండవ ఉత్పత్తిని ప్రారంభించినప్పుడే అసలైన పరీక్ష ఎదురవుతుంది.
ఒక మంచి ప్లాట్ఫారమ్ మొదటి ఉత్పత్తి కంటే తర్వాతి ఉత్పత్తిని సులభతరం చేస్తుంది.
రెండవ ఉత్పత్తికి కూడా మొదటి ఉత్పత్తికి అవసరమైనంత ప్లాట్ఫారమ్ పనే అవసరమైతే, వాస్తవానికి చాలా తక్కువ మాత్రమే పునర్వినియోగించబడింది.
ఒక కొత్త వేరియంట్, ఆపరేటింగ్ మోడల్లో మారకుండా ఉన్న భాగాలను వారసత్వంగా పొందగలగాలి: అవి ప్రొవిజనింగ్ ఫ్లోలు, ఐడెంటిటీ, లైఫ్సైకిల్ మెకానిక్స్, ఫ్లీట్ టూల్స్, ఫర్మ్వేర్ ప్రాసెస్లు, సపోర్ట్ విజిబిలిటీ మరియు సాధారణ ఇంటిగ్రేషన్లు. ఆ తర్వాత, పునాదిని పునర్నిర్మించడానికి బదులుగా, ఇంజనీరింగ్ కృషిని తేడాలపై — బహుశా ఒక కొత్త సెన్సార్ ప్యాకేజీ, మరొక కంట్రోల్ వర్క్ఫ్లో లేదా కస్టమర్-నిర్దిష్ట ఇంటిగ్రేషన్ వంటి వాటిపై — కేంద్రీకరిస్తారు.
కొత్త హార్డ్వేర్ తరం అదే ఆలోచనపై మరింత ఒత్తిడిని పెంచుతుంది. పాత యూనిట్లు క్షేత్రస్థాయిలో చురుకుగా ఉన్నప్పటికీ, దాని సామర్థ్యాలు గణనీయంగా మారవచ్చు. వినియోగదారులు ఇప్పటికీ ఒకే ఉత్పత్తి కుటుంబంగా భావించే దాని కోసం, రెండు వేర్వేరు ప్లాట్ఫారమ్ స్టాక్లను నిర్వహించమని బృందాన్ని బలవంతం చేయకుండా, ఒక పరిణతి చెందిన ప్లాట్ఫారమ్ రెండింటికీ మద్దతు ఇవ్వగలదు.
వీటన్నిటికీ ఒకే భారీ బ్యాకెండ్ అవసరం లేదు. వేర్వేరు ఉత్పత్తులకు స్పష్టమైన నిర్మాణపరమైన సరిహద్దులు అవసరం కావచ్చు. సరైన కారణం లేకుండా, ఒకే ఇంజనీరింగ్ బాధ్యతను రెండవసారి అమలు చేయడాన్ని నివారించడమే ముఖ్యం.
అప్పుడే ప్లాట్ఫారమ్ అనేది పేరుకుపోయిన అదనపు భారం కాకుండా ఒక ఆస్తిగా మారుతుంది. సపోర్ట్ విభాగానికి అర్థం చేసుకోవడానికి సమాంతర టూల్స్ తక్కువగా ఉంటాయి, విడుదలలు మరింత స్థిరమైన మార్గాలను అనుసరిస్తాయి, మరియు మరొక ఉత్పత్తిని జోడించడం అనేది కంపెనీ నిరవధికంగా వారసత్వంగా పొందే మరో బ్యాకెండ్ కాకుండా, ఒక నియంత్రిత విస్తరణగా మారుతుంది.
ప్లాట్ఫారమ్ను ఉత్పత్తి నిర్మాణంలో భాగంగా పరిగణించండి
భౌతిక ఉత్పత్తులను సవరణలు, సర్వీసబిలిటీ, తయారీ సామర్థ్యం మరియు భవిష్యత్ మార్పులను దృష్టిలో ఉంచుకుని రూపొందిస్తారు. కనెక్ట్ చేయబడిన ఉత్పత్తులకు సాఫ్ట్వేర్ విషయంలో అదే క్రమశిక్షణ అవసరం.
మొదటి బ్యాకెండ్ తాత్కాలికంగా ఉండవచ్చు. అలాగే మొదటి ప్రొవిజనింగ్ స్క్రిప్ట్ లేదా సపోర్ట్ టూల్ కూడా. అందులో అంతర్గతంగా తప్పు ఏమీ లేదు. ఉత్పత్తి అభివృద్ధి చెందుతూ ఉండగా, ఆ తాత్కాలిక యంత్రాంగాలు నిశ్శబ్దంగా శాశ్వత నిర్మాణంగా మారినప్పుడు సమస్యలు మొదలవుతాయి.
అప్పటికి, కనెక్ట్ చేయబడిన ఉత్పత్తి కేవలం హార్డ్వేర్, ఫర్మ్వేర్ మరియు ఒక యాప్ మాత్రమే కాదు. అది ప్రతి పరికరాన్ని గుర్తించి, దాని సామర్థ్యాలను అర్థం చేసుకుని, సరైన కాన్ఫిగరేషన్ను వర్తింపజేసి, అప్డేట్లకు మద్దతునిచ్చి, రవాణా జరిగిన సంవత్సరాల తర్వాత కూడా సమస్యలను నిర్ధారించడంలో బృందాలకు సహాయపడే మౌలిక సదుపాయాలపై కూడా ఆధారపడి ఉంటుంది.
ఒకసారి ఆ పొరను ఉత్పత్తి నిర్మాణంగా పరిగణించిన తర్వాత, విభజన మరింత స్పష్టమవుతుంది: ప్రామాణిక యంత్రాంగాలు పునర్వినియోగించదగినవిగా ఉంటాయి, అయితే ఒక ఉత్పత్తిని లేదా ఉత్పత్తి కుటుంబాన్ని మరొకదాని నుండి వాస్తవంగా వేరుచేసే దానిలోకి కస్టమ్ పని వెళ్తుంది.
అత్యంత బలమైన ప్లాట్ఫారమ్ అంటే కేవలం మొదటి కనెక్టెడ్ ఉత్పత్తిని సాధ్యం చేసేది మాత్రమే కాదు. అది, ఇంజనీరింగ్ బృందం ప్రతిసారీ కొత్త బ్యాకెండ్ను స్వీకరించకుండా రెండవ, మూడవ మరియు నాల్గవ ఉత్పత్తులను నిర్మించడానికి వీలు కల్పించేదే.

