SharePointi ärirollid

Jutukeses Ringmäng ümber SharePointi kirjutasin kolmest SharePointi põhirollist, aga seda peamiselt IT-inimeste ja arenduse vaatevinklist. Medalil on aga alati ka teine pool, kellest kõik alguse saab ning kes kõigele sellele sebimisele mõtte (loe:kasumi) annab – äripool. Lisaks ei lõpe tarkvaraprojekt sugugi live’i minekuga, vaid siis alles päris elu algabki.

Iga IT-projekti argipäev on tavakasutaja ja IT ühendamine. Igal rakendusel on tavaliselt

• tavakasutaja
• sisuline administraator – keegi äripoolelt, kes tavakasutaja jaoks asju sätib. Sõltuvalt rakendusest on tema tööpõld väga lai või väga kitsas (elementaarne näide on foorumi moderaator (või blogipidaja), keerukamad on mitmed ärirakendused). Üldiselt äripoole vastutaja, puhver IT ja tavakasutaja vahel, jagab infot mõlemal suunal, näiteks teeb täiendusettepanekuid.
• tehniline administraator – keegi IT-poolelt, kes asja toimimas hoiab, alates serverite püstihoidmisest kuni varunduse ja muu selliseni

Lisaks üldrollid nagu kasutajatugi, projektijuht jne. See on siis kõige lihtsam IT-projekt. SharePoint ei ole aga just väga lihtne projekt (kordame kõik koos: Sharepoint on strateegiline platvorm). SharePoint on nagu termotuumaenergia (tuli/nuga/vms), mis õigetes kätes võib suuri asju teha, aga valedes (või lihtsalt teadmatutes) kätes lõpeb suure jamaga. SharePoint ongi mõeldud äripoolele suurte võimaluste andmiseks, aga sellega kaasneb ka suur vastutus.

Üks töötava SharePointi rakenduse rollide võimalik jaotus on toodud http://www.letscollaborate.co.za/Resource-Centre/SitePages/JobDescriptionsIndex.aspx:

• tavakasutaja (SharePoint End User)
• saidi omanik (SharePoint Site Owner)
• saidikollektsiooni omanik (SharePoint Site Collection Administrator)
• kasutajatugi (SharePoint Helpdesk Administrator)
• evangelist/populariseerija* (SharePoint Evangelist / User Adoption Specialist) 
• Farmi/serveri administraator (SharePoint Farm / Server Administrator)
• arhitekt (SharePoint Architect)
• projektijuht (SharePoint Project Manager)

Omast tarkusest märkisin punasega ärirollid, sinisega tehnilised rollid ja lillaga vahepealsed, kuigi siin on ka vaieldavusi ja kõik sõltub konkreetsest olukorrast. Kui on tehtud veel mingit SharePointi eriarendust (ärirakendus, line of business (LOB) application), siis lisanduvad siia veel konkreetse rakenduse samad rollid (hea küll, serveri admin jääb võibolla ära).

Loomulikult on ei ole väiksemas organisatsioonis vaja igale rollile oma inimest, aga tihtipeale jäävad need rollid üleüldse õhku rippuma – äripool arvab, et see on IT ülesanne ja IT arvab, et sellega peaks äripool tegelema. Lõpptulemus – vt paar lõiku ülespoole.

Igal SharePointi asjal (projektil, installatsioonil, farmil, veebirakendusel jne kuni saidini ja vajadusel iga üksiku sisuelemendini välja) peab olema oma vastutaja, kes tõepoolest sellega ka tegeleb. Vastav inimene peab ka teadma, et see vastutamine kuulub tema tööülesannete juurde ning tal peab selleks ka aega olema. Tihti läheb nii, et inimesele öeldakse, et “nii, sina nüüd vastutad selle eest”, aga muid kohustusi vähemaks ei võeta. Kui just pole tegu eriti entusiastliku või kohusetundliku inimesega ning piisavalt oskusi/teadmisi ka pole, siis sinnapaika see jääbki. Lõpptulemus – vt paar lõiku ülespoole.

TL, TR: SharePoint nõuab äripoolelt:

1. tugevat organisatsiooni
2. pühendumist
3. hoolt ja kontrolli
4. inimeste aega

Ja sealt edasi on juba kõik võimalik, konkreetsete probleemide lahendamiseks (näiteks kontrollimatud alamsaidid) on targematel inimestel mitmeid nippe ja trikke, aga see on puhtalt delo tehniki.

* jah, mõtlesin ise välja, sest eesti keeles EI OLE vastavaid termineid olemas või on need väga hästi peidetud.

Piirivalvur/majahaldjas

Kui eelmine jutt rääkis sellest, millised rollid SharePointi projekti juures tavaliselt vajalikud on, siis nüüd võtaksin ette selle, mis tegelikult toimuma hakkab. Eeldades, et äripool on võtnud vastu põhjendatud otsuse SP kasutsele võtta ning suudab omi vajadusi/probleeme (analüütiku mõningase abiga) mõistlikult sõnastada, siis on edasine stsenaarium lihtsustatult ja
ideaalses maailmas umbes selline:

analüütik, administraator ja arendaja (või kõik ühes isikus = arhitekt) vaatavad otsa ärivajadustele ning tuvastavad, milliseid vajadusi saab rahuldada OOTB vahenditega (seadistus ja kohandamine), mille jaoks läheb vaja eraldi arendust ning panevad sellest tulenevalt paika arhitektuuri – nii füüsilise, loogilise kui ka informatsioonilise.

Ilmselgelt ei ole see lihtne ülesanne, ilmselgelt ei käi see kiiresti ja ilmselt on vaja korduvalt ka äripoolega suhelda: “Kas me võime teie vajadusi just täpselt nii rahuldada?”. Aga noh, põhimõtteliselt.

Edasi tegelevad:

• analüütik ja administraator kohandamisega
• arendaja arendamisega
• arendaja ja administraator kogu kompoti kokku- ja käimapanekuga
• analüütik kasutajate koolitamisega/kasutajatoega
• administraator tööshoidmisega

Ja ongi valmis, nii lihtne see oligi;)

Eelkirjutatust on näha, et administraator on praktiliselt igal sammul tegev, tema rollil on suur osa mängida. Hea administraator, ütleks lausa Administraator, on kulda väärt. Kui on olemas inimene, kes suudab hinnata, mida erinevad vajadused tähendavad SharePointi struktuurile/arhitektuurile, samuti hoida silma peal turvalisusel, jõudlusel, varundusel,
seotud teenustel-toodetel: AD (FS), Exchange, Office, IIS, SQL ja paljudel-paljudel teistel, siis on SharePointi puhul meil juba kolmveerand võitu käes.

Hea administraator on nagu majahaldjas/piirivalvur ühes isikus, kes ühelt poolt süsteemi tõrgeteta toimimas hoiab ja teiselt poolt lööb lärmi, kui kuskilt mingi jama paistma hakkab.

Kuidas teha vahet administraatoril ja Administraatoril (tuntud ka kui “rockstar admin”)?

Üks võimalus on näiteks Microsofti sertifikaadid – ja kuigi ka näiteks 70-667 eksamist on kahtlemata palju kasu, algab Administraator siiski 70-668. Muidugi ei tee paber iseenesest midagi, aga olles pisut nende eksamitega tutvunud, läheks ma vastava serdi omanikuga luurele iga kell;) Teine võimalus – hea administraator tegeleb ennetavalt, mitte ei kustuta tulekahjusid ja heal administraatoril on plaan (vt ka Jaga ja valitse).

Mis juhtub, kui sellele rollile ei pöörata piisavalt tähelepanu ja meil ei ole tugevat administraatorit?

Keegi, tavaliselt IT-st paneb SP purgi(d) püsti. Analüütik ja arendaja mõtlevad välja loogilise strukuuri, ehitavad selle osa lahendusest, mis suudavad, vajadusel mõningaid teenuseid/seadeid sudides ning aegajalt IT-osakonda piinates (“Pange profiilide sünk tööle!”). Arendaja arendab oma asja ja paneb selle üles, vajadusel mõningaid teenused/seadeid sudides. Kui lahendus on piisavalt väike, analüütik ja arendaja teavad, mida nad teevad, suhtlevad omavahel, dokumenteerivad oma tegevusi ja ka muidu läheb kõik hästi, siis kõik töötabki. Pigem läheb aga natuke teisiti. Arendaja ja analüütik vaatavad asju oma mätta otsast, kitsalt ja teineteisest eraldi. Üldpilti ei näe keegi, jõudlus ja turvalisus on täpselt sellised, kuidas välja kukuvad. Kui midagi katki läheb, siis ei pole kellelgi aimu miks läks, kes ja kuidas parandama peaks ning millised muud osad sellest veel sõltuvad (vt ka Jaga ja valitse).

Lõppkokkuvõttes on muidugi oluline, et üleüldse oleks olemas mingigi plaan ja keegi asjadel silma peal hoiaks – hoolimata ametinimetusest.

Jaga ja valitse – SharePoint ja sõbrad

See tuleb nüüd selline kokkuvõtte jutt kuumadest teemadest consumerization ja governance, peamiselt SP võtmes, aga ka muidu. Terminite tõlkimisega on muidugi probleeme:

• Consumerization on tarbimine või tarbimiskultuur ehk siis IT vaates on kasutajad praegu pigem tarbijad, kellel on valikuvõimalus ja kes ootavad kvaliteetset teenust
• Governance on umbes nagu haldus, aga laiem, alustades strateegilisest tasandist ja lõpetades administreerimisega.

Teemad on omavahel üsna tihedalt seotud, vähemalt minu peas – mida rohkem käitub kasutaja kui tarbija, seda suuremad on tema ootused, seda rohkem vajame me korrektset haldust. Minu jaoks olid need (eriti haldus) kokkuvõttes ühed olulisemad teemad, mis mitmetest ettekannetest läbi jooksid. Proovin oma mõtted ja argumendid ritta ajada, mis pole aga üldse nii lihtne,  sest nagu Dan Holme ütleb: “It’s complex, but not necessarily difficult”.

Peamiselt refereerin siin OSP233, Managing the SharePoint Disruption with End-to-End SharePoint Governance (Dan Holme), aga ka OSP01-LNC, 36 Terabytes: How Microsoft IT Manages SharePoint in the Enterprise (Jim Adams ja Nate Bruneau) ja FDN03, Enable Consumerization of IT (Ward Ralston), lisaks keynotes jms

Aga proovime pihta hakata.

Infoühiskonna probleemid on ammu teada:

• Infot on palju
• Info on killustatud/mitmes kohas/mitu erinevat versiooni
• Erinevad inimesed võivad näha ainult teatud infot
• Erinevad inimesed tahavad näha ainult teatud infot
• Inimesed tahavad näha seda infot igal pool, igal ajal, iga seadmega

Selge pilt, mängu tuuakse tuleb SP, mis kõike seda võimaldab. Aga just võimaldab, mitte ei tee. Tihti arvatakse, et SP (või jumala eest mingi muu tehnoloogia) on just see hõbekuul, mis kõik probleemid lahendab. Kahjuks mitte, vajadus seda hallata jääb siiski alles, kuid eriti SP puhul tuleb puuduliku halduse puhul löök varem või hiljem. Ja see saab olema valus. SharePoint kasutab filigraanselt ära entroopia iseeneslikku suurenemist – kui selle (st SP farmide jms) eest hoolt ei kanta, siis lähevad asjad metsa:

• kellelgi pole aimu, mis SP sees toimub – palju on seal saite ja mis info seal, kellele see info kättesaadav on (turvalisus!)
• ei kasutata mitte SharePointi, vaid mingeid muid, mittetoetatuid vahendeid (turvalisus!), sest ei teata/osata
• SP kasutatakse valedel eesmärkidel ja asjadeks, milleks see mõeldud pole – tulemuseks aeglane ja/või mittetoimiv süsteem
• lõppkokkuvõttes nagu midagi oleks, aga äril sellest olulist kasu pole

See ongi see koht, kus meil peaks olema korralik haldus(strateegia).  Halduse eesmärk on nüüd ja tulevikus pakkuda kasutajatele võimalikult valutult parimat teenust. Haldus peaks sisaldama:

• ootuste juhtimist, eesmärkide seadmist (ka pikemas perspektiiviks)
• muutustega kohanemist
• eeskirjade ja reeglite väljatöötamist
• riskide ja tulude (võimaluste) tuvastamist
• rollide ja vastutuse määramist
• tulemuste (sh kõige eelnimetatu) kontrollimist

Soojenduseks tuleb aru saada, et ilma halduseta lähevad asjad valesti ja nagu eelnevalt mainitud, eriti SP puhul. Kui see arusaamine on olemas, saab hakata nuputama, kuidas asju kuidagi rööpasse ajada ning seal ka hoida. Kõige olulisem on mõista, et SP on strateegiline otsus ja strateegiline platvormi valik:

• jah, me armastame Microsofti
• jah, me hakkame SP kasutama
• jah, me hoolitseme selle eest

Juhuslik SP on ikaldus (ma nagu oleks seda kuskil juba öelnud?). SP käib kokku kõigi muude MS toodete-tehnoloogiatega, alates Windows Serverist, MSSQList, AD’st ja IISist ning lõpetades Exchange, Office ja Lynciga. Ilma nendeta on SP kasutegur väga küsitav. Samuti ei ole investeering – nii rahaline kui ka inimestesse ja aega (teadmised!) – ainult ühe projekti puhul eriti mõistlik. SP on ühe projekti jaoks kallis ja keeruline, tõenäoliselt on ühe spetsiifilise eesmärgi täitmiseks ka odavamaid, lihtsamaid ja paremaid asju, aga SP võib olla hiilgav ja väga võimas ning suhteliselt odav platvorm – kui sellega korralikult ümber käia. Kui sellega ei käida korralikult ümber, siis on ta ka mitme projekti jaoks kallis ja ebaefektiivne. Arvestada tuleb nii ROId (Return on Investment), aga võib-olla hoopis rohkem ROId (Risk of Inaction), mis tähendab jälle seda, et kõik läheb metsa, kui me õigesti ei tee ja ka kasust on sel juhul asi kaugel.

(Mulle tuleb sellega seoses alati meelde üks tšuktšianekdoot:

Tšuktšile kingitakse mootorsaag Družba, kusjuures uueks päevanormiks on 5 ruumi puid. Tsuktsile oli see enne käkidegu. Alustab lõikust. Lõikab ja lõikab, kuid päevanormi täis ei saa. Ka järgmistel päevadel ei tule üle 3,5 ruumi. Ülemused mõtlevad, et milles on asi. Lähevad asja uurima. Üks komisjonist näitab, kuidas tema Družbaga saeb. Tsuktsi vaatab ja imestab:
“Kui mina saagisin, siis ta küll ei põrisenud!”

Kõiki asju on võimalik valesti kasutada, eksole)

Et SP on pikema-ajaline strateegiline ja poliitiline otsus, tuleb ka poliitikast aru saada – kes ja miks SharePointi tahab, keda see mõjutab (kes on kasutajad) ning kuidas selle kõige vahel ellu jääda ja normaalseid tulemusi saada.

Kui meil on strateegilises plaanis olemas arusaamine, et SP on meie platvorm ja nüüd teeme sinna peale mingi projekti, siis noh, see on nagu tarkvaraprojekt ikka, aga omade konksudega. Alustuseks äripoole vajadused:

• Mida me tahame ehk tulemused
• Miks me tahame ehk äriline vajadus
• Kellele seda vaja on ehk poliitika
• Kuidas me seda hindame ehk mõõdupuud (metrics)

Seejärel tuleb projekt ellu viia – sh lahenduse arhitektuur, realisatsioon, paigaldused jms, mis on üleüldse omaette teema. Kõige olulisem on aga nagu iga tarkvaraprojekti puhul, et kõik sõltub eesmärkidest (=äri vajadustest), skoopi tuleb suuta hoida ning otseteid ei tohi võtta – maksavad hiljem kätte (tuleb tuttav ette?).

SharePointi mõttes on kriitiline koht arhitektuuri paikapanemine, sest siia alla läheb lisaks füüsilisele ja loogilisele arhitektuurile ka infoarhitektuur koos kõigi oma reeglite ja standarditega. Just selles kohas tuleb tihtipeale välja organisatsiooni nõrkus – suurem osa süsteeme ei laseb asju teha ka suvaliselt, nt võrguketas ei küsi sinult nt lepingute salvestamisel ette, kaua sa seda alles hoida tahad, kes seda nägema peaks (nt erinõuded salajastele või isikuandmetele), mis tema metaandmed on jne. SharePoint küsib, sest need on olulised küsimused ja reeglina tagavad kogu organisatsiooni parema toimimise. Siinkohas peab siis analüütik (või kesiganes sellega tegeleb) äripoolelt need vastused välja pressima – kuidas ikkagi tegelikult olema peaks? Kui äripoolel ei ole vastuseid, siis tuleb need ise välja mõelda, aga kindlasti peab äripool need heaks kiitma. Konks on muidugi selles, et absoluutselt kõik on omavahel seotud – äri vajadused, infohalduse strateegia ning loogiline ja füüsiline arhitektuur. Aga noh, see kõik on tarkvaraprojektipuhul tavapärane. Ebatavaline on SP otseste rangete nõuete puudumine, selle asemel on vajadused, strateegiad ja arhitektuur, mis on kõik läbiräägitavad (või -röögitavad, sõltuvalt temperamendist). Loomulikult mingis faasis tekivad nõuded, aga alguses on vajadused ja variandid, kuidas SP neid rahuldada saab, seega harjumatult suur osakaal on konsultandil/analüütikul/lahenduse arhitektil. Nii mõnegi projekti puhul ei ole vaja koodi võibolla üldse kirjutadagi, aga seda rohkem on vaja seadistust ning ettekirjutust, kuidas seda lahendust õigesti kasutama peaks.

Ütleme nüüd, et traditsioonilises mõttes on meil projekt “valmis”, st mingi osa läheb live’i. Nüüd on vaja seda ka käigus hoida ja vastavalt vajadusele parandada. Vajadus kindlasti tuleb, sest tarkvaral on rumal komme muuta maailma ja seega ka äripoole vajadusi, millest kõik alguse saabki. SP puhul tuleb uuenduste stsenaariumid samuti hoolega läbi mõelda, sest

1. uuendada tuleb SharePoint ennast, vastavat lahendust (kohandusi) ja sisu
2. lahenduse ja sisu piir on üsna õrn, näiteks CSS, mida hoitakse laaditeegis (jah, nii on Style Library eesti keeles), ning mida saab muuta seega otse live’is, rääkimata õigustest jpm

Ehk siis liiklus ei käi mitte traditsioonilisel suunal test->live vaid teatud juhtudel ka vastupidi, suunal live->test.

Kasutajate kaasamine on iga projekti võtmeküsimus. SP on suur ja kipub inimesed ära hirmutama, seetõttu tuleb seda teha ettevaatlikult:

• müüa SP maha ehk näidata kuidas konkreetsete kasutajate mure saab kiiresti elegantse lahenduse
• koolitada väheseid vajalikke asju ja muus osas pakkuda materjale – kogu SP ei õpi keegi ära, see ajab ainult segadusse. Jällegi – kiired ja lihtsad lahendused, mida SP konkreetsete kasutajate muredele pakub
• teha SP omaseks ja isiklikuks – branding ja muu turundusteema

See võib hardcore nohikule tunduda selline ümmargune pehme möla, aga kahjuks on see oluline. Meil võib olla maailma parima funktsionaalsusega tarkvara, aga kui seda ei kasutata, siis pole sellest suurt kasu…

Niisiis, meil on live’is projekt, kasutajad kasutavad ja kõik on hästi. Võib vist asjad kokku pakkida? Ilmselgelt vale vastus. SP tuleb jälgida. Hooldada ja teha vajalikke seadistusi või muudatusi, sealjuures need dokumenteerida (miks ehk äri vajadus; mis ehk muudatus; kuidas ehk tegevus või protseduur) ning tungivalt soovitatavalt ka automatiseerida – tuleb pikas perspektiivis odavam (tagab järjepidevuse, kvaliteedi ja korratavuse). Muidu on meil olukord – “jah, oli küll ükskord varem midagi taolist, ma midagi vist tegin ja nagu hakkas tööle, aga ma enam ei mäleta, mis see oli”. Jälgida tuleb nii ühte projekti kui kogu SP keskkonda tervikuna ning ka ärivajaduste kontekstis:

• kas kõik  vastab algsetele vajadusetele?
• kas vajadused on muutunud?
• kuhu läheme edasi?

Ja siis tuleb edasi minna ning teha kõike seda uuesti. SP pole ühekordne projekt. SP on strateegiline valik, lõputu teekond ja areng (isiklik kasv ja muu new age). Tuleb meeles pidada, et SP vajab tegelemist, peavad olema paigas strateegiad ja protseduurid ning tuleb teada, mida tuleb teada;), edasi on juba lihtne.  “It is complex, but it’s not difficult“.

TL, DR: SharePoint on suur ja väga võimas, aga vale kasutuse korral on verd, higi ja pisaraid väga palju, seetõttu tuleb kogu üritust algusest saadik hoolega rööbastel hoida, asju õigesti teha ning seejärel kogu aeg silma peal hoida. Et SharePointi on mõttekas kasutada mitmeks projektiks, tähendab üks kord halvasti tegemist mitu korda selle kirumist.

Ja nüüd ma jõuan oma ivani. Eesti on väike ja ainult vähesed ettevõtted on tegelik SP sihtgrupp, mis kasutab kõiki võimalusi (vt SP kui strateegiline valik). Tihtipeale ostetakse endale SP koos mingi lahendusega, endale täpselt asjast aru andmata, millega tegemist on. Siinkohal peab tarnija (peamiselt projektijuhi isikus) ilmutama lausa üliinimlikke võimeid ja kõik selle ülalpoolkirjutatu selgeks tegema nii oma ülemustele kui ka tellija poole juhtisikutele:

• SP tuleb läbi mõelda
• SP tuleb monitoorida
• SP saab ja tuleb muuta vastavalt uutele vajadustele
• kasutajaid tuleb koolitada ja koolitada ja siis veel koolitada
• SP ei ole tavaline tarkvaraprojekt

Kui nende asjadega ei arvestata, siis üldiselt on tulemuseks ühel (tellija pole rahul) või teisel (kahjumis) viisil halb projekt. Mõlemal juhul saab vastu pead tarnija (peamiselt projektijuhi isikus), kuigi objektiivselt võivad puudujäägid olla hoopis tellija organisatsioonis. Ehk siin on nüüd suur karvane küsi- ja hüüumärk, kuidas neid riske kõigile osapooltele tutvustada ja mitte isegi pähe, vaid juba selgroo sisse tampida.

Kogu see teema oli minul juba enne TechEd sügaval olemas, aga ma ei osanud seda kuidagi sõnastada, lihtsalt oli selline näriv tunne, et kuskil on midagi väga olulist… Nii et kui OSP233 sel teemal alustas, siis ma oleks nagu valgustatud saanud:) Loodetavasti suutsin midagi edasi ka anda.

Lingid:

• Dan Holme’i presentatsioonid
• Dan Holme SP arhitektuurist
• Dan Holme automatiseerimisest
• Nate Bruneau blogi ja koodinäited