1.6 IT arhitektuur
- Miks on süsteemi arhitektuur oluline?
- Mis on arhitektuur?
- Arhitekt
- Arhitektuuri kirjeldus
- Arhitektuuri esitamine
- Hea arhitektuuri omadused
- Arhitektuuri loomise “reegleid”
- Arhitektuuri ohud
- suhelda IT-arhitektiga
help_circle"[Architect must] bring technical realism into a project."" — Michael Pichler (2011) Did You Ever Wonder What an IT Architect Does?
Süsteemi arhitektuuri mõiste ja vajadus selle järele. Arhitektuuri esitamise tehnikad. Põhimõtteid ja juhiseid süsteemi arhitektuuri kujundamiseks.
Miks on süsteemi arhitektuur oluline?
Praktiliselt iga reaalselt kasulik süsteem:
- koosneb suurest hulgast elementidest
- muutub nii süsteemi väljatöötamise kui ka kasutamise perioodil
- leiab kasutamist mitmete erinevate kasutajate gruppide poolt.
Süsteemi arhitektuur on vajalik selleks, et:
- anda süsteemi tegijatele ja kasutajatele ülevaade süsteemist
- aktiivselt kujundada süsteemi struktuuri, vastavalt arhitektuuripõhimõtetele (moodulprintsiip, tasakaalustatus jm).
Eristada:
- arhitektuurse lahenduse taset – kui hästi on süsteem arhitektitud?
- arhitektuuri esitamise taset – kui hästi süsteemide arhitektuur on kirjeldatud?
Mõneti paradoksaalne, kuid sageli süsteemil polegi korralikku arhitektuuri kirjeldust. Detailid on kirjeldatud, kuid üldpilt on ainult süsteemi tegija peas.
Mis on arhitektuur?
Arhitektuuri all mõistetakse süsteemi üldist struktuuri. Loodava süsteemi korral – lahenduse alusraamistikku. Arhitektuuri mõistega on ajalooliselt, lahutamatult seotud esteetiline mõõde. Arhitektuur ei ole ainult mõõdetavad proportsioonid vaid ka nende proportsioonide otstarbekus ja efektiivsus kõige laiemas, ka esteetilises mõttes.
Arhitektuur on midagi püsivat (süsteemi tunnusjooned või omadused, mis on suhteliselt raskesti muudetavad või muutuvad; ajutine ei ole arhitektuur). Arhitektuur on midagi olulist. Arhitektuur on midagi inimese poolt kujundatut (juhuslik või looduslikult arenenud ei ole arhitektuur).
Arhitektuur on midagi ümbruskonnaga suhtestuvat (vaevalt on arhitektuuri, mis seisab omaette). Arhitektuur on eriti süsteemi tervikstruktuur; see on kuidas-asjad-koos-käivad.
Arhitektuur on idee (kandev idee?) ja selle teostus.
Arhitektuur on sisemine ehitus, ühendav alusstruktuur, aga ka väliselt, kasutaja poolt nähtav ja kogetav.
“Architecture, of a system — The fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors.” – INCOSE SAWG
“Architecture, of a system — The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” – IEEE P1471
Olulisemad momendid süsteemi arhitektuuri loomisel:
- eesmärkide väljaselgitamine: kellele ja milleks süsteemi vaja on?
- kontseptsioon ja struktuur: üldine ehitus, erinevatest vaatepunktidest lähtudes
- teostatavuse kontrollimine: kui valmis ehitada, kas siis on suuteline vajadusi rahuldama, eesmärke täitma?
Arhitekt
Arhitekt loob vajadusi rahuldava, teostatava süsteemi kontseptsiooni, tagab selle kontseptsiooni ühtsena säilimise arenduse protsessis ning kontrollib loodud süsteemi valmisolekut kasutusse võtuks.
Arhitekt sünteesib erinevad vaated ja nõudmised ühtseks tervikuks – leiab optimaalse lahenduse, tehes vajadusel kompromisse erinevate nõudmiste ja piirangute vahel. Lahendus peab olema ühest küljest vajadusi rahuldav, teisest küljest teostatav. Arhitekti töö ei piirdu projekti valmimisega; ta osaleb aktiivselt lahenduse teostamisel, nõuandja ja järelevalvaja rollides.
Igal vähegi tõsisemal süsteemil peaks olema arhitekt.
Arhitektuuri kirjeldus
Kas arhitektuur on abstraktne või konkreetne mõiste?
Kuidas näeme arhitektuuri? Kas arhitektuuri saab tajuda vahetult?
Kas kahemõõtmeline diagramm on arhitektuur?
Kas kolmemõõtmeline virtuaalmaailm on arhitektuur?
Arhitektuuri esitused, kirjeldused ja arhitektuur ise on erinevad. Süsteemi arhitektuur alati on tervik. Seda tervikut on äärmiselt raske ühe skeemi abil esitada. Selle tõttu esitatakse süsteemi arhitektuur tavaliselt spetsialiseeritud jooniste – vaadete – abil.
Arhitektuuri esitamine
Arhitektuurivaade on süsteemi lihtsustatud kirjeldus abstraktsioon) ühest vaatepunktist või vaatenurgast. Vaade ei esita antud vaatenurga jaoks ebaolulisi detaile.
Arhitektuuri kirjeldused on harilikult mitmevaatelised. Vaadete ja mudelite valik sõltub uuritavast probleemist.
Süsteemi vaade esitatakse harilikult visuaalsete kujutiste (diagrammide, skeemide, jooniste) abil, mida täiendavad tekstid (seletuskiri jooniste juurde). Kasutatakse nii praktikas väljakujunenud diagrammide tüüpe (kokkuleppeid tähistuste jm. kujutusviiside osas) kui ka formaliseeritud meetoditega antud diagrammitüüpe.
UML keel pakub 9 standardset diagrammitüüpi (vaadet), milles enimkasutatavad on:
- kasutusjuhu diagramm (Use Case Diagram)
- komponentdiagramm (Component Diagram)
- paigaldusdiagramm (Deployment Diagram)
- jadadiagramm (Sequence Diagram)
- olekudiagramm (Statechart)
Ärikasutajale on UML diagrammid tavaliselt liiga tehnilised.
Uuem, lihtne ja loogiline on “C4” meetod. Vt Simon Brown (2015) Communicating software architecture with sketches, diagrams and the C4 model.
Hea arhitektuuri omadused
Hea arhitektuur kestab. “The test of a good architecture is that it will last. The sound architecture is an enduring pattern.”
Thomas: tasakaalustatud / struktureeritud / elegantne ja lihtne / terviklik.
Booch: toimepidev (resilient) / lihtne / arusaadav (approachable) / erinevaid aspekte selgelt väljatoov (clear separation of concerns) / kohustuste tasakaal (balanced distribution of responsibilities) / majanduslike ja tehnoloogiliste piirangute tasakaal.
Arhitektuuri loomise “reegleid”
Kas arhitektuur ainult tekitatakse või tekib ka ise?
Dale Thomas loetleb huvitava rea arhitektuuri loomise „reegleid”. Seejuures:
- Sellised reeglid ei ole absoluutsed. Näiteks on võimalik leida lahendus, mis on nii efektiivne kui ka universaalne. Lahendatavate probleemide klassi laiendamine (samm universaalsuse suunas) on sageli just efektiivsuse saavutamise vahendiks.
- Reeglid tuleb alati osata rakendada konkreetses situatsioonis. Raskuspunkt võib olla just selles, mitte reeglist üldises arusaamises.
-
Reeglite loetelu peaks süsteemi arendaja ise jätkama (leida oma tööstiilile sobivaid reegleid).
- Efektiivsus ja universaalsus on sageli üksteise suhtes vastukäivad. Efficiency is inversely proportional to universality.
- Esimeseks kaitsejooneks keerukuse vastu on disaini lihtsus. The first line of defence against complexity is simplicity of design.
- Ükski keerukas süsteem ei saa rahuldada kõigi osapoolte soove täielikult. No complex system can be optimum to all parties concerned.
- Laiem eesmärk suurendab võimalike lahenduste ringi. Moving to a larger purpose widens the range of solutions. – Mõeldud on seda, et oluline on kontekst, milles süsteemi vaadelda. Mõnda probleemi või süsteemi peab vaatama väga laias kontekstis.
- Kui sa ei suuda seda lahti seletada, siis ära ürita seda ehitada. If you can’t analyze it, don’t build it. – Mõeldud ei ole seda, et analüütiline kirjeldus peab tingimata paberil olema; süsteemi arhitektil peab olema kindel mentaalne pilt (vaimukujutis) loodavast lahendusest – ja sellest tulenev kindlus.
- Elemendid, mis on üksteisega tihedalt seotud, koonda ühte moodulisse; elemendid, mille vaheline funktsionaalne seos on nõrk, võivad paikneda eraldi. Group elements that are strongly connected, separate elements that are unrelated. – See on nõrga seostatuse (loose coupling) põhimõte.
- Vali ülesehitus, milles kommunikatsioon alamsüsteemide vahel on minimaalne. Choose a configuration with minimal communications between the subsystems.
- Süsteemi struktuur peab järgima süsteemi funktsioonide struktuuri. System structure should resemble functional structure.
- Dekomponeeri süsteem (jaota allsüsteemideks ja mooduliteks) nii, et igal tasandil on 5 kuni 9 alamsüsteemi. Iterate the partition/aggregation procedure until systems on each level are composed of 5..9 subsystems.
- Tõkesta mittekasuliku energia (müra, vigade, igat liiki ebaefektiivsuse) levikut. Contain excess energy as close to the source as possible.
- Suurimad võimalused asja parendada on liidestes. Seal on ka suurimad ohud. The greatest leverage in system architecting is at the interfaces. And the greatest dangers. Be sure to ask the question: “What is the worst thing that other systems could do to you across the interface?”
Maier, M et al (2001) The Art of Systems Architecting. CRC Press.
The Open Group. Arhitektuuriraamistik TOGAF.
Ehitusblokid, ingl building blocks on IT arhitektuuri kujundamise viis, kasutusel eelkõige suurtes süsteemides. Kavandatakse ja teostatakse rida komponente - “ehitusblokke” (taristulisi teenuseid), pöörates erilist tähelepanu komponentide kokkusobivusele (koostalitlusvõimele, ingl interoperability). Komponte kombineerides saab paindlikult ja kuluefektiivselt teha erinevaid lahendusi ja teenuseid.
Ehitusblokkide arhitektuuripõhimõte on kasutusel mitmete riikide rahvuslike e-taristute ehitamisel:
- Norra rahvusliku e-taristu ehitusblokid
- Soome National Architecture for Digital Services
- Euroopa Liidu piiriülese e-taristu ehitusblokid: CEF building blocks.
Ehitusblokkide arhitektuurile on rajatud ka suured pilveplatvormid, nt:
Arhitektuuri ohud
Spolsky, Joel (2008) Architecture astronauts take over
Oluline artikkel, räägib tihtiesinevast nähtusest - arhitektuuri minekust “pilvedesse”, reaalsustaju kadumisest.
RDX (2016) 10 Modern Software Over-Engineering Mistakes
“Sometimes Engineers get carried away. Instead of trying to solve the business problem, we waste our time trying to find the perfect abstractions.”
Tehniline, intrigeeriv kirjutis tänapäeva IT arhitektuuri mõnedest eksiteedest.
Blow, Jonathan (2011) Programming Aesthetics learned from making independent games (YouTube)
“It’s easy to see benefits of an idea developed for benefit’s sake! Very hard to measure subtle negatives chained to this idea. (Which often outweigh these benefits).”
Peavooluseisukohtadele oponeerivaid mõtteid tuntud arvutimängude programmeerijalt.
Sústrik, Martin () ZeroMQ. in: The Architecture of Open Source Applications.
“Make sure you understand the problem you are solving. Even a problem as simple as “make it fast” can take lot of work to understand properly”.
Tehniline, kuid IT arhitektuuri probleeme ilmekalt avav case study nimekalt sõnumijadasüsteemide (Message Queue) väljatöötajalt.