Taannoin tässä keskustelin työkaverini kanssa tästä IT-alalla jatkuvasti tapahtuvasta abstraktiotasojen nousemisesta,
aikaisemmin oli proseduraalinen ohjelmointi rautaa, tämän jälkeen olioparadigma oli kova sana. Nyt puhutaan
palvelukeskeisestä arkkitehtuurista ja prosessien hallinnasta. Nämä sinäänsä ovat aivan luonnollisia kehityssuuntia,
mutta työ tuskin ainakaan minun elinaikana loppuu miltään abstraktiotasolta. Koodajat puhuvat että arkkitehdit tai
prosessi"ajattelijat" ovat täysin turhia.Eihän se keneltäkään ole pois, eikä IT-arkkitehdit tarkoita että he ovat
hierarkiassa ylempänä vaan että he ainoastaan keskittyvät korkeamman abstraktiotason asioihin. Järjestelmät ovat
vain nykyään niin kompleksisia että tarvitaan joka abstraktiotasolle tekijöitä. Eihän rakennuksen piirtäminen
tarkoita että ei tarvittaisi muurareita, rakennusmestareita yms. Esimerkiksi Javassa on mielestäni tavallaan
onnistuttu hyvin siinä että ajettava koodi on abstratoitu ns."alemman tason" koodista. Niin ettei sovelluskehittäjän
enää tarvitse miettiä pointtereita yms, mutta ei se tarkoita että sillä tasolla hommat olisi täysin kunnossa.
Tarvitaan vain eri osaamisprofiilin omaavia henkilöitä koodaamaan JVM:ää, he huolehtivat omasta osuudestaan ja
sovelluskehittäjä omastaan.
Yksi paradoksi tässä kaikessa vain on... Tarvitaan jatkuvasti enemmän ihmisiä suorittamaan eri rooleja järjestelmien
kehityksessä. Kuitenkin tämä mielestäni on loogista järjestelmien kompleksisuuden kasvaessa. Mikä taas sotii
liiketoiminnan ydintoimintaan keskittymistä vastaan, koska jos liiketoimintaa tukevien järjestelmien kompleksisuus
vaatii paljon työntekijöitä (jotka ymmärtävät esim. kyseisen yrityksen järjestelmien päälle) pitämään näitä
järjestelmiä pystyssä. Voidaanko tätä myöskään ulkoistaa ja jos se ulkoistetaan niin onko se todella hyödyllistä?
Tämän tyyppisiä ajatuksia minulla on herännyt työssäni, olisin kiitollinen mikäli joku kertoisi omia ajatuksiaan...
Ala menee niin vauhdikkaasti eteenpäin ja ennen kuin edellinen ohjelmointiparadigma on edes keritty omaksumaan on
jo toinen nurkan takana. Puhumattakaan teknologioista 90-luvulla Corba:n yms piti ratkaista kaikki ongelmat, tätä
aikaisemmin COBOL oli sen ajan hopealuoti yms. Nyt SOA, BPM ja vastaavat tekevät organisaatioista ketteriä ja
prosesseja voidaan muokata lennossa. Uskoo ken haluaa. Kuitenkin olen tehnyt havainnon että et ole enää soveltuva
esimerkiksi ohjelmoijaksi jos et jaksa opetella uutta ohjelmointikieltä... Yhdessä työpaikassa erään työkaverin
kommentti oli havainnollistava (yritys oli Oraclen tuotteita konsultoiva, pääsääntöisesti asioita oli tehty
PL/SQL:llä): "Ei kai meidän tarvitse alkaa opetella mitään Javaa". Mielestäni kyllä, ja sen jälkeen jotain muuta.
Kun olet esim. Javan opetellut voitkin jo pikkuhiljaa alkaa opettelemaan esim. BPEL:l ;)
Tässä vain tämmöistä jäsentelemätöntä ajatuksenvirtaa, kirjoittakaa omaa ajatuksenvirtaa aiheeseen (tai aiheen
viereen) liittyen.
aikaisemmin oli proseduraalinen ohjelmointi rautaa, tämän jälkeen olioparadigma oli kova sana. Nyt puhutaan
palvelukeskeisestä arkkitehtuurista ja prosessien hallinnasta. Nämä sinäänsä ovat aivan luonnollisia kehityssuuntia,
mutta työ tuskin ainakaan minun elinaikana loppuu miltään abstraktiotasolta. Koodajat puhuvat että arkkitehdit tai
prosessi"ajattelijat" ovat täysin turhia.Eihän se keneltäkään ole pois, eikä IT-arkkitehdit tarkoita että he ovat
hierarkiassa ylempänä vaan että he ainoastaan keskittyvät korkeamman abstraktiotason asioihin. Järjestelmät ovat
vain nykyään niin kompleksisia että tarvitaan joka abstraktiotasolle tekijöitä. Eihän rakennuksen piirtäminen
tarkoita että ei tarvittaisi muurareita, rakennusmestareita yms. Esimerkiksi Javassa on mielestäni tavallaan
onnistuttu hyvin siinä että ajettava koodi on abstratoitu ns."alemman tason" koodista. Niin ettei sovelluskehittäjän
enää tarvitse miettiä pointtereita yms, mutta ei se tarkoita että sillä tasolla hommat olisi täysin kunnossa.
Tarvitaan vain eri osaamisprofiilin omaavia henkilöitä koodaamaan JVM:ää, he huolehtivat omasta osuudestaan ja
sovelluskehittäjä omastaan.
Yksi paradoksi tässä kaikessa vain on... Tarvitaan jatkuvasti enemmän ihmisiä suorittamaan eri rooleja järjestelmien
kehityksessä. Kuitenkin tämä mielestäni on loogista järjestelmien kompleksisuuden kasvaessa. Mikä taas sotii
liiketoiminnan ydintoimintaan keskittymistä vastaan, koska jos liiketoimintaa tukevien järjestelmien kompleksisuus
vaatii paljon työntekijöitä (jotka ymmärtävät esim. kyseisen yrityksen järjestelmien päälle) pitämään näitä
järjestelmiä pystyssä. Voidaanko tätä myöskään ulkoistaa ja jos se ulkoistetaan niin onko se todella hyödyllistä?
Tämän tyyppisiä ajatuksia minulla on herännyt työssäni, olisin kiitollinen mikäli joku kertoisi omia ajatuksiaan...
Ala menee niin vauhdikkaasti eteenpäin ja ennen kuin edellinen ohjelmointiparadigma on edes keritty omaksumaan on
jo toinen nurkan takana. Puhumattakaan teknologioista 90-luvulla Corba:n yms piti ratkaista kaikki ongelmat, tätä
aikaisemmin COBOL oli sen ajan hopealuoti yms. Nyt SOA, BPM ja vastaavat tekevät organisaatioista ketteriä ja
prosesseja voidaan muokata lennossa. Uskoo ken haluaa. Kuitenkin olen tehnyt havainnon että et ole enää soveltuva
esimerkiksi ohjelmoijaksi jos et jaksa opetella uutta ohjelmointikieltä... Yhdessä työpaikassa erään työkaverin
kommentti oli havainnollistava (yritys oli Oraclen tuotteita konsultoiva, pääsääntöisesti asioita oli tehty
PL/SQL:llä): "Ei kai meidän tarvitse alkaa opetella mitään Javaa". Mielestäni kyllä, ja sen jälkeen jotain muuta.
Kun olet esim. Javan opetellut voitkin jo pikkuhiljaa alkaa opettelemaan esim. BPEL:l ;)
Tässä vain tämmöistä jäsentelemätöntä ajatuksenvirtaa, kirjoittakaa omaa ajatuksenvirtaa aiheeseen (tai aiheen
viereen) liittyen.
Vastaukset 5
Vanhimmat
Kuule, itse IT-arkkitehtinä töitä tekevänä olen aika paljon joutunut tekemisiin ton "korkeamman tason" abstrahoija porukan kanssa.
Useimmat niistä on ei-minkään-alan-tai-asian osaajia. Ihmisiä, jotka vaan touhuttaa kovalla IT-alan palkalla jotain höpöä eikä osaa edes rivin vertaa koodia vääntää.
Osa noista arkkitehdeiksi itseään tituleeraavista ei ole edes Visual Pasikkiä nähnyt. Osa on koodannut joskus 30 vuotta sitten kun COBOL oli vielä kova sana ja uunituore uutuus.
Ei kaikkien toki tartte olla koodareita, mutta kyllähän se AUTTAISI, jos päävastuullinen järjestelmädisainer olisi edes vähän kärryillä siitä teknologiasta millä hommat hoidetaan....sen rajoitteista ja ominaisista piirteistä.
IT-arkkitehdeistä aika iso osa ei osaa myöskään sitä businessaluetta hyvin tai edes jotenkuten huonosti, että siitä tulisi fiksuja systeemejä. Se olisi toki olemassa olon oikeus, jos osais Businees Process Reengineeringin pätevästi ja sille sitten väännättäisi systeemit. Mutta eipä ole vielä sen tason hemmoa vastaan tullut tällä alalla....on ilmeisesti neonvihreää korppiakin harvempi otus.
Tarkoitan lähinnä että siihen on tarvetta, se mikä ammattitaito nykyisillä "arkkitehdeilla" on. Lisäksi onko itse järjestelmän määrittely/suunnittelu muuttunut niin paljon? UML-mallinnus ja ER-mallinnus loppujen lopuksi on aika sama asia. Jos itse jaksat jatkuvasti opetella uuden ohjelmointikielen/paradigman joka toinen vuosi onnittelen, mutta jos tänä päivänä teet SOA paradigman mukaisen järjestelmän se on jo muutaman vuoden päästä vanhentunut ja juuri tekusta valmistuneet insinörtit naureskelevat sille. Niin se vain menee... 90-luvulla väännettiin otsahiessä CORBA-järjestelmiä, nyt nauretaan miksi nähty moinen vaiva kun Web Serviisillä homma hoituu paljon helpommin.
Mielestäni "arkkitehtien" pitäisi keskittyä bisnesalueeseen ja ns. business framework:keihin (esim. BPM, CMMI yms. Business Process Reengineering on "SO LAST SEASON").
Muuten "Visual Pasik":han on myös aika "SO LAST SEASON" eihän se ole edes puhdas oliopohjainen-kieli... ;)
Otetaan nyt vielä yksi esimerkki mitä tarkoitan korkeamman abstraktion "arkkitehdeista" tai ihan miksi haluaa näitä nimittää... Yritysten taloushallinto ja niihin liittyvät järjestelmät ovat olleet IT:n kehityksen kohteina varmaan niin kauan kun tietotekniikkaa on yrityksissä ollut. Silti taloushallinnon prosessit eivät ole vieläkään sillä tasolla kun voisi olettaa. Esim. tilauksesta maksatukseen prosessi. Jos yritys tekee tilauksenhallintajärjestelmästä tilauksen, ei ole mitenkään poikkeuksellista että tätä ei pystytä ostoreskontrassa yhdistämään ostolaskuun. Yritystä ei pahemmin kiinnosta väännetäänkö koodi C:llä, Javalla, PL/SQL:llä vai Visual Basic:lla kunhan tehty tilaus voitaisiin yhdistää ostolaskuun. Miksi yritystä kiinnostaisi tai pitäisi kiinnostaa? Kuitenkin tarvitaan ihminen joka ymmärtää tietotekniikasta jotain ja ihminen joka osaa tehdä tarvittavan toteutuksen. Vai pitäisikö koodarin ymmärtää taloushallinnon, alla olevien järjestelmien ja (mikä nyt sattuukaan olemaan) käytettävä ohjelmointikieli päälle? Jos näin on niin koodareiden osaamisessa on todella suuri aukko? Jokaisen koodarin tulee näin osata ainakin muutama ns. "business" alue, kuten esim. logistiikka ja taloushallinto. Tämän lisäksi muutama ohjelmointikieli?
Eikö fiksumpaa olisi jakaa tekeminen rooleille jossa jokainen tekee oman osa-alueensa?
...eli ihan kummia mietit.
***
Se on tämä koodimaailma ihan samanlaista kuin mikä muukin tässä pienoisessa muurahaispesässämme; kukin puuhastelee omiaan ja sitten aina välillä joku kantaa oikean korren oikeaan kohtaan kekoa.
Noin ovat asiat aina tapahtuneet ihmiskunnassa ja niin tapahtuu vast'edes.
Kiva tietenkin että asiasta pystyy filosofioimaan, mutta miksi filosofioida abstraktista?
Eli turhia mietit, tulee päivä jolloin joku painaa suurille saavutuksillesi delete, ei mitään uutta auringon alla.
Tottakai, näin on... Mutta tämä vain olikin tajunnanvirtaa, mutta jos jatkuvasti järjestelmät monimutkaistuvat niin eikö tarvita ihmisiä jotka edes yrittävät ajatella kokonaisuutta? Se on asia erikseen. Varsinkin nykyisin jos teet hienon SOA-järjestelmän kaikkine kilkkeineen se on jo vanhentunutta teknologiaa muutaman vuoden kuluttua ja sille lähinnä nauretaan.