Suurimman osan viimeisistä kahdesta vuosikymmenestä niukka resurssi yritystoimituksissa oli kyky ylipäätään rakentaa. Tiimit olivat hitaita, ympäristöt manuaalisia ja julkaisut tapahtumia. Aikakauden arkkitehtoninen energia meni toimitusten avaamiseen: monoliittien pilkkomiseen, cloudin käyttöönottoon, jatkuvaan integraatioon siirtymiseen ja tiimien autonomian rakentamiseen, jotta ne omistaisivat palvelunsa päästä päähän. Tuo ohjelma onnistui pääosin. Nykyään niukka resurssi ei ole enää kyky rakentaa. Se on kyky rakentaa yhtenäisesti, niin että se, minkä kymmenet autonomiset tiimit tuottavat, kokoontuu järjestelmäksi eikä kokoelmaksi.

Muutoksella on merkitystä, koska kustannukset ovat siirtyneet. Kun yksi tiimi rakensi hitaasti, kustannus oli paikallinen ja näkyvä. Kun neljäkymmentä tiimiä rakentaa nopeasti ja eri suuntiin, kustannus on systeeminen ja siirtyy tulevaisuuteen: se ilmenee integraatioverona, päällekkäisenä kyvykkyytenä, tietoturvapoikkeuksina ja kyvyttömyytenä muuttaa jaettua osa-aluetta, kuten identiteettiä tai havainnoitavuutta, koskettamatta jokaista palvelua käsin. Mitään tästä ei näy yhdenkään tiimin taululla. Se kertyy tiimien välisiin tiloihin, juuri sinne missä yksikään tiimi ei ole vastuussa.

Kaksi voimaa on terävöittänyt tätä. Ensimmäinen on organisatorinen: tiimien tiimi -malli, joka yleistyi tapana skaalata toimituksia, poistaa tarkoituksella keskitetyn koordinaattorin. Autonomia on koko pointti, ja sitä kannattaa puolustaa. Toinen on tekninen: cloudin ja alustojen talous palkitsee standardointia voimakkaasti, koska kaikkien noudattama malli voidaan automatisoida, suojata ja operoida kertaalleen, kun taas räätälöity valinta on kannettava ikuisesti. Organisaatio, joka ei kykene tarjoamaan hyviä oletuksia, ei saa autonomiaa ilman kustannusta. Se saa hajaantumista ja maksaa siitä jokaisena sitä seuraavana vuosineljänneksenä.

Referenssiarkkitehtuuria käsitellään usein yhtenä artefaktina, tavallisesti kaaviona. Hyödyllisempää on nähdä se yhtenä pisteenä arkkitehtonisten resurssien kirjolla, jotka eroavat abstraktiotasoltaan ja sitovuudeltaan. Koko kirjon ymmärtäminen on juuri se, mikä antaa organisaation valita oikean välineen kuhunkin päätökseen sen sijaan, että se tarttuisi asiakirjaan joka kerta.

Abstrakteimmassa päässä ovat periaatteet: kestäviä aikomuksen ilmauksia, jotka selittävät, miksi organisaatio suosii yhtä ratkaisuluokkaa toisen sijaan. Periaate kuten suosi hallittuja palveluita itse operoidun infrastruktuurin sijaan ei kerro kenellekään, mitä rakentaa, mutta se rajaa hyväksyttävien vastausten joukkoa. Periaatteiden alapuolella ovat mallit: nimettyjä, uudelleenkäytettäviä ratkaisuja toistuviin ongelmiin, kuvattuna riittävällä kontekstilla, jotta tiimi tunnistaa milloin malli soveltuu ja mukauttaa sitä. Malli ei ole määräys; se on talteen otettua kokemusta, joka tarjotaan oletukseksi.

Referenssiarkkitehtuuri on suurempi kokonaisuus: kantaaottava järjestely malleja, teknologioita ja rajapintoja, joka ratkaisee kokonaisen ongelmaluokan, kuten tapahtumapohjaisen integraatioselkärangan tai vakiomuotoisen asiakaskäyttöisen verkkosovelluksen. Se on määräävä rakenteen suhteen mutta jättää toteutuksen avoimeksi. Standardit ovat kapeita, testattavia sitoumuksia, jotka saavat itsenäiset toteutukset toimimaan yhteen: identiteettiprotokolla, lokiskeema, API-tyyli, tägäyskäytäntö. Standardeissa yhtenäisyys todella pannaan täytäntöön, koska ne ovat riittävän täsmällisiä tarkistettaviksi.

Konkreettisessa päässä ovat suojakaiteet: periaatteiden, standardien ja mallien suoritettava ilmaus, koodattuna niin että turvallinen polku on oletus ja vaarallinen polku estetään tai merkataan automaattisesti. Ratkaiseva ero tällä kirjolla on niiden resurssien välillä, jotka informoivat päätöstä, ja niiden, jotka rajoittavat sitä. Molemmat ovat oikeutettuja. Vaikeudet alkavat, kun organisaatio kirjoittaa kaiken informatiivisena proosana ja ihmettelee sitten, miksi mikään ei lähene, tai kirjoittaa kaiken kovana estona ja ihmettelee sitten, miksi tiimit kiertävät alustan.

Viime vuosien näkyvä suuntaus on arkkitehtonisen resurssin ja sen käytön välisen etäisyyden romahtaminen. Referenssiarkkitehtuuri, joka eli diaesityksenä jaetulla asemalla, jota katsottiin harvoin ja noudatettiin valikoivasti, korvautuu päällystetyllä tiellä: joukolla oletuksia, jotka tiimi voi ottaa käyttöön aloittamalla mallipohjasta, ajamalla putken ja perimällä säädösten mukaisen perustason lukematta lainkaan asiakirjaa. Resurssi on siirtynyt jostakin, mistä sinulle kerrotaan, joksikin, jonka päälle rakennat.

Alustakehitys on organisatorinen muoto, jonka tämä saa. Sisäinen alustatiimi kohtelee kultaista polkua tuotteena, jonka asiakkaita toimitustiimit ovat, ja mittaa itseään käyttöönotolla eikä julkaisulla. Tämä uudelleenkehystys on merkittävämpi kuin miltä kuulostaa. Asiakirja on valmis, kun se on kirjoitettu; tuote ei ole koskaan valmis, koska sen on jatkuvasti ansaittava käyttönsä sitä vaihtoehtoa vastaan, että tiimit tekevät sen itse. Juuri tuo paine pitää referenssiarkkitehtuurin rehellisenä.

Tämän rinnalla policy-as-code on siirtänyt hallinnan arviointikokouksista putkeen. Säännöt sallituista alueista, vaadituista salauksista, pakollisista tägeistä tai hyväksytyistä perusimageista ilmaistaan koodina ja arvioidaan automaattisesti suunnittelu- tai käyttöönottohetkellä. Sama vaisto tuottaa arkkitehtuurin kuntofunktiot: automaattisia testejä, jotka väittävät rakenteellisia ominaisuuksia, kuten kiellettyjä riippuvuuksia kerrosten välillä tai vakiomuotoisen terveydentilan rajapinnan olemassaolon, niin että arkkitehtoninen aikomus todennetaan jatkuvasti eikä tarkasteta satunnaisesti. Architecture-as-code ja versioidut, koneluettavat mallit täydentävät kuvan: standardia ei pelkästään kuvata, se on määritelmä, jota muut järjestelmät voivat kuluttaa, josta ne voivat generoida ja jota vasten ne voivat tarkistaa. Kulkusuunta on johdonmukainen. Yhtenäisyyttä siirretään vasemmalle, pois arviointilautakunnasta ja niihin työkaluihin, joita tiimit jo käyttävät, missä sen noudattaminen ei maksa mitään ylimääräistä.

Se, käytetäänkö jaettuja resursseja todella uudelleen, riippuu vähemmän niiden teknisestä laadusta kuin muutamasta resursseja itseään koskevasta suunnitteluvalinnasta. Ensimmäinen on, että oletuksen on oltava aidosti helpompi kuin vaihtoehdon. Malli, joka tiimin on löydettävä, tulkittava ja koottava käsin, kilpailee tasavertaisesti tiimin oman harkinnan kanssa, ja harkinta yleensä voittaa. Malli, joka toimitetaan valmiina mallipohjana, kytkettynä putkeen ja oletuksena suojattuna, ei kilpaile; se on yksinkertaisesti vähimmän vastuksen polku. Uudelleenkäyttö seuraa mukavuutta paljon luotettavammin kuin oikeellisuutta.

Toinen periaate on, että suojakaiteiden tulisi rajoittaa lopputuloksia, ei määrätä jokaista askelta. Hyödyllinen sitoumus on, että kaikki palvelut tarjoavat todennuksen vakiomuotoisen identiteetintarjoajan kautta, ei että jokainen palvelu kirjoitetaan yhdellä ohjelmistokehyksellä. Kultaiset polut, jotka määräävät liikaa yksityiskohtia, muuttuvat hauraiksi ja hylätään sillä hetkellä, kun tiimillä on oikeutetusti erilainen tarve. Taito on tehdä mallin raja eksplisiittiseksi, niin että tiimi tietää tarkalleen, missä sen on mukauduttava ja missä se on vapaa, ja suunnitella hyväksytty tapa poiketa sen sijaan, että teeskenneltäisiin ettei poikkeamia tapahdu.

Kolmas periaate on versiointi ja kehittyminen ensiluokkaisina huolenaiheina. Referenssiarkkitehtuuri on väite nykyhetkestä, joka on väärä kahdeksantoista kuukauden kuluttua. Jos sitä ei voida versioida, poistaa käytöstä ja migratoida kuten mitä tahansa muuta riippuvuutta, se luutuu, ja tiimit oppivat sivuuttamaan sen, koska sen noudattaminen tarkoittaa sellaisten päätösten perimistä, joihin organisaatio itsekään ei enää usko. Neljäs periaate on, että jokainen standardi kantaa oman täytäntöönpanonsa kustannuksen. Standardi, jota kukaan ei tarkista, on neuvo, eikä neuvo tuota yhtenäisyyttä mittakaavassa. Kysymys, joka esitetään mille tahansa ehdotetulle standardille, ei ole onko se oikea vaan onko se testattavissa ja kuka ajaa testin. Jos automaattista vastausta ei ole, standardi on tavoitteellinen, ja se tulisi merkitä sellaiseksi eikä erehtyä pitämään sitä valvontana.

Jaetun resurssin ohjelmat epäonnistuvat tunnistettavilla tavoilla, ja epäonnistumistapojen nimeäminen on nopein reitti niiden välttämiseen. Norsunluutorni. Arkkitehdit määrittelevät referenssikokonaisuuden erillään niistä tiimeistä, joiden on siinä elettävä. Tulos on sisäisesti elegantti ja käytännössä käyttökelvoton, koska sitä ei koskaan koeteltu todellista toimitusrajoitetta vasten. Tuntomerkki on kaunis luettelo lähes olemattomalla käyttöönotolla, ja diagnoosi on, että resurssit julkaistiin sen sijaan että ne olisi suunniteltu yhdessä.

Kullattu oletus. Päällystetty tie on olemassa mutta on raskaampi, hitaampi tai rajoittavampi kuin asian tekeminen itse, joten pätevät tiimit rakentavat hiljaa oman polkunsa ja kultainen polku palvelee vain niitä, joilta puuttuu taito paeta. Tämä on vaarallisin epäonnistuminen, koska se näyttää osittaiselta onnistumiselta valikoiden samalla aktiivisesti vääriä käyttäjiä. Kultainen polku, jota vain heikoimmat tiimit käyttävät, ei ole standardi; se on tukiopetuskaista.

Standardit arkeologiana. Wiki sisältää neljäkymmentä standardia, puolet ovat keskenään ristiriidassa, kolmasosa kuvaa teknologioita, jotka eivät ole enää käytössä, eikä yhdessäkään ole päivämäärää tai omistajaa. Tiimit eivät osaa erottaa elävää ohjeistusta kerrostumasta, joten ne kohtelevat kaikkea perustellusti valinnaisena. Suojakaiteet pelkkänä esteenä. Hallinta ilmaistaan pelkästään estoina, ilman tarjottua päällystettyä vaihtoehtoa, joten suojakaide opettaa tiimit näkemään arkkitehtuurin ei-osastona ja sijoittamaan kekseliäisyytensä kiertämiseen. Esto ilman tuettua polkua eteenpäin ei nosta kokonaisuuden tasoa; se nostaa kiertotoimien tasoa. Versioimaton totuus. Referenssiarkkitehtuuria kohdellaan ajattomana, sitä ei koskaan poisteta käytöstä, joten se etääntyy hitaasti siitä, mitä organisaatio todella suosittelee, kunnes sen uskollinen noudattaminen on itsessään virhe. Jokaisella näistä epäonnistumisista on sama juuri: resurssi optimoitiin oikeellisuuden lausumana eikä joksikin, jota kiireinen tiimi järkevästi valitsisi käyttää.

Nashua lähestyy referenssiarkkitehtuuria ja standardeja tarjontaongelmana, ei hallintaongelmana, ja toimeksianto muotoillaan sen mukaisesti. Aloitamme kartoittamalla kokonaisuuden sellaisena kuin se todella on eikä sellaisena kuin tavoitekaavio väittää: missä tiimit ovat jo lähentyneet ilman käskyä, missä ne ovat hajaantuneet ja millä kustannuksella, ja mitä toistuvia ongelmia ratkaistaan tyhjästä yhä uudelleen. Tuo hajaantumiskartta on todellinen työjono, koska se osoittaa tarkalleen, missä jaettu oletus maksaisi takaisin rakentamisensa vaivan ja missä standardointi vain lisäisi seremoniaa ongelmaan, joka ei toistu.

Tuosta kartasta työskentelemme toimitustiimien kanssa, emme heidän ohitseen, tislataksemme talteen ottamisen arvoiset mallit. Malli ansaitsee paikkansa luettelossa vasta, kun se on ratkaissut todellisen ongelman todelliselle tiimille, mikä pitää norsunluutornin loitolla ja varmistaa, että ensimmäinen käyttäjä on kannattaja eikä pakotettu. Olemme harkitsevia sen suhteen, missä kukin resurssi sijaitsee kirjolla periaatteesta suojakaiteeseen, ja sen suhteen, miten se sitoo: mikä on aidosti pakollista ja automaattisesti täytäntöönpantua, mikä on vahva oletus jolla on hyväksytty polku poiketa, ja mikä on pelkkää ohjeistusta tarjottuna ilman velvoitetta. Näiden sekoittaminen on yleisin lähde sekä närälle että ajautumiselle, ja niiden puhdas erottaminen on suurin osa arvosta.

Sitten teemme oletuksesta helpon polun. Se tarkoittaa panostamista mallipohjiin, putken integraatioon, policy-as-codeen ja kuntofunktioihin, niin että mallin käyttöönotto on kysymys päällystetyltä tieltä aloittamisesta eikä siitä lukemisesta, ja niin että vaatimustenmukaisuus tarkistetaan jatkuvasti eikä portilla. Kaiken aikaa kohtelemme resursseja tuotteena, jolla on omistajat, versiot ja käytöstäpoiston kurinalaisuus, ja luovutamme toimintamallin, joka pitää luettelon elossa lähtömme jälkeen. Mitta, johon itsemme sidomme, ei ole se kuinka monta standardia on olemassa vaan kuinka montaa noudatetaan oletuksena ja kuinka paljon integraatiovero on sen seurauksena laskenut.

Ero, jonka Nashua tuo, on kieltäytyminen kohtelemasta referenssiarkkitehtuuria dokumentaatioharjoituksena. Monet yritykset tuottavat komean mallien luettelon ja joukon standardeja, esittelevät ne ja lähtevät. Luettelo ei ole lopputulos. Lopputulos on kokonaisuus, jossa itsenäiset tiimit rakentavat yhtenäisesti ilman keskitettyä pullonkaulaa, ja tuo lopputulos riippuu kokonaan siitä, ovatko resurssit halvempia noudattaa kuin sivuuttaa. Pidämme toimeksiannon tuossa kovemmassa mitassa, ja tuomme sekä arkkitehtonisen harkinnan päättääksemme mitä pitäisi standardoida että alustakehityksen kyvykkyyden tehdäksemme noista standardeista suoritettavia eikä tavoitteellisia.

Tästä seuraa myös käytännöllinen johdannaisvaikutus, joka muuttaa sen, mitä työ saa olettaa. Kun toimeksianto vaatii kyvykkyyttä, jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintakierrosta tai toimittajan tiekarttaa. enterprise platform on rakennettu mukautumaan lähes mihin tahansa ominaisuuteen vauhdilla, agenttipohjaisen suunnittelun kautta: tarvittava kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, niin että nopeus ei koskaan tule yhtenäisyyden, tietoturvan tai hallinnan kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää tee tai osta -rajaa, pitää valinnanvapauden halpana ja antaa arkkitehtuurin seurata strategiaa sen sijaan, että strategia taipuisi sen mukaan, mitä sattui olemaan hyllyllä.

Eroa ylläpitää se, että ajattelemme toimintamalleina emmekä toimituksina. Referenssiarkkitehtuuri, jota ei versioida, rappeutuu; standardi, jota ei panna täytäntöön, on neuvo; kultainen polku, jota ei ylläpidetä tuotteena, hylätään sillä hetkellä, kun parempi paikallinen vaihtoehto ilmestyy. Rakennamme omistajuuden, kehittymisen kurinalaisuuden ja automaattisen vaatimustenmukaisuuden, jotka pitävät jaetut resurssit ansaitsemassa käyttönsä kauan alkuperäisen työn valmistumisen jälkeen, ja mittaamme onnistumista laskevana integraatiokustannuksena ja nousevana oletusten käyttöönottona emmekä luettelon koossa. Yhtenäisyyden arvo mittakaavassa ei ole siinä, että jokainen tiimi tekee saman asian. Se on siinä, että organisaatio ottaa jokaisen kovalla työllä ansaitun päätöksen talteen kerran ja käyttää sitä monta kertaa, ja että autonomia ja yhtenäisyys lakkaavat olemasta kompromissi ja muuttuvat samaksi päällystetyksi tieksi.