Kahden vuosikymmenen ajan yritysteknologian rajoittava tekijä oli toteutus. Järjestelmien rakentaminen oli hidasta, kallista ja riskialtista, joten etulyöntiaseman saivat ne organisaatiot, jotka pystyivät toteuttamaan luotettavasti. Tuo rajoite on suurelta osin purkautunut. Cloud-alustat, hallitut palvelut, low-code-työkalut ja kypsä software-as-a-service -markkina tarkoittavat, että lähes mikä tahansa kyvykkyys voidaan pystyttää nopeasti lähes minkä tahansa budjetin omaavan tiimin toimesta. Toteutus ei ole enää pullonkaula. Johdonmukaisuus on.

Seurauksena on IT-maisema, joka kasvaa nopeammin kuin kenenkään kyky hahmottaa sitä. Liiketoimintayksiköt hankkivat omat alustansa, integraatio kertyy pisteestä pisteeseen kytkentöjen verkoksi ja sama asiakas- tai tuotetieto hallinnoidaan neljässä paikassa neljällä hienovaraisesti eri tavalla määritellyllä tavalla. Jokainen yksittäinen päätös oli puolustettavissa. Kokonaisuus on organisaatio, joka ei voi luottavaisesti sanoa, mitä se omistaa, mitä näiden järjestelmien käyttö maksaa tai onko kokonaisuus liikkumassa kohti julkilausuttuja tavoitteitaan vai niistä poispäin.

Tämän vuoksi IT-strategia ja arkkitehtuuri on siirtynyt taustatoimintojen suunnittelutehtävästä hallitustason asiaksi. Sääntelyjärjestelmät edellyttävät nyt, että instituutiot osoittavat hallitsevansa teknologiamaisemaansa ja operatiivista resilienssiään. Investointiperusteet riippuvat yhä useammin siitä, sopiiko ehdotettu muutos johdonmukaiseen suuntaan vai lisääkö se vielä yhden poikkeuksen jo ennestään sotkeutuneeseen maisemaan. Niukka resurssi ei ole enää kyky rakentaa. Se on uskottava, yhteinen vastaus kysymykseen siitä, mitä pitäisi rakentaa, mitä pitäisi poistaa käytöstä ja missä järjestyksessä. Tämän suunnan asettaminen ja sen puolustaminen paikallisen optimoinnin jatkuvaa painetta vastaan on varsinaista työtä.

Tämän osaamisalueen perustava liike on erottaa se, mitä liiketoiminta tekee, siitä, miten se sen tällä hetkellä tekee. Liiketoimintakyvykkyys on vakaa, teknologianeutraali lausuma kyvystä, joka organisaatiolla on oltava: ratkaista korvausvaatimus, ottaa asiakas käyttöön, ennustaa kysyntää, täsmäyttää kirjanpito. Kyvykkyydet muuttuvat hitaasti, koska ne kuvaavat yrityksen olemusta. Sovellukset, prosessit ja infrastruktuuri, jotka toteuttavat ne, muuttuvat jatkuvasti. Suunnittelun ankkurointi kyvykkyyksiin järjestelmien sijaan antaa strategialle koordinaatiston, joka kestää uudelleenorganisoinnit, toimittajanvaihdokset ja teknologiasyklit.

Kyvykkyysmalli on tarkoituksellisesti hierarkkinen ja tarkoituksellisesti tylsä. Ylimpänä on muutama kymmen tason yksi kyvykkyyttä, jotka mikä tahansa alan vertaistoimija tunnistaisi. Niiden alapuolella kaksi tai kolme lisätasoa hajottamista yltää siihen tarkkuuteen, jolla investointi- ja omistajuuspäätökset todella tehdään. Mallin arvo ei ole taksonomia itsessään vaan se, mitä sen päälle voidaan kerrostaa. Jokainen kyvykkyys voidaan arvioida liiketoiminnallisen tärkeyden, sitä tukevien järjestelmien kunnon ja kustannusten sekä siihen liittyvän strategisen kunnianhimon suhteen. Tuloksena on lämpökartta, joka muuttaa hallitsemattoman maiseman pieneksi joukoksi priorisoituja keskusteluja.

Tämä uudelleenkehystäminen muuttaa kysymyksiä, joita johto esittää. Sen sijaan, että pohdittaisiin, uusitaanko tietty alusta, keskustelu muuttuu siihen, mitkä kyvykkyydet ovat strategisesti erottavia ja ansaitsevat siksi räätälöityä investointia, mitkä ovat välttämättömiä mutta erottamattomia ja siten valmispakettien ehdokkaita, ja mitkä ovat hiipumassa ja jätettävä näivettymään. Rakenna vai osta lakkaa olemasta hankintarefleksi ja muuttuu seuraukseksi siitä, missä kohdassa tuota jatkumoa kyvykkyys sijaitsee. Tiekartat lakkaavat olemasta luetteloja projekteista ja muuttuvat nimettyjen kyvykkyyksien jaksotetuiksi siirtymiksi nykytilasta tavoitetilaan. Kyvykkyys on se, mikä antaa strategian ja arkkitehtuurin puhua samaa kieltä, ja se on se, mikä pitää molemmat kiinnittyneinä liiketoimintaan hetken teknologian sijaan.

Osaamisaluetta muokkaa uudelleen useita voimia yhtä aikaa, ja kannattaa erottaa kestävät muutokset muodista. Merkittävin on siirtymä arkkitehtuurista dokumentaationa arkkitehtuuriksi elävänä mallina. Vuosien ajan tavoitearkkitehtuuri asui diaesityksissä ja staattisissa arkistoissa, jotka olivat vanhentuneita sinä päivänä, kun ne hyväksyttiin. Nykyaikainen käytäntö kohtelee arkkitehtuuria datana: kyvykkyydet, sovellukset, tietovirrat, teknologiat ja niiden suhteet pidetään kyseltävässä mallissa, joka voidaan pitää ajan tasalla ja jota voidaan tutkia. Tämä tekee mahdolliseksi vastata iltapäivässä eikä neljänneksessä siihen, mihin järjestelmiin alustan käytöstä poistaminen vaikuttaisi tai mitkä kyvykkyydet ovat riippuvaisia tuen loppumista lähestyvästä teknologiasta.

Toinen muutos on strategian ja jatkuvan toimituksen välisen rajan hälveneminen. Kun teknologiaa julkaistiin vuosittain, monivuotinen suunnitelma ja vuotuinen katselmus riittivät. Kun tiimit julkaisevat jatkuvasti, staattinen kolmivuotissuunnitelma on rasite. Nykyaikainen vastaus ei ole hylätä suuntaa vaan pitää vakaata tavoitetta kevyesti ja tarkistaa polkua siihen usein. Suunta asetetaan vuosiksi; tiekarttaa kohti sitä tarkastellaan neljännesvuosittain sen valossa, mitä on todella toimitettu ja miltä IT-maisema nyt näyttää.

Kolmas voima on paine, jonka koneoppiminen ja generatiiviset järjestelmät kohdistavat suunnitteluun. Tässä on aitoa sisältöä, mutta se saapuu meluun kääriytyneenä. Kurinalainen vastaus on kohdella näitä kyvykkyyksinä, jotka sijoitetaan malliin kuten mikä tahansa muukin, rehellisesti arvioiden, mitkä ovat erottavia ja mitkä hyödykkeitä, sen sijaan että ne olisivat käsky rakentaa kaikki uudelleen. Tämän ohella suvereniteetti-, datan sijainti- ja resilienssivaatimukset vetävät joitakin organisaatioita takaisin kohti harkittuja hybridi- ja on-premise-valintoja vuosikymmenen ehdottoman cloud-migraation jälkeen. Kypsä asenne ei ole cloud-first tai cloud-only vaan sijoittelu, joka päätetään kyvykkyyskohtaisesti kustannuksia, hallintaa ja sääntelyrajoitteita vasten. Jokaisessa näistä trendeistä vakio on sama: pärjäävät ne organisaatiot, joilla on malli, jota vasten päätellä, ja ne joilla ei ole, hoipertelevat toimittajapuheenvuorosta toiseen.

Tavoitearkkitehtuuri on hyödyllinen vain, jos se on rakennettu kestämään kosketuksen todellisuuden kanssa. Ensimmäinen periaate on huolenaiheiden eksplisiittinen erottaminen kerrosten välillä. Liiketoimintakyvykkyydet, niitä toteuttavat sovellukset, näiden sovellusten hallinnoima data ja teknologia, jolla ne toimivat, tulisi mallintaa erillisinä ja yhdistää selkeillä suhteilla. Kun nämä kerrokset sekoitetaan, muutos yhdessä leviää ennakoimattomasti muihin, eikä kukaan voi jäljittää päätöksen vaikutusaluetta. Erillään pidettynä arkkitehtuurista tulee navigoitava: strategisesta kyvykkyydestä voi liikkua alas siihen tiettyyn teknologiaan, joka sitä rajoittaa.

Toinen periaate on, että arkkitehtuuriperiaatteiden on oltava harvoja, täsmällisiä ja seurauksellisia. Periaate kuten osta erottamattomiin kyvykkyyksiin, rakenna vain siellä missä erotumme on hyödyllinen, koska se ratkaisee todellisia tapauksia ja sulkee asioita pois. Periaate kuten tulemme olemaan ketteriä ja asiakaskeskeisiä ei ratkaise mitään. Hyvät periaatteet kirjoitetaan perusteluineen ja, mikä ratkaisevaa, niiden seuraukset auki kirjoitettuina, jotta kun projekti ehdottaa poikkeusta, tuon poikkeuksen kustannus on näkyvissä. Periaatteet, joita ei voi rikkoa, eivät ole periaatteita; ne ovat pyrkimyksiä. Kurinalaisuus piilee siinä, että kunkin niistä asettama kompromissi nimetään.

Kolmas periaate on suunnitella korvattavuutta pysyvyyden sijaan. Mikään komponentti IT-maisemassa ei ole ikuinen, joten arkkitehtuurin tulisi minimoida kustannus minkä tahansa niistä poistamisesta. Tämä suosii hyvin määriteltyjä rajapintoja syvän integraation sijaan, standardimuotoisia datamäärittelyjä järjestelmäkohtaisten sijaan ja löyhää kytkentää saumoissa, joissa organisaatio- tai toimittajarajat kulkevat. Viitemallit ansaitsevat paikkansa tässä: yhteinen viitearkkitehtuuri integraatiolle, datalle tai yhteiselle toimialueelle antaa tiimeille hyväksytyn mallin seurattavaksi, mikä vähentää räätälöityjen päätösten määrää ja siten tulevien rasitteiden määrää. Tavoitteena ei ole täydellinen lopputila, joka ei koskaan saavu, vaan IT-maisema, jonka osat voidaan vaihtaa ilman että jokaisesta vaihdosta tulee kaivaustyö.

Tämän osaamisalueen epäonnistumistavat ovat riittävän johdonmukaisia nimettäviksi. Norsunluutorni. Arkkitehtuuritoiminto vetäytyy tuottamaan tyylikkäitä tavoitetilamalleja, joita toimitustiimit eivät ymmärrä eivätkä noudata. Dokumentit ovat sisäisesti johdonmukaisia ja käytännössä eloperäisiä. Ratkaisu ei ole parempia kaavioita vaan arkkitehtien upottaminen todellisten päätösten virtaan, jossa heidän mallinsa testataan todellisia projekteja vasten ja pidetään ajan tasalla tuolla kitkalla.

Strategia ja maisema ajautuvat erilleen. Suunta asetetaan vakaumuksella, minkä jälkeen organisaatio lakkaa tarkistamasta, liikkuuko IT-maisema todella kohti sitä. Projektit toimittavat, poikkeukset kertyvät ja kolme vuotta myöhemmin todellinen maisema muistuttaa vain vähän tavoitetta, jota kukaan ei tarkastellut uudelleen. Tämä on yleisin ja kaikkein syövyttävin epäonnistuminen, koska jokainen yksittäinen poikkeama oli järkevä. Sen estäminen vaatii hallintarytmin, joka vertaa aikomusta todellisuuteen kiinteällä tahdilla ja kohtelee erotusta ensisijaisena johtamissignaalina.

Rakenna vai osta refleksinä. Päätökset asettuvat oletusarvoisesti siihen, mitä organisaatio kulttuurisesti suosii, rakentaen kaiken koska pystyy, tai ostaen kaiken välttääkseen insinöörityötä, sen sijaan että päätettäisiin tapauskohtaisesti sitä vasten, missä kohdassa kyvykkyys strategisesti sijaitsee. Tuloksena on räätälöidyt järjestelmät hyödyketoiminnoille tai valmispakettien rajoitteet juuri niille kyvykkyyksille, joiden tulisi erottaa. Tiekartat projektiluetteloina. Tiekartta, joka luettelee rahoitetut projektit jaksotettujen kyvykkyyssiirtymien sijaan, optimoi sen suhteen mikä on jo hyväksytty ja kadottaa langan siihen, minne organisaatio yrittää päästä. Meren keittäminen. Yritys mallintaa koko maisema yhtenäiseen syvyyteen ennen kuin mitään päätetään, mikä tuottaa valtavan artefaktin eikä yhtäkään päätöstä. Kurinalaisuus on mallintaa siihen syvyyteen, jonka päätös vaatii, eikä pidemmälle, ja sitten liikkua. Jokaisella näistä epäonnistumisista on yhteinen juuri: liiketoiminta-aikomuksen ja teknisen todellisuuden välinen sidekudos annetaan katketa.

Nashua kohtelee IT-strategiaa ja arkkitehtuuria jatkuvana käytäntönä eikä kertaluonteisena toimeksiantona, joka päättyy tuotokseen. Työ alkaa yleensä koordinaatiston pystyttämisestä: kyvykkyysmallista, joka heijastaa sitä, miten tämä organisaatio todella toimii, arvioituna liiketoiminnallisen tärkeyden, järjestelmien kunnon ja kustannusten suhteen. Tuo arviointi on tarkoituksellisesti todistuspohjainen. Sen sijaan että hyväksyisi idealisoidun organisaatiokaavion, Nashua tutkii todellista IT-maisemaa: mitä sovelluksia on olemassa, mitä ne maksavat, miten ne integroituvat ja mitä kyvykkyyksiä ne aidosti tukevat. Esiin nouseva lämpökartta on yleensä epämukava ja aina selkeyttävä, koska se tekee aikomuksen ja todellisuuden välisen kuilun ensimmäistä kertaa näkyväksi.

Tuosta lähtötasosta suunta asetetaan tavoitearkkitehtuurina, joka ilmaistaan samalla kyvykkyyskielellä ja jota täydentää pieni joukko arkkitehtuuriperiaatteita, jotka on kirjoitettu kompromissit eksplisiittisesti esiin tuoden. Nashua suosii periaatteita, jotka ratkaisevat tapauksia, ja viitemalleja, jotka antavat tiimeille hyväksyttyjä malleja, jotta arkkitehtuuri vähentää avoimien kysymysten määrää sen sijaan että lisäisi katselmuskerroksen. Rakenna vai osta ja cloud vai on-premise -päätökset kehystetään kyvykkyyskohtaisesti, sen strategista painoarvoa sekä sääntely- ja kustannusrajoitteita vasten, ei kaikenkattavana linjauksena.

Sitä seuraava tiekartta jaksotetaan kyvykkyyssiirtyminä nykytilasta tavoitetilaan, riippuvuudet ja käytöstä poistot tehden yhtä näkyviksi kuin uudet investoinnit, koska ne järjestelmät, jotka organisaatio sammuttaa, ovat yhtä tärkeitä kuin ne, jotka se rakentaa. Ratkaisevaa on, että Nashua ottaa käyttöön hallintarytmin, joka estää strategiaa ja maisemaa ajautumasta erilleen: säännöllisen vertailun siitä, missä IT-maisema todella on, siihen missä tavoite sanoo sen olevan, ja erotusta kohdellaan signaalina, joka ohjaa seuraavia päätöksiä. Tämä on epäglamouria ja se on osa, joka jätetään useimmiten väliin, mikä on juuri syy siihen, että siihen arvo kertyy. Nashuan rooli on pitää suunta vakaana samalla kun polkua siihen tarkistetaan sitä vasten, mitä organisaatio on todella toimittanut.

Ero, jonka Nashua tuo, ei ole niinkään mikään yksittäinen artefakti vaan pikemminkin kurinalaisuus pitää aikomus ja todellisuus yhteydessä ajan mittaan. Monet yritykset osaavat tuottaa tavoitearkkitehtuurin; huomattavasti harvempi hallitsee sitä vasten vielä kaksi vuotta myöhemmin, kun paikallisella optimoinnilla on ollut aikaa vaikuttaa. Nashuan tekijät ovat istuneet pöydän molemmilla puolilla, asettaen strategiaa ja sitten eläen sen tuloksena syntyvän IT-maiseman kanssa, ja tuo kokemus näkyy neuvoissa, jotka ovat täsmällisiä eivätkä yleisluontoisia, ja periaatteissa, jotka kestävät ensimmäisen vaikean projektin eivätkä ensimmäistä hiljaista viikkoa. Työn mittari ei ole mallin tyylikkyys vaan se, voiko organisaatio vuosien päästä yhä luottavaisesti sanoa, minne se on menossa ja kuinka pitkällä se on.

Tähän liittyy myös käytännöllinen seuraus, joka muuttaa sitä, mitä työn sallitaan 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 vauhdilla, agenttipohjaisen engineerin avulla: tarvittava kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, jotta nopeus ei koskaan tule johdonmukaisuuden, tietoturvan tai hallinnan kustannuksella. Vaikutus on strateginen eikä pelkästään mukava. Se siirtää rakenna vai osta -rajaa, pitää valinnanvapauden edullisena ja antaa arkkitehtuurin seurata strategiaa sen sijaan että strategia taipuisi siihen, mitä sattui olemaan hyllyllä.

Sen sitoo yhteen kieltäytyminen antamasta osaamisalueen muuttua teatteriksi. Strategia ja arkkitehtuuri ansaitsevat paikkansa vain silloin, kun ne muuttavat sitä mitä rakennetaan, mitä ostetaan ja mitä sammutetaan, ja kun ne jatkavat tekemistä niin liiketoiminnan ja sen teknologian liikkuessa niiden alla. Nashuan panos on tehdä tuosta yhteydestä kestävä: yhteinen näkemys suunnasta, ilmaistuna kyvykkyyksinä, jotka liiketoiminta tunnistaa, pidettynä rehellisenä todellista IT-maisemaa vasten tahdilla, joka ei raukea. Se on se, mikä estää teknologiamaisemaa ajautumasta erilleen organisaatiosta, jota sen on tarkoitus palvella, ja siinä harkitseva kumppani on arvokkaampi kuin mikään kaavio.