About Jukka Uusisalo

Systems Architect and Software Samurai

Nimikkeistä käsitteisiin ja kirahvin kautta takasin

Tällä foorumilla on varsin usein pohdiskeltu sitä, mikä on nimike ja mitä tarkoittaa nimikkeellistäminen. Samojen ajatuskulkujen syövereihin ajauduin eräänä päivänä PDM-saarnamiehemme  ja toisaalta omien lasten ajatuskulkuja seuratessa. Omalla tavallaan molemmat aiheuttivat innostusta, joskin toisessa tapauksessa oli myös twisti harmaiden hiusten ja vatsahaavan pariin. Lukija voi itse päätellä kummassa tapauksessa näin kävi.

Aiemmin on todettu, että nimike on asia, jolle voidaan antaa yksilöivä tunnus, nimi, kuvaus ja erilaisia attribuutteja kuvaamaan nimikkeen ominaisuuksia.

Nimikkeellistettäessä sovitaan ja määritellään tavat ja käytännöt koodituksille, nimien ja kuvausten muodostamiselle ja määritellään eri nimikkeiden tarvitsemat attribuutit.

Kapasitanssi on tarpeeton tieto mutterille, mutta kondensaattorille varsin keskeinen. Toisaalta myös perspektiivi nimikkeeseen vaikuttaa nimikkeen mallinnukseen. Oston ja myynnin tiedot saattavat hyvinkin erota siitä tietotarpeesta, mikä suunnittelulle ja valmistukselle on olennaista tietoa. Nimikkeellistettäessä yrityksen tuotteet (myymät, ostamat, valmistamat, suunnittelemat) mallinnetaan liiketoimintaprosesseja varten.

Onko nimikkeellistämisellä ja käsitteellistämisellä ja käsitemalleilla sitten jotain eroa toisiinsa nähden? Sovelluskehityksen piirissä tehdään käsitemalleja ja kuvauksia käsitteistä, joita ratkaistavassa ongelmakentässä esiintyy. Selvitetään käsitteiden suhteita toisiinsa, käsitteisiin liittyviä ominaisuuksia ja attribuutteja. Tätä analogiaa seuraten voidaan väittää, että minkä tahansa asian voi nimikkeellistää. Kun määrittelytyötä tehdään, on tietysti olennaista ymmärtää mikä on se entiteetti, jota ollaan kuvaamassa.

Nuoremman tyttären kanssa usein automatkoilla tms. pelataan eläinarvoituksia. Siinä toinen antaa vinkkejä ja toinen koittaa arvata mikä eläin on kyseessä. Mikä on sellainen, jolla on pitkä kaula, pilkkuja ja neljä jalkaa? No kirahvihan se.

Kirahvikysymys

Mallintamisessa tehdään samaan tyyliin. Tunnistamme entiteetin ominaisuuksia ja attribuuttien tyypillisiä arvoja ja sen perusteella voidaan päätellä mistä oikein on kysymys. Tämä toimii varsinkin silloin, kun mallinnetaan asioita, joille on tosiolevainen vastine reaalimaailmasta. Joskus ongelmakenttää mallinnettaessa ratkaisun aikaan saamiseksi täytyykin käsitemalliin lisätä entiteetti, jolla ei olekaan konkreettista vastinetta reaalimaailmassa tai reaalimaailman vastine on hyvin abstrakti. Esimerkkinä näistä ovat tyypillisesti sovelluksissa käytetyt, koosteita esittävät käsitteet, kuten tuoteryhmä, hintaryhmä tai projektiryhmä. Ilman tietoa kontekstista ei voi päätellä, tarkoittaako projektiryhmä jollain kriteerillä ryhmiteltyä projektien joukkoa, vai projektiin osallistuvien henkilöiden muodostamaa ryhmää. Se millaisia attribuutteja tässä projektiryhmälle tarvitaan riippuukin siitä, kumpi käsitys projektiryhmästä on kyseessä.

Laajoja kokonaisuuksia mallinettaessa syntyy paljon näitä abstrakteja käsitteitä, jotka ovat alttiita virheellisille tai ainakin erilaisille tulkinnoille. Tätä ongelmaa ratkaistaan usein terminologisella sanastotyöllä, luodaan sanakirja ko. ongelma-alueen käsitteistä ja termeistä ja näin saadaan yhteinen ymmärrys nämä projetiryhmän kaltaiset abstraktiot tässä tilanteessa tarkoittavat. Suora analogia nimikkeiden maailmassa löytyy yrityksen sanakirjasta, corporate dictionary. Tämä sanakirja identifioi ja selittää yrityksen nimikkeistössä käytetyt termit ja mahdollisesti tarjoaa yrityksen käyttämät käännökset eri kielille. Toisaalta ostajan ja myyjän välillä olisi syytä olla yhteinen käsitys termistöstä tai tilaajan ja alihankkijan välillä. Yhtenäiset käännökset helpottavat tai jopa mahdollistavat nmikkeistön harmonisoinnin eri kielialueiden välillä.

PDM Preacher Jukka S mainitsi eräässä blogi-kirjoituksessaan vaatimusten nimikkeellistämisestä. Vaatimushan on myös abstraktio, joka täytyy mallintaa kontekstin mukaan. Kun vaatimus mallinnetaan tai nimikkeellistetään, luodaan vaatimustenhallinnan perusteita.  Vaatimus voi esiintyä käsitteenä kun asiaa tarkastellaan tuotekehityksen, muutoshallinan tai laadun varmistuksen silmin. Toisaalta vaatimusten hallinta voi olla myös näkökulmansa edellämainituihin. Kaikki kuitenkin liittyvät toisiinsa ja ehkä tässäkin kannattaa nousta helikopterin kyytiin ja katsoa tarkemmin missä kaikissa prosesseissa vaatimus oikeastaan esiintyy ja missä prosesseissa tieto vaatimuksista olisi hyödyllinen.

Nämä kaikki innoittavat ajatukset saivat kuitenkin täysin aivan uuden ulottuvuuden kun samana päivänä tulin töistä kotiin ja kohtasin aivan uudenlaiset vaatimusten maailman varhaisteini-ikäisen tyttäreni taholta. Vastassa oli vaatimusten big dataa, joiden luokittelutekijät olivat täysin portaattomia n-uloitteisessa avaruudessa. Huusin avukseni sumean logiikan ratkaisuja ja kvanttikoneita. Onneksi lopulta ratkaisu oli kuitenkin varsin yksinkertainen, Spagetti Bolognese. Maslovin tarvehierarkiaa kannattaakin vaatimustenhallissa kunnioittaa.

– Software Samurai –

Seitsemän kuolemansyntiä

Hyllystä tarttui käteen vanha kirja ”Anti-patterns: Refactoring Software, Architectures, and Projects in Crisis”. Varsinkin ohjelmistokehityksen parissa työskentelevän kannattaa tähän perusteokseen tutustua, sieltä saattaa löytyä syitä kävellä tuijottamaan itseään vessan peilistä.

Kirjassa esitellään ongelmien perimäisiksi aiheuttajiksi seitsemän kuolemansyntiä. Voisiko näistä perisynneistä johtaa myös järjestelmähankkeiden ongelmien syitä?

7 sins

1. Kiire

Kiirehän on aina, deadline jyskyttää päälle koko ajan. Tietysti hyvin suunniteltu aikataulutus tuo projektille tarvittavaa ryhtiä. Synniksi kiire muuttuu siinä vaiheessa, kun tehtäville ei anneta niiden vaatimaa aikaa ja puristetaan hatusta vedettyyn aikatauluun taskit kohdalleen luottaen tekijöiden sankarillisiin yksilösuorituksiin. Tälläinen toimii kerran ja kaksi, ehkä kolmekin jos tekijää oikein kehutaan, mutta sitten se on siinä.

2. Välinpitämättömyys

Välinpitämättömyys voi ilmetä monellakin tavalla. Esiintuleva ongelma siirretään syrjään analysoimatta sen kriittisyyttä, koska se ei oikein tunnu osuvan kenenkään osapuolen vastuualueelle. Toimintatavoissa on ongelmakohtia, mutta muutosta ei saada aikaan , koska ’aina on tehty näin’.

3. Ahdaskatseisuus

Ahdaskatseisuus ja näköalattomuus johtuu pitkälti muutoksen pelosta. Järjestelmähankkeet, yllättäen, aiheuttavat usein muutoksia. Muutoksen pelko aiheuttaa usein tunnepohjaista vastustusta, pelkoon reagoidaan vihamielisesti. Jos jättää muutosvastarinnan huomioimatta, se potkaisee vähintään nilkkaan myöhemmin.

4. Laiskuus 

Laiskuudesta löytyy varmasti esimerkkejä. Jos projektipalaverissa joku sanoo, että ”en usko että sitä XXX tarvitsee tehdä”, ja tuo XXX asia on sinun vastuualueellasi, niin herätys! Jollain tavalla joudut tämän asian hoitamaan myöhemmin ja yleensä alkuperäistä suuremmin kustannuksin. Tässä kohdassa tuntuisi avainsanoja olevan QA, muutoksen hallinta ja lisensointikysymykset.

Usein törmää myös siihen, että jätetään ratkaisu puolitiehen. Ajatellaan, että tehdään ensi vaiheessa vain välttämätön ja loput joskus myöhemmin. Sitä myöhemmin ei koskaan tule. Samalla on kuitenkin tiedostettava, että tie helvettiin on päällystetty hyvillä aikomuksilla, kuten täydellisyyden tavoittelulla (ks 5. Ahneus).

5. Ahneus

Ahneudessa mikään ei tunnu riittävän. Ahne haluaa vain lisää, vaikka sitä ei muillakaan olisi, eikä missään nimessä luovu omastaan toisen tai yhteiseksi hyväksi.  Järjestelmähankkeiden kohdalla ahneus esiintyy keskittyminä. Toimintoja ja prosesseja keskittyy kokonaisarkkitehtuurissa järjestelmäkartassa yhteen paikkaan. Ydinprosessien ja -toimintojen kohdalla tämä saattaa olla mielekästä ja tietoinen valinta, mutta seuraukset on syytä tiedostaa.

6. Tietämättömyys

Tietämättömyys tuntuu tulevan vastaan päivittäin. Nykymaailman informaatiotulvassa ja muutosten määrässä on oma haasteensa pitää osaaminen ajan tasalla. Kerran hyväksi koettu ratkaisu saattaa olla vanhentunut ja parempaa olla jo tarjolla. Toisaalta uusin teknologia ja innovaatio ei välttämättä ole aina alkumetreillään ihan paras ratkaisu. Oman ajantasaisen ratkaisupakin hallinta on tänä päivänä onnistumisen edellytys.

7  Ylpeys

Tästä löytyy varmasti esimerkkijä ja sudenkuoppia. Kuvitellaan perusteettomasti, että kyllä osaamista löytyy, uskotaan sokeasti omiin kykyihin, kuvitellaan datan laadun ja tietomallien olevan täydellisiä ja aukottomia. On eri asia luulla tietävänsä kuin tietää tietävänsä.

Teologiassa yhtenä synnin tunnusmerkkinä pidetään tietoisuutta väärin tekemisestä. Tässä yhteydessä tiedon puute on kuitenkin nähtävä yhtenä syntinä. Toisaalta tiedon haalimisen riivaamana ajautuu helposti ahneuden syntiin, johtaa kiireen kautta välinpitämättömyyteen ja ahdaskatseisuuteen. Samoin käy jos osaamisen kehittäminen laiminlyödään kiireen välttämiseksi ja laiskuuden vuoksi – päädytään helposti ahdaskatseisuuden ja ylpeyden synteihin, joissa oma osaaminen ja toiminta nähdään ainoana olemassa olevana  ratkaisuna ja palvotaan sitä kultaisena vasarana ja kaikki ongelmat ovat nauloja.

Näiden seitsemän kuolemansynnin välttäminen näyttäisi tarkoittavan yleisesti kohtuullisuutta ja kokonaisuuden huomioimista. Osa-optimointi ja yhteen asiaan keskittyminen johtaa syntiin ja kadotukseen, näin mahtipontisesti sanottuna. Jos esimerkiksi Six-Sigma yleensä pyrkii estämään osa-optimointia, niin missähän on tapahtunut virhe, jos kuudella koitetaan korjata seitsemää. Puuttuuko Six-Sigmasta jotain vai onko seitsemässä kuolemansynnissä jotain liikaa. Palataan tähän numerologiaan tuonnempana

– Software Samurai –

Tuotetietoa miekan tiellä, osa 3/3

Tulen kirja on taistelun kirja. Katsotaanpa tässä yhteydessä tuotetiedon hallintaa muuttuvassa maailmassa taisteluna. Musashi puhuu kahlaamon ylittämisestä. Kahlaamon tai vesistön ylittäminen on tietynlainen riski sodankäynnissä, johon pitää huolella valmistautua. Toisaalta Musashille kahlaamon ylitys on vertauskuva elämän aikana tehtäville suurille päätöksille, joita ei enää voi perua.

Tuotetiedon hallinnassa tulee eteen erilaisia projekteja, jotka ovat kahlaamoita. Ennen ylitystä tutkitaan ympäristö ja suunnitellaan ylitys huolellisesti oikeaan aikaan ja kun hetki on koittanut, käydään päättäväisesti toimeen tavoitteena päästä vastarannalle.  Olosuhteet tietenkin voivat muuttua projektin aikana, mutta ”jos tuuli kääntyy kun olet muutaman mailin päässä määrästäsi, sinun on soudettava loppumatka ilman purjeita”. Suunnitelmat ovat tärkeitä maaliin pääsemiseksi, mutta muutoksiin on reagoitava nopeasti.

Tuulen kirjassa Musashi tekee markkina-analyysia ja tutkii muiden koulujen ominaispiirteitä.  Musashi näkee eräänä muiden koulujen heikkoutena niiden kapeakatseisuuden muissa kouluissa. Saatetaan keskittyä tekniikoihin, jotka ovat mahdollisia vain lyhyellä miekalla tai haetaan erityisen pitkästä miekasta hyötyä.  Musashi sanoo, että hänen koulussaan ei riitä vain miekkailu- tai sotataidon opiskelu, vaan pitää tuntea kaikkien taiteiden tiet. Samoin on onnistuneen tuotetiedon hallinnan kanssa. Tuoteinformaatio yksinään, ilman siihen liittyviä liiketoiminnassa esiintyvien käsitteiden assosiaatiota, jää torsoksi ja käyttökelvottomaksi. Tuotehallinnassa on tunnettava ainakin erppien ja crm:n tiet.

Musahsin koulukunnassa opiskeltiin laaja-alaisesti

Tyhjyyden kirja onkin sitten abstraktiudessaan todellista tykitystä.

Se, mitä nimitetään tyhjyyden hengeksi, on siellä missä ei ole mitään. Se ei sisälly ihmisen tietoon. Tyhjyys on tietysti olemattomuutta. Samalla kun tiedät mitä on olemassa voit tietää mitä ei ole olemassa. Se on tyhjyys.

Tähän voisi hakea assosiaation vaikkapa organisaation oppimisen kautta. Toimintaa kehitettäessä yksittäisen ihmisen päässä syntyy ajatus organisaation toimintatavasta tai käytännöstä, monien vaiheiden jälkeen tätä otetaan käyttöön ja opetetaan organisaatiolle erilaisten ohjeistusten kautta. Usein kehitys pysähtyy tähän eikä se ole ”tyhjyyttä”. Parhaassa tapauksessa onnistunut toimintatavan käyttöönotto opettaa organisaatiolle tämän toimintatavan muutoksen syyt ja periaatteet niin hyvin, että maailman muuttuessa organisaatio osaa automaattisesti mukauttaa omaa toimintaansa niin, että prosessit reagoivat ympäristön muutoksiin ilman suuria kehityshankkeita ja projekteja.

Tässä oli enemmän tai vähemmän vakavasti käyty läpi Musashin Gorin no sho -teos tuotetiedon hallinnan näkökulmasta, enemmän kuitenkin vähemmän vakavasti. Vaikka Musashilla oli hyvä ymmärrys eri asioista, niin asiasta lisää kiinnostuneille suosittelen teoksen lukemista, suhteuttamista ja soveltamista omaan ympäristöön. Neljäsataa vuotta sitten elänyt samurai tuskin osasi kovin tarkkaan nähdä millaisia taisteluja me käymme omassa työssämme. Toisaalta ikkunan Musashin maailmaan voi tänäkin päivänä saada tulemalla dojolle harjoittelemaan.

Lue osa 1/3

Lue osa 2/3

Tuotetietoa miekan tiellä, osa 2/3

Maan kirjassa Musashi ottaa kantaa kolmeen pääkohtaan. Eri ammattien tiet suhteessa strategiaan, aseiden merkitys strategialle, ja ajoitus strategiassa.  Ei tarvitse käyttää paljon mielikuvitusta löytääkseen näille vastineita liike-elämän parista.

Eri ammattikuntien tiet (jap. Dõ, Michi) voidaan käsittää ammatilliseksi osaamiseksi, ammattitaidoksi tai koko ammatilliseksi uraksi.  Musashi käyttää esimerkkinä puusepän ammattitaitoa ja kuinka eri osaamiset valjastetaan juuri tarkoituksen mukaiseen tehtävään eikä keneltäkään voida vaatia enempää kuin mitä osaaminen mahdollistaa. Kuulostaa nykyaikaiselta henkilöstöjohtamiselta.

Tietynlainen ase sopii tietynlaiseen tehtävään paremmin kuin toinen

Aseiden merkityksestä strategialle Musashi opettaa, että eri aseet ovat tarkoituksen mukaisia eri tilanteissa ja aseet tulee valita tilanteen mukaan. ”On paha, jos komentajilla ja ratsumiehillä on mieltymyksiä ja epämieltymyksiä.”  Tämäkin on varsin tyypillinen tapa suunniteltaessa tuotekehitystä, pyritään valitsemaan työkaluiksi ”best-of-breed”, lajinsa parhaat. Toisaalta jos jokainen kehitysprojekti tai hanke evaluoi ja valitsee uudet työkalut, kuluu näiden opetteluun ja käyttöönottoon suhteettoman paljon aikaa. ”Se, että tulee liian tutuksi jonkin aseen kanssa, on yhtä suuri virhe kuin se, ettei tunne asetta tarpeeksi hyvin.”

On paha, jos komentajilla ja ratsumiehillä on mieltymyksiä ja epämieltymyksiä

Ajoituksen suhteen Musashi toteaa varsin yksinkertaisesti, ”Kaikessa on ajoitus. Strategian ajoitusta ei voi hallita ellei ole harjoitellut riittävästi.”  Kuulostaa prosessien kehittämistyöltä. Uusia toimintatapoja suunniteltaessa ja käyttöönotettaessa on usein vaikea löytää sopiva rytmitys tehtäville. Monesti koneiston hammaspyörät lyövät yli ja ketjut tippuvat rattailta, mutta jos tunnustetaan liikkeellelähdön vaikeus ja ollaan valmiita reagoimaan näihin tarvittaviin prosessin säätötoimiin, opitaan ajoitus ja rytmi harjoituksen kautta. Toisaalta myynti- ja markkinointihenkilöille tuskin tarvitsee mainita mitään oikeasta markkinoille tulon ajoituksesta.

Maan kirjassa Musashi luetteli vielä yhdeksän ohjetta heille, jotka haluavat seurata tätä strategian tietä. Tässä yhteydessä haluaisin nostaa näistä esiin viimeisen, yhdeksännen ohjeen. ”Älä tee mitään turhaa”.  300 vuotta myöhemmin tämä periaate nousi uudelleen esiin Toyotan kehittäessä tuotantomenetelmäänsä, Toyota Production Systems. Voisin vannoa että Toyotan kehitysryhmälle Gorin no sho on ollut tuttu teos. Tälle vuosituhannelle tultaessa Toyotan menetelmistä jalostettiin edelleen ketterä ohjelmistotuotannon menetelmä, Lean Software Development, jossa kaikuu sama periaate:

”Älä tee mitään turhaan / Eliminate Waste ”

Veden kirjassa Musashi vertaa strategiaansa ja kouluaan veteen. Vesi on tihkumista, pisaroita ja samalla toisaalla hurja ja myrskyävä meri. Samoin on tuotetiedon suhteen. Suurinkin ja mitä monimutkaisin laite esitetään yhtenä nimikkeenä, mutta voi sisältää miljoonia nimikkeitä joista se koostuu. Toisaalta vesi ottaa astiansa muodon.  Sama nimike näyttäytyy meille tietosisällöltään ja assosiaatioiltaan erilaisissa ”astioissa” sen mukaan mistä näkökulmasta sitä katsellaan. Oston, myynnin, suunnittelun tai valmistuksen näkemykset samasta nimikkeestä voivat olla hyvinkin erilaiset.

Lue osa 1/3

Lue osa 3/3

Tuotetietoa miekan tiellä, osa 1/3

Kun elämään on parinkymmenen vuoden ajan kuulunut japanilainen miekkailu sekä budo ylipäätään mielenkiinnon kohteena, niin on selvää, että budo infektoituu kaikkeen muuhunkin toimintaan elämässä.  Tässä kirjoituksessa annetaan tuotetiedollekin pieni budo-tartunta tällaisen tuotetiedon järjestelmäkehityksen parissa puurtavan ’Software Samurain’ näkökulmasta.

Software Samurai auringonlaskussa

Miyamoto Musashi oli kuuluisa samurai, joka kirjoitti vuonna 1645 kirjan Gorin no sho, Viiden kehän kirja, Maa, vesi, tuli, tuuli ja tyhjyys. Kirja esittelee Musashin kehittämän miekkailuun ja strategiaan keskittyneen koulukunnan, hyõhõ niten ichi ryu, periaatteet.  Näitä periaatteita ja opetuksia on vuosien saatossa siteerattu erilaisissa yhteyksissä, kuten liike-elämän, kaupankäynnin, opetuksen ja urheilun parissa.  Kannan oman roponi tähän kekoon hakemalla opetusta ja valaistusta tuotetiedon mysteereihin tämän miekkapyhimyksen opastuksella.

Musashi syntyi vuonna 1584 ja osoitti jo varhain lahjakkuutensa miekkailutaidoissa.  Jo 12 vuoden ikäisenä hän kävi ensimmäisen kaksintaistelunsa, jossa hän surmasi Arima Kihei nimisen samurain. 16 vuoden ikäisenä hän taisteli Japanin historian kannalta merkittävässä Sekigaharan taistelussa Toyotomi Hideoshin joukoissa. Hideoshin joukot hävisivät taistelun, ja taistelun voittanut Togugawa Ieyasu perusti hallinnon, joka säilyi Japanissa 1800-luvun meiji-kaudelle saakka. Noin 30 vuoden ikään saakka Musashi eli shugyōshan, vaeltavan samurain, elämää. Hän etsi vastustajia, joilta oli mahdollisuus oppia miekkailua syvemmin. Musashi kävi lukuisia kamppailuja voittamattomana. Tämän jälkeen hän vietti noin 60-vuotiaaksi asti vakiintunutta elämään daimioiden palveluksessa jatkaen kuitenkin koko ajan miekkailun ja strategian opiskelua ja harjoittelua, ja hakemalla selitystä sille, miksi hän oli ollut voittamaton. Viimeiset elinvuotensa hän eli erakkona ja kirjoitti kirjan Gorin no sho. Musashi kuoli saatuaan kirjan valmiiksi vuonna 1645.

Gorin no sho, viiden kehän kirja, koostuu viidestä kirjasta: Maan, veden, tulen, tuulen ja tyhjyyden kirjoista.  Kukin kirja käsittelee Musashin oppia miekkailusta ja strategiasta viidestä eri näkökulmasta. Tässä kohdin voikin viitata tietojärjestelmien arkkitehtuuri-suunnittelussa usein käytettyyn menetelmään, Krutchenin 4+1 näkökulmiin. Ilmeisesti on niin, että mitään asiaa ei voida kattavasti nähdä, ellei siihen paneuduta vähintään viidestä eri näkökulmasta.

Maan kirja esittelee Musashin koulun yleisesti strategian tasolla: mitä taitoja on oltava, hankittava tai harjoiteltava seuratakseen Musashin tietä. Veden kirja selittää, miten kamppailut ja taistelut voitetaan seuraamalla maan kirjassa viitoitettua polkua. Tulen kirja on taistelun kirja, jossa annetaan tekniikat taistelujen voittamiseen. Tuulen kirja opettaa että on tunnettava vihollinen ja vertailee Musashin koulua muiden koulukuntien opetuksiin. Tyhjyyden kirja lopulta tekee kaikesta edellisestä opitusta luonnollista vaistonvaraista tietoa, jota voidaan hyödyntää ilman erityistä ponnistelua.

Lue osa 2/3

Lue osa 3/3