Modernin yrityksen teknologiamaiseman määrittävä piirre on se, ettei kukaan yksittäinen henkilö pysty kuvaamaan sitä tarkasti. Vuosikymmen sitten IT:n raja oli kohtuullisen selkeä: hankinta, konesali, lisenssisopimus ja projektimenetelmä pitivät yhdessä suurimman osan teknologiasta tunnetun kehän sisällä. Tuo kehä on hajonnut. Software as a service voidaan ottaa käyttöön yrityskortilla ilman minkäänlaista keskitettyä hyväksyntää. Cloud-alustat mahdollistavat sen, että yksittäinen insinööri pystyttää infrastruktuurin minuuteissa. Liiketoimintayksiköt, joilta odotetaan nopeaa etenemistä, ostavat kyvykkyyttä suoraan toimittajilta, jotka ovat enemmän kuin halukkaita myymään IT-toiminnon ohitse. Jokainen näistä päätöksistä on paikallisesti järkevä. Kokonaisuutena ne tuottavat hallitsematonta rönsyilyä.

Seuraukset ovat mitattavissa ja ne kumuloituvat. Päällekkäiset järjestelmät kahdentavat lisenssikulut ja tukityön. Integraatiopinta-ala kasvaa nopeammin kuin integroitava arvo, koska jokainen uusi työkalu on kytkettävä perusjärjestelmiin. Data pirstoutuu instansseihin, jotka eivät enää ole keskenään yhtä mieltä, joten raportoinnista tulee täsmäytysharjoitus oivalluksen sijaan. Tietoturva- ja vaatimustenmukaisuusriski laajenee jokaisen hallitsemattoman päätelaitteen ja jokaisen unohtuneen pääkäyttäjätilin myötä. Ja inhimillinen hinta on todellinen: osaavat ihmiset käyttävät aikansa moninaisuuden ylläpitämiseen kyvykkyyden rakentamisen sijaan.

Mikä tekee tästä ajankohtaisen, ei pelkän ikuisen valituksen aiheen, on teknologian muuttunut talous. Kun valtaosa kuluista oli investointeja, rönsyily oli hidasta ja näkyi taseessa. Kun kulut perustuvat kulutukseen ja tilauksiin, rönsyily on nopeaa, jatkuvaa ja helppo jäädä huomaamatta. Lepotilassa oleva cloud-ympäristö laskuttaa yhä. Harvoin käytetty sovellus uusiutuu silti. IT-maisema ei enää odota budjettisykliä kasvaakseen, mikä tarkoittaa, ettei hallintakaan voi enää toimia budjettisyklin tahdissa. Sen on muututtava jatkuvaksi toiminnoksi, ja konsolidoinnista on tultava käynnissä oleva ohjelma kertaluonteisen siivouksen sijaan.

Hallinnan ensimmäinen periaate on epäglamouri mutta ratkaiseva: hallinta ei ensisijaisesti koske teknologiaa, vaan sitä, kuka saa päättää mistäkin ja millä perusteella. Ennen kuin organisaatio voi järkeistää IT-maisemaansa, sen on oltava rehellinen siitä, miten valinnat todella tehdään. Useimmissa yrityksissä todellinen päätösvalta on epämuodollista, kiisteltyä ja epäjohdonmukaista. Yksi kululuokka on tiukasti kontrolloitu, kun taas toinen, suurempi virtaa vapaasti. Keskitetyllä arkkitehtuuriryhmällä on paperilla auktoriteetti, jota se ei käytännössä pysty käyttämään. Näiden oikeuksien tekeminen näkyväksi on hallinnan perustava teko, ja se on arvokkaampaa kuin mikään työkalu.

Toimiva malli erottaa muutaman päätöstyypin ja osoittaa kunkin selkeälle omistajalle. Periaatteet ja standardit, kestävät säännöt jotka muokkaavat kaikkea muuta, kuuluvat keskitetylle auktoriteetille jolla on ylimmän johdon tuki. Investointipäätökset, mitä kyvykkyyksiä rahoitetaan ja mitä näivetetään, kuuluvat portfolioelimelle joka näkee koko maiseman yli yhden projektin kerrallaan sijaan. Hyväksytyn standardin sisäiset suunnittelupäätökset kuuluvat työtä lähimpänä oleville toimitustiimeille, koska niiden nostaminen ylöspäin luo vain pullonkauloja. Taito on näiden rajojen vetämisessä niin, että keskus hallitsee ne harvat asiat joiden on oltava yhtenäisiä ja delegoi ne monet joiden ei tarvitse olla.

Portfolion hallinta on väline, joka muuttaa päätösvallan tuloksiksi. Sen sijaan että kutakin järjestelmää käsiteltäisiin erillisenä varallisuutena, portfolioajattelu esittää vertailevan kysymyksen koko maiseman yli: mitä tämä kyvykkyys maksaa, mitä arvoa se tuottaa, mitä riskiä se kantaa, ja miten se on päällekkäinen kaiken muun kanssa joka tekee jotain samankaltaista. Tuosta näkymästä seuraa elinkaarikohtainen ratkaisu jokaiselle sovellukselle. Investoi, koska se on strateginen ja terve. Siedä, koska se toimii eikä korvaaminen ole vielä perusteltua. Migratoi, koska parempi standardi on olemassa. Tai poista käytöstä, koska se on tarpeeton, vanhentunut tai tuen ulkopuolella. Hallinta, joka ei pysty tuottamaan tätä ratkaisua IT-maisemalleen, ei ole vielä hallintaa. Se on hallinnointia.

Hallinnalla on maine, usein ansaittu, byrokraattisena jäänteenä: ohjausryhmiä, arkkitehtuurin arviointilautakuntia ja pitkiä asiakirjoja, joiden ohi toimitustiimit oppivat kiertämään. Viime vuosien merkittävä kehitys on se, että kurinalaisuutta ovat muokanneet sitä ympäröivät toimintamallit, ja paras käytäntö näyttää nyt olennaisesti erilaiselta kuin klassinen kuva.

Tärkein muutos on siirtymä projektirahoituksesta tuoterahoitukseen. Kun teknologiaa rahoitettiin projekteina, hallinta oli episodimaista: liiketoimintaperustelu tutkittiin alussa, minkä jälkeen hanke katosi toimitukseen ja ilmestyi uudelleen vasta ylittäessään aikataulunsa. Pysyvät tuotetiimit, joita rahoitetaan omistamaan kyvykkyys sen elinkaaren ajan, muuttavat hallintakysymyksen muodosta pitäisikö meidän hyväksyä tämä projekti muotoon ansaitseeko tämä tuote yhä paikkansa portfoliossa. Se on paljon hyödyllisempi kysymys konsolidoinnin kannalta, koska se pakottaa jatkuvaan arvioon merkityksellisyydestä kertaluonteisen hyväksynnän sijaan, jota kukaan ei palaa tarkastelemaan.

Tämän rinnalla kustannusläpinäkyvyydestä on tullut muodollinen käytäntö. Technology business management ja FinOps-liike ovat antaneet organisaatioille yhteisen sanaston teknologiakustannusten kohdentamiseksi liiketoimintapalveluihin, niin että keskustelu konsolidoinnista voi perustua lukuihin väitteiden sijaan. Myös platform engineeringin nousu on merkityksellinen: sisäiset alustatiimit, jotka tarjoavat valmiiksi rakennettuja, itsepalvelupohjaisia reittejä, tekevät toimitustiimeille helpommaksi tehdä standardin mukainen asia kuin keksiä oma, mikä on ainoa kestävä tapa valvoa standardeja mittakaavassa. Ja sääntely-ympäristö, tietosuojasta operatiivisen kestävyyden velvoitteisiin, on nostanut hallitsemattoman maiseman hintaa, muuttaen hallinnan harkinnanvaraisesta hyvästä tilivelvolliseksi velvollisuudeksi. Yhteinen lanka on se, että hallinta sulautuu yhä enemmän siihen, miten työ virtaa, sen sijaan että se kerrostettaisiin sen päälle tarkastuksena.

Hyvän hallinnan arkkitehtuuri lepää yhden erottelun varassa: eron suojakaiteen ja portin välillä. Portti pysäyttää työn kunnes joku hyväksyy sen, ja portteja kertyy kunnes toimitus hidastuu hitaimman komitean vauhtiin. Suojakaide rajoittaa päätöksen muotoa mutta antaa itse päätöksen edetä odottamatta. Skaalautuva hallinta rakennetaan lähes kokonaan suojakaiteista, ja portit varataan aidosti peruuttamattomille tai suuriseurauksisille valinnoille. Suunnittelutavoite ei ole arvioida enemmän, vaan tehdä oikeasta valinnasta pienimmän vastuksen tie ja väärästä valinnasta näkyvästi vaivalloinen.

Tämä saavutetaan pienellä, tarkoituksella kuratoidulla standardijoukolla kattavan luettelon sijaan. Referenssiarkkitehtuuri kuvaa hyväksytyt mallit yleisiin ongelmiin, niin että tiimit kokoavat ratkaisunsa tunnetuista hyvistä rakennuspalikoista sen sijaan että suunnittelisivat joka kerta alusta. Teknologiastandardi nimeää suositellut tuotteet kussakin kategoriassa ja, aivan yhtä tärkeästi, nimeää ne jotka ollaan poistamassa käytöstä, niin että suunta on yksiselitteinen. Golden pathit, alustatiimien tarjoamat valmiiksi rakennetut itsepalvelureitit, upottavat nämä standardit työkaluihin niin että standardin noudattaminen on nopein tapa toimittaa. Vain asiakirjoihin kirjatut standardit ovat pyrkimyksiä. Toimituksen polkuun upotetut standardit ovat hallintaa.

Konsolidointi soveltaa samaa suunnitteluajattelua vähentämiseen. Järkeistäminen noudattaa kurinalaista järjestystä. Ensin kartoita IT-maisema sellaisena kuin se todella on, koska et voi konsolidoida sitä mitä et näe, ja varjojärjestelmät ovat juuri niitä jotka kartoituksen on nostettava esiin. Toiseksi arvioi jokainen sovellus johdonmukaisen kehyksen kautta: liiketoiminta-arvo, tekninen kunto ja kokonaiskustannus, niin että vertailut ovat reiluja. Kolmanneksi päätä tavoitetila: mikä järjestelmä kustakin päällekkäisestä ryppäästä säilyy ja mihin muut migratoidaan. Neljänneksi, ja tämän vaiheen organisaatiot useimmiten jättävät väliin, tosiasiallisesti poista käytöstä, mikä tarkoittaa datan migratointia, integraatioiden uudelleenohjausta, käyttöoikeuksien peruuttamista, lisenssien lopettamista ja sen varmistamista, ettei mikään ole riippuvainen siitä mikä on sammutettu. Käytöstäpoisto on paikka jossa säästöt piilevät, ja se on työn vaikein, vähiten juhlittu osa.

Hallinta ja konsolidointi epäonnistuvat tunnistettavilla tavoilla, ja mallien nimeäminen on ensimmäinen puolustus niitä vastaan.

Hallinta esteenä. Yleisin epäonnistuminen on arviointilautakunta, joka lisää viivettä parantamatta päätöksiä. Kun jokainen muutos jonottaa komiteaan, joka kokoontuu kahden viikon välein, tiimit oppivat välttämään hallintaa kokonaan, ja valvomatta rakentamansa IT-maisema on juuri se jonka estämiseksi hallinta oli olemassa. Hallinta, joka koetaan kitkana, kierretään, ja ohitettu kontrolli on pahempi kuin ei kontrollia lainkaan, koska se luo väärän tunteen valvonnasta.

Standardit ilman käyttöönottoa. Referenssiarkkitehtuuri, jota mikään tiimi ei noudata, ei ole standardi vaan toive. Näin käy aina kun standardit kirjoittaa keskitetty ryhmä eristyksissä toimituksesta, ne pakotetaan sen sijaan että ne rakennettaisiin valmiiksi, eikä niitä koskaan tehdä helpommaksi noudattaa kuin sivuuttaa. Ratkaisu ei ole pakottaminen vaan houkuttelu: standardin on oltava se mukavampi vaihtoehto.

Järkeistäminen joka pysähtyy analyysiin. Monet konsolidointiohjelmat tuottavat tyylikkään sovellusinventaarion, päällekkäisyyden lämpökartan ja tavoitetilaesityksen, ja pysähtyvät sitten. Käytöstäpoistoon merkityt järjestelmät pyörivät edelleen, koska käytöstäpoisto on aidosti vaikeaa ja harvoin rahoitettua. Analyysi ilman käytöstäpoistoa ei tuota lainkaan säästöä. Se pelkästään dokumentoi ongelman.

Kuolematon sovellus. Edelliseen liittyen järjestelmät sammutetaan nimellisesti mutta niitä ei koskaan aidosti poisteta käytöstä: palvelin pysyy pystyssä siltä varalta että joku tarvitsee sitä, lisenssi uusiutuu oletuksena, integraatio pysyy elossa. IT-maisema kantaa sekä vanhan että uuden kustannuksen yhtä aikaa. Todellinen käytöstäpoisto vaatii kurinalaisuutta varmistaa ettei mikään ole riippuvainen järjestelmästä ja poistaa se sitten päättäväisesti.

Konsolidointi huonompaan standardiin. Joskus järkeistämisessä säilyvä järjestelmä valitaan poliittisin eikä teknisin perustein, ja organisaatio käyttää paljon rahaa migratoidakseen alustalle joka ei tosiasiallisesti ole joukon paras. Konsolidointi vähentää lukumäärää mutta heikentää kyvykkyyttä. Päätös siitä mikä järjestelmä säilyy ansaitsee yhtä paljon huolellisuutta kuin päätös konsolidoida ylipäätään.

Kaiken hallitseminen yhtäläisesti. Kun sama raskas prosessi koskee triviaalia muutosta ja strategista muutosta, triviaalit muutokset hukuttavat prosessin ja strategiset saavat liian vähän huomiota. Suhteellisuus, hallinnan painon sovittaminen päätöksen seurauksiin, on se mikä pitää hallintatoiminnon uskottavana ja nopeana.

Nashua käsittelee hallintaa ja konsolidointia rakennettavana operatiivisena kyvykkyytenä, ei toimitettavana raporttina. Toimeksianto alkaa rehellisellä kuvalla IT-maisemasta ja siitä, miten päätökset todella tehdään sen sisällä, koska molemmat ovat yleensä vähemmän järjestelmällisiä kuin virallinen versio antaa ymmärtää. Yhdistämme sovellusten, infrastruktuurin ja kulujen automaattisen kartoituksen jäsenneltyihin keskusteluihin IT:n ja liiketoiminnan välillä, niin että varjomaisema ja epämuodollinen päätösvalta tulevat näkyviin dokumentoitujen rinnalle. Tuotos ei ole pelkkä inventaario. Se on portfolionäkymä, jossa jokainen merkittävä sovellus kantaa arvon, kustannuksen, riskin ja selkeän ratkaisun.

Siitä eteenpäin työ on tarkoituksella vaiheistettu niin, että arvoa saapuu varhain eikä organisaatiota pyydetä nielemään monivuotista ohjelmaa uskon varassa. Tunnistamme päällekkäiset ryppäät joissa konsolidointi maksaa itsensä nopeasti takaisin, ja pystytämme hallintamekanismit rinnakkain: päätösvaltamallin, sen pienen standardijoukon joka kestää, ja kevyet foorumit jotka tekevät suhteellisia päätöksiä toimituksen tarvitsemalla nopeudella. Ratkaisevaa on, että suunnittelemme hallinnan suojakaiteina jotka on upotettu siihen miten tiimit jo työskentelevät, niin että se mahdollistaa toimituksen sen sijaan että jonottaisi sen edessä. Suunnittelemme käytöstäpoiston ensiluokkaisena toimintana, jossa datan migratointi, integraatioiden uudelleentyöstö ja lisenssien lopettaminen käsitellään rahoitettuna työnä eikä jälkiajatuksena, koska juuri siellä luvatut säästöt tosiasiallisesti realisoituvat.

Läpi koko työn Nashua toimii käytännön tekijänä asiakkaan omien ihmisten rinnalla eikä etäisenä neuvonantajana. Standardit joita organisaation tiimit ovat olleet muokkaamassa ovat standardeja jotka he ottavat käyttöön. Portfolio jota organisaatio pystyy ylläpitämään meidän lähdettyämme on arvokkaampi kuin täydellinen tilannekuva jota se ei pysty pitämään ajan tasalla. Tavoitteemme on jättää jälkeemme hallintatoiminto joka on suhteellinen, portfolio joka on elävä, ja IT-maisema joka on mitattavasti pienempi ja johdonmukaisempi kuin se jonka löysimme.

Ero jonka Nashua tekee on siirtymä yksittäisestä konsolidointiharjoituksesta kestävään kyvykkyyteen, joka estää rönsyilyn paluun. Mikä tahansa pätevä yritys voi tuottaa sovellusten järkeistämisen kerran. Vaikeampi ja arvokkaampi lopputulos on organisaatio, joka hallitsee omia päätöksiään riittävän hyvin, jotta IT-maisema pysyy johdonmukaisena, joka poistaa järjestelmiä käytöstä rutiininomaisesti eikä harvinaisena kampanjana, ja joka kokee hallinnan kiihdyttimenä eikä verona. Se on lopputulos jota kohti rakennamme, ja se riippuu yhtä paljon toimintamallista ja ihmisistä kuin mistään arvioinnista.

On myös käytännöllinen seuraus, joka muuttaa sen mitä työ saa olettaa. Kun toimeksianto vaatii kyvykkyyttä jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintasykliä tai toimittajan tiekarttaa. enterprise platform on rakennettu mukautumaan lähes mihin tahansa ominaisuuteen nopeasti, agenttipohjaisen tuotekehityksen kautta: se mitä tarvitaan kuvataan selkokielellä ja tuotetaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alla, niin ettei nopeus koskaan tule johdonmukaisuuden, turvallisuuden tai kontrollin kustannuksella. Vaikutus on strateginen eikä pelkästään käytännöllinen. Se siirtää tee tai osta -rajaa, pitää optionaalisuuden edullisena ja antaa arkkitehtuurin seurata strategiaa sen sijaan että strategia taipuisi siihen mitä sattui olemaan hyllyllä.

Tämän kaiken sitoo yhteen Nashuan asema yritysteknologia- ja konsultointiyrityksenä, joka pysyy mukana läpi toimituksen ja sen jälkeenkin. Emme ole kiinnostuneita hallintakehyksestä joka näyttää vaikuttavalta asiakirjassa ja kuolee kohdatessaan todellisen toimituksen tahdin, emmekä konsolidointisuunnitelmasta jonka säästöt eivät koskaan poistu laskentataulukosta. Mittaamme onnistumisemme konkreettisin termein jotka merkitsevät liiketoiminnalle: vähemmän tarpeettomia järjestelmiä, matalampi toistuva kustannus, pienentynyt integraatio- ja tietoturvapinta, nopeammat ja selkeämmät päätökset, ja portfolio jota organisaatio pystyy ohjaamaan itse pitkään toimeksiannon päätyttyä. Hyvin päättäminen teknologiasta ja huonojen päätösten luoman rönsyilyn kesyttäminen ei ole projekti jolla on päättymispäivä. Se on kyvykkyys, ja asiakkaidemme auttaminen omistamaan se on paikka jossa Nashua tekee eron.