Tyypillinen yritys pyörittää useasta sadasta useaan tuhanteen sovellukseen, ja lukumäärä on lähes aina suurempi kuin johto uskoo. Varjo-IT, kululaskuilla maksetut osastojen SaaS-tilaukset ja järjestelmät, jotka selvisivät migraatiosta, koska kukaan ei ollut varma, olivatko ne kuolleita, kaikki paisuttavat todellista lukua. Lähes jokaisen portfolioarvioinnin ensimmäinen epämukava havainto ei ole se, että sovellukset ovat vanhoja, vaan se, ettei kukaan pysty tuottamaan niistä luotettavaa luetteloa, saati kertomaan, mitä kukin niistä tekee liiketoiminnan hyväksi.

Tällä on nyt suurempi merkitys kuin vuosikymmen sitten yhdestä nimenomaisesta syystä: uuden sovelluksen hankkimisen rajakustannus on romahtanut. Kun kyvykkyyden lisääminen tarkoitti investointihanketta, palvelinta ja lisenssineuvottelua, ympäristö kasvoi hitaasti ja harkitusti. Kun se tarkoittaa, että osastopäällikkö kirjautuu iltapäivän aikana pilvipalveluun, kasvu on jatkuvaa ja koordinoimatonta. Ympäristö laajenee nopeammin kuin mikään keskitetty toiminto ehtii sitä kartoittaa, ja toiminnallisesta päällekkäisyydestä tulee poikkeuksen sijaan oletustila. Kaksi tiimiä ratkaisee saman ongelman kahdella eri työkalulla, eikä kumpikaan tiedä toisen olemassaolosta.

Kustannus ei ole vain lisenssimeno, vaikka päällekkäinen meno on todellista ja usein merkittävää. Syvempi kustannus on kytkeytyneisyys ja hauraus. Jokainen asiakasdataa käsittelevä sovellus on yksi paikka lisää, jossa data voi ajautua erilleen, yksi integraatio lisää ylläpidettäväksi, yksi järjestelmä lisää, joka on otettava huomioon ennen kuin mikään muutos on turvallinen. Vahingossa kasvanut ympäristö on tyypillisesti tiheästi ja näkymättömästi toisiinsa kytkeytynyt, jolloin minkä tahansa muuttamiseen tarvittava vaivannäkö skaalautuu koko kokonaisuuden koon eikä muutoksen koon mukaan. Sovellusarkkitehtuuri on olemassa tehdäkseen tuosta ympäristöstä luettavan ja muokatakseen sitä sitten tarkoituksellisesti.

Sovellusarkkitehtuurin järjestävä periaate on se, että sovellukset eivät ole ensisijainen kohde. Liiketoiminnan kyvykkyydet ovat. Kyvykkyys on vakaa kuvaus jostakin, mitä organisaation on kyettävä tekemään, ilmaistuna riippumatta siitä, miten se tehdään: hallita asiakassuhdetta, hinnoitella vakuutus, suorittaa maksu, suunnitella tuotanto. Kyvykkyydet muuttuvat hitaasti, koska ne kuvaavat itse liiketoimintaa. Sovellukset muuttuvat jatkuvasti, koska ne ovat toteutusta. Arkkitehtuurin ankkuroiminen kyvykkyyksiin antaa sinulle koordinaatiston, joka kestää minkä tahansa yksittäisen järjestelmän yli.

Tuota koordinaatistoa vasten rakennat ne kaksi näkymää, jotka tekevät ympäristöstä luettavan. Ensimmäinen on kyvykkyyksien ja sovellusten välinen kartoitus: mitkä sovellukset tukevat kutakin kyvykkyyttä ja missä määrin. Tämä nostaa välittömästi esiin redundanssin, jossa useat sovellukset väittävät tukevansa samaa kyvykkyyttä, sekä aukot, joissa liiketoiminnalle elintärkeää kyvykkyyttä ei tue muu kuin taulukkolaskenta ja tottumus. Toinen näkymä on toiminnallinen jäsentäminen: sovelluksen purkaminen niihin toiminnallisiin rakennuspalikoihin, joita se todella tarjoaa, niin että yhtenä pakettina myyty järjestelmä ymmärretään niinä kahdeksana tai kymmenenä erillisenä palveluna, jotka se tuottaa ja joista osa on päällekkäisiä täysin eri tuotteiden palveluiden kanssa.

Nämä kaksi näkymää muuttavat subjektiivisen väittelyn todistusaineistoksi. Kun liiketoimintayksikkö vaatii saada pitää järjestelmän, kysymyksestä tulee täsmällinen: mitä kyvykkyyttä se tukee, jota mikään muu ei tue, ja jos vastaus on ei mitään, keskustelu siirtyy tunteesta järjestykseen. Laajalti käytetty työkalu syntyvien päätösten jäsentämiseen on dispositiomalli, joka ilmaistaan usein muodossa siedä, investoi, migroi ja poista. Kukin sovellus sijoitetaan sekä liiketoiminta-arvonsa että teknisen soveltuvuutensa suhteen, ja neljännes, johon se päätyy, sanelee tarkoituksen: kasvata sitä, ylläpidä sitä, korvaa se tai poista se käytöstä. Mallin arvo eivät ole nimikkeet vaan kuri, joka pakottaa jokaiselle sovellukselle julistetun tulevaisuuden oletustulevaisuuden sijaan.

Kaksi voimaa muokkaavat sitä, miten maisemia kootaan. Ensimmäinen on ratkaiseva siirtymä suurista integroiduista paketeista kohti koostettavia ympäristöjä, jotka rakennetaan pienemmistä, itsenäisesti korvattavista osista. Sanasto on siirtynyt sen mukana: paketoidut liiketoimintakyvykkyydet, koostettava ERP ja arkkitehtuurityylit, jotka suosivat vaihdettavia komponentteja sen sijaan, että yksi toimittaja omistaisi koko toimialueen. Tarkoitus on järkevä: pienennä minkä tahansa yksittäisen järjestelmän vaikutussädettä ja säilytä mahdollisuus korvata komponentti korvaamatta kaikkea sen ympäriltä. Koostettavuus on suojautumista sitä monivuotista, riskialtista pakettien korvaamista vastaan, jonka useimmat organisaatiot ovat läpikäyneet ainakin kerran eivätkä halua toistaa.

Toinen voima on hankinnan kuluttajistuminen, joka on tehnyt SaaS-rönsyilystä vuosikymmenen määrittävän portfolio-ongelman. Ympäristö kasvaa nyt reunoilta, monien pienten tilausten kautta muutaman suuren käyttöönoton sijaan, ja suuri osa siitä on näkymätöntä keskitetylle arkkitehtuurille, kunnes uusiminen tai tietoturva-arviointi paljastaa sen. Tuloksena on ympäristö, joka on samanaikaisesti sekä modulaarisempi että pirstoutuneempi: helpompi täydentää, vaikeampi nähdä kokonaisuutena.

Koostettavuus myös siirtää monimutkaisuutta sen sijaan, että poistaisi sen. Monista pienistä vaihdettavista komponenteista koostuva ympäristö on vain yhtä hyvä kuin niitä sitova integraatio- ja data-arkkitehtuuri, ja maisema voi hajottaa monoliitin hajautetuksi järjestelmäksi, josta on vaikeampi päätellä kuin monoliitista oli. Nykyinen kuri ei siksi koske niinkään modulaarisen valitsemista integroidun sijaan opinkappaleena, vaan pikemminkin sen päättämistä kyvykkyys kyvykkyydeltä, missä organisaatio aidosti hyötyy itsenäisestä korvattavuudesta ja missä hyvin rajattu paketti on rehellisempi vastaus. Kypsyvä näkemys kohtelee koostettavuutta työkaluna, jolla on hintansa, ei päämääränä.

Maisema, joka palvelee kyvykkyyksiä hyvin, noudattaa tyypillisesti pientä joukkoa periaatteita, ja ne kannattaa todeta selkeästi, koska juuri ne erottavat suunnitellun ympäristön kasautuneesta. Ensimmäinen on yksi toiminnallinen omistajuus: kullakin kyvykkyydellä tulisi olla yksi auktoritatiivinen sovellus ja kullakin merkittävällä data-alueella yksi järjestelmä, joka toimii tietolähteenä. Tämä ei tarkoita yhtä sovellusta kyvykkyyttä kohden kaikkialla, mikä ei ole saavutettavissa eikä aina toivottavaakaan, mutta se tarkoittaa, että siellä missä päällekkäisyyttä on, se on tarkoituksellinen, dokumentoitu valinta eikä vahinko, jota kukaan ei huomannut.

Toinen periaate on löyhä kytkeytyneisyys ja korkea toiminnallinen koheesio. Sovellukset tulisi järjestää niin, että yhdessä muuttuvat asiat sijaitsevat yhdessä ja itsenäisesti muuttuvat asiat on erotettu vakaiden, eksplisiittisten rajapintojen avulla. Terveen ympäristön mittari ei ole se, kuinka vähän järjestelmiä sillä on, vaan se, kuinka itsenäisesti ne voivat muuttua. Ympäristöllä, jossa yhden järjestelmän muutos pakottaa koordinoituihin muutoksiin viidessä muussa, on korkea kytkeytyneisyys riippumatta siitä, kuinka moderneja sen yksittäiset komponentit ovat, ja kytkeytyneisyys, ei ikä, on yleensä todellinen lähde sille tunteelle, että maisemaa on mahdotonta liikuttaa.

Kolmas periaate on, että integraatio on arkkitehtuuria, ei putkitusta. Se, miten sovellukset keskustelevat keskenään, tapahtumien kautta, jaettujen palveluiden kautta, hallitun datakerroksen kautta vai hauraiden, kriisi kerrallaan rakennettujen kahdenvälisten rajapintojen kautta, määrittää koko kokonaisuuden kytkeytyneisyyden. Kahdenvälisesti kytketty maisema muuttuu verkoksi, jonka monimutkaisuus kasvaa kokonsa neliönä. Neljäs periaate on, että jokaisella sovelluksella on oltava julistettu elinkaaren vaihe ja nimetty omistaja. Ilman omistajaa olevia järjestelmiä ei voida hallita, ja ilman julistettua tulevaisuutta olevat järjestelmät ovat niitä, jotka selviävät ikuisesti oletuksena. Erityisesti käytöstä poistaminen on suunnittelutoimintaa: alasajo suunnitellaan siitä hetkestä, kun korvaava ratkaisu valitaan, ja datan migraatio, rajapintojen irrottaminen ja arkistointi käsitellään ensiluokkaisena työnä eikä jälkiajatuksena, joka ei koskaan aivan saa rahoitusta.

Rationalisointi taulukkolaskentaharjoituksena. Yleisin epäonnistuminen on kohdella rationalisointia kertaluonteisena kustannusleikkauksena: konsultti tuottaa listan, tavoite asetetaan, muutama ilmeinen päällekkäisyys karsitaan, ja ympäristö jatkaa kasautumistaan sinä päivänä, kun projekti päättyy. Rationalisointi on jatkuva kyvykkyys, ei tapahtuma. Ilman omistajaa ja pysyvää prosessia lukumäärä on takaisin lähtöpisteessä muutamassa vuodessa ja harjoitus on maksettava uudelleen.

Käytöstä poistaminen, joka ei koskaan valmistu. Organisaatiot ovat hyviä ostamaan korvaavia ratkaisuja ja huonoja sammuttamaan sen, minkä ne korvaavat. Uusi järjestelmä otetaan käyttöön, vanhan on tarkoitus seurata, ja vuosia myöhemmin se on yhä käynnissä, koska yhtä raporttia, vaatimustenmukaisuusarkistoa tai yhtä itsepäistä rajapintaa ei koskaan migroitu. Ympäristö päätyy kantamaan sekä vanhaa että uutta, mikä on huonompaa kuin kumpikaan yksinään. Epäonnistuminen on lähes aina se, että alasajoa ei koskaan rahoitettu tai suunniteltu todellisena työnä.

Rakenna vai osta ratkaistuna asenteen eikä soveltuvuuden perusteella. Jotkut organisaatiot rakentavat refleksinomaisesti, koska insinöörit haluavat, toiset ostavat refleksinomaisesti, koska hankinta on helpompaa, ja molemmat kohtelevat aitoa arkkitehtuuripäätöstä kulttuurisena oletuksena. Oikea kehys on kapea: rakenna vain siellä, missä kyvykkyys on aidon erottautumisen lähde, ja osta siellä, missä se on hyödyke, jonka markkina ratkaisee hyvin. Hyödykekyvykkyyden rakentaminen on tapa, jolla organisaatiot hankkivat räätälöityjä järjestelmiä, joita niiden on ylläpidettävä ikuisesti ilman kilpailuetua.

Pakettiin lukkiutuminen erehdyksessä integraatioksi. Yhtä toimittajaa, joka kattaa monta kyvykkyyttä, myydään usein integroituna ympäristönä, ja joskus se aidosti onkin. Mutta integraatio, joka saavutetaan yhden tuotteen omistaessa kaiken, ei ole arkkitehtuuria, se on riippuvuutta, ja se poistaa mahdollisuuden korvata mikä tahansa osa ilman ohjelmaa. Vikatila on huomata uusimisen yhteydessä, että ympäristöllä ei ole neuvotteluvoimaa eikä ulospääsyä. Päällekkäisyys siedettynä itsenäisyytenä. Lopuksi, toiminnallista päällekkäisyyttä puolustetaan usein liiketoimintayksikön itsenäisyytenä. Joskus se on oikeutettua. Usein se on yksinkertaisesti hallitsematonta päällekkäisyyttä, joka pukeutuu voimaannuttamisen kieleen, ja se säilyy, koska kukaan ei ole tehnyt kustannusta näkyväksi.

Nashua aloittaa tekemällä ympäristöstä luettavan, koska mikään jatkovaihe ei ole puolustettavissa ilman sitä. Se tarkoittaa luotettavan sovellusinventaarion rakentamista, joka heijastaa todellisuutta eikä sitä, milloin joku viimeksi päivitti taulukkolaskentaa, mukaan lukien varjo- ja osastojärjestelmät, jotka viralliset rekisterit ohittavat. Kukin sovellus kartoitetaan sitten niihin liiketoiminnan kyvykkyyksiin, joita se tukee, ja puretaan niihin toiminnallisiin palveluihin, joita se todella tarjoaa, niin että päällekkäisyys ja redundanssi lakkaavat olemasta anekdootteja ja muuttuvat todistusaineistoksi, johon voit osoittaa.

Tuosta lähtötasosta työ kääntyy dispositioon. Nashua sijoittaa kunkin sovelluksen sekä sen liiketoiminta-arvon että sen teknisen ja toiminnallisen soveltuvuuden suhteen ja määrittää julistetun tarkoituksen: ylläpidä, investoi, korvaa tai poista käytöstä. Tämä tehdään liiketoiminnan kanssa, ei sille, koska dispositio, jota omistava toiminto ei hyväksy, on liukuma, ei päätös. Kun tarkoitus on rationalisoida, Nashua järjestää työn kytkeytyneisyyden ja riskin eikä helppouden mukaan, tarttuen siihen päällekkäisyyteen ja kahdenväliseen kietoutumiseen, jotka tekevät ympäristön muuttamisesta kallista, ja käsittelee korvattujen järjestelmien alasajon rahoitettuna, suunniteltuna työnä, jossa datan migraatio ja rajapintojen irrottaminen on mitoitettu alusta lähtien.

Rakenna vai osta -päätökset jäsennetään erottautumista eikä mieltymystä vasten. Nashua auttaa erottamaan ne muutamat kyvykkyydet, joissa räätälöity rakentaminen ansaitsee elinkaarensa ylläpitokustannuksen, siitä enemmistöstä, jossa hyvin rajattu paketoitu komponentti on rehellinen valinta, ja suunnittelee sen integraatio- ja data-arkkitehtuurin, joka pitää nuo komponentit löyhästi kytkettyinä ja itsenäisesti korvattavina. Kauttaaltaan painopiste on sovellusportfolion hallinnan vakiinnuttamisessa pysyväksi kyvykkyydeksi, jolla on nimetyt omistajat, julistetut elinkaaret ja toistettava tarkasteluväli, niin että ympäristö lakkaa kasautumasta vahingossa ja alkaa muuttua suunnitelmallisesti. Tuotos ei ole kertaluonteinen raportti vaan hallittu portfolio, joka pysyy luettavana toimeksiannon päätyttyä.

Ero, jonka Nashua tuo, on kieltäytyminen kohtelemasta sovellusarkkitehtuuria joko puhtaana kustannusharjoituksena tai puhtaana teknologiaharjoituksena. Ympäristön rationalisointi on helppo luvata ja vaikea ylläpitää, koska ne voimat, jotka saivat sen rönsyilemään, helppo hankinta, paikallinen itsenäisyys ja haluttomuus sammuttaa mitään, eivät lakkaa sinä päivänä, kun tavoite saavutetaan. Nashua pyrkii jättämään jälkeensä ei laihemman tilannekuvan vaan portfolion, jonka organisaatio voi pitää hallittuna: kyvykkyydet kartoitettuina, dispositiot omistettuina, kytkeytyneisyys ymmärrettynä ja tarkasteluväli, joka nappaa seuraavan vahingossa syntyneen päällekkäisyyden ennen kuin se kovettuu. Juuri tuo toiminnallisen tarkkuuden ja organisatorisen realismin yhdistelmä muuttaa maiseman jostakin, joka tapahtui organisaatiolle, joksikin, jota se voi ohjata.

Tähän liittyy myös käytännöllinen seuraus, joka muuttaa sen, mitä työn sallitaan olettaa. Kun toimeksianto edellyttää kyvykkyyttä, jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintasykliä tai toimittajan tuotekarttaa. 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 ettei nopeus koskaan tule koherenssin, tietoturvan tai kontrollin kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää rakenna vai osta -rajaa, pitää optionaalisuuden edullisena ja antaa arkkitehtuurin seurata strategiaa sen sijaan, että strategia taipuisi siihen, mitä sattui olemaan hyllyllä.

Se, mikä johdonmukaisesti erottaa lopputuloksen, on se, että Nashua pitää liiketoiminnan ja tekniset näkymät yhdessä samassa keskustelussa. Dispositiomalli on vain yhtä hyvä kuin sen alla oleva kyvykkyyskartta, kyvykkyyskartta on vain yhtä hyvä kuin sen alla olevan inventaarion rehellisyys, eikä mikään siitä selviä kohtaamisesta organisaation kanssa, ellei omistavat toiminnot hyväksy päätöksiä ja niitä ylläpitävää hallintaa. Nashua työstää koko ketjua eikä mitään yksittäistä lenkkiä, ja siksi ympäristö, jonka se auttaa suunnittelemaan, pysyy tyypillisesti suunniteltuna, palvellen niitä kyvykkyyksiä, joista liiketoiminta todella riippuu, sen sijaan että se kasautuisi hiljaa seuraavaan tuskalliseen tilinpäätökseen asti.