Power Platform ਨੂੰ ਗੁੰਝਲਦਾਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਹੱਲਾਂ ਲਈ ਆਰਕੀਟੈਕਟ ਕਰਨਾ — Ian Tweedie [MVP] ਨਾਲ

Microsoft Power Platform ਨੂੰ ਅਕਸਰ ਇੱਕ ਲੋ-ਕੋਡ ਪਲੇਟਫਾਰਮ ਵਜੋਂ ਵਰਣਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪਰ ਜਦੋਂ ਤੁਹਾਡੀਆਂ ਬਣਾਈਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਪਾਰ ਲਈ ਅਹਿਮ ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਜੁੜੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਸਧਾਰਨ ਮੇਕਰ-ਪਹਿਲੀ ਪਹੁੰਚ ਲਈ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

M365 FM ਦੇ ਇਸ ਐਪੀਸੋਡ ਵਿੱਚ, Mirko Peters ਪਾਵਰ ਪਲੇਟਫਾਰਮ ਸੋਲਿਊਸ਼ਨ ਆਰਕੀਟੈਕਟ Ian Tweedie ਨਾਲ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ ਕਿ ਜਦੋਂ ਪਾਵਰ ਪਲੇਟਫਾਰਮ ਸਧਾਰਨ ਲੋ-ਕੋਡ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ ਅੱਗੇ ਵਧ ਕੇ ਇੱਕ ਗੰਭੀਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਆਰਕੀਟੈਕਚਰ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।

ਲੋ-ਕੋਡ ਦਾ ਮਤਲਬ ਘੱਟ ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ ਹੁੰਦਾ

Power Platform ਤੇਜ਼ੀ ਨਾਲ ਵਪਾਰਕ ਮੁੱਲ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਹੱਲਾਂ ਵਿੱਚ ਲਗਭਗ ਹਮੇਸ਼ਾ ਅਜਿਹੀਆਂ ਲੋੜਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਮਿਆਰੀ ਲੋ-ਕੋਡ ਸਮਰੱਥਾਵਾਂ ਤੋਂ ਅੱਗੇ ਜਾਂਦੀਆਂ ਹਨ।

Ian ਦੱਸਦੇ ਹਨ ਕਿ ਲੋ-ਕੋਡ ਨੂੰ ਕਦੇ ਵੀ ਨੋ-ਕੋਡ ਨਾਲ ਉਲਝਾਉਣਾ ਨਹੀਂ ਚਾਹੀਦਾ — ਅਤੇ ਪਰੰਪਰਾਗਤ ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ ਦੇ ਸਿਧਾਂਤ ਅਜੇ ਵੀ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ ਜਦੋਂ Power Apps, Power Automate, Dataverse, ਕਸਟਮ ਕਨੈਕਟਰਾਂ, APIs ਅਤੇ Azure ਸੇਵਾਵਾਂ ਨਾਲ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੋਵੇ।

ਜਦੋਂ Power Platform ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਾਫਟਵੇਅਰ ਬਣ ਜਾਂਦਾ ਹੈ

"ਲੋ-ਕੋਡ" ਅਤੇ "ਐਂਟਰਪ੍ਰਾਈਜ਼" ਵਿਚਕਾਰ ਕੋਈ ਸਾਫ਼ ਲਾਈਨ ਨਹੀਂ ਹੁੰਦੀ। ਜਟਿਲਤਾ ਉਦੋਂ ਵਧਣੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਕਈ ਯੂਜ਼ਰ ਜਰਨੀਆਂ, ਡਿਵੈਲਪਮੈਂਟ ਟੀਮਾਂ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਸੁਰੱਖਿਆ ਲੋੜਾਂ, ਵਪਾਰ-ਨਾਜ਼ੁਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਆਪਸ ਵਿੱਚ ਜੁੜੀਆਂ ਸੇਵਾਵਾਂ ਸ਼ਾਮਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

ਉਸ ਸਮੇਂ ਆਰਕੀਟੈਕਚਰ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ। Ian ਦੱਸਦੇ ਹਨ ਕਿ ਹੱਲਾਂ ਨੂੰ ਇੱਕ ਵੱਡੀ ਆਪਸ ਵਿੱਚ ਜੁੜੀ ਐਪਲੀਕੇਸ਼ਨ ਬਣਨ ਦੀ ਬਜਾਏ, ਸਾਫ਼ ਇੰਟਰਫੇਸਾਂ ਵਾਲੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਫੀਚਰਾਂ ਅਤੇ ਮਾਡਿਊਲਾਂ ਵਿੱਚ ਕਿਉਂ ਵੰਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

"ਵੈਕ-ਏ-ਮੋਲ" ਡਿਵੈਲਪਮੈਂਟ ਸਮੱਸਿਆ ਤੋਂ ਬਚਣਾ

ਇੱਕ ਬੱਗ ਠੀਕ ਕਰੋ ਤਾਂ ਕਿਤੇ ਹੋਰ ਨਵਾਂ ਬੱਗ ਪ੍ਰਗਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਜਾਣੀ-ਪਛਾਣੀ ਡਿਵੈਲਪਮੈਂਟ ਸਮੱਸਿਆ ਅਕਸਰ ਕੱਸ ਕੇ ਜੁੜੀ ਆਰਕੀਟੈਕਚਰ ਦਾ ਲੱਛਣ ਹੁੰਦੀ ਹੈ।

Ian ਚਰਚਾ ਕਰਦੇ ਹਨ ਕਿ ਮਾਡਿਊਲਰ ਡਿਜ਼ਾਈਨ ਕਿਵੇਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਅਲੱਗ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਅਣਚਾਹੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ। ਈਮੇਲ ਡਿਲੀਵਰੀ ਦੀ ਉਦਾਹਰਣ ਵਰਤਦੇ ਹੋਏ, ਉਹ ਦੱਸਦੇ ਹਨ ਕਿ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਡਿਲੀਵਰੀ ਮਕੈਨਿਜ਼ਮ ਤੋਂ ਵੱਖ ਕਰਨ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਟੈਸਟਿੰਗ, ਰੱਖ-ਰਖਾਅ, ਬਦਲਣ ਅਤੇ ਸਕੇਲਿੰਗ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ।

ਲੋ-ਕੋਡ + ਪ੍ਰੋ-ਕੋਡ = ਹਾਈਬ੍ਰਿਡ ਆਰਕੀਟੈਕਚਰ

Power Platform ਨੂੰ ਪਰੰਪਰਾਗਤ ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

Power Apps ਫਰੰਟਐਂਡ ਕਿਸੇ ਵੱਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਸਿਰਫ਼ ਛੋਟਾ ਹਿੱਸਾ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ Azure, AWS, GCP, APIs ਜਾਂ ਕਸਟਮ ਸੇਵਾਵਾਂ ਵਰਤਦਾ ਹੋਵੇ। ਅਹਿਮ ਆਰਕੀਟੈਕਚਰਲ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਕੋਈ ਚੀਜ਼ "ਲੋ-ਕੋਡ" ਹੈ ਜਾਂ "ਪ੍ਰੋ-ਕੋਡ", ਬਲਕਿ ਇਹ ਹੈ ਕਿ ਹਰ ਫੀਚਰ ਲਈ ਕਿਹੜੀ ਤਕਨਾਲੋਜੀ ਸਭ ਤੋਂ ਵਧੀਆ ਢੁੱਕਦੀ ਹੈ।

ਸਿਟੀਜ਼ਨ ਡਿਵੈਲਪਰ, ਮੇਕਰ ਅਤੇ ਆਰਕੀਟੈਕਚਰ

ਸਿਟੀਜ਼ਨ ਡਿਵੈਲਪਰ ਬਹੁਤ ਕੀਮਤੀ ਚੀਜ਼ ਲਿਆਉਂਦੇ ਹਨ: ਉਹ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਡੂੰਘਾ ਗਿਆਨ ਰੱਖਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਉਹ ਹਰ ਰੋਜ਼ ਕੰਮ ਕਰਦੇ ਹਨ।

ਪਰ ਵਪਾਰਕ ਮੁਹਾਰਤ ਆਪਣੇ-ਆਪ ਚੰਗੀ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦੀ। Ian ਮੇਕਰਾਂ ਨੂੰ ਸਸ਼ਕਤ ਕਰਨ ਅਤੇ ਹੱਲਾਂ ਨੂੰ ਔਖੇ-ਸੰਭਾਲ ਬਣਨ ਤੋਂ ਰੋਕਣ ਲਈ ਕਾਫ਼ੀ ਆਰਕੀਟੈਕਚਰ, ਗਵਰਨੈਂਸ, ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਤਕਨੀਕੀ ਸਮੀਖਿਆ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ।

ਇਨੋਵੇਸ਼ਨ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ ਗਵਰਨੈਂਸ

ਬਹੁਤ ਘੱਟ ਗਵਰਨੈਂਸ ਅਰਾਜਕਤਾ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਗਵਰਨੈਂਸ ਰੁਕਾਵਟ ਬਣਦੀ ਹੈ — ਅਤੇ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਗੈਰ-ਸਮਰਥਿਤ ਵਰਕਅਰਾਊਂਡਾਂ, ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ, VBA ਅਤੇ ਸ਼ੈਡੋ IT ਵੱਲ ਧੱਕ ਸਕਦੀ ਹੈ।

ਚੁਣੌਤੀ ਸੰਗਠਨਾਤਮਕ ਜੋਖਮ, ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਮਹੱਤਤਾ, ਯੂਜ਼ਰਾਂ ਅਤੇ ਵਪਾਰਕ ਪ੍ਰਭਾਵ ਦੇ ਆਧਾਰ 'ਤੇ ਸਹੀ ਪੱਧਰ ਦੀ ਗਵਰਨੈਂਸ ਲੱਭਣਾ ਹੈ।

Power Platform, APIs ਅਤੇ Azure

ਵਪਾਰਕ ਲੌਜਿਕ ਕਿੱਥੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ? ਕੀ ਸੀਕ੍ਰੇਟਸ Power Platform ਦੇ ਅੰਦਰ ਸਟੋਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ? ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ Azure Key Vault, Azure Functions, ਜਾਂ API Management ਕਦੋਂ ਸ਼ਾਮਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ?

Ian ਸਮਝਾਉਂਦੇ ਹਨ ਕਿ ਆਰਕੀਟੈਕਚਰ ਹਮੇਸ਼ਾ ਹੱਲ ਕੀਤੀ ਜਾ ਰਹੀ ਸਮੱਸਿਆ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਸ ਲਈ Azure ਸੇਵਾਵਾਂ ਜੋੜਨਾ ਕਿਉਂਕਿ ਉਹ ਉਪਲਬਧ ਹਨ।

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.