Power Platform hallinta: Irti telineistä!
Ehkä teidänkin yrityksessä/organisaatiossa on lähdetty kokeilemaan tai jopa luomaan kokonaisuuksia Power Appsin ja Power Automaten parissa.
Näillä työkaluilla saa varsin näppäriä ja laajojakin kokonaisuuksia rakenneltua ja aloituskynnys on suhteellisen matala, riippuen toki siitä mitä haluaa tehdä 😉
Se, mikä harmittavan usein unohdetaan kun hypätään suoraan tekemisen maailmaan, on tekemisen hallinta
Kuvitteellinen tilanne:
Organisaatiossa on tehty kaikenlaista hassua toteutusta Power Appseilla ja Power Automatella. Joku IT:stä tietää että “jossain” pisneksen puolella käytetään “jotain” todella tärkeää toteutusta em. työkaluilla tehtynä. Tai ainakaan ei ole ostettu mitään custom softaa ulkoa. Hyvä homma!
Sitten tulee eteen se päivä kun IT saa ilmoituksen että nyt tämä supertärkeä, rahavirtoja ohjaava toteutus ei toimi. Alkaa kalabaliikki ja kädet heiluu. Kukaan ei tiedä mistä etsiä, mitä tutkia. Dokumentaatiota ei tietenkään ole missään. Tässä vaiheessa olisi sitten tosi kiva, kun tämä Power Platform -tekeminen olisi jossain hallinnassa sille olisi yhteiset pelisäännöt.
Käydäänpä vähän läpi, mistä voisi lähteä liikkeelle jotta sitä hallintaa saadaan aikaiseksi.
1. Power Platform -ympäristöt tutuiksi
Jokainen Power Apps ja Power Automate -toteutus tallentuvat johonkin Power Platform -ympäristöön. Eli kun esim. sinä luot tunnuksellasi jonkin Power Automate Flowin, tallentuu se Power Platform -ympäristöön, joka asuu siinä 365-tenantissa jossa tunnuksesikin on.
365 Global Admin ja Power Platform Admin -rooleilla pääsee hallitsemaan ja tarkastelemaan näitä ympäristöjä.
Ympäristöt löytyvät Power Platform Admin Centerin takaa.
Oletusympäristö (default environment)
Jokaisessa 365-tenantissa on valmiina ns. oletusympäristö. Tämän ympäristön nimi on aina mallia “<365 organisaation nimi> (default)”
Ilman mitään hallintatoimenpiteitä tänne tallentuvat jokaikinen Power Apps ja Power Automate -toteutus joka organisaatiossa tehdään.
Kun aikaa kuluu ja toteutuksia syntyy kuin sieniä sateella, voi vain kuvitella kuinka työlästä esim. IT:n on sitten etsiä niitä toimenpiteitä vaativia toteutuksia yhdestä ja samasta ympäristössä jossa on jokaisen käyttäjän henkilökohtaisetkin toteutukset ja kokeilut.
Tämä oletusympäristö kannattaakin nimetä joksikin kuvaavammaksi kuten:
Personal
Personal productivity
Näin viestitään, että tämä ympäristö on tarkoitettu niille omille, hlökohtaisille toteutuksille tai pienten porukoiden toteutuksille. Eli siis semmoisille toteutuksille joilla ei ole mitään isompaa roolia tai varsinkaan kriittistä roolia organisaatiossa.
Toki pelkkä nimenmuutos ei riitä. Asiasta pitää viestiä ja sopia käyttäjien kanssa jotta tietävät mitä tekevät kun luovat niitä erilaisia toteutuksia.
Tuotanto- ja testiympäristöt
Niitä tuotantokriittisiä ym. tärkeitä toteutuksia varten olisi hyvä perustaa erilliset testi- ja tuotantoympäristöt. Ympäristöjen perustamiseen tarvitaan Power Platform -kapasiteettia. Kapasiteettia saa lisää lisensseillä ja addon-lisensseillä.
Microsoftin Power Platform -lisenssioppaasta saa hyvän kuvan siitä, mitkä lisenssit antavat kapasiteettia. Kapasiteettimielessä kannattaa lukaista sivut 23-25.
Yksinkertaisimmillaan Power Platform -ympäristökokonaisuus voisi olla jotain tällaista:
Personal (default)
Production
Development
Ideana siis on että kehitystyö tehtäisiin Developmentissa ja tuotannossa olevat toteutukset pyörisivät Productionissa. Käyttäjien ja pienten poruikoiden omat, ei kriittiset toteutukset voisivat hyvin pyöriä siellä Personal-ympäristössä
Kannattaa kuitenkin muistaa että tähän ympäristökokonaisuuteen ei ole yhtä oikeaa vastausta. Jotkin toteutukset voi olla järkevämpää luoda ihan omaan, dedikoituun ympäristöön.
Ja näitä ympäristöjähän pystyy luomaan siellä Power Platform Admin Centerissä
Erillisten ympäristöjen myötä pystytään myös paremmin hyödyntämään Power Platformin Data Loss Prevention -mekanismeja!
SharePointin kustomoidut lomakkeet vs. ympäristöt
Huomiona nostettakoon nämä Power Apps toteutukset. Eli jos on luotu SharePoint-listojen kylkeen kustomoituja lomakkeita Power Appsilla, niin näitä lomakkeita tai “lomakesovelluksia” ei pystytä allokoimaan mihinkään erillisiin ympäristöihin. Näiden lomakesovellusten voi mieltää asuvan siellä SharePoint Onlinessa niiden listojen kyljessä. Periaatteessa nämä toteutukset siis asuvat väkisin siinä tenantin mukana tulevassa default-ympäristössä.
2. Tenant level analytics – Vihdoinkin helpotusta kipuihin
Tämä on asetus joka yksinkertaisesti kannattaa laittaa päälle, jälleen kerran siellä Power Platform Admin Centerissä. Suurin hyöty mitä tällä asetuksella saavutetaan, on Power Automaten seuraaminen organisaatiossa joka on tähän mennessä ollut melko surkealla tasolla.
Power Apps ja Power Automate kuluttavat käyttäjäkohtaisia palvelupyyntöjä. Eri lisenssit antavat erilaisen määrän 24h sisällä suoritettavia pyyntöjä. Tähän mennessä näiden rajojen ylittäminen ei ole tarkoittanut mitään, mutta todennäköistä on, että jatkossa näihin tullaan puuttumaan Microsoftin toimesta.
Jälleen kerran kuvitteelinen tilanne:
Yrityksellä on kriittinen Power Automate -toteutus joka on palvelupyyntöjen osalta ylikäytöllä per 24h. Jossain vaiheessa voi käydä niin että Microsoft puuttuu tähän ylikäyttöön ja sammuttaa/estää ko. toteutuksen toiminnan. Tällanen tilanne olisi tietysti kiva saada kiinni mahdollisimman ajoissa.
Tenant level analyticsin saa päälle Power Platform Admin Centeristä, oikealta ylhäältä rataspyörän takaa:
Samalla kannattaa myös tarkistaa että kuvassa näkyvät ympäristöjen luontioikeudet on laitettu asentoon Only specific admins. Käytännössä tämä tarkoittaa sitä että vain Global Adminit ja Power Platform Adminit voivat luoda uusia ympäristöjä. Tämä tosin ei estä Teams-pohjaisten Dataverse-ympäristöjen luomista 😉
Tämän jälkeen organisaation Power Platform -käytöstä alkaa muodostumaan raportoitavaa dataa. Data tallentuu maantieteellisesti sinne alueeseen jossa organisaation 365-tenantti asuu.
3. Palvelutunnukset, Multiplexing, Service Principal… mmmikä?
Kun luodaan automaattisia tai ajastettuja Floweja, kannattaa ne Flowin sisällä käytettävät yhteydet laittaa menemään palvelutunnuksen kontekstissa eikä sillä omalla tunnuksella.
Flowin sisällä pystyy tarkastamaan ja vaihtamaan eri toimintojen tunnuskontekstin toiminnon asetuksista.
Esim. SharePoint-yhdistin:
Allekirjoittanut tykkää myös luoda Flowit palvelutunnuksella vaikka sitten muokkaisikin sitä Flowia omalla hlökohtaisella tunnuksella. Näin luotu Flow on heti varmuudella palvelutunnuksen alaisuudessa.
Nykyään toki Flowin omistajuuden pystyy vaihtamaan jälkikäteenkin 🙂
Huomiona, että Power Apps -pohjaiset Flowit toimivat aina sen käyttäjän kontekstissa joka Flowin on käynnistänyt Power Appsista joten näihin ei voida kohdentaa palvelutunnuspohjaista ajattelua
Multiplexing-lisenssiehto
Lisenssiteknisenä huomiona muistutettakoon siitä, että Microsoftilla on olemassa multiplexing-lisenssiehto.
Lyhyesti: Kun luodaan totetutus, esim. Power Automate Flow joka toimii ajastetusti ja automaattisesti, pitää kaikkien käyttäjien jotka toteutuksesta hyötyvät, olla huomioitu lisensoinnin puolesta.
Eli skenaario jossa
- Palvelutunnuksella pyörii jokin Premium-flow tai Floweja
ja
- Käyttäjillä jotka hyötyvät toteutuksesta ei ole Premium-lisenssiä
== Tämä on lisenssiehtojen vastaista ==
Tuossa skenaariossa kaikilla käyttäjillä jotka käyttävät tai hyötyvät toteutuksesta, tulee olla joko Power Automate per User -lisenssi tai sitten se itse Flow tulee olla lisensoitu Power Automate per Flow -lisenssillä (ns. organisaatiolisenssi) Tämä on toki lisenssitekniikkaa mutta on kyllä osa Power Platform hallintaa.
Service Principal
Kun puuhataan Dataversen kanssa, palvelutunnuksen sijaan kannattaa mahdollisuuksien mukaan käyttää service principaleja
Näin päästään irti tunnuspohjaisesta toteutuksesta ja elämä on (toivottavasti) helpompaa!
4. Center of Excellence Starter (eli CoE “KitKat”)
Jos tenant level analytics (kohta 2.) tuomat raportoinnit eivät riitä, voidaan sukeltaa vielä syvemmälle. Center of Excellence Starter Kit (CoE) on Microsoftin julkaisema ja jatkuvasti päivittyvä paketti jolla voidaan mm. seurata ja analysoida oman organisaation Power Platform käyttöä (Power Apps, Power Automate, Power Virtual Agents) CoE:sta on syytä ymmärtää se, että se vaatii perehtymistä ja käyttöönoton. CoE on myös syytä asentaa omaan, dedikoituun Power Platform -ympäristöön. Eli ei kannata lähteä asentelemaan sitä siihen tenantin mukana tulleeseen default-ympäristöön. CoE-pakettia voidaan myös kustomoida oman organisaation tarpeisiin, toki vaatii sitä kuuluisaa ymmärrystä ja osaamista Power Platformista jotta tämä onnistuu 🙂
Täältä löytyy kätevä listaus asioista, mitä CoE:n asentaminen vaatii.
Hyvinä huomioina nostettakoot nämä asiat:
- Tunnus jolla CoE-paketin palikat pyörivät, pitää olla Power Apps per User ja Power Automate per User -lisenssit
- Eli Premium-lisenssit
- Tunnuksella pitää olla sähköpostilaatikko
- Tunnuksella tulee olla rooleina:
- Power Platform Admin
tai
- Global Admin -rooli
tai
- Dynamics 365 Service Admin
- Privileged Identity Management ei toimi tässä skenaariossa tällä tunnuksella
5. Time to play the Game!
Kaikki edellämainitut asiat ovat suhteellisen teknisiä toimenpiteitä. Näiden lisäksi tai pohjaksi tärkeimpänä toimenpiteenä on avata avoin keskustelu organisaatiossa Power Platformin roolista ja siitä, kuinka sillä meillä tehdään hommia. Eli luoda yhteiset pelisäännöt tekemiselle.
Hallintaa ja hallittua tekemistä on vaikea toteuttaa jos käyttäjät eivät tiedä pelisäännöistä tai jos niitä ei ole edes tehty.
– Pilviguru / Huru-ukko Jasu Snell
