Portaaleja sinulle ja minulle

Katselin tänään pitkästä aikaa missä eri portaalitoteutukset menevät ja millaisia kehitysaskeleita portaaliteknologiat ovat ottaneet eteenpäin sitten Alma-projektin aloituksen. Ja ennen kuin lopetat tämän postauksen lukemisen sen takia, että ajattelet että portaalit ovat mennyttä kauraa – eikä niillä ole mitään tarjottavaa yliopistolle, pyydän sinua odottamaan vielä hetken ja palaamaan ajassa taaksepäin.

Mikä olikaan – ja on edelleen – portaalien viehätys? 

Portaalit tulivat ihmisten tietoisuuteen ja maailmalle esiin tilanteessa, jossa ihmiset yrityksissä ja muissa organisaatioissa joutuivat kamppailemaan kymmenien erilaisten tietojärjestelmien, tietokantojen ja tietolähteiden kanssa. Jokaisessa niistä oli luonnollisesti erilaiset käyttöliittymät, käyttölogiikka ja monesti myös eri käyttäjätunnukset. Portaaleista tarjottiin ratkaisua tilanteeseen, portaalin yhdistäessä sovellukset ja tietolähteet yhteiseen ympäristöön ja yhtenäisiin käyttöliittymiin. Ylläpitäjille, kehittäjille ja IT-johtajille portaalit tarjosivat helpotusta ympäristön parempana hallittavuutena ja erilaisten käyttöympäristöjen sekä tunnusten vähenemisenä.

Unelma ja tavoitteet eivät kadonneet minnekään, mutta toisaalta portaalit eivät myöskään lunastaneet lupauksia kaikkien mielessä. Portaaleista tuli möhköfantteja ja monimutkaisia kokonaisuuksia, joita käyttäjät eivät tykänneet käyttää.

Google ja muut kehittyvät verkkopalvelut muuttivat maailmaa – ja toisaalta myös nostivat tasoa jota verkkosovelluksilta voidaan vaatia. Verkkosovelluksista tuli entistä responsiivisempia käyttäjien operaatioille, kiitos Ajax-teknologioiden. Mashup-teknologiat aina RSS-feedeistä lähtien todistivat että portaalien ideat voidaan kuin voidaankin toteuttaa, ja oikein tehtyinä käyttäjät rakastavat käyttää niitä.

Omalla kohdallani käytän melkein päivittäin paria eri portaalisovellusta, joista tärkeimpänä on Netvibes-niminen  eri uutisfeedejä yhdistävä portaali. Netvibesin läpi luen kaikki tärkeimmät uutiset useista kymmensitä eri lähteistä – miltä tahansa internettiin yhdistetyltä tietokoneelta. Käyttöliittymä toimii näpsäkästi, voin helposti drag & droppailla portletteja paikasta toiseen, esimerkiksi sen mukaan mitkä asiat kiinnostavat minua minäkin hetkenä enemmän.

Netvibesin ympärillä on oma pieni ekosysteeminsä, jossa sovelluskehittäjät voivat toteuttaa Netvibes-portaalissa  ajettavia portaaleja, tai vastaavasti jakaa halutun sisällön ATOM tai RSS-feedinä, jotta käyttäjät saavat tiedon käyttöön portaalissa. Ei mitään uutta, mutta se toimii – vaikka se onkin portaali.

Portaalien vastaisku – toimivia Java-teknologioita oikeaan tarpeeseen

Portaaleita ei siis olekaan tarve kuopata, vaan kannattaa katsoa uusin silmin miten portaalien ajatukset olisi parasta toteuttaa nykyaikana. Java-ekosysteemissa rakastetaan standardeja, yhteisiä sopimuksia, sillä ne mahdollistavat yhteistoiminnan yli toimittajarajojen ja teknologiapinojen, yhdistämään parhaita paloja eri toimittajilta ja toiaalsta täydentämään tai korvaamaan paloja avoimilla ratkaisuilla silloin, kun ne ovat parhaita vaihtoehtoja.

Portaalimaailmaan liittyy muutama oleellinen standardi, joista on hyvä olla tietoisia.

JSR-168 ja JSR-286  ovat  Java-maailman tärkeimmät portaalispeksit, sillä ne määrittelevät miten portaali – eli se ympäristö joka ottaa sovellukset sisäänsä – toimii ja keskustelee yhdessä portlettien – portaaliin tulevien sovelluksien – kanssa. JSR-168 on vanhempi speksi, mutta tarjoaa pohjan siihen mikä on portletin ja portaalin suhde. JSR-168:n on kuitenkin syntynyt aikana, jolloin www-sovelluksien uusia ominaisuuksia — tärkeimpänä ajax:in hyödyntäminen – ei vielä tunnettu, joten uudempi speksi JSR-286 täydentää sitä muutamalla merkittävällä laajennuksella.

Portaalissa joka tukee JSR-286 -speksin mukaisia portletteja, on mahdollista tehdä todella näpsäkästi toimivia portletteja, jotka päivittävät dynaamisesti omaa sisältöään java-scriptin avulla – ja osaavat kommunikoida toisten portlettien kanssa. Samalla sivulla olevat portletit voivat esimerkiksi reagoida siihen, että valitset toisessa portletissa organisaatiorekisteristä tietyn yksikön – ja näyttää sinulle automaattisesti esimerkiksi puhelinluettelossa ko. yksikön tiedot ja kolmannessa vaikkapa kaikki serverit, jotka on konehuoneessa rekisteröitä ko. yksikön käyttöön.

Pretty neat.

Alma ja sähköinen työpöytä 

Portaaliajatukset tulevat jollain tasolla olemaan varmasti mukana myös sähköisessä työpöydässä, joten niiden teknologioiden ja periaatteiden opiskeleminen ei  mene missään tapauksessa hukkaan. Alman kanssa epäonnistuimme siinä, että Alman merkitystä, tarkoitusta ja hyödyntämismahdollisuuksia ei koskaan käyty kunnolla läpi yliopiston eri ohjelmistokehittäjien tai toimittajien kanssa. Toisinsanoen vaikka Almaa ajateltiin integraatiopisteeksi sisällölle ja sovelluksille, on se jäänyt monessakin mielessä yksinäiseksi saarekkeeksi.

Tätä virhettä ei ole varaa tehdä enää uudestaan, ja yksi tapa lähteä liikkeelle siinä onkin parantaa Alman tilannetta – eli tehostaa sitä kuinka Almaan tuotetaan uusia sovelluksia. Alma toteuttaa tällä hetkellä suurimman osan JSR-168 – speksistä ja suunnitelmissa olisi toteuttaa ennen pitkää speksi kokonaan sekä samalla myös JSR-286-speksi. Vaatii kuitenkin aikaa, kunnes muutokset on tehty ja toiminnassa – mutta jo ennen sitä itse portlettien tekemistä on helppo harjoitella ja tehdä uusiin sovelluksiin valmiiksi myös portlet, jonka kautta ainakin päätoiminnot voidaan suoraan Almassa.

Sunin OpenPortalin portlet container täytttää sekä JSR-168 ja JSR-286 speksit, ja sisältää www-sovelluksen jonka avulla  portletteja voidaan testata aivan kuin ne olisivat portaalissa. Allaolevasta linkistä löytyy esimerkki uusista ominaisuuksista portlet-speksissä – sekä linkit eteenpäin kuinka asentaa portlet container Glassfishiin ja kokeilla portletteja.

http://java.sun.com/developer/technicalArticles/J2EE/sdk_portletcontainer2/ 

Jossain vaiheessa kevättä tai muuten tämän vuoden aikana olisi tarkoituksena pitää vielä ohjelmistotuottajien kesken workshoppia, jossa voimme kokeilla ja harjoitella asioita yhdessä – sekä tietenkin  keskustella siitä että mitä sähköisen työpöydän pitäisi tarkoittaa ohjelmistotuotannolle yliopistolla tulevaisuudessa.

Sitä ennen käsittelen asioita myös tulevissa blogipostauksissa.

Ehkä jopa esimerkein, jos sellaisille olisi kiinnostusta.

Palveluarkkitehtuurin komponentteja

Olemme saaneet viimein liikkeelle vakiointi-projektin tärkeän osa-alueen, integraatioarkkitehtuurin määrittelemisen. Integraatioarkkitehtuurilla käsitämme useita eri komponentteja, jotka muodostaisivat tulevaisuudessa pohjan yliopiston palveluarkkitehtuurille, eli käytännönläheisimmin

kuinka tietojärjestelmät keskustelisivat ja vaihtaisivat tietoja keskenään, sekä kuinka tietojärjestelmien tarjoamia toiminnallisuuksia olisi mahdollista yhdistää kokonaan uusiksi palveluiksi.

Mutta mikä meitä kiinnostaa palveluarkkitehtuurissa?

Pitämissäni esityksissä ja workshopeissa olen yrittänyt tiivistää meidän tarpeita ja ajatuksiamme seuraaviin virkkeisiin.

Hyötyä paremmin tehdyistä investoinneista

Toteuttamalla tietojärjestelmiä monoliittisten isojen kokonaisuuksien sijaan myös pienemmissä osissa – ja paljastaen niiden toiminnallisuuksia muille järjestelmille uudelleenkäytettävinä palveluina, voidaan välttää samojen toiminnallisuuksien tekeminen useaan kertaan ja hyötyä jo tehdyistä investoinneista paremmin.

“Ympäristön hallittavuuden, ketteryyden ja elinkaarikustannuksien hallinnan parantaminen siilojen
purkamisella”

Isot tietojärjestelmät eivät määritelmän mukaisesti ole kovin ketteriä. Palveluarkkitehtuurilla toivomme pystyvämme lisäämään ketteryyttä ympäristöömme ja samalla pienentämään järjestelmien kehittämiskustannuksia. Kun tulevaisuuden tietojärjestelmiä ei enää kehitetäkään siiloajattelulla, pystytään niiden elinkaarta myös hallitsemaan paremmin ja käyttämään tai uudistamaan niistä vain niitä osia, joita oikeasti tarvitaan.

Läpinäkyvyyttä ja hallittavuutta prosesseihin

Hallitsemalla yli tietojärjestelmien kulkevia prosessej, ja toisaalta siirtämällä prosesseja myös ulos yksittäisistä tietojärjestelmistä, saadaan aikaiseksi läpinäkyvyyttä ja hallittavuutta toimintaan. Enää ollakaan kiinnostuneita pelkästään tiedosta, vaan myös prosessista johon tieto liittyy.

Yhdenmukaisuutta ja hallittavuutta tietovirtoihin

Jotta järjestelmät voivat keskustella toistensa kanssa, pitää meillä olla jokin yhteinen näkemys siitä mitä asiat ovat ja mitä ne tarkoittavat. Tämän takia osana palveluarkkitehtuuria tulemme myös paremmin määrittämään yliopiston yhteisen käsitemallin ( domain model ) , jota tulevaisuudessa kaikki tehtävät sovellukset noudattavat.

Koska meidän käsitemallimme ei tule olemaan sama kuin esimerkiksi SAP:n tai muiden valmisohjelmistoja toimittavien tietotekniikkatalojen käsitemallit ovat, on integraatioarkkitehtuurin tehtävänä sovittaa yhteen näitä käsitemallien eroja – ja toimia tulkkina välissä.

Yhtenäistää sisäiset ja ulkoiset kehitystavat

Palveluarkkitehtuurin tarjotessa meille yhteiset raamit kuinka järjestelmät tarjoavat palveluita muiden järjestelmien käyttöön, ja kuinka loppukäyttäjille palveluita tehdään esimerkiksi portaaleissa tai työpöydällä käytettäväksi, on meidän helpompa yhtenäistää toimintatapoja joita käytämme yliopiston sisällä ohjelmistokehityksen johtamiseen sekä ohjelmistokehityksen ostamiseen yliopiston ulkopuolelta.

Suurempi hyöty sisäisistä kehitysresursseista

Keskittämällä kehitysresurssit tiettyihin alustoihin ja ratkaisuihin, saamme myös enemmän hyötyä irti yliopiston sisäisitä kehitysresursseista. Tällä hetkellä kehitystyötä tehdään ja ylläpidetään usealla eri kehitysalustalla, mikä hankaloittaa asioiden uudelleenkäyttöä kun mitään yhteistä rajapintaa järjestelmien ja kehitysympäristöjen välillä ei ole.

Ajatukset palveluarkkitehtuurista eivät sinällään ole uusia. Olemmehan me tietotekniikka-alalla puhuneet jo vuosia uudelleenkäytettävyydestä ja toiminnallisista komponenteista. Ja aikojen saatossa samoja ajatuksia on pyritty toteuttamaan monilla erilaisilla teknologioilla ja ratkaisuilla.
Ensimmäisinä tehtävinämme olemme aloittaneet tutustumisen markkinoiden ja työkalujen nykytilanteeseen, sekä lähteneet määrittelemään tarkemmin visiota – kuvausta tahtotilasta jonne haluaisimme olla menossa.

Tulevissa postauksissa kerron tarkemmin kuinka työ edisty ja miten mallinnamme eri asioita.

Luvassa mm. tarinointia workshopeista Sun Microsystemsin ja Bea:n kanssa.

Haen, haen – mutta löydänkö koskaan

Enterprisey.

Olemme osana Yliopistolaisen sähköistä työpöytää ( also known as intranet 2010 ) tutustuneet jonkun verran isojen toimijoiden tarjoamiin haku- ja tiedon hallintaratkaisuihin. Siinä missä aikaisemmin näkökulmana ja ratkaisujen lähtökohtana oli tiedon saaminen yhden sisällönhallintajärjestelmän sisään, nykypäivänä yhä useammin tunnustetaan että todellisessa maailmassa joudumme elämään useiden kilpailevien järjestelmien kanssa ja meidän on pystyttävä hallitsemaan sekä löytämään tietoa niistä kaikista.

Olemme katsastaneet lyhykäisesti Googlen search appliancen, Fast-searchin sekä Autonomyn tarjonnan – ja loppujen lopuksi emme ole juurikaan viisaampia kuin aloittaessamme. Siinä missä sisällönhallintajärjestelmien hinnat ovat laskeneet kilpailun ja avoimien vaihtoehtojen parantumisen myötä, on hakumaailma vielä hyvin pitkälle propietary-maailmansa ja se näkyy ja tuntuu myös hinnoissa. Serach appliancea lukuunottamatta keskustelut lähtevät liikkeelle helsinkiläisen kaksion hinnoista.

Tosin huomioitavaa on, että hakumaailmassa ollaan siirrytty jo paljon eteenpäin pelkistä asiasana-hauista ja ratkaisut pyrkivät olemaan todellisia moottoreita organisaation tiedon hallintaan, ymmärtäen parhaimmillaan viestien sisältöä, yhdistäen tietoa muuhun indeksoituun tietoon ja tarjoten uudenlaisia mahdollisuuksia käsitellä tietoa eri järjestelmien ja varastojen rajojen yli.

Vaikka ratkaisut ovat vielä nyt kalliita, antavat ne jo nyt hyvin viitteitä siitä mihin maailma on menossa.  Ehkä samanlaiset toiminnot ja ominaisuudet rakentuvat vielä joskus myös Apache Lucene-projektin ympärille. Kukapa sen tietää.

Agile leadership

Mary Poppendieck piti Agile 2007-konferenssissa loistavan esityksen ohjelmistokehityksen johtamisesta.

Katso se täältä.

Esitys on samalla hyvä yhteenveto johtamisnäkökulmien kehityksestä kautta aikojen.

Service centric IT

http://blogs.sun.com/mikejude/entry/service_centric_it

” The key to managing the awareness of corporate decision makers is to ensure that these decision makers are engaged as customers of an internally provided service offering. This is not simply the notion of a service level agreement that is merely adhered to, it is an active service engagement where the customer is provided value added services and where there is a constant attempt to “up sell” the client on additional services.

This active service dynamic is pretty much a foreign notion to much of IT. IT understands service levels, but generally only actively engages corporate decision makers at the end of the year when budgets are being drawn up.

As a service provider, IT should use every customer contact as an opportunity to either assess the value perception of the user or to enlist that user as an agent for increased service offerings and an increased budget to support them.

Instead of a service desk call where the customer’s complaint is noted and a time for resolution is given, there ought to be an active engagment that seeks to more than satisfy the client and attempts to add features to the service offering.

Of course, this means that the operation group should have more than one level of service and should tie that service level the level of funding coming from the client’s organization. And, of course, IT funding needs to be line driven rather than corporate overhead driven.

If, however, IT does move to a service centric approach, it will not only have an incentive to get really good at service delivery and definition, it will also have a means to increase operations budgets and avoid outsourcing critical business support functions.”

Juurikin näin.

Virtualisointia työpöydälle

Virtualisoinnista on tullut kovaa huutoa monilla markkinoilla, erityisesti kun puhutaan palvelinten konsolidoinnista. Virtualisoinnilla on kuitenkin myös paljon annettavaa myös työpöydällä erilaisille käyttäjäryhmille.

Erilaiset myyntimiehet ja demojen pitäjät ovat jo pitkään käyttäneet virtuaalikoneita demoympäristöinään, sillä mikäs sen parempi kuin ottaa aina evrkkolevyltä mukaan varmasti toimiva ympäristö – jolta asioita voi mukavasti demonstroida ilman verkkoyhteyttä tai pelkoa että joku toinen sotkee samaan aikaan ympäristöä omalla demollaan.

Samalla tavalla ohjelmoijat ja testaavat voivat hyötyä virtuaalikoneista omassa työssään. Ei tarvita enää erillisiä testikoneita, kun erilaisia konfiguraatioita varten voidaan näppärästi ylläpitää yhteisiä virtuaalikoneita. Omalta työpöydältä poistumatta voi tarkistaa miten softa käyttäytyikään vanhemmalla versiolla Windowsia tai kuinka Internet Explorer raiskaakaan uuden ajax-sovelluksesi.

Toisaalta virtualisoinnin avulla on mahdollista myös paketoida kivasti kokonaisia kehitysympäristöjä. Tällaiselle hardcore-mac -käyttäjälle esimerkiksi on hurjan kätevää pystyä pyörittämään Linux-kehitysympäristöä ja Windows-testiympäristöä samassa koneessa. Vmware Fusionin avulla voin tarvittaessa jopa kopioida ko. ympäristöt palvelimelle pyörimään tai pyörittää niitä jollain toisella, tehokkaammalla pöytäkoneella. Ja kaikki tämä tieteknkin hyväksikäyttäen ja nauttien samalla OS X:n muista ominaisuuksista.

Virtualisoinnin myötä toki toiveet prosessorien tehon ja multicoreisuuden suhteen kasvavat, samaten kuin muistitarve ja toisaalta vieno toive nopeaa IO:ta varten. Virtualisointiympäristöt ovat kuitenkin kehittyneet jo niin paljon, että käyttökokemus nykyaikaisella raudalla alkaa olemaan kohdillaan.

Kustannusten kohdentaminen ja palveluiden hinnoittelu kohti hyötypohjaista hinnoittelua?

Maria Ruuskasen johdolla käynnistyi osana IT-2009 -ohjelmaa projekti kustannuslaskennan uudistamiseksi, ja luvassa on vähintäänkin mielenkiintoisia keskusteluita ja ajatuksia – ja ehkäpä jopa perustavaa laatua olevaa mietintää siitä, kuinka me tietotekniikkaosastona näymme asiakkaidemme budjeteissa entistä selkeämmin myöa palveluorganisaationa eikä vain sisäisenä tukipalveluna – eli koko yliopiston kokemana kustannuspaikkana.

Yksi iso haaste on kulttuurin muuttaminen ja luominen sellaiseksi, että pystymme puhumaan erikseen kustannuksien kohdentamisesta ja palveluiden hinnoittelusta. Vaikka kummallakin tarkoitetaan lopulta rahamäärää, jota jostakin maksetaan – on termien lähestyminen asiaan hieman erilainen.

Kustannusten kohdentaminen on sopinut hyvin yhteisille konsernipalveluille, sellaisille palveluille joihin on ollut pakko investoida, mutta kukaan yksinään ei ole halunnut sellaista investointia tehdä. Silloin on pakko keksiä sopiva kustannuksien jakoperuste, esimerkiksi organisaation koon mukaan tai  budjettiosuuden mukaan – ja laskuttaa toteutuneet kustannukset jakoperusteiden mukaan.

Toteutuneiden kustannuksien laskuttaminen on ainakin palveluiden tuottajien kannalta helppo tapa toimia ja joissain tapauksissa myös asiakkaille järkevää. Haittapuolena on, että tuollainen kustannuksien laskuttaminen ei kannusta toimintojen tehostamiseen ja innovointiin – koska kaikki palvelun kustannukset katetaan joka tapauksessa.

Käytön mukaan laskutettavissa palveluissa taas iso kysymys on palveluiden hinnoittelussa. Hinnoittelun takana toki pitää edelleen tietää mitä palvelun tuottaminen oikeasti maksaa, mutta sen lisäksi myös mikä palvelun hinnan pitäisi olla – jotta sitä käytettäisiin. Jos palvelun kustannukset ja oletettu hinta palvelulle eivät ole järkevässä suhteessa toisiinsa, joudutaan kysymään neljä kysymystä:

  1. Tuotammeko palvelun järkevällä ja kustannustehokkaalla tavalla?
  2. Piiloutuuko palveluun jotain hyötyjä jotka kuvaamalla asiakkaat olisivat valmiimpia maksamaan halutun hinnan?
  3. Onko palvelusta mahdollista poistaa toimintoja tai ominaisuuksia, jotta sen hintaa voitaisiin laskea?
  4. Onko palvelu oikeasti hyödyllinen?

Todellisuudessa joudumme kysymään myös muita kysymyksiä, mutta näillä me pääsemme jo hyvin alkuun.

Microsoft-pomo vierailulla HY:ssä

Meillä oli harvinaislaatuinen mahdollisuus keskustella hetken aikaa tänään korkea-arvoisen Microsoft-pomon, Anoop Goptan, kanssa siitä mitä Microsoft on tekemässä korkeakoulumaailmassa ja mitä korkeakoulumaailma Microsoftilta toivoo. Selkeää on, että Microsofilla on kova panostus nyt käynnissä korkeakoulumaailmassa – aivan samalla tavalla kuin julkisella sektorilla muutenkin.

Microsoftin korkeakoulutarjonta rakentuu samojen platformien ja perusteiden päälle kuin muutkin ratkaisut, mutta tavoitteena heillä on pystyä laajentamaan tarjontaa opetussektorille merkitykselliseen suuntaan, esimerkiksi kehittämällä entistä parempia yhteistoiminnan työvälineitä ja opetuksen hallinnan ratkaisuja esimerkiksi Live-, Sharepoint- ja Office-platformien päälle. Visiot ovat hienoja ja siihen suuntaan mitä olemme maailman toivoneen menevän, mutta Microsoft-lisällä.

Puhuimme paljon avoimuuden, yhteentoimivuuden ja yksinkertaisuuden merkityksestä, ja Microsoftin edustajat kertoivat kuulleensa samaa viestiä kyllä riittävästi jo monelta muultakin taholta. Avoimuus ja yhteentoimivuus, samoin kuin ratkaisujen ymmärrettävyys ( riittävä yksinkertaisuus versus järjetön kompleksisuus ) ovat meille – ja monille muille organisaatioille – tärkeitä asioita. Olimme kuitenkin yhtä mieltä siitä, että Microsoft tekee varmasti monia sellaisia asioita – joista meidän yliopistollemme olisi hyötyä, kunhan tietäisimme paremmin mitä ne asiat ovat ja kuinka hyödyntää niitä meidän infrastruktuurissamme omien periaatteidemme mukaisesti.Actionpointiksi tapaamisesta tuli arkkitehtuurityöhön liittyen koota meiltä kasaan joukko henkilöitä, joiden olisi syytä ymmärtää paremmin Microsoftin tarjonta ja sen toimivuus kokonaisuutena sekä joltain eritysosaamisalueelta. Harjoituksen tarkoituksena olisi ymmärtää ja käsittää paremmin Microsoftin stackin merkitys, ja mahdollinen arvo meidän organisaatiollemme – jos hyödyntäisimme siitä osia esimerkiksi sähköisen työpöydän tulevaisuudessa tai muissa hankkeissa.

Vaikkemme Microsoftin teknologioita nykyistä enempää tulevaisuudessa hylödyntäisi, on harjoitus sinällään muutenkin hyvä meille, sillä sitä kautta opimme ymmärtämään paremmin kuinka valtionhallinnossa ja korkeakoulumaailmassa muiden toimijoiden Microsoft-ympäristöt toimivat – ja kuinka voimme rakentaa yhteentoimivuutta niiden kanssa.

Kehittämispäivän poimintoja

Kehittämispäivän videotallennetta katsoessa ( vaatii sähköpostissa tulleen käyttäjätunnuksen ja salasanan ), tulee mieleen erilaisia ajatuksia siitä mihin suuntaan olemme menossa. Osaston koko on kasvanut aikojen saatossa ja tulevaisuuden suuntaviivat alkavat selkeytymään, vaikka vieläkin on paljon keskusteltavaa ja väännettävää siitä miten toimimme tulevaisuudessa paremmin organisaation yksiköiden rajojen yli, ja toisaalta organisaation rajojen yli.

Eija esitteli hyvin ajatuksia siitä miten olemme siirtymässä putiikki-ajattelusta kohti marketti-ajattelua, vaikka vertaus persoonattomaan automarkettiin ei tuntuisikaan mairittevalta. Marketti-analogia on kuitenkin hyvä, sillä markettien taustallahan on hyvin tehokkaasti toimiva tuotanto- ja logistiikkaketju, joka mahdollistaa perustuotteiden laadun ja halvat hinnat – mutta samalla myös erikoistuotteiden ja -palveluiden kehittämisen niitä tarvitseville asiakkaille. Todisteena siitä on esimerkiksi isojen markettien laadukkaat ja hyvin toimivat liha- ja kala-tiskit, joiden veroisia ei aikaisemmin voinut uneksia löytävänsä omasta lähikaupasta. Vaatii ehkä vielä jonkun verran töitä muokata meidän osastomme tarina sellaiseksi, että me kaikki ymmärrämme sen suunnilleen samalla tavalla ja osaamme toimia sen johdattelemana oikein – mutta ei anneta sen häiritä.

Tarinankerronnan lisäksi meillä on paljon opeteltavaa ja kehitettävää asioiden johtamisessa. Vaikka joskus asiantuntijatehtävissä ajatteleekin, että asiat sujuvat aina sitä paremmin mitä kauempana johto on – on johtamisella ja johdolla tärkeä merkitys niin tämän kuin monen muunkin organisaation onnistumisessa tavoitteissaan. Mika Kivilompolo kertoi johtoryhmätyöskentelyn ja johtamisen kehittämisestä, sekä monille meistä jo rakkaan katkerasta Benchmarking-tutkimuksesta.

Benchmarking-tutkimus ja erilaisten kaavakkeiden täyttäminen on saattanut tuntua hankalalta, epämukavalta ja jopa turhauttavalta – ainakin päätellen sähköpostilla tulleista palautteista. Tutkimuksella on kuitenkin eritätin tärkeät tavoitteet, ja vaikka tulokset eivät todellisuuden kannalta olisikaan täysin tarkkoja – pitäisi niiden ainakin riittävällä tavalla antaa meille mielikuvaa ja näkökulmaa siitä mikä on tilanteemme IT-toimintojen suhteen tällä hetkellä.

Liittyen service desk-projektiin ja toimintojen kehittämiseen yleensä, järjestetään marraskuussa toimintojen mittausviikko – jonka aikana yritetään saada mittareille baseline siitä miten paljon tukitoimia ja -pyyntöjä organisaatiomme käsittelee normaalin viikon aikana. Hypoteesihan on, että SD:n käyttöönoton jälkeen tukipyyntöjen ylivuoto organisaation muihin osiin vähenee tai loppuu kokonaan – joten saatuamme jonkun perustason selville, voimme myöhemmin seurata miten hypoteesi oikeasti toteutuu.

Vaikka tällä kertaa ei puhuttukaan mitään tuotteistamisesta ja sen kehittymisestä, puhui Maria Ruuskanen tuotteistamiseen tiukasti liittyneestä asiasta – eli työajan kohdentamisen uudistuksesta. Osana kustannuslaskennan uudistumista pääsemme nimittäin viimein eroon myös Kellokallesta – ja saamme tilalle uuden Sole Time Management -sovelluksen.  SoleTM:ssä työajan kohdistamisen pohjana toimii uusi palveluluettelo, jota on kehitetty tuotteistus-projektin osana. Palveluluettelo kuvaa kokonaisuutena ne osa-alueet, joita meidän toiminnassamme on ja miten niistä puhutaan. Tämä sama rakenne toimii pohjana nyt myös työajan kohdentamisellekin.

Ja loistavaan tyyliinsä päivän yhteenvedon tai lopetuksen tarjosi Pauli Assinen, jonka hämmennysmiehen rooli oli sekä hauska että osuva.

SOA:n ja unixin periaatteiden samanlaisuus

Bongasin seuraavan helmen Sunin blogeista:

For example, the famous “Unix philosophy” characterized by Dr. Doug McIlroy:

Write programs that do one thing and do it well.
Write programs to work together.
Write programs that handle text streams, because that is a universal interface.

can be translated into SOA terms, First, programs are replaced by services. The one thing that a service should do well is the WSDL interface it implements. Then, how to make services work together has become a much more complex problem in the modern computing environment. In addition to input and output data, there are policies between the service consumer and the service provider covering, e.g., messaging, security, and transactional context. Finally, all services should handle XML streams, the universal interface.

http://blogs.sun.com/tientien/entry/the_soa_philosophy_a_new