Power Platform-നെ സങ്കീർണ്ണമായ എന്റർപ്രൈസ് സൊല്യൂഷനുകൾക്കായി ആർക്കിടെക്റ്റ് ചെയ്യൽ — Ian Tweedie [MVP]-യോടൊപ്പം

Microsoft Power Platform اغلب ഒരു ലോ-കോഡ് പ്ലാറ്റ്ഫോം ആയി വിവരിക്കപ്പെടാറുണ്ട്. എന്നാൽ നിങ്ങൾ നിർമ്മിക്കുന്ന ആപ്ലിക്കേഷനുകൾ ബിസിനസിന് അത്യാവശ്യമായി മാറുകയും, ഉയർന്ന തോതിൽ സംയോജിതമാവുകയും, ലളിതമായ മേക്കർ-ഫസ്റ്റ് സമീപനത്തിന് വളരെ സങ്കീർണ്ണമാവുകയും ചെയ്താൽ എന്ത് സംഭവിക്കും?

M365 FM-ന്റെ ഈ എപ്പിസോഡിൽ Mirko Peters, Power Platform Solution Architect ആയ Ian Tweedie-യുമായി സംസാരിക്കുന്നു. ലളിതമായ ലോ-കോഡ് ആപ്ലിക്കേഷനുകൾക്കപ്പുറം Power Platform ഗൗരവമുള്ള എന്റർപ്രൈസ് ആർക്കിടെക്ചറിന്റെ ഭാഗമാകുമ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്നതാണ് ചർച്ച.

ലോ-കോഡ് എന്നാൽ ലോ ആർക്കിടെക്ചർ അല്ല
Power Platform-ന് ബിസിനസ് മൂല്യത്തിന്റെ വലിയൊരു ഭാഗം വേഗത്തിൽ നൽകാൻ കഴിയും. എന്നാൽ എന്റർപ്രൈസ് സൊല്യൂഷനുകളിൽ മിക്കപ്പോഴും സാധാരണ ലോ-കോഡ് കഴിവുകൾക്കപ്പുറമുള്ള ആവശ്യകതകൾ ഉണ്ടാകാറുണ്ട്. Power Apps, Power Automate, Dataverse, കസ്റ്റം കണക്റ്ററുകൾ, APIs, Azure സേവനങ്ങൾ എന്നിവ ഉപയോഗിച്ച് നിർമ്മിക്കുമ്പോഴും പരമ്പരാഗത സോഫ്റ്റ്വെയർ ആർക്കിടെക്ചർ തത്വങ്ങൾ പ്രസക്തമാണെന്ന് Ian വിശദീകരിക്കുന്നു. ലോ-കോഡിനെ നോ-കോഡുമായി ഒരിക്കലും തെറ്റിദ്ധരിക്കരുത് എന്നും അദ്ദേഹം ഓർമ്മിപ്പിക്കുന്നു.

Power Platform ഒരു എന്റർപ്രൈസ് സോഫ്റ്റ്വെയർ ആകുമ്പോൾ
"ലോ-കോഡ്", "എന്റർപ്രൈസ്" എന്നിവയ്ക്കിടയിൽ വ്യക്തമായ വേർതിരിവ് സാധാരണയായി ഉണ്ടാകാറില്ല. ഒന്നിലധികം ഉപയോക്തൃ യാത്രകൾ, ഡെവലപ്മെന്റ് ടീമുകൾ, ഇന്റഗ്രേഷനുകൾ, സുരക്ഷാ ആവശ്യകതകൾ, ബിസിനസിന് നിർണായകമായ പ്രക്രിയകൾ, പരസ്പരം ബന്ധിപ്പിച്ച സേവനങ്ങൾ എന്നിവ ഉൾപ്പെടുമ്പോൾ സങ്കീർണ്ണത വർധിക്കുന്നു. ആ ഘട്ടത്തിൽ ആർക്കിടെക്ചർ അനിവാര്യമാകുന്നു. ഒരു വലിയ പരസ്പര ബന്ധിത ആപ്ലിക്കേഷനായി മാറുന്നതിന് പകരം, സൊല്യൂഷനുകൾ വ്യക്തമായി നിർവചിക്കപ്പെട്ട ഫീച്ചറുകളും മൊഡ്യൂളുകളും ആയി, വ്യക്തമായ ഇന്റർഫേസുകളോടെ വിഭജിക്കണമെന്ന് Ian വിശദീകരിക്കുന്നു.

"വാക്-എ-മോൾ" ഡെവലപ്മെന്റ് പ്രശ്നത്തിൽ നിന്ന് മോചനം
ഒരു ബഗ് പരിഹരിക്കുമ്പോൾ മറ്റൊരിടത്ത് പുതിയ ബഗ് പ്രത്യക്ഷപ്പെടുന്നത് പരിചിതമായ പ്രശ്നമാണ്. ഇത് പലപ്പോഴും ദൃഢമായി ബന്ധിപ്പിച്ച (tightly coupled) ആർക്കിടെക്ചറിന്റെ ലക്ഷണമാണ്. മൊഡ്യൂളാർ ഡിസൈൻ എങ്ങനെ പ്രവർത്തനങ്ങളെ വേർതിരിച്ച് അനാവശ്യ ആശ്രിതത്വങ്ങൾ കുറയ്ക്കുമെന്ന് Ian ചർച്ച ചെയ്യുന്നു. ഇമെയിൽ ഡെലിവറിയെ ഉദാഹരണമായെടുത്ത്, ബിസിനസ് പ്രക്രിയകളെ ഡെലിവറി മെക്കാനിസത്തിൽ നിന്ന് വേർതിരിക്കുന്നത് ആപ്ലിക്കേഷനുകൾ പരീക്ഷിക്കാനും പരിപാലിക്കാനും മാറ്റിസ്ഥാപിക്കാനും സ്കെയിൽ ചെയ്യാനും എളുപ്പമാക്കുമെന്ന് അദ്ദേഹം വിശദീകരിക്കുന്നു.

ലോ-കോഡ് + പ്രോ-കോഡ് = ഹൈബ്രിഡ് ആർക്കിടെക്ചർ
Power Platform പരമ്പരാഗത സോഫ്റ്റ്വെയർ ഡെവലപ്മെന്റുമായി മത്സരിക്കണമെന്നില്ല. Azure, AWS, GCP, APIs, അല്ലെങ്കിൽ കസ്റ്റം സേവനങ്ങൾ ഉപയോഗിക്കുന്ന ഒരു വലിയ ആപ്ലിക്കേഷന്റെ ചെറിയ ഭാഗം മാത്രമായിരിക്കാം ഒരു Power Apps ഫ്രണ്ടെൻഡ്. ഒരു കാര്യം "ലോ-കോഡ്" ആണോ "പ്രോ-കോഡ്" ആണോ എന്നതല്ല, ഓരോ ഫീച്ചറിനും ഏത് സാങ്കേതികവിദ്യയാണ് ഏറ്റവും അനുയോജ്യം എന്നതാണ് പ്രധാന ആർക്കിടെക്ചറൽ ചോദ്യം.

സിറ്റിസൺ ഡെവലപ്പർമാർ, മേക്കർമാർ, ആർക്കിടെക്ചർ
സിറ്റിസൺ ഡെവലപ്പർമാർ അവർ ദിവസവും പ്രവർത്തിക്കുന്ന ബിസിനസ് പ്രക്രിയകളെക്കുറിച്ചുള്ള ആഴത്തിലുള്ള അറിവ് കൊണ്ടുവരുന്നു. എന്നാൽ ബിസിനസ് വൈദഗ്ധ്യം സ്വയമേവ നല്ല ആപ്ലിക്കേഷൻ ആർക്കിടെക്ചറായി മാറുന്നില്ല. മേക്കർമാരെ ശാക്തീകരിക്കുന്നതും, സൊല്യൂഷനുകൾ പരിപാലിക്കാൻ കഴിയാത്തവിധം സങ്കീർണ്ണമാകുന്നത് തടയാൻ ആവശ്യമായ ആർക്കിടെക്ചർ, ഗവേണൻസ്, നോർമലൈസേഷൻ, സാങ്കേതിക അവലോകനം എന്നിവയും തമ്മിലുള്ള സന്തുലനത്തെക്കുറിച്ച് Ian ചർച്ച ചെയ്യുന്നു.

നവീകരണത്തെ തടയാതെ ഗവേണൻസ്
വളരെ കുറഞ്ഞ ഗവേണൻസ് അരാജകത്വം സൃഷ്ടിക്കുന്നു. വളരെ കൂടുതലായാൽ അത് ഘർഷണം ഉണ്ടാക്കുകയും, ജീവനക്കാരെ പിന്തുണയില്ലാത്ത വർക്ക്എറൗണ്ടുകൾ, സ്പ്രെഡ്ഷീറ്റുകൾ, VBA, ഷാഡോ IT എന്നിവയിലേക്ക് നയിക്കുകയും ചെയ്യും. സംഘടനാ അപകടസാധ്യത, ആപ്ലിക്കേഷന്റെ നിർണായകത, ഉപയോക്താക്കൾ, ബിസിനസ് ആഘാതം എന്നിവയെ അടിസ്ഥാനമാക്കി ശരിയായ ഗവേണൻസ് നില കണ്ടെത്തുന്നതാണ് വെല്ലുവിളി.

Power Platform, APIs, 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, APIs, ഓട്ടോമേഷൻ, പരമ്പരാഗത സോഫ്റ്റ്വെയർ എൻജിനീയറിംഗ് രീതികൾ എന്നിവ എങ്ങനെ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു എന്ന് മനസ്സിലാക്കുന്നതിലാണ് കൂടുതലായി അധിഷ്ഠിതമാകുന്നത്.

ഈ പോഡ്കാസ്റ്റിന്റെ സപ്പോർട്ടർ ആകുക: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.