IT architektura. Dovolte mi, abych vám řekl, proč

Milujeme kreslení !!

(Miguel Angel Coll) (2. července 2020)

Posledních 5 let jsem do své kariéry investoval do práce na funkci IT architektura. Celé ty roky jsem musel ospravedlňovat pouhou existenci funkce Architecture i sám sobě. Někdy se také cítíme, jako bychom byli vetřelci obklopeni lidmi, kteří opravdu dělají práci (vývojáři a sys-ops).

Po 5 letech jsem stále přesvědčen, že na architektuře záleží, dovolte mi uvést několik argumentů prokázat to.

Nejlepší hodnota za peníze

Pokud si mám vybrat pouze jednu misi pro IT architekturu, zvolím tuto. IT oddělení a platformy se obvykle jen rozrůstají. Některé z nich proto, že společnost roste, jiné proto, že společnost je uprostřed digitální transformace. Výsledek je každopádně stejný, rok co rok máte více systémů, více týmů, větší složitost.

Rád hyper-over-zjednodušuji IT platformu takto:

Hlavní funkcí architektury je udržovat vztah s Náklady na IT platformu a její hodnota v dobrém stavu.

Před časem jsem pracoval ve společnosti Travel s obchodním modelem založeným na online distribuci produktů prostřednictvím API. Tato API byla silně spojena s obrovským monolitickým systémem založeným na Oracle Exadata. To znamená, že pokaždé, když rosteme na provozu API (a provoz rostl více než míra konverze), musíme naši databázi vertikálně škálovat.

Architektura zvyšuje efektivitu IT platformy

Návrh architektury v té době spočíval v oddělení služeb API a vytvoření nové vrstvy mikro služeb na cloud zvládne veškerý provoz s nižšími náklady při zachování databázové infrastruktury jen pro rezervaci a provoz (které bohužel nerostou exponenciálně). Výsledkem bylo, že v následujících letech nebude pro DB zapotřebí žádná nová infrastruktura a lepší vztah mezi provozem a náklady na IT.

Používejte stejný jazyk

Nedělejte si starosti nemluvíme o programovacích jazycích (java, python atd.). Jako architekt jsem více než otevřený rozmanitosti s určitou kontrolou (ne chaosem). Tady mám na mysli Konceptuální integritu, pojem, který jsem si poprvé přečetl Měsíc mýtického muže a další eseje o softwarovém inženýrství od Fredericka P . Brooks Jr.

V knize Fred Brooks vysvětluje, jak rostou IT týmy a jak tento rostoucí dopad na jejich produktivitu. Pro Freda je jedním z největších problémů, které je třeba řešit při pokusu o škálování IT týmu, komunikace mezi týmy. Abyste mohli paralelizovat úkoly, potřebujete, aby týmy byly co nejvíce nezávislé. Jakmile však všechny týmy pracují na vzájemně propojené platformě, potřebujeme nějakou komunikaci mezi týmy. Je v těchto scénářích, když společný jazyk je klíčem k úspěchu.

Stále si pamatuji nekonečné rozhovory s mými bývalými týmovými kolegy, kteří diskutují o tom, co je systém, technologická součást, rozhraní nebo stavební blok. Pokud pracujete na velkém IT oddělení, pravděpodobně víte, jak frustrující je, že týmy pojmenovávají věci jinak. Někdy je dokonce nejhorší, když používají stejné jméno pro různé věci.

Běžným příkladem posledního z nich je pojmenování monolitické aplikace pouze jedním jménem. I když to dává smysl (protože je to monolit), chcete-li ten monolit rozbít, budete potřebovat více podrobností. Proces vám pomůže představením různých názvů pro databázi, rozhraní, datový model atd.

I když jste v malém oddělení IT nebo ve větším, vždy je vhodné začít s konvencí pojmenování, katalogem služeb / systémů / řešení atd. Nikdy nevíte, jak velká v budoucnu budete.

O koncepční integritě, holý se mnou, čím dříve, tím lépe.

Vynutit konverzace v designu

Podle mého názoru každé řešení problému vždy začíná s analýza situace a návrh řešení před implementací. Realita vývojového týmu je taková, že každý týden máme na stole nové problémy, které musíme vyřešit. Po několika měsících rutin Business as obvyklých týmy začnou běžet na autopilotu a budou jen hledat řešení problémů, aniž by příliš přemýšlely o střednědobých a dlouhodobých důsledcích.

Integrovaná funkce architektury ve vývojových týmech vždy pomůže na zvyšování konverzací o designu, abychom našli nejlepší řešení problémů, kterým čelíme.

Také bych rád zpochybnil proces vývoje staré módy, kde je design považován za něco, co je třeba udělat hned na začátku projekt.V článku The Architect Elevator – Visiting the upper floor , Gregor Hohpe dokonale popisuje mé chápání role architektury:

„… Takže místo toho, aby byla všechna důležitá rozhodnutí svěřena jedné osobě, lze riziko projektu snížit o minimalizace počtu rozhodnutí, která jsou nevratná .“

Ve všech procesech vývoje musí být architektura. . Ve skutečnosti, pokud pracujete na Agile, budete rozhodovat o každé iteraci.

Diskuse o strategii

Jako IT člověk bych rád byl v představenstvu společnosti s velmi specifickými a podrobné technické diskuse. Realita pro střední a velké společnosti spočívá v tom, že si členové správní rady nemohou dovolit zacházet příliš podrobně. Měla by však správní rada společnosti rozhodovat o strategii, aniž by pochopila situaci v IT?

V současném světě existuje jen několik společností, které mohou říci, že IT není středem jejich strategie. Kdo je tedy odpovědný za převod strategie do IT a naopak? – odpověď už znáte.

Jedním z našich největších příspěvků v architektonickém týmu TUI Destination Experiences bylo nakreslit model cílové architektury. TAM umožňuje lidem, kteří nejsou IT, porozumět našim hlavním řešením a systémům a jejich propojení s hodnotovými toky naší společnosti. Po distribuci TAM většina našich strategických konverzací začala hledáním toho, jak vypadá naše architektura a jak bychom se měli přizpůsobit nové situaci.

Ale buďte opatrní, model cílové architektury nemá být statický obrázek architektury „tak, jak je“, a „budoucí“. Pokus o tento druh cvičení skončí něčím pomíjivým, co se hodí pro konkrétní projekt. Podle mého názoru je lepší zaměřit se na kreslení hlavních komponent vaší architektury a výběr věcí, které chcete zachovat (protože jsou jádrem vašeho podnikání), a poukázat na věci, které budete muset změnit nebo vyvinout.

První snímek prezentace TAM

Vždy si pamatujte, co řekl Dee Hock, zakladatel Visa:

Jednoduchý, jasný účel a principy vedou ke složitému inteligentnímu chování. Složitá pravidla a předpisy vedou k jednoduchému hloupému chování.

do nekonečna a dále

posedlost agilitou někdy transformuje IT týmy na krátkodobé rozhodovací orgány . Jak jsme již diskutovali, musíme si být jisti, že rozhodnutí, která dnes přijímáme, jsou připravena na budoucnost. Někdy to znamená mít dlouhodobě jasný pohled na strategii. Někdy to znamená být opatrní, abyste nebyli připraveni na řešení, které se nehodí do vaší budoucnosti. Většinou to znamená zajištění výchozí úrovně kvality a schopnost přizpůsobit se všemu, co přišlo.

Jak jsme již uvedli, architektura musí pracovat také na strategické úrovni. To znamená, že pravděpodobně bude mít čerstvé informace o budoucích možnostech, které by mohly ovlivnit IT platformu. Někdy jsou tyto strategické změny dokonce důvěrné. Schopnost ovlivnit některá rozhodnutí a snaha vyhnout se lítostným pohybům je někdy těžký úkol, protože neinformovaní lidé nikdy nepochopí skutečný důvod.

V určitém okamžiku jsme byli uprostřed diskuse o zlepšení architektury platformy B2C. Opravdu má smysl hodně vylepšit architekturu. Někteří z nás však věděli, že jsme v rozhovorech, abychom získali společnost, která nahradí naši platformu B2C.

Věřte mi, není vždy snadné být architektem, ale musíte vždy myslet na to, co je nejlepší pro společnost.

A také…

… Také milujeme kreslení a v kanceláři uděláme mnohem více pohody.

Vývojový tým, který diskutuje s využitím diagramu architektury

Doufám, že tento skromný příspěvek přispějte v budoucnu k pochopení takové krásné práce.

Migue Coll, vedoucí technologické domény v Tui Destination Experiences.