SharePoint-kehitys – miten tehdä oikea päätös toteutustavasta? Artikkelit

Cubescomin Office 365 -asiantuntija Pasi Pohjola keskittyy artikkelissaan pohtimaan eri vaihtoehtoja SharePoint-ratkaisulle. Artikkeli sukeltaa syvälle SharePointiin, joten se on suunnattu lähinnä asiaan perehtyneille. Asiasta  kiinnostuneen ei silti tarvitse itse olla asiantuntija, sillä me autamme oikean SharePoint-ratkaisun valinnassa.

Pasi Pohjola Cubescom

” Microsoft tuo voimakkaasti esille JavaScript -kieltä SharePointin mukauttamiseksi.  Erityisesti SPFx- teknologia on lyönyt itsensä läpi, vaikka SPFx-perusteinen ratkaisu on turhan raskas muutaman koodirivin rakentamista varten, eikä JavaScript ole kielenä ongelmaton. Kriittisen mielipiteen voit lukea vaikkapa ”The JavaScript phenomenon is a mass psychosis”  tai pohtia syitä. Mahdollisuus hyödyntää olemassa olevaa JavaScript-osaamista, tai ratkaisun liittäminen osaksi yrityksen versiohallinnointia sekä verraten yksinkertainen kehitysprosessi ovat monelle kehittäjille ”ketsuppia” perinteiseen kehitysmalliin verrattuna. Eikä ainakaan haittaa, että ratkaisut hyödyntävät palvelimen sijasta työaseman resursseja.

SharePoint-JavaScript-hypetyksen vuoksi moni kehittäjä ei muista, että toiminnallisuuden ei tarvitse olla osa SharePoint-käyttöliittymää – paras ratkaisu ei sijaitse SharePointissa lainkaan. Microsoft onkin tuonut vahvasti esille satelliittiajattelua. Esimerkiksi suositut Teams- ja Yammer-sovellukset ovat saatavissa perinteisinä työpöytäratkaisuina. Ulkoiset verkkosivut on mahdollista liittää osaksi SharePoint Online ja Office 365 -ympäristöä, siten että käyttäjän ei tarvitse muistaa useita kirjautumisia. Lopputulos voi olla vaikkapa Ruby on Rails -kielellä toteutettu verkkosivu tai Microsoft-kaupan kautta julkaistava työpöytäratkaisu. Ratkaisu voi hyödyntää jopa keinoälyä ja erilaisia tausta-ajoja. Esimerkiksi Epicor- toiminnanohjausjärjestelmästä on mahdollista nostaa yrityksen kannalta olennaista tietoa, ja jalostaa sitä edelleen hyödyntämällä Azuren tiedonkäsittelyn palveluita  tai hyödyntää SharePoint-käyttäjäprofiileita ja kasvontunnistusta personoitavien palveluiden toteuttamisessa.

 

Azure, Azure AD ja Office 365 ovatkin yllättävän edullisia

Monesti törmää väärinkäsitykseen, että satelliitteina toteutettu ratkaisu olisi erityisen kallis. Tämä on ymmärrettävää, koska Microsoft on markkinoinut SPFx -ratkaisuja edullisena tapana tehdä sovelluskehitystä.  Lisäksi O365-käyttäjien varasto (AAD) on ainoa O365-ympäristöön liittyvien ratkaisuiden yhteinen tekijä. Useimmiten kuitenkin riittää, että Azuresta ostetaan tietokanta (noin 5 €/ kk) sekä ilmainen verkkosivu. Kehityskustannukset eivät poikkea merkittävästi JavaScript-pohjaisten SPFx-ratkaisuiden rakentamisesta. Olennaisempaa on kokemus valitusta teknologiasta.

 

Miten valita oikea toteutustapa?

Mikä teknologia olisi oikea valinta omalle yritykselle? Kumpikaan edellä mainituista tavoista ei poista vahvan SharePoint-osaamisen tarvetta, koska se on edellytys parhaan toteutustavan valinnalle. Tässä artikkelissa käsittelemäni tavat eivät ole suinkaan ainoat tavat SharePointin mukauttamiseksi. Tämän vuoksi kannattaa kertoa osaavalle yhteistyökumppanille toiveet ja tavoitteet, ja pyytää perusteluja ehdotetulle tavalle ratkaista ongelma. Kysyminen ei maksa mitään. Seuraavassa on kuitenkin muutama pointti pohdittavaksi.

SPFx-ratkaisut ovat mainioita, mutta eivät aivan mainostetun ongelmattomia. JavaScript-perusteinen sovellus ei ole koskaan täysin eristyksissä SharePointista, ja lisäksi sovellukset ovat herkkiä Microsoft-päivityksistä seuranneille ongelmille. Käyttöönotto on kuitenkin helpottunut päivitysten myötä, eikä toteutukseen yleensä liity juoksevia kuluja. SharePointiin liittyvää satelliittiratkaisua ei myöskään kannata liittää osaksi intranetin käyttöliittymää.  Erillisen verkkosivun perustaminen ja rekisteröiminen aktiivihakemistoon edellyttää hiukan työtä, joten aivan triviaalien ratkaisuiden rakentaminen erillisenä ratkaisuna ei välttämättä ole järkevää. Toisaalta SPFx-perusteisten ratkaisuiden kehitystyökalut näyttävät edellyttävän ylläpitoa, joten pienimmissä ratkaisuissa kehitystyökalujen ylläpitäminen tulee huomioida kokonaiskuluissa.

 

 Lopuksi

Kun valitset toteutustapaa, kannattaa muistaa vanha nyrkkisääntö: valmistoiminnallisuus (tee-se-itse) on parempi kuin SharePoint verkko-osien mukauttaminen. Edellä mainittu on usein parempi kuin kustomoitu sovelluskehitys. Kannattaa muistaa, että yksinkertaisimmat ratkaisut on yhä parasta liittää suoraan SharePoint-sivulle esimerkiksi komentosarjaeditori-verkko-osan avulla. Mitä vaativammaksi ratkaisu muuttuu, sitä enemmän kannattaa miettiä toiminallisuuden toteuttamista SharePointiin liittyvänä, erillisenä verkkosivustona. Nykypäivänä ohjelmistokehittäjien ulottuvissa on paljon enemmän mahdollisuuksia kuin vielä kymmenen vuotta sitten. Tämän vuoksi yritysten tietojärjestelmistä vastaavien onkin tärkeää pohtia ohjelmistohankintoja aika-ajoin uudelleen.”

– Pasi Pohjola, Cubescom –


Meiltä laadukkaat ja helposti käyttöönotettavat digitaalisen työn ratkaisut tehostamaan liiketoimintaasi. Ota yhteyttä jo tänään.”

Jani Laakso, myyntipäällikkö
jani.laakso@cubescom.fi
+358 40 1837 447

- INNOVATE | IMPLEMENT -