Leveringsmodeller
Afhængigt af størrelsen på organisationen kan det være en god ide at formalize din Microsoft Power Platform-indføring ved at implementere en struktureret organisationsmodel. Du skal overveje følgende metoder til at strukturere dit team og afgøre, hvad der er bedst egnet til din situation og organisation.
Microsoft Power Platform indeholder fire leveringsmodeller, men hver er bare en mental model – alle organisationer har en variation af flere modeller sammen med dette kontinuum. Selvom du f.eks. vælger en centraliseret model, hvor alle krav kommer til et team for central levering, kan du stadig få borgerudviklere til at finde platformen og bygge apps til deres teams. Så har du altid elementer af matrix eller BizDevOps.
Disse modeller kan hjælpe dig med at finde ud af, hvad din aktuelle softwareleveringsmodel er, og hvordan Microsoft Power Platform kan overlejres i den, eller hvordan din aktuelle model kan udvikle sig til at rumme den hurtige udvikling, der er muliggjort af Microsoft Power Platform.
Centraliseret
I denne model kan du oprette centrale teams af produktejere, der ejer leveringen med lav eller ingen kode af afdelingsløsninger fra hele organisationens afdelinger. Professionelle udviklere, der ejer kode-først-løsninger, arbejder tæt sammen med virksomheden om at levere i en delt model. Virksomhedsarkitekter ejer mellemlaget og services og sikrer, at data er tilgængelige for udviklere. Den centrale it-afdeling ejer de licenser og systemer, alle bruger.
Med denne model kan du oprette et centralt team, der kan registrere udviklingen af apps baseret på organisationens prioriteter. Fordi de har væsentlig ekspertise i Power Apps, vil dit team også omfatte medlemmer, der er specialiseret i bestemte dele af Microsoft Power Platform som f.eks. Power Automate, Power BI og Power Apps component framework, eller de kan være specialiseret i at integrere tredjepartsløsninger og kunstig intelligens. Denne model er en effektiv metode til at foretage ændringer i på tværs af organisationen, og den bedste metode til at levere alle typer applikationer.
Her er en digital briefing fra Schlumberger, der illustrerer denne type model, som er udvidet gennem både decentraliserede og matrix-baserede modeller. Få mere at vide om, hvordan Schlumberger indfører Microsoft Power Platform: Kreativ appopretter iværksætter revolution med brug af lav kode hos Schlumberger
| Applikationsleveringstype | Leveringsmodeltype | Buildtidspunkt for applikationen | Levetid for applikationen | Eksempler | It-engagement |
|---|---|---|---|---|---|
| Selvbetjening | Vilkårlig | 1-2 uger | 6-12 måneder | Små, afdelingsrelaterede eller LOB-løsninger. | Decentraliseret it-afdeling |
| Små teams | Matrix-baseret/centraliseret | 3-6 måneder | 6-24 måneder | Små teams, der arbejder på at levere mellemstore løsninger eller løsninger til flere afdelinger. | Decentraliseret it-afdeling |
| Løsninger til flere afdelinger eller store brancheløsninger | Matrix-baseret/centraliseret | 3-6 måneder | 6-24 måneder | Store matrix-baserede teams, der arbejder på at levere mellemstore og store løsninger eller afdelingsrelaterede løsninger. | Centraliseret it-afdeling |
| Produktlevering i stor målestok | Centraliseret | 1-2 år | 5-7 år | Store produktleveringer i hele virksomheden, der anvender en blanding af Power Apps-løsninger med lidt eller ingen kode og kode-først sammen med løsninger for leverandør og førstepart. | Centraliseret it-afdeling |
| Levering til stor virksomhedsleverandør | Centraliseret | 7 år | 10-15 år | Omslutningsstrategi for et tredjepartssystem for post- og supportstruktur. For eksempel SAP-implementering og omgivelse af det med en blanding af low-code- og code-first-løsninger i Power Apps og andre Microsoft og tredjepartsintegrationer. | Centraliseret it-afdeling |
Decentraliseret
I denne model kan du oprette flere teams i hele organisationen, der er tæt på den daglige drift af forskellige teams. De har ressourcer til at sikre ensartet levering af apps inden for organisationens retningslinjer. Hvert team kan køre selvstændigt, og de kan opdeles og udvides i mobil form. Men med denne model skal du stadig bruge centraliseret styring for at sikre, at virksomheden overholder en række digitale retningslinjer på højt niveau og overholder angivne standarder. Disse kan inkludere elementer som styring af datatabsforebyggelse (DLP), forbindelses- og licensadministration for at sikre, at brugere og udviklere sikkert kan udvikle og udgive løsninger med minimalt indgreb fra IT-afdelingen, mens virksomhedens data holdes sikre og kompatible. Dette er en fantastisk selvbetjeningsfunktion.
Matrix
Med denne model kan du blande de bedste dele decentraliserede og centraliserede løsninger. Du har et centralt team med uddannede og certificerede Microsoft Power Platform-specialister. Du får ledere for forandring, design, levering og arkitektur foruden specialiserede undervisere til uddannelse af lokale teams i hele organisationen. Lokale teams, der består af borgerudviklere, forbindes med eksperter fra den centraliserede struktur for at sikre, at der ikke går noget tabt i oversættelsen mellem de personer, der udfører det daglige arbejde og bruger de apps, der bliver bygget. Med denne model kan du skalere til de tusindvis af personer, der arbejder med appoprettelse.
Dette team skal også inddrage Center of Excellence for at administrere deres dataejendom og installere løsninger med retningslinjer for alle. Dette fungerer fint ved selvbetjening og små teams til hurtig levering af funktioner med begrænset inddragelse af it-afdelingen.
BizDevOps
Hurtig appudvikling kan kun ske med den hastighed, som f.eks. it-handlinger kan støtte de oprettede apps. BizDevOps er en holistisk relation mellem appudviklere og -handlinger, der fungerer i en omfattende løkke. For at dette kan fungere skal alle teams have en klar forståelse af den digitale kultur, som organisationen bevæger sig hen imod. Hvis du vil have maksimal værdi ud af de oprettede apps, skal de have pålidelig support, styring og vedligeholdelsesevne. I takt med at teknologien udvikler sig, skal der foretages opdateringer af apps for at holde dem opdaterede. Det er ikke kun afgørende at være opmærksom på forandringerne, men at have en plan for håndteringen af den for at bygge vellykkede apps.