Luka Ferlež
Autor:
Luka Ferlež

Voditelj razvoja

Znamo li raditi enterprise?

  • 3.10.2014

Razgovarao sam s kolegom neki dan o tome da li znamo raditi Enterprise software i koliko smo dobri u tomeZanimljivo pitanje koje često čujemo od potencijalnih korisnika, kolega, u raspravama, na konferencijama odgovor obično dobijemo u obliku reklamnih slogana "enterprise-level features", "enterprise software", "enterprise support", enterprise bla bla i prečesto direktnih odgovora Da. Lijepi niz velikih riječi u pravoj tradiciji BS binga, koje pokušavaju odgovoriti na pitanje iza kojeg se može skrivati cijela šuma kompleksnosti bez dodatnih informacija o prirodi traženog rješenja.

Što je enterprise software?

Ne postoji neka dogovorena definicija što predstavlja enterprise software i kakve su njegove karakteristike. Neka globalna definicija bi bila da enterprise software rješava probleme cijele organizacije, a ne pojedinog sektora/odjela/korisnika. U domenu takvih rješenja bi prema tome ušla ERP, CRM, BI, BPM, itd. i custom rješenja za poslovne procese na razini cijele organizacije, ali to opet nije sve jer to nije sav software o kojem poslovanje tvrtki ovisi i koje su njihov core posao.

Prema takvoj definiciji rješenje koje se radi za firmu od 10 ljudi za praćenje servisa računala spada u enterprise rješenje jer zadovoljava potrebe cijele organizacije. Sumnjam da netko tko želi sustav za 10.000 transakcija u sekundi ima to na pameti kada ga zanima naše iskustvo i sposobnosti.

Termin enterprise rješenje se danas više odnosi na određene karakteristike rješenja, tj. njegovu kompleksnost i tehničke zahtjeve koji se postavljaju pred to rješenje kao što su up-time, količina korisnika, količina podataka, skalabilnost, robusnost itd. I tu se stvari počinju komplicirati. Dolazi do izražaja to da imamo mnogo različitih rješenja koja rješavaju različite probleme i kompleksne potrebe, ali kompleksne na hrpu različitih načina.

Kada znamo da znamo?

Iskren odgovor bi bio nikada u potpunosti. Možda smo radili super rješenje za određenu banku, ali to ne znači da znamo napraviti video streaming servis ili webshop ili custom ERP za hrpu simultanih korisnika i obrnuto. Cijeli skup našeg iskustva i znanja koje smo stekli na prošlim projektima može invalidirati neki zahtjev koji do sada nismo radili. Tako na primjer zahtjev za 99,95% uptime ili količinom podataka od 20 TB može kompletno izbaciti projekt iz tračnica iako smo radili razne kompleksne sustave.

Primjerice ekipa koja je radila VS Online je u nekom trenutku postigla up-time od 95%, ali njihov commitment je bio 99,95%. Ako su došli do 95% onda je do 99,95 još samo malo zar ne, koliko bi to moglo koštati? Mislim da je Brian Harry u jednom trenutku rekao da im je trebalo 10 - 15% ukupnog vremena projekta da realiziraju tih dodatnih 4,95% i to u suradnji s ekipom koja je radila već WindowsAzure i koji su imali iskustvo u tom području, a već u tom trenutku su imali podržane online deploymente i ažuriranja sustava.

Problem s kompleksnim rješenjima je da je krivulja učenja u principu nije krivulja već je niz jako strmih stepenica gdje s svakim novim zahtjevom koji se stavlja pred sustav stvari postaju za cijelu razinu kompleksnije. Prilagodba novoj razini nije potrebna samo na tehničkoj razini u developmentu nego kako se povećava kompleksnost počinju se pojavljivati problemi tamo gdje smo do sada stvari uzimali zdravo za gotovo i o njima nismo razmišljali.

Stepenice kompleksnosti

Kako nailazimo na stepenice kompleksnosti tako svi problemi koje smo dosada smatrali ekstremima postaju svakodnevni, a dobivamo nove ekstremne probleme kompletno novih dimenzija. Odjednom load-balancing web servera više nije nešto posebno, sada moramo početi razmišljati o load-balancingu baza, pa o sinkronizaciji različitih DB servera, pa o propusnosti mreže i firewalla i tako dalje do sljedeće stepenice. Tehnički dio je samo jedan dio problema, ali postoji i procesno-organizacijski dio problema, da li znamo organizirati helpdesk, da li znamo skalirati razvoj, da li imamo kompetentne PM, PO, SM-ove, da li znamo raditi s dislociranim timovima...

Kako se naš proces skalira je jednako važno pitanje kao i kako se naša tehnika skalira. Tehnika koja više ne uključuje samo developere već moramo imati ljude za storage, mrežu, servere, čak i šire od DevOps timova. To ide do te mjere da današnji internet giganti (gdje nitko od nas nije niti blizu) ima svoje dizajnere hardware-a koji rade custom hardware samo za njihove potrebe. Sve to samo dodaje dodatnu kompleksnost i pritisak na organizacijske sposobnosti koje se moraju jednako razvijati i transformirati kao i tehnika.

Svi veliki, srednji i mali servisi koji danas postoje na internetu kao Amazon, Google search, Facebook, Youtube što god su prolazili kroz isti proces i vrlo vjerojatno sadrže ništa do malo originalno napisanog koda, neki od njih nemaju više niti originalno ime pod kojim su pokrenuti, neki su pisali svoj vlastiti transpiler za PHP jezik, većina njih se susreće i našla je rješenje za probleme koje mi ne možemo niti vidjeti iz svoje pozicije niti ćemo se ikada susresti s njima.

Kako prolazimo kroz te stepenice kompleksnosti pojavljuju se nove stvari dio onih kojih smo se sjetili i dio onih koje nam nikada nisu pale na pamet. 

Odgovor na pitanje

Kada netko na naslovno pitanje odgovori kao iz puške s "Da, naravno" tu nešto ne štima, onaj tko odgovori "Ne" ne zna, ali je barem iskren. Onaj koji čeka objašnjenje ili ima 30 pitanja taj bi nešto mogao znati, taj se puno puta opekao u izradi tako nečega i neće tako olako dati odgovor. Kako mi kao isporučitelji rješenja i naši naručitelji možemo pokušati navigirati kroz cijelu priču tako kompleksnih rješenja?

Svaki puta kada se pred nas postavi zahtjev koji moramo ispuniti, moramo se zapitati puno zašto i nakon toga puno kako i pokušati donijeti odluku koja nas neće dovesti u problem. Kada prepoznamo zahtjeve rješenja moramo ih upariti s našim sposobnostima i pokušati napraviti proof-of-concept  implementacije, nabaviti znanje na tržištu, nabaviti gotovo rješenje, što god možemo da umanjimo svoje slabosti. Ključno je biti maksimalno pragmatičan i ne upuštati se u avanture na projektima koje vama i korisniku život znače ukoliko to nije apsolutno nužno .

Na površini stvari izgledaju jednostavno pa kada se raspadne neki sustav se može vidjeti puno komentara "pa kako su to uspjeli zeznuti, to je samo xyz, to složim u 5 dana". E kada bi stvari bile tako jednostavne. Isti stav postoji i kod reinventinga rješenja koje već postoje na tržištu, naš developerski ego smatra da mi to možemo napraviti u 12 ili 6 ili 4 mj. i to naravno bolje od drugih koji su to radili recimo 4 godine. Rješavati takve probleme zvuči sexy cool, ali vrlo vjerojatno nismo 3-4 puta pametniji i ne radimo više od ostalih, pa nas takve sexy cool stvari dovedu u probleme koji nisu jednostavno rješivi, a naručitelj čeka i gubi povjerenje.

Onaj tko zna raditi kompleksne sustave zna svoje jake i slabe strane, spreman je bez ega i razmišljanja "što ako netko vidi da mi to ne znamo", priznati da ne zna, vjerujte vidjeti će se da ne znate prije ili poslije. S takvim znanjem možemo se pripremiti da će biti problem sve ono što smo pretpostavili pa još toliko što nismo pretpostavili i zajedno s naručiteljem možemo ići na novu stepenicu.

Gdje smo mi?

Mi stalno mozgamo o tome kako savladati sljedeću stepenicu. Da li mi znamo raditi kompleksan software? Možda, koji su zahtjevi?

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone benchmark BI BI projekti Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection dinamička forma dinamički parametri dinamički query distribuirani razvoj Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban king KING ICT Kingovci Knockout kvaliteta lambde leadership Lean legacy code M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs oblikovni obrasci OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing overengineering paginacija Performance performanse PERT PMI PMP; Agile; Project management; Scrum; KING ICT; razvoj; metodologija podatkovni skup pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima refaktoriranje Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg tdd Team team building team development Team Foundation Server tech tehnologije terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica underengineering unit testing Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web Zagreb STC

PRIJAVA NA NEWSLETTER

Najnovije novosti iz ICT svijeta