Planiranje SharePoint projekata

by Adis Jugo, Komentari [0] Font:
Planiranje SharePoint projekata

U nastavku serije članaka posvećenih Microsoft SharePointu, fokusiramo se na proces planiranja SharePoint projekta.


Planiranje SharePoint projekata

Ako kažemo da je planiranje ključ uspjeha implementacije SharePoint projekata, to neće biti puko ponavljanje floskula koje važe za skoro svaku tehnologiju koju koristimo.

"It's about economy, stupid!" je bila jedna od ključnih parola Clintonovih izbornih kampanja u devedesetim godinama prošlog vijeka (a evo izgleda da će se i to ponoviti) - kada počnemo sa implementacijom SharePoint projekta, uvijek na umu moramo imati varijaciju ove parole - "It's about business, stupid!".

SharePoint je namijenjen da bude IT infrastruktura poslovnim i organizacijskim procesima unutar firme, ukoliko nam ovo stalno nije na umu, ukoliko nemamo tačno definiran krajnji cilj implementacije SharePointa, projekt će neminovno srljati u propast.

Nakon ovako katastrofičnog početka trećeg nastavka serije članaka o SharePointu, potrebno je ipak reći da se većina SharePoint projekata završava uspješno i na zadovoljstvo korisnika. I tu smo već došli do sljedeće ključne riječi pri implementaciji SharePoint projekata - acceptance. Zadovoljstvo korisnika.

Naravno da je zadovoljan korisnik cilj i krajnja mjera uspjeha svakog IT projekta. Opet, razlika je u tome da je u SharePoint projektima to jedina mjera, iz prostog razloga što korisnik nije prinuđen da koristi SharePoint, ili bilo koje drugo IWS rješenje. U prosječnoj firmi, radnici u financijama su prinuđeni da koriste postojeći ERP (financijski) softver. Možda će gunđati, ali koristiti ga moraju. Slična je stvar sa bilo kojim LOB (Line of Business) softverom, pa čak i sa CRM softverom.

Kod IWS softvera je, kako rekosmo, stvar drugačija: ukoliko organizacija portala, predlošci na portalu i uspostavljeni workflow nisu napravljeni tako da ubrzaju, olakšaju i pomognu svakodnevni rad korisnika, oni ga neće koristiti. Dokumente će nastaviti slati e-mailom, za odobrenje godišnjeg odmora će telefonom zovnuti šefovu sekretaricu, i ništa strašno se neće desiti. Business as usual.

Sam proces planiranja SharePoint projekta, kojim se bavi ovaj članak, možemo podijeliti na dva isprepletena kolosijeka: infrastrukturno i poslovno planiranje projekta.

 

Infrastrukturno planiranje SharePoint projekta

 
U infrastrukturnom planiranju projekta moramo voditi računa o tome gdje i kako ćemo instalirati SharePoint server, kakva nam je infrastruktura, koja varijanta SharePoint Servera nam je potrebna, ko mora imati pristup podacima na SharePoint serveru, kao i tome kako će se korisnici prijaviti.
 
Prvo pitanje na koje moramo odgovoriti je koja nam je varijanta SharePointa potrebna. Da li ćemo SharePoint instalirati na sopstvenoj infrastrukturi, ili ćemo koristiti Microsoft BPOS i SharePoint u cloudu. Ako se odlučimo za BPOS, moramo znati da onda nemamo mogućnosti prilagodbe i dodatnog razvoja SharePointa. Ukoliko su nam vlastiti webpartsi i proširenja od važnosti, onda je odluka jasna, SharePoint ćemo instalirati na sopstvenoj infrastrukturi. 

U tom slučaju, moramo donijeti odluku koja edicija SharePoint Servera nam je u stvari potrebna? Da li ćemo koristiti besplatni SharePoint Foundation, SharePoint Standard Server, ili SharePoint Enterprise Server? Razlika je, naravno, kako u cijeni licenci, tako i u hardverskoj infrastrukturi koja nam je potrebna za svaku od ovih edicija. 

Ova odluka, pored financijskih ili hardverskih ograničenja, ipak bi trebala da bude donesena primarno na osnovu potreba korisnika. Iako je SharePoint Enterprise Server mnogo skuplji od (besplatnog) SharePoint Foundationa, ukoliko su za kvalitetnu IT podršku poslovnih procesa u firmi neophodne neke napredne mogućnosti koje nudi Enterprise Edition (npr. BCS - Business Connectivity Services), onda se isplati i uzeti Enterprise edition jer podsjetimo se da je acceptance, zadovoljstvo korisnika, ključni cilj svake SharePoint instalacije.

Jeftina instalacija koju korisnici ne koriste ne može se nazvati uspješno izvedenim projektom, a novac uložen u Enterprise ediciju koja se putem BCS-a može integrirati sa postojećim softverskim aplikacijama može biti jako pametno utrošen novac. Ipak, treba reći da je SharePoint Foundation u ovoj verziji zaista prilično moćna. U svakom slučaju, potrebno je usporediti mogućnosti svake od edicija SharePointa, i nakon analize potreba izabrati odgovarajuću.
 
Sljedeća odluka koja se mora donijeti je način instalacije SharePointa, da li ćemo SharePoint instalirati kao samostalni serverski proizvod na jednom serveru (standalone), ili želimo da kreiramo SharePoint farmu. Mnogo je razloga za jednu ili drugu varijantu. Ukoliko je riječ o manjoj SharePoint instalaciji, možda ima smisla napraviti standalone instalaciju gdje će i SharePoint Server sa svim svojim servisima i SQL server biti instalirani na jednom fizičkom serveru (hardverskom ili virtualnom). Takva instalacija je vrlo jednostavna, i zahtijeva jako malo administratorskog konfiguriranja. Sa druge strane, ukoliko se naknadno pokaže potreba za proširenjem infrastrukture, sa standalone instalacijom smo vrlo ograničeni. Veliki broj SharePoint administratora upravo iz ovog razloga SharePoint server instalira uvijek kao farmu, čak i ako je farma sastavljena od jednog jedinog servera.

Takva instalacija ipak nudi mogućnosti da naknadno klasteriziramo cijelu SharePoint infrastrukturu dodajući u farmu nove database servere, frontend servere ili search servere. Ipak, instaliranje SharePointa u farmu je značajno kompleksnije i zahtijeva mnogo više administratorskog umijeća da bi se ispravno konfigurirale sve postavke, nego što je to slučaj u standalone verziji. Opet, možemo ponoviti isti zaključak od ranije jer ova odluka mora biti prevashodno uslovljena potrebama korisnika.

Ukoliko smo sigurni da će u sljedećim mjesecima ili godinama SharePoint portal koristiti sve veći broj korisnika, da će broj podataka i dokumenata značajno rasti, isplati se na početku uložiti vremena i instalirati SharePoint kao farmu i odlučiti da li ćemo database server odmah odvojiti na drugi fizički server, koliko nam je potrebno frontend servera, ili nam je za početak dovoljna farma od jednog jedinog servera.
 
Četvrto, i možda najbitnije pitanje u tehničkom planiraju je način na koji ćemo prijavljivati korisnike SharePoint portala. SharePoint je dosta otvoren po tom pitanju, radi na principu takozvanih Authentication Providera (poznatih iz ASP.NET-a), što u principu znači da mi možemo SharePointu odrediti izvor autentifikacije. Standardni, podrazumijevani izvor autentificiranja Active Directory. Dakle, svi domenski korisnici mogu biti i korisnici SharePoint portala. Za većinu SharePoint implementacija, ovo rješenje je sasvim dovoljno.
 
Međutim, kada je potrebno da se na SharePoint portal prijave korisnici koji nisu domenski korisnici (npr. poslovni partneri), ili kada dio portala hoćemo da pustimo javno, kao web stranicu tj. kada hoćemo da dozvolimo anonimni pristup, tada je uz Active Directory potrebno kombinirati i druge metode autentificiranja.

Prilikom planiranja portala i namjene, potrebno je definirati koje korisnike uopće želimo fizički pustiti na portal, da li će portal biti dostupan samo u intranetu, ili treba da bude dostupan i putem interneta, da li na portalu želimo samo AD korisnike, ili želimo i druge korisnike. Na osnovu odgovora na ova pitanja, određujemo koji načini autentificiranja su nam potrebni, i da li je pored standardnih metoda potrebno razviti i vlastite.
 
Čest problem u implementaciji SharePoint projekata je upravo "prljav" Active Directory, gdje je za jednu osobu često kreirano i više korisničkih računa, ničim povezanih. Ili su u Active Directory još uvijek aktivni korisnici koji već godinama nisu u firmi. SharePoint zahtijeva "čist" Authentification Provider, jer se inače može desiti da datoteke ili zadaci pridruženi određenom korisniku, do tog korisnika nikada ne stignu.

Pravljenje kompleksnih workflowa ili korisničkih timova je u takvim slučajevima besmisleno jer nije moguće jednoznačno identificirati korisnika. Ukoliko je ActiveDirectory u dezolatnom stanju, a planirano je da se koristi kao Authentification Provider za SharePoint, pametno je prvo investirati vrijeme u sređivanje stanja u AD-u prije ulaska u projekat implementacije SharePointa.
Analiza potreba - poslovno planiranje SharePoint projekta
Izaberite željenu stranu teksta:

Komentari (0)

Komentiraj

Pošalji svoj komentar