Työn kohde on liiketoiminnan lopputulos ja sen mahdollistava järjestelmä
Liiketoimintajärjestelmä on koko järjestely, joka tuottaa lopputuloksen: ihmiset tekevät päätöksiä, prosessit kuljettavat työtä, data antaa työlle merkityksen, sovellukset ja rajapinnat toteuttavat sitä, säännöt rajaavat sitä ja näyttö osoittaa, mitä tapahtui. Teknologia on välttämätöntä, mutta se ei yksin määritä järjestelmää. Sama sovellus voi tukea hyvin erilaisia lopputuloksia omistajuuden, ajoituksen, toimivallan ja ympäröivän manuaalisen työn mukaan.
Liiketoimintajärjestelmien kehittäminen alkaa siksi konkreettisesta lopputuloksesta tai päätöksestä. Se selvittää, mitä on tapahduttava, kuka vastaa siitä, mitä tietoa tarvitaan, missä tieto muuttuu, mitkä rajat työ ylittää ja miten onnistuminen tai epäonnistuminen tulee näkyväksi. Vasta sen jälkeen ratkaistaan, millainen arkkitehtuuri-, integraatio- tai ohjelmistotoimenpide on tarkoituksenmukainen.
Miksi tuttu jako liiketoimintaan ja teknologiaan epäonnistuu
Suuret muutokset jaetaan usein liiketoimintaperusteeseen, prosessi-, data-, arkkitehtuuri- ja toteutustyöhön. Jako voi helpottaa johtamista, mutta samalla se luo tulkintarajoja. Liiketoimintakäsite voi saada datamallissa toisen merkityksen. Arkkitehtuuripäätös voi poistaa valvontakeinon, jonka operatiivinen toiminta on hoitanut epävirallisesti. Toteutuksen hyväksymistesti voi todistaa rajapinnan vastaavan mutta olla kertomatta, pystyykö vastaanottava tiimi ymmärtämään tapahtuman tai palautumaan virheestä.
Ongelma ei ole erikoisalojen olemassaolo vaan se, ettei kukaan kanna jatkuvuutta niiden yli. Liiketoimintajärjestelmien kehittäminen antaa jatkuvuudelle nimenomaisen paikan. Siinä merkitys, omistajuus, päätösoikeudet, tekninen käyttäytyminen ja operatiivinen näyttö ovat toisiinsa liittyviä suunnittelukysymyksiä, vaikka syvään erityisosaamiseen käytetään edelleen asiantuntijoita.
Kuusi kysymystä pitää muutoksen yhtenäisenä
Hyödyllinen diagnostinen ketju on Identiteetti → Konteksti → Päätös → Toimivalta → Toteutus → Näyttö. Identiteetti kysyy, viittaavatko järjestelmän kaikki osat samaan liiketoimintakohteeseen tai tapahtumaan. Konteksti kysyy, säilyvätkö sen merkitys, historia ja olennaiset rajoitteet mukana. Päätös kirjaa, mitä päätettiin ja miksi. Toimivalta osoittaa, kenellä tai millä oli oikeus tehdä päätös. Toteutus yhdistää ohjeen tehtyyn työhön. Näyttö tekee lopputuloksesta jäljitettävän ja kyseenalaistettavan.
Ketju ei ole tuoteominaisuus eikä takuu, vaan tapa paikantaa katkos. Jos kumppani antaa uuden tunnisteen ilman korrelaatiota, työnkulku kadottaa hyväksynnän taustalla olevan säännön tai mallin suositus muuttuu automaattiseksi toiminnaksi ilman nimenomaista toimivaltaa, järjestelmä saattaa edelleen toimia mutta sen lopputulokseen on vaikea luottaa.
Kehittäminen vie perustelut operoitavaksi lopputulokseksi
Suosituksesta tulee kehittämistyötä, kun se rajaa todellisia päätöksiä ja voidaan testata toiminnassa. Tavoitearkkitehtuuri osoittaa rajat ja omistajuuden. Datasopimus määrittelee merkityksen, versiokäyttäytymisen ja odotukset virhetilanteissa. Siirtymätilalla on aloitus-, lopetus- ja palautumiskriteerit. Työnkulkusuunnitelma tekee poikkeukset ja ihmisen toimivallan näkyviksi. Käyttöönottoon kuuluvat seuranta ja vastuun siirtämisen polku.
Tämä ei tarkoita, että yksi ihminen rakentaisi kaikki osat. Se tarkoittaa perustelujen säilymistä yhtenäisinä vastuun siirtyessä johdon, tietoalueiden omistajien, arkkitehtien, kehittäjien, toimittajien ja operaattorien välillä. Kyvykkyyskartat, päätöskirjaukset, rajapintasopimukset ja hyväksymiskriteerit ovat hyödyllisiä, koska ne säilyttävät kontekstin näissä vastuun siirroissa.
Työ etenee ymmärryksen, tavoitteen, polun ja oppimisen kautta
Käytännön eteneminen on haasteen jäsentäminen, järjestelmän ymmärtäminen, tavoitetilan määrittely, etenemispolun suunnittelu sekä toteutus ja oppiminen. Kyse ei ole jäykästä vesiputousmallista. Toteutuksen aikana löytyvä näyttö voi muuttaa tavoitetta. Siirtymäsuunnittelu voi paljastaa alkuperäisen ongelmarajauksen vääräksi. Olennaista on päivittää perustelut eikä piilottaa muutosta projektin tilaraportin taakse.
MTeran viisi periaatetta täydentävät toisiaan tässä etenemisessä: Mastery kysyy, onko ymmärrys riittävän syvää; Transformation suojaa jatkuvuutta; Engineering muuttaa valinnat ylläpidettäväksi lopputulokseksi; Reason säilyttää tarkoituksen ja hyväksytyn riskin; Architecture luo rakenteen seuraavaa muutosta varten. Loppuun viedyn syklin pitäisi parantaa seuraavan syklin laatua.
Mitä ostajan pitäisi odottaa saavansa
Tuotos riippuu päätöksestä. Arviointi voi tuottaa järjestelmäkartan, näyttöön perustuvat havainnot, riskinäkymän ja suositellun suunnan. Arkkitehtuurityö voi tuottaa tavoite- ja siirtymätilat, omistajuudet, päätöskirjaukset, sopimukset ja vaiheistetun etenemissuunnitelman. Toteutus voi tuottaa toimivia komponentteja, automaattisia testejä, operatiivisen seurannan, dokumentaation ja osaamisen siirron.
Yhteinen laatutekijä on jäljitettävyys: ostajan pitäisi pystyä yhdistämään jokainen ehdotettu muutos liiketoiminnalliseen perusteeseen, ymmärtämään oletukset, näkemään vastuullinen omistaja, tietämään, miten eteneminen hyväksytään, ja tunnistamaan epävarmaksi jäävät asiat. Pitkä teknologialuettelo ei korvaa tätä perusteluketjua.
Milloin tästä tieteenalasta on eniten hyötyä
Liiketoimintajärjestelmien kehittäminen on arvokkainta, kun lopputulos ylittää useita rajoja: vanha järjestelmä uudistetaan rinnakkaiskäytössä, useat tietoalueet käyttävät samaa dataa, kumppanit kiistelevät integraation tilasta, tekoäly tulee osaksi ihmisen päätöstä, automaatio korvaa epävirallisia valvontakeinoja tai räätälöidyn ohjelmiston on toimittava nykyisen järjestelmäkokonaisuuden rinnalla.
Rajatussa, vähäriskisessä muutoksessa, jonka omistajuus ymmärretään, näin laaja tarkastelu voi olla tarpeeton. Menetelmä on suhteutettava kysymykseen. Tavoitteena ei ole arkkitehtuuriteatteri vaan todellisen järjestelmän tekeminen riittävän näkyväksi vastuullista päätöstä ja seuraavaa hyödyllistä lopputulosta varten.