IT-arkkitehtuurilla on merkitystä. Haluan kertoa teille, miksi

Rakastamme piirtämistä !!

(Miguel Angel Coll) (2. heinäkuuta 2020)

Investoin viimeiset 5 vuotta uraani työskentelemällä IT-arkkitehtuuritoiminnon ympärillä. Kaikkien näiden vuosien aikana minun piti perustella pelkkä arkkitehtuuritoiminnan olemassaolo jopa itselleni. Joskus tuntuu myös siltä, ​​että olisimme tunkeilijoita ihmisten ympärillä, jotka todella tekevät työtä (kehittäjät ja järjestelmät).

Viiden vuoden kuluttua olen edelleen vakuuttunut siitä, että arkkitehtuurilla on merkitystä, anna minun antaa sinulle joitakin argumentteja todista se.

Paras vastine rahalle

Jos minun on valittava vain yksi tehtävä IT-arkkitehtuurille, valitsen tämän. IT-osastot ja -alustat yleensä kasvavat. Jotkut heistä siksi, että yritys kasvaa, toiset siksi, että yritys on keskellä digitaalista muutosta. Tulos on joka tapauksessa sama, vuosi vuodelta sinulla on enemmän järjestelmiä, enemmän tiimejä, monimutkaisempi.

Haluan yksinkertaistaa IT-alustan liikaa seuraavalla tavalla:

Tärkein arkkitehtuuritoiminto on säilyttää suhde IT-alustan kustannukset ja sen tuottama arvo hyvässä kunnossa.

Jokin aika sitten työskentelin matkailuyrityksessä liiketoimintamallilla, joka perustuu online-tuotteiden jakeluun API: n kautta. Nämä sovellusliittymät yhdistettiin vahvasti valtavaan Oracle Exadataan perustuvaan monoliittijärjestelmään. Tämä tarkoittaa sitä, että joka kerta kun kasvamme API-liikenteessä (ja liikenne kasvoi enemmän kuin tulosprosentti), meidän on skaalattava tietokanta pystysuunnassa.

Arkkitehtuuri lisää IT-alustan tehokkuutta

Arkkitehtuuriehdotus oli tuolloin irrottaa sovellusliittymäpalvelut ja luoda uusi mikropalvelutaso pilvi hoitaa kaiken liikenteen alhaisemmilla kustannuksilla pitäen tietokanta-infrastruktuurin vain varausta ja toimintoja varten (jotka valitettavasti eivät kasva eksponentiaalisesti). Tuloksena ei ollut enää tarvetta uudelle infrastruktuurille DB: lle seuraavina vuosina ja parempi suhde liikenteen ja IT-kustannusten välillä.

Käytä samaa kieltä

Älä huoli ei puhu ohjelmointikielistä (Java, Python jne.). Arkkitehtina olen enemmän kuin avoin monimuotoisuudelle, jossa on jonkin verran hallintaa (ei kaaosta). Tarkoitan tässä käsitteellistä eheyttä , jota luin ensimmäistä kertaa Frederick P: n Mythical Man Month ja muissa esseissä ohjelmistotuotannossa . Brooks Jr.

Kirjassa Fred Brooks selittää kuinka IT-tiimit kasvavat ja miten tämä kasvava vaikutus heidän tuottavuuteensa. Fredille yksi suurimmista ongelmista, joita on käsiteltävä, kun yrität laajentaa IT-tiimiä, on joukkueiden välinen viestintä. Tehtävien rinnakkaistamiseksi sinun on tiimien oltava mahdollisimman riippumattomia. Mutta heti kun kaikki joukkueet työskentelevät yhteenliitetyn alustan parissa, tarvitsemme jonkin verran viestintää joukkueiden välillä. Onko kyseisissä skenaarioissa, kun yhteisen kielen käyttäminen on avain menestykseen.

Muistan edelleen loputtomat keskustelut entisten tiimikaverini kanssa keskustelemalla siitä, mikä on järjestelmä, teknologiakomponentti, käyttöliittymä tai rakennusosa. Jos työskentelet suurella IT-osastolla, tiedät todennäköisesti kuinka turhauttavaa on, että tiimit nimeävät asiat eri tavalla. Joskus on jopa pahinta, kun he käyttävät samaa nimeä eri asioihin.

Yleinen esimerkki viimeksi mainitusta on monoliittisovelluksen nimeäminen vain yhdellä nimellä. Jopa sillä on järkeä (koska se on monoliitti), kun haluat rikkoa sen, tarvitset lisätietoja. Eri nimien käyttöönotto tietokannalle, käyttöliittymälle, tietomallille jne. Auttaa prosessia.

Vaikka olisit pienessä tai suuremmassa IT-osastossa, on aina hyvä aika aloittaa. nimityskäytännöllä, palvelu / järjestelmä / ratkaisukatalogi jne. Et koskaan tiedä kuinka suuri olet tulevaisuudessa.

Tietoja käsitteellisestä eheydestä, paljas kanssani, sitä nopeammin, sitä parempi.

Pakota suunnittelukeskustelut

Mielestäni jokainen ongelman ratkaisu alkaa aina analyysi tilanteesta ja ratkaisun suunnittelu ennen toteuttamista. Kehitystiimin todellisuus on, että meillä on joka viikko ratkaistavia uusia ongelmia. Muutaman kuukauden Business as Usual -rutiinien jälkeen tiimit alkavat toimia autopilotilla ja löytävät vain ratkaisuja ongelmiin miettimättä liikaa keskipitkän ja pitkän aikavälin vaikutuksia.

Arkkitehtitoiminnon integrointi kehitystiimeihin auttaa aina suunnittelukeskustelujen lisäämisestä löytääksemme parhaat ratkaisut kohtaamiemme ongelmiin.

Haluan myös haastaa vanhan muodin kehitysprosessin, jossa muotoilun nähdään olevan jotain tekemistä heti projekti.Artikkelissa Arkkitehtihissin vierailu ylemmissä kerroksissa , Gregor Hohpe kuvailee ymmärrystäni arkkitehtuuriroolista täydellisesti:

”… Joten sen sijaan, että kaikki tärkeät päätökset annettaisiin yhdelle henkilölle, projektiriskiä voidaan vähentää peruuttamattomien päätösten määrän minimointi .”

Arkkitehtuurin on oltava mukana kaikessa kehitysprosessissa . Itse asiassa, jos työskentelet ketterän palvelun parissa, teet päätökset jokaisesta iteraatiosta.

Strategiakeskustelut

IT-kaverina rakastan olla yrityksen hallituksessa hyvin tarkkana. ja yksityiskohtaiset tekniset keskustelut. Keskisuurten ja suurten yritysten todellisuus on se, että hallituksen jäsenillä ei ole varaa mennä liian syvälle yksityiskohtiin. Pitäisikö yrityksen hallituksen tehdä strategiapäätöksiä ymmärtämättä IT-tilannetta?

Nykyisessä maailmassa on vain muutama yritys, joka voi sanoa, että IT ei ole heidän strategiansa keskipisteessä. Kuka sitten vastaa strategian kääntämisestä IT: ksi ja päinvastoin? – tiedät jo vastauksen.

Yksi suurimmista panoksistamme TUI Destination Experiences -arkkitehtuuritiimissä oli Piirrä Kohdearkkitehtuurimalli. TAM antaa muiden kuin IT-ihmisten ymmärtää tärkeimmät ratkaisumme ja järjestelmämme ja miten ne ovat yhteydessä yrityksen arvovirtoihin. TAM: n jakamisen jälkeen suurin osa strategiakeskusteluistamme alkoi tarkastelemalla miltä arkkitehtuurimme näyttää ja kuinka meidän pitäisi sopeutua uuteen tilanteeseen.

Ole kuitenkin varovainen, Kohdearkkitehtuurimallin ei ole tarkoitus olla staattinen kuvan olemassa olevasta ja tulevasta arkkitehtuurista. Tällaisen harjoituksen yrittäminen johtaa jotain lyhytaikaiseen, joka sopii vain tiettyyn projektiin. Mielestäni on parempi keskittyä piirtämään arkkitehtuurin pääkomponentit ja valitsemaan säilytettävät asiat (koska ne ovat yrityksesi ydin) ja osoittamaan asioita, joita sinun on muutettava tai kehitettävä.

TAM-esityksen ensimmäinen dia

Muista aina, mitä Visa-perustaja Dee Hock sanoi:

Yksinkertainen, selkeä tarkoitus ja periaatteet johtavat monimutkaiseen älykkääseen käyttäytymiseen. Monimutkaiset säännöt ja säädökset johtavat yksinkertaiseen tyhmään käyttäytymiseen.

Äärettömyyteen ja pidemmälle

Ketteryyden pakkomielle muuttaa joskus IT-tiimejä lyhytaikaisiksi päättäjiksi . Kuten jo keskustelimme, meidän on oltava varmoja siitä, että tänään tekemämme päätökset ovat tulevaisuuden kestäviä. Joskus se tarkoittaa selkeää näkemystä strategiasta pitkällä aikavälillä. Joskus se tarkoittaa varovaisuutta, ettet lukitse ratkaisua, joka ei sovi tulevaisuuteesi. Useimmiten tarkoittaa oletuslaadun varmistamista ja kykyä sopeutua mihin tahansa.

Kuten jo kommentoimme, arkkitehtuurin on toimittava myös strategisella tasolla. Tämä tarkoittaa, että sillä on todennäköisesti uutta tietoa tulevaisuuden mahdollisuuksista, jotka voivat vaikuttaa IT-alustaan. Joskus nuo strategiset muutokset ovat jopa luottamuksellisia. Mahdollisuus vaikuttaa joihinkin päätöksiin yrittäen välttää pahoillani olevia liikkeitä on joskus vaikea tehtävä, koska tietämättömät ihmiset eivät koskaan ymmärrä todellista syytä.

Jossakin vaiheessa olimme keskellä keskustelu B2C-alustan arkkitehtuurin parantamisesta. On todella järkevää parantaa paljon arkkitehtuuria. Jotkut meistä tiesivät kuitenkin keskustellessamme yrityksen hankkimisesta, joka korvaa B2C-alustamme.

Luota minuun, ei ole aina helppoa olla arkkitehti, mutta sinun täytyy aina miettiä, mikä on paras yritykselle.

Ja myös…

… Rakastamme myös piirtämistä ja teemme toimistosta paljon hienomman.

Kehitystiimi keskustelee arkkitehtuurikaavion avulla

Toivottavasti tämä vaatimaton viesti auta tulevaisuudessa ymmärtämään niin kaunista työtä.

Migue Coll, Tui Destination Experiencesin teknologia-alueen johtaja.