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