Enterprise Architecture & Business-IT Alignment
Kokonaisarkkitehtuuri muistetaan suurten kaavioiden ja pitkien hyväksyntäjonojen tieteenalana, hallintotoimintona, joka saapuu vasta sitten kun mielenkiintoiset päätökset on jo tehty. Tuo maine kuvaa käytännön epäonnistumista, ei työn tarkoitusta: arkkitehtuuri on olemassa pitääkseen liiketoiminnan tavoitteiden ja järjestelmien kyvykkyyksien välisen suhteen riittävän ymmärrettävänä, jotta sitä voidaan ohjata. Seuraavassa esitetään, miten päättelemme liiketoiminnan ja IT:n yhteensovittamista silloin kun maasto liikkuu nopeammin kuin mikään sitä kuvaava malli ehtii vakiintua, ja miksi arvo piilee nykyään muutoksen pitämisessä edullisena eikä harvinaisena.
Järjestelmämaisemasta on tullut liikkuva maali
Suurimman osan historiastaan kokonaisarkkitehtuuri oletti tutkimuskohteensa vakaaksi. Sovellusportfolio muuttui usean vuoden syklissä, integraatio oli kallista ja siksi harvinaista, ja hyvin piirretty malli saattoi kuvata järjestelmämaiseman tarkasti koko suunnittelusyklin ajan. Näissä oloissa arkkitehti saattoi perustellusti toimia vartijana: pitää hallussaan kanonisen kokonaiskuvan, hyväksyä poikkeamat ja puolustaa yhtenäisyyttä paikallista tarkoituksenmukaisuutta vastaan. Menetelmä vastasi hallitsemansa teknologian fysiikkaa.
Tuo oletus on hiljaa vanhentunut. Pilvialustat, hallitut palvelut, ohjelmisto joka toimitetaan käyttöliittymänä eikä asennuksena, sekä tavanomainen odotus siitä että tiimit julkaisevat jatkuvasti, ovat kaikki nostaneet järjestelmämaiseman aineenvaihdunnan tahtia. Kyvykkyys, jonka pystyttäminen vei aiemmin kahdeksantoista kuukautta, koostetaan nyt iltapäivässä palveluista, jotka tiimi on saattanut valita kysymättä keneltäkään. Seuraus ei ole se että arkkitehtuurin merkitys vähenisi, vaan se että mikä tahansa hitaasti liikkuvan tuotoksen valvomiseksi rakennettu arkkitehtuurikäytäntö on nyt pysyvästi jäljessä sitä, mitä se väittää kuvaavansa.
On syytä olla täsmällinen sen suhteen, mikä on muuttunut, koska houkutus on käsitellä tätä mittakaavaongelmana, jonka parempi työkalutus lopulta ratkaisee. Ei se ole sitä. Vaikeus on rakenteellinen. Kun mikä tahansa tiimi voi hankkia hallitun palvelun yrityksen luottokortilla ja kytkeä sen prosessiin viikon loppuun mennessä, arkkitehtuuripäätösten painopiste on jo hajaantunut organisaation reunoille, tunnusti keskitetty toiminto sitä tai ei. Käytäntö joka reagoi tähän kiristämällä hyväksyntää vain siirtää nuo päätökset varjoihin, joissa ne tehdään ilman kirjausta ja havaitaan vasta kun jokin hajoaa. Rehellinen lähtökohta on, että valta järjestelmämaisemaan on nyt oletusarvoisesti hajautettua, ja työ on tehdä hajautetuista päätöksistä ymmärrettäviä sen sijaan että teeskenneltäisiin niiden voitavan koota takaisin yhteen paikkaan.
Merkityksellinen muutos on siis tarkoituksen eikä työkalujen muutos. Arvokas kysymys ei enää ole se, noudattaako järjestelmämaisema mallia, koska se ei noudata, ja noudattamisen pakottaminen työntää päätökset yksinkertaisesti kehyksen ulkopuolelle, jossa niitä ei voi nähdä. Arvokas kysymys on se, pystyykö liiketoiminta yhä päättelemään mitä se omistaa, mitä varten nuo osat ovat, ja mihin strategian muutoksen olisi kohdistuttava. Arkkitehtuuri ansaitsee paikkansa pitämällä tuon päättelyn mahdollisena samalla kun kaikki sen alla liikkuu. Siitä tulee tapa ylläpitää yhteistä ymmärrystä, ei kontrolli joka jäädyttää kuvan ymmärtääkseen sitä.
Yhteensovittamisen yksikkönä kyvykkyydet, eivät järjestelmät
Ensimmäinen periaate josta lähdemme on se, että liiketoiminta ja teknologia sovitetaan yhteen kyvykkyyksien kautta, ei sovellusten. Kyvykkyys on vakaa lausuma jostakin, mitä organisaation on kyettävä tekemään: käsittelemään korvausvaatimus, ottamaan asiakas käyttöön, ennustamaan kysyntää, täsmäyttämään kirjanpito. Se on tarkoituksellisesti abstrakti sen suhteen, miten tekeminen tapahtuu. Järjestelmät, tiimit ja prosessit ovat muuttuvia keinoja; kyvykkyys on pysyvä päämäärä. Tämä erottelu ei ole akateeminen. Strategia ilmaistaan luontevasti sen kautta mitä liiketoiminta haluaa tehdä paremmin tai uudella tavalla, ja kyvykkyydet ovat ainoa sanasto, jossa tuo aikomus kartoittuu selkeästi järjestelmämaisemaan.
Kyvykkyyspohjainen suunnittelu antaa yhteensovittamiselle selkärangan. Tarkoituksellisen matalana pidetty kyvykkyyskartta antaa mahdollisuuden kysyä, mistä kyvykkyyksistä strateginen tavoite todella riippuu, mitkä ovat vahvoja ja mitkä hauraita, ja missä investointi muuttaisi lopputulosta sen sijaan että vain päivittäisi teknologian. Se erottaa kysymyksen siitä mikä on tärkeää kysymyksestä siitä mitä on tällä hetkellä asennettuna, ja näillä kahdella kysymyksellä on hyvin erilaiset vastaukset useimmissa maisemissa. Suuri osa kustannuksista kertyy kyvykkyyksille, joilla ei enää ole strategista painoarvoa, juuri siksi että keskustelu kehystettiin järjestelmien kautta, joissa jokaisella järjestelmällä on tukija, eikä kyvykkyyksien kautta, joissa merkityksellisyydestä voidaan väitellä.
Tähän kuuluu varoitus, koska kyvykkyysmallinnuksella on oma patologiansa. Asiantuntijoiden käsissä se hajoaa loputtomiin, ja kartta joka aiemmin mahtui yhdelle sivulle muuttuu useiden satojen alakyvykkyyksien taksonomiaksi, jota yksikään johtaja ei koskaan lue eikä yksikään insinööri koskaan tutki. Kehyksen arvo romahtaa juuri sillä hetkellä kun siitä tulee kattava. Pidämme kartan kahdessa tasossa, korkeintaan kolmessa, sen verran että voidaan väitellä siitä missä strategia kohtaa järjestelmämaiseman eikä enempää, koska tarkoitus on yhteinen keskustelu eikä täydellinen ontologia. Kyvykkyysmalli on linssi päätöstä varten, ja linssi joka yrittää näyttää kaiken ei näytä mitään hyödyllistä.
Toinen periaate on se, että arkkitehtuuri kuvaa suhteita, ei komponentteja. Mielenkiintoinen tieto on harvoin sovellusten luettelo; se on se, miten muutos yhdessä kyvykkyydessä etenee: mitkä alavirran prosessit olettavat vanhan käyttäytymisen, mitkä datasopimukset rikkoutuisivat, minkä sääntelyvelvoitteen hoitaa hiljaa järjestelmä jota kukaan ei ajattele. Arkkitehtuuri joka vangitsee riippuvuudet ja aikomukset, ja pitää ne riittävän löyhinä jatkuvaan päivittämiseen, on arvokkaampi kuin tyhjentävä inventaario joka on oikein allekirjoituspäivänään ja väärin kuukauden sisällä.
Ajankohtaiset kehityskulut ja mallit
Koostettavuus oletusasenteena. Järjestelmämaisemat kootaan yhä useammin itsenäisesti hankituista palveluista sen sijaan että ne rakennettaisiin yhtenäisinä kokonaisuuksina, ja arkkitehtuurin tehtävä siirtyy järjestelmien suunnittelusta muiden rakentamien asioiden välisten sopimusten, rajojen ja datan semantiikan suunnitteluun. Tieteenala siirtyy rakentamisesta koostamiseen, ja niukaksi taidoksi muodostuu sen päättäminen, mihin raja tulisi asettaa, jotta kumpi tahansa puoli voi muuttua kysymättä lupaa toiselta.
Sisäisten alustojen tuotteistaminen. Monet organisaatiot pyörittävät nyt sisäisiä alustoja, jotka tarjoavat kyvykkyyksiä toimitustiimeille itsepalvelutuotteina, joilla on selkeät rajapinnat ja omistetut tiekartat. Tämä muotoilee arkkitehtuurin uudelleen niiden asfaltoitujen polkujen suunnitteluksi, jotka tekevät järkevästä valinnasta helpon, eikä tarkastukseksi joka nappaa epäjärkevän valinnan jälkikäteen. Hallinnasta tulee jotakin mitä tiimit kuluttavat eikä jotakin mitä niille tehdään.
Arkkitehtuuripäätöskirjaukset yleisdokumenttien sijaan. Painopiste on siirtymässä suurista ylläpidetyistä malleista kohti kevyitä, versioituja kirjauksia yksittäisistä päätöksistä ja niiden perusteluista. Päätösloki vanhenee rehellisesti: se kertoo mikä oli totta valinnan tekohetkellä ja miksi, mikä on hyödyllisempää kuin kaavio joka teeskentelee olevansa pysyvästi ajan tasalla. Se myös palauttaa vastuullisuuden, koska nimen ja päivämäärän saanut päätös voidaan tarkastella uudelleen kun sen oletukset vanhenevat.
Yksittäisen totuuden lähdejärjestelmän perääntyminen. Vuosikymmenten ajan tavoitteena oli yksi arvovaltainen tietovarasto toimialuetta kohti, ja integraatio tarkoitti kaiken täsmäyttämistä takaisin siihen. Tuo malli väistyy hajautetun omistajuuden tieltä, jossa useat palvelut pitävät hallussaan päällekkäisiä näkymiä ja yksimielisyyteen päästään julkaistujen sopimusten kautta eikä jaetun tietokannan avulla. Tämä on rehellisempää sen suhteen miten suuret organisaatiot todella toimivat, mutta se siirtää vaikean ongelman tallennuksesta merkitykseen: järjestelmämaisema on yhtenäinen vain siltä osin kuin sen osat ovat yksimielisiä siitä mitä asiakas, tilaus tai tili tarkoittaa. Arkkitehtuurista tulee tässä asetelmassa yhteisen sanaston vaalimista, ja kiistat jotka aiemmin näyttivät teknisiltä paljastuvat erimielisyyksiksi määritelmistä.
Data ja tekoäly ensiluokkaisina arkkitehtuurikysymyksinä. Kun koneoppiminen siirtyy tavanomaisiin prosesseihin, kysymykset datan alkuperäketjusta, malliriippuvuuksista ja jaetun tiedon semantiikasta lakkaavat olemasta erikoisalan liitteitä ja muuttuvat keskeisiksi sille, onko järjestelmämaisema yhtenäinen. Yhteensovittaminen riippuu yhä enemmän siitä, ovatko liiketoiminta ja sen järjestelmät yksimielisiä siitä mitä data tarkoittaa, ei pelkästään siitä pystyvätkö ne vaihtamaan sitä.
Suunnitteluperiaatteet jotka saavat sen toimimaan
Standardien tulisi vähentää päätöksiä, ei lisätä niitä. Viitearkkitehtuuri ansaitsee paikkansa kun se poistaa työtä sitä noudattavilta tiimeiltä: oletusteknologia, ensisijainen integraatiotyyli, vakiintunut tapa käsitellä identiteettiä, niin että yhdeksänkymmentä prosenttia tapauksista ei vaadi harkintaa ja huomio säästyy sille kymmenelle prosentille joka aidosti poikkeaa. Standardi joka lisää tarkastusvaiheen poistamatta päätöstä on pelkkää yleiskustannusta, ja tiimit tekevät oikein kiertäessään sen.
Tee yhteensovitetusta polusta vähimmän vastuksen polku. Valvonnalla ylläpidetty yhteensovittaminen rapautuu sillä hetkellä kun huomio herpaantuu; malleihin, putkiin, alustoihin ja oletuksiin rakennettu yhteensovittaminen ylläpitää itseään, koska noudattaminen on yksinkertaisesti helpompaa kuin poikkeaminen. Arkkitehdin kestävin tuotos on usein hyvä oletus, ei hyvä käytäntö. Suunnittele ympäristö niin että järkevän asian tekeminen ei vaadi sankaruutta eikä lupaa.
Suosi eksplisiittisiä sopimuksia jaettujen sisäisten rakenteiden sijaan. Kaksi järjestelmämaiseman osaa voivat toimia yhdessä joko sopimalla rajapinnasta tai kurottamalla toistensa oletuksiin, ja jälkimmäinen on aina halvempi tänään ja tuhoisa myöhemmin. Julkaistu sopimus, vaatimatonkin, ilmaisee mihin voidaan luottaa ja siten myös mikä voi vapaasti muuttua sen takana. Tuo raja on se, mikä antaa kahden tiimin liikkua eri nopeuksilla ilman jatkuvaa neuvottelua. Suuri osa työstä on yksinkertaisesti näiden sopimusten nimeäminen, kirjaaminen ja sen rajan puolustaminen, joka erottaa luvatun pelkästä nykyisestä, koska oletus jota ei koskaan luvattu rikkoutuu lopulta jonkun toimesta joka ei koskaan tiennyt sen olevan kantava.
Suunnittele peruutettavuutta varten oikeellisuuden sijaan. Koska järjestelmämaisema liikkuu nopeasti ja tulevaisuus on aidosti epävarma, päätöksen arvokkaampi ominaisuus on usein se, kuinka edullisesti se voidaan peruuttaa, eikä se kuinka varmoja olemme sen oikeellisuudesta. Suosi rajoja jotka eristävät muutoksen, sopimuksia jotka voidaan versioida, ja valintoja jotka eivät sulje muita pois. Arkkitehtuuri joka on optimoitu olemaan ikuisesti oikea taipuu hauraaksi; edulliseen korjaamiseen optimoitu pysyy elossa.
Pidä malli tarkoituksellisesti epätäydellisenä. Kartta joka yrittää vangita kaiken on kallis ylläpitää ja siksi nopeasti hylätty, jolloin se on huonompi kuin ei karttaa lainkaan, koska ihmiset yhä puoliksi luottavat siihen. Pidämme arkkitehtuurituotokset tarkoituksella matalina, vangiten kantavat suhteet ja jättäen yksityiskohdat niille tiimeille jotka elävät niissä. Mallin koe ei ole täydellisyys vaan se, tutkisiko joku sitä ennen päätöksen tekemistä.
Yleiset epäonnistumisen tavat
Norsunluutorniarkkitehtuuri. Malleja jotka on tuotettu erillään toimituksesta, tyylikkäitä paperilla ja käyttämättömiä käytännössä, koska ne kuvaavat järjestelmämaisemaa jonka arkkitehti toivoi olevan olemassa eikä sitä jossa tiimit työskentelevät. Tuotoksesta tulee muistomerkki hetkelle, jota kukaan ei tutki, ja sen tekijät erehtyvät pitämään valitusten puuttumista suostumuksena.
Arkkitehtuuri kontrolliporttina. Kun käytäntö määrittelee itsensä oikeuden kautta sanoa ei, se muuttuu jonoksi. Tiimit oppivat suunnittelemaan tarkastuksen ohi eikä sen kautta, päätökset siirtyvät sinne missä ne voidaan tehdä ilman porttia, ja arkkitehtuuritoiminto päätyy hallitsemaan kuvaa joka ei enää vastaa hyväksymäänsä järjestelmämaisemaa.
Standardointi itsensä vuoksi. Yhtenäisyyttä tavoitellaan pisteen ohi jossa se palvelee mitään, niin että tiimit pakotetaan yhteiseen työkaluun joka ei sovi yhdellekään heistä hyvin, ja yhdenmukaisuuden kustannus ylittää hiljaa sen moninaisuuden kustannuksen jonka se korvaa. Standardeja tulisi perustella yhteiseksi tehdyn asian arvosta, ei väittää hyveeksi itsessään.
Hallinta mitattuna toiminnan määrällä. Käytäntö joka laskee tarkastuksensa, julkaisemansa standardit ja osallistumisensa lautakuntiin näyttää aina kiireiseltä, eikä yksikään noista luvuista kerro mitään siitä onko järjestelmämaisemaa helpompi muuttaa vai kykeneekö liiketoiminta paremmin päättelemään siitä. Kun mittarit palkitsevat liikkeen, toiminto optimoituu liikkeeseen, ja tuotosten kertyminen muuttuu erottamattomaksi edistyksestä. Ainoat luottamisen arvoiset mittarit osoittavat ulospäin: kuinka nopeasti tiimi voi tehdä järkevän muutoksen, kuinka luottavaisesti johtaja voi sanoa mistä kyvykkyys riippuu, kuinka edullisesti aiempi päätös voidaan peruuttaa. Kaikki muu on tieteenala ihailemassa omaa peilikuvaansa.
Ikuisesti ajan tasalla oleva malli. Yksi yleiskaavio jota ylläpidetään sankarillisin ponnistuksin, aina hieman väärässä, ja väärässä tavoilla joita kukaan ei näe ennen kuin päätös tehdään sen varassa. Epäonnistuminen ei ole vanhentuneisuus; se on väärä luottamus, koska arvovaltaiselta näyttävään malliin luotetaan pitkälti sen pisteen ohi jossa se on lakannut olemasta totta.
Yhteensovittaminen julistettuna, ei todistettuna. Ohjausfoorumeita jotka vahvistavat yhteisen kuvan huoneessa samalla kun todellinen maisema poikkeaa sen ulkopuolella, niin että kaikki ovat yksimielisiä arkkitehtuurista joka ei kuvaa kenenkään työtä. Yhteensovittaminen jota ei voi havaita toimivissa järjestelmissä on sosiaalinen rituaali, ei tekninen ominaisuus.
Miten työskentelemme
Aloitamme kyvykkyyksistä emmekä järjestelmistä, koska se on ainoa pohja jolla liiketoimintajohtajat ja insinöörit voivat käydä samaa keskustelua. Toimeksiannon alkuvaiheessa rakennamme matalan kyvykkyyskartan niiden ihmisten kanssa jotka omistavat lopputulokset, käytämme sitä paikantaaksemme missä strategia todella riippuu järjestelmämaisemasta, ja pidämme sitä kaiken seuraavan kehyksenä. Kartta on päättelyn väline, ei ihailtava tuotos, ja pidämme sen riittävän pienenä jotta sen päivittäminen pysyy vaivan arvoisena.
Sieltä eteenpäin työskentelemme päätösten emmekä dokumenttien kautta. Kirjaamme merkitykselliset arkkitehtuurivalinnat perusteluineen ja niiden oletuksineen joihin ne nojaavat, ja saatamme nuo kirjaukset elämään siellä missä työ tapahtuu eikä erillisessä varastossa jota tiimit eivät koskaan avaa. Tämä antaa käytännölle jotain mitä yleismallilähestymistavalla ei koskaan ollut: tavan vanheta arvokkaasti, koska päivämäärän saanut päätös voidaan tarkastella rehellisesti uudelleen kun sen oletukset vanhenevat, ja tavan tuoda uudet tulokkaat mukaan ymmärtämään miksi asiat ovat kuten ne ovat, ei pelkästään mitä ne ovat.
Suosimme mahdollistavia rajoitteita tarkastusporttien sijaan. Missä standardi on säilyttämisen arvoinen, pyrimme toimittamaan sen oletuksena, mallina tai asfaltoituna polkuna jonka tiimit kuluttavat, niin että yhteensovittaminen on ympäristön ominaisuus eikä toimitukselle asetettu vero. Missä aito harkinta on tarpeen, kutsumme sen koolle nopeasti, päätämme niiden ihmisten kanssa jotka vastaavat lopputuloksesta, ja kirjaamme tuloksen. Tavoite läpi koko työn on pitää järjestelmämaisema liiketoiminnalle ymmärrettävänä samalla kun tiimeille jää se itsenäisyys joka tekee heistä nopeita, ja olla läsnä niinä hetkinä joina valinta on kallis peruuttaa sen sijaan että valvottaisiin niitä jotka eivät ole.
Olemme myös tarkkaharkintaisia sen suhteen miten toimeksianto päättyy, koska käytäntö joka toimii vain tekijöidensä läsnä ollessa ei ole sovittanut yhteen mitään; se on pönkittänyt jotakin pystyssä. Tavoitteemme on jättää jälkeemme pieni määrä kestäviä tapoja: kyvykkyyskartta jota omistajat ylläpitävät koska he todella käyttävät sitä, päätöskirjaus joka elää yksilöitä kauemmin, ja joukko oletuksia jotka pitävät yhteensovitetun valinnan helppona pitkään lähtömme jälkeenkin. Jos lähtömme saa arkkitehtuurin ajautumaan, teimme työn riippuvuutena eikä kyvykkyytenä, ja se on juuri se virhe jonka välttämiseksi tämä tieteenala on olemassa.
Missä Nashua tekee eron
Käytäntöämme erottaa se, että kohtelemme arkkitehtuuria keinona pitää muutos mahdollisena, ei keinona hallita sitä. Olemme tekijöitä jotka istuvat toimituksen sisällä eivätkä kommentaattoreita jotka tarkastavat sitä ulkopuolelta, ja mittaamme työtämme sillä liikkuvatko tiimit nopeammin ja pystyykö liiketoiminta yhä päättelemään mitä se omistaa, ei tuotettujen mallien tai suoritettujen tarkastusten määrällä. Olemme valmiita olemaan väärässä edullisesti ja sanomaan sen kirjaukseen, koska käytäntö joka ei kykene myöntämään ohitettua päätöstä luutuu hiljaa ensimmäisten virheidensä ympärille. Tuo asenne, kyvykkyysvetoinen, päätöspohjainen ja ympäristöön rakennettu eikä sille pakotettu, on se mikä pitää yhteensovittamisen todellisena lähtömme jälkeen, ja se on tarkoituksellisen vaatimaton: ei ole yleiskuvaa paljastettavana, vain järjestelmämaisema joka pysyy ymmärrettävänä ja jälki valinnoista jota kuka tahansa voi seurata.
Tähän liittyy 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 sopeutumaan lähes mihin tahansa ominaisuuteen nopealla tahdilla, agenttipohjaisen suunnittelun avulla: tarvittava kuvataan tavallisella kielellä ja tuotetaan 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äytännöllinen. Se siirtää tee-tai-osta-rajaa, pitää valinnanvapauden edullisena, ja antaa arkkitehtuurin seurata strategiaa sen sijaan että strategia taipuisi siihen mitä sattui olemaan hyllyllä.
Tuloksena on arkkitehtuurikäytäntö joka ansaitsee paikkansa tekemällä järkevästä polusta helpon, joka kuvaa järjestelmämaiseman riittävän rehellisesti ohjatakseen sitä teeskentelemättä jäädyttävänsä sitä, ja joka jättää organisaation kykenevämmäksi muuttamaan mieltään edullisesti. Meidät tuomittakoon mieluummin niiden muutosten perusteella jotka liiketoiminta voi tehdä lähtömme jälkeen kuin niiden kaavioiden perusteella jotka piirsimme läsnä ollessamme. Se, eikä kaavion noudattaminen, on se mitä varten liiketoiminnan ja IT:n yhteensovittaminen on lopulta olemassa.
