Power Platform ఎంటర్‌ప్రైజ్ సొల్యూషన్స్‌ను ఆర్కిటెక్ట్ చేయడం: Ian Tweedie [MVP]తో

Microsoft Power Platform is often described as a low-code platform. But what happens when the applications you build become business-critical, highly integrated, and too complex for a simple maker-first approach?In this episode of M365 FM, Mirko Peters talks with Power Platform Solution Architect Ian Tweedie about what happens when Power Platform moves beyond simple low-code applications and becomes part of a serious enterprise architecture.

లో-కోడ్ అంటే తక్కువ ఆర్కిటెక్చర్ కాదు
Power Platform చాలా వ్యాపార విలువను త్వరగా అందించగలదు, కానీ ఎంటర్‌ప్రైజ్ పరిష్కారాలలో దాదాపు ఎల్లప్పుడూ ప్రామాణిక లో-కోడ్ సామర్థ్యాలకు మించిన అవసరాలు ఉంటాయి.Ian ఎందుకు లో-కోడ్‌ను ఎప్పుడూ నో-కోడ్‌తో గందరగోళపరచకూడదో, మరియు Power Apps, Power Automate, Dataverse, కస్టమ్ కనెక్టర్లు, APIలు మరియు Azure సేవలతో నిర్మిస్తున్నప్పుడు సాంప్రదాయ సాఫ్ట్‌వేర్ ఆర్కిటెక్చర్ సూత్రాలు ఇంకా ఎందుకు ముఖ్యమో వివరిస్తారు.

Power Platform ఎంటర్‌ప్రైజ్ సాఫ్ట్‌వేర్‌గా మారినప్పుడు
"లో-కోడ్" మరియు "ఎంటర్‌ప్రైజ్" మధ్య ఖచ్చితమైన రేఖ ఉండదు.అనేక వినియోగదారు ప్రయాణాలు, డెవలప్‌మెంట్ బృందాలు, ఇంటిగ్రేషన్లు, భద్రతా అవసరాలు, వ్యాపార-కీలక ప్రక్రియలు మరియు అనుసంధానించబడిన సేవలను అప్లికేషన్లు కలిగి ఉన్నప్పుడు సంక్లిష్టత పెరుగుతుంది.అప్పుడు ఆర్కిటెక్చర్ అత్యవసరమవుతుంది.పెద్ద ఒకే అనుసంధానిత అప్లికేషన్‌గా కాకుండా, పరిష్కారాలను స్పష్టంగా నిర్వచించిన ఫీచర్లు మరియు మాడ్యూళ్లుగా, స్పష్టమైన ఇంటర్‌ఫేస్‌లతో ఎందుకు విభజించాలో Ian వివరిస్తారు.

"ఒక బగ్ సరిచేస్తే మరొకటి ఎక్కడో కనిపిస్తుంది" సమస్యను తప్పించుకోవడం
ఒక సమస్యను సరిచేస్తే, మరొకటి మరెక్కడో కనిపిస్తుంది.ఈ సుపరిచిత డెవలప్‌మెంట్ సమస్య తరచుగా గట్టిగా కలిపిన (tightly coupled) ఆర్కిటెక్చర్ యొక్క లక్షణం.మాడ్యులర్ డిజైన్ కార్యాచరణను వేరుచేసి అనుకోని ఆధారాలను ఎలా తగ్గించగలదో Ian చర్చిస్తారు. ఇమెయిల్ డెలివరీని ఉదాహరణగా తీసుకుని, వ్యాపార ప్రక్రియలను డెలివరీ మెకానిజంల నుండి వేరు చేయడం అప్లికేషన్లను పరీక్షించడానికి, నిర్వహించడానికి, మార్చడానికి మరియు విస్తరించడానికి ఎలా సులభతరం చేస్తుందో వివరిస్తారు.

లో-కోడ్ + ప్రో-కోడ్ = హైబ్రిడ్ ఆర్కిటెక్చర్
Power Platform సాంప్రదాయ సాఫ్ట్‌వేర్ అభివృద్ధితో పోటీపడాల్సిన అవసరం లేదు.ఒక Power Apps ఫ్రంట్‌ఎండ్ Azure, AWS, GCP, APIలు లేదా కస్టమ్ సేవలను ఉపయోగించే చాలా పెద్ద అప్లికేషన్‌లో చిన్న భాగాన్ని మాత్రమే సూచించవచ్చు.ముఖ్యమైన ఆర్కిటెక్చరల్ ప్రశ్న ఏదైనా "లో-కోడ్" లేదా "ప్రో-కోడ్" అనేది కాదు.ప్రతి ఫీచర్‌కు ఏ సాంకేతికత ఉత్తమంగా సరిపోతుందన్నదే.

సిటిజన్ డెవలపర్లు, మేకర్లు మరియు ఆర్కిటెక్చర్
సిటిజన్ డెవలపర్లు అత్యంత విలువైనదాన్ని తీసుకువస్తారు: వారు రోజూ పని చేసే వ్యాపార ప్రక్రియల గురించి లోతైన జ్ఞానం.అయితే వ్యాపార నైపుణ్యం స్వయంచాలకంగా మంచి అప్లికేషన్ ఆర్కిటెక్చర్‌గా మారదు.మేకర్లను శక్తివంతం చేయడం మరియు పరిష్కారాలు నిర్వహించడం కష్టమయ్యేలా కాకుండా ఉండేందుకు తగిన ఆర్కిటెక్చర్, గవర్నెన్స్, నార్మలైజేషన్ మరియు సాంకేతిక సమీక్షను ఎలా సమతుల్యం చేయాలో Ian చర్చిస్తారు.

ఆవిష్కరణను చంపకుండా గవర్నెన్స్
చాలా తక్కువ గవర్నెన్స్ గందరగోళాన్ని సృష్టిస్తుంది.ఎక్కువ గవర్నెన్స్ ఘర్షణను సృష్టిస్తుంది — మరియు ఉద్యోగులను మద్దతులేని ప్రత్యామ్నాయాలు, స్ప్రెడ్‌షీట్‌లు, VBA మరియు షాడో IT వైపు నెట్టగలదు.సంస్థ రిస్క్, అప్లికేషన్ యొక్క కీలకత, వినియోగదారులు మరియు వ్యాపార ప్రభావం ఆధారంగా సరైన స్థాయి గవర్నెన్స్‌ను కనుగొనడమే సవాలు.

Power Platform, APIలు మరియు Azure
వ్యాపార లాజిక్ ఎక్కడ ఉండాలి?రహస్యాలను (secrets) Power Platform లోపల నిల్వ చేయాలా?Azure Key Vault, Azure Functions లేదా API Management ఎప్పుడు ఆర్కిటెక్చర్‌లో భాగమవ్వాలి?అందుబాటులో ఉన్నాయన్న కారణంతో Azure సేవలను జోడించడం కాకుండా, ఆర్కిటెక్చర్ ఎల్లప్పుడూ పరిష్కరించాల్సిన సమస్యతోనే ప్రారంభం కావాలని Ian వివరిస్తారు.

Git, సోర్స్ కంట్రోల్ మరియు CI/CD
Power Platform డెవలప్‌మెంట్ మరింత సహకారాత్మకంగా మారినప్పుడు, సాంప్రదాయ డెవలప్‌మెంట్ పద్ధతులు మరింత సంబంధితమవుతాయి.Git, రిపోజిటరీలు, డెవలప్‌మెంట్ ఎన్విరాన్‌మెంట్లు, పైప్‌లైన్లు, సోర్స్ కంట్రోల్, ఫీచర్ ఐసోలేషన్, క్రాస్-డిపెండెన్సీలు మరియు CI/CD గురించి సంభాషణ అన్వేషిస్తుంది.Power Platformలో సోర్స్ కంట్రోల్‌కు ఎల్లప్పుడూ పరిపూర్ణమైన విధానం ఉండకపోవచ్చు — కొన్నిసార్లు లక్ష్యం ప్రాజెక్ట్ కోసం "అత్యంత తక్కువ చెడ్డ ఎంపిక"ను ఎంచుకోవడమే.

Ian యొక్క Power Platform ఆర్కిటెక్చర్ ప్లేబుక్

Ian యొక్క ప్రధాన సూత్రం సరళమైనది:పరిష్కారాలను ఫీచర్లు మరియు మాడ్యూళ్లుగా విభజించండి.ప్రతి ఫీచర్‌కు ఉనికిలో ఉండటానికి స్పష్టమైన కారణం ఉండాలి మరియు ఆదర్శంగా ఒక నిర్దిష్ట బాధ్యతను మాత్రమే నిర్వహించాలి.ఆ తర్వాత ఆ ఫీచర్లు ఎలా కమ్యూనికేట్ చేస్తాయి, లాజిక్ ఎక్కడ అమలు కావాలి, వాటిని ఎలా పరీక్షించాలి, మరియు వాటిని అమలు చేయడానికి ఏ సాంకేతికత ఉత్తమమో నిర్ణయించండి.

రాపిడ్-ఫైర్ రౌండ్
Mirko Ianను త్వరిత ప్రశ్నల శ్రేణితో పరీక్షిస్తారు:ప్రతి ఎంటర్‌ప్రైజ్ అప్లికేషన్ Dataverseను ఉపయోగించాలా?Power Platform మిషన్-క్రిటికల్ అప్లికేషన్లను నిర్మించగలదా?Power Automate Logic Appsను భర్తీ చేయగలదా?లో-కోడ్ స్వయంచాలకంగా టెక్నికల్ డెట్‌ను తగ్గిస్తుందా?Power Platform సాంప్రదాయ అప్లికేషన్ డెవలప్‌మెంట్‌ను భర్తీ చేయగలదా?మరియు బహుశా అత్యంత ముఖ్యమైనది: Newcastleను సందర్శించినప్పుడు ఏమి ఆర్డర్ చేయాలి?

ముఖ్య సారాంశం
లో-కోడ్ అంటే తక్కువ ఆర్కిటెక్చర్ కాదు.Power Platform పరిష్కారాలు పెద్దవిగా, మరింత అనుసంధానితంగా మరియు వ్యాపారానికి మరింత ముఖ్యమైనవిగా మారినప్పుడు, సాఫ్ట్‌వేర్ ఇంజనీరింగ్ యొక్క ప్రాథమికాంశాలు ఇంకా సంబంధితమే.ఆర్కిటెక్చర్ ముఖ్యం.డేటా మోడలింగ్ ముఖ్యం.గవర్నెన్స్ ముఖ్యం.భద్రత ముఖ్యం.API డిజైన్ ముఖ్యం.DevOps ముఖ్యం.మరియు విజయవంతమైన ఎంటర్‌ప్రైజ్ Power Platform డెవలప్‌మెంట్ అనేది లో-కోడ్, ప్రో-కోడ్, Azure, APIలు, ఆటోమేషన్ మరియు సాంప్రదాయ సాఫ్ట్‌వేర్ ఇంజనీరింగ్ పద్ధతులు కలిసి ఎలా పనిచేస్తాయో అర్థం చేసుకోవడంపై ఎక్కువగా ఆధారపడి ఉంటుంది.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.