code

Loeng 9 · Süsteemi arhitektuur

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 arhitektuurist vaja rääkida?

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 arhitektuuri mõiste on vajalik selleks, et:

• anda süsteemi tegijatele ja kasutajatele ülevaade süsteemist

• aktiivselt kujundada süsteemi struktuuri, vastavalt arhitektuursete printsiipidega (moodulprintsiip, tasakaalustatus jt.).

Näide süsteemi arhitektuuri kirjeldusest

X-tee talitlusskeem (detail). Allikas: Kaljo, A. (2003) Projekti X-tee arengusammud. A & A, 3, 18.

Ülalesitatud X-tee talitlusskeem on üks vaade suhteliselt suure ja keeruka infosüsteemi arhitektuurile.

Näide süsteemi arhitektuuri kirjeldamise tehnikast: Süsteemi põhimõtteskeem (concept of operation diagram)

Süsteemi ideed (toimimise põhimõtet) selgitav diagramm (fragment) (high level operational concept graphic). Allikas: C4ISR Architecture Framework 2.0.

Näide süsteemi arhitektuuri kirjeldamise tehnikast: Zachmani raamistik (Zachman Framework)

Zachmani raamistik (detail). Allikas: A Practical Guide to Federal Enterprise Architecture (USA).

Arhitektuurse praktika tase

Eristada tuleb arhitektuursete lahenduste taset – kui hästi on süsteemid arhitektitud? – ja arhitektuuri esitamise taset – kui hästi süsteemide arhitektuur on kirjeldatud?

Süsteemide arhitektuurse taseme osas on üldistuvat seisukohta ilma vastavate uurimusteta raske võtta.

Kuid mida näeme süsteemi arhitektuuri esitamise praktikas? Paradoksaalne, kuid tõsi – süsteemi arhitektuurne kirjeldus on sageli puudu. Mida see tähendab? – Üldpilt saab siis olla ainult süsteemi tegijate peas. Kas see pilt on aga selge? Mille põhjal saavad süsteemi hiljem lülituvad arendajad ja kasutajad luua endale üldise pildi?

Teine väärnähtus: tehakse kirjeldusi, mille järele pole tegelikult vajadust. Reaalse süs­teemi ehitamisel/arendamisel on peaaegu alati ajapuudus. Seda, mida teha, on rohkem kui aega, energiat, teisi ressursse. Selle tõttu tuleks teha ai­nult selliseid tegevusi, mis viivad süsteemi arengut edasi. Küsimus on ainult selles, kas konkreetne arendus­tegevus annab kohese, silmaga nähtava efekti või on tegevuse mõ­ju kaugem ja vähem vahetu. Vahel tuleb arendus katkestada ja kõigepealt takistu­seks olev tehnoloogiline probleem lahendada (õppida tundma, katsetada) – alles siis saab kindlusega edasi minna. Skeeme ja kirjeldusi, millest midagi ei järgne, ei tuleks teha. Kahjuks küllaltki sageli produtseeritakse dokumentatsiooni kliendile mulje jätmiseks.

Kuidas mõistet “arhitektuur” kasutatakse?

• Arhitektuuri all mõistetakse süsteemi üldist struktuuri.

• Loodava süsteemi korral – lahenduse alusraamistikku.

• Arhitektuuri mõistega on ajalooliselt, lahutamatul seotud esteetiline mõõde. Arhi­tek­tuur ei ole ainult mõõdetavad proportsioonid vaid ka nende proportsioonide otstarbekus ja efektiivsus kõige laiemas, ka esteetilises mõttes.

• Arhitektuuriga seondub küsimus heast toimimistavast (praktikast). Halba arhitektuuri ei nimetatagi arhitektuuriks.

Mis on arhitektuur?

Mis on süsteemi arhitektuur?

• See on midagi püsivat (süsteemi tunnusjooned või omadused, mis on suhteliselt raskesti muudetavad–või muutuvad; ajutine ei ole arhitektuur).

• See on midagi olulist.

• See on midagi inimese poolt kujundatut (juhuslik või looduslikult arenenud ei ole arhitektuur).

• See on midagi ümbruskonnaga suhtestuvat (vaevalt on arhitektuuri, mis seisab omaette).

• See on eriti süsteemi tervikstruktuur; see on kuidas-asjad-koos-käivad.

• Arhitektuur on idee (kandev idee?) ja selle teostus?

• Arhitektuur on sisemine ehitus, üldjoontes aga ka väliselt, kasutaja poolt nähtav ja kogetav.

• Ühendav alusstruktuur

• “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?

Vajadus süsteemi arhitekti järele

Igal vähegi tõsisemal süsteemil peaks olema süsteemi arhitekt. Süsteemi arhitekti positsiooni on viimasel kümnel aastal aktiivselt kasutama. Süsteemi (pea)arhitekt peaks olema üks isik. Laeval saab olla – ja peab olema – ainult üks kapten. Vrdl. ainujuhtimise põhimõte militaaralal. Süsteemi arhitekt on isik, kes lõppkokkuvõttes vastutab süsteemi konstruktsioonilise kandvuse eest. Vastutamine eeldab õigust ja kohustust teha olulisi arhitektuurseid otsustusi. Arhitekt peab arvesse võtma ja ühitama erinevate huvirühmade soove; kuid demokraatlik määratlematus kujundusprotsessides ei garanteeri head arhitektuuri. Olukord, kus süsteemil ei ole ühte, kindlat arhitekti, on tõsise riski märk. See tähendab, et süsteem on triivimas.

“Experience shows the value of a coherent vision through a single person or a very small team”. Edukatel, innovaatilistel süsteemidel on reeglina olnud üks selgelt eristatav arhitekt: masstootmise süsteem (Henry Ford), raketitehnoloogia (Koroljov NSVLs, Saturn/Apollo projektid USAs), ARPAnet/Internet, Ethernet, GSM, MPEG jt.

Majanduslik motiiv

Arhitekti töö ei ole suunatud mitte ainult (ja peamiselt) sellele, et teha kaunist ja võimast süsteemi, vaid suures osas ka kulude kontrolli all hoidmisele. Õigeaegsed arhitektuursed valikud võimaldavad kokku hoida raha (saavutada sama või parem tulemus väiksema töö- ja materjalikuluga). Hea arhitektuurne lahendus tähendab reeglina ka väiksemat riski.

Projekti alustamisel ja esimeses kavandamistsüklis tehtud valikutel võib olla eriti suur mõju kogu projektile. Selle tõttu on arhitekti töö vastutusrikas, mitte ainult projekti esteetilise tulemuse vaid ka funktsionaalse ja majandusliku tulemi suhtes.

Arhitekti ülesanne

Kokkuvõttes: arhitekt loob vajadusi rahuldava, teostatava süsteemi kont­sept­siooni, tagab selle kontseptsiooni ühtsena säilimise arenduse prot­ses­sis ning kontrollib loodud süsteemi valmisolekut kasutusse võtuks.

Tähele panna: 1) arhitekt sünteesib erinevad vaated ja nõudmised ühtseks tervikuks – leiab optimaalse lahenduse, tehes vajadusel kompromisse erinevate nõudmiste ja piirangute vahel; 2) lahendus peab olema ühest küljest vajadusi rahuldav, teisest küljest teostatav; 3) arhitekti töö ei piirdu projekti valmimisega; ta osaleb aktiivselt lahenduse teostamisel, nõuandja ja järelevalvaja rollides.

Eesti keeles ei ole kahjuks levinud eraldi, eestipärased sõnad mitmete süsteemi­arendus­tegevuste, sh. arhitektuuri loomise kohta. Tasuks kaaluda järgmiste oskussõnade kasu­tu­selevõttu:

arhitektimine – arhitektuuri loomine, kujundamine; töö arhitektuuri kallal

projektimine – projekteerimine; töö projekti kallal.

Süsteemi arhitekti töö spetsiifika

Arhitekti ülesanded on suures osas põhimõtteliselt samad, sõltumata alast, kus:

• Arhitekt töötab kliendi jaoks, ehitajaga koostöös, kuid siiski ehitajast eraldi. Arhitektuuri suhteline sõltumatus on oluline.

• Tasustatakse ehitajast eraldi. Ehitise maksumus otse ei mõjuta arhitekti tasu.

• Arhitekt on (peaks olema) tehnoloogiate suhtes erapooletu.

• Arhitekt saab kliendilt lähteinfo vajaduste kohta, kuid mitte täieliku. Aitab vajadusi välja selgitada.

• Probleemi uurimine ja lahenduse skeemi väljatöötamine käsikäes.

• Arhitekti töö tulemused on suhteliselt abstraktsed (projekt)lahendused. Nt korruste plaanid, maksumuse arvestused. Ei ole täielikud tööde teos­ta­mi­seks vajalikud joonised. Tööjoonised tulevad hiljem.

Hea arhitekt

• küllaltki kaootilises arendusprotsessis on see, kes annab stabiilse struktuuri elemendid

• töötab kliendile, kuid suhtleb kõigi osapooltega

Projektijuhti ja süsteemi arhitekti suhe

Suuremas projektis on vajalik süsteemi arhitekt ja projektijuhi rollide eristamine ja andmine erinevatele töötajatele. Süsteemi arhitekt ei jõua tegelda kõigi organisatoorsete ja administreerimise küsimustega. Projektijuht ei jõua süveneda tehnoloogilistesse ja kompositsioonilistesse probleemidesse. Projektijuht ja süsteemi arhitekt peavad töötama käsikäes. Ei ole õige seada projektijuhti süsteemi arhitektist kõrgemale; pigem vastupidi – projektjuht peaks abistama süsteemi arhitekti projekti administratiivses aspektis.

• arhitekti roll on peamiselt tehniline, vähem organisatoorne

• sõltuvalt projekti tüübist võib arhitekt olla suhteliselt eraldatult töötav spetsialist (ei juhi otseselt väljatöötatud lahenduste realiseerimist).

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.

Arhitektuursed vaated

Arhitektuuriline vaade on süsteemi lihtsustatud kirjeldus abstraktsioon), mis on tehtud ühest vaatepunktist või vaatenurgast. Vaade katab süsteemi valitud aspekte. Vaade ei esita antud vaatenurga jaoks ebaolulisi detaile. Arhitektuursed vaated on süsteemi tehtud „läbilõiked”.

Süsteemi arhitektuuri esitamiseks vajame reeglina mitut, erinevat kuid siiski omavahel kooskõlas olevat vaadet (ehk mudelit). Arhitektuuri kirjeldused on harilikult mitme­vaa­te­lised. Millised vaated (mudelid) on vajalikud – seda ei saa alati ette öelda. Vaadete ja mudelite valik sõltub uuritavast probleemist.

Tarkvarasüsteemide arhitektuuri esitamiseks on tänapäeval laialt populaarsust võitnud viiest vaate käsitlus:

1. Use Case View

2. Logical View — lõppkasutajale pakutav funktsionaalsus (End-User Functionality)

3. Process View — jõudlus, skaleeritavus, läbilaskevõime (Performance, Scalability, Throughput)

4. Implementation View — programmeerija vaade

5. Deployment View — süsteemi topoloogia, kasutuselevõtmine, paigaldamine.

Kui palju arhitektuurseid vaateid on mõistlik?

Vaadete nomenklatuur ei pea olema jäik. Küsimus ei ole mitte niivõrd selles, kas ideaalseks on 4, 5 või 6 vaadet, vaid õige vaadete komplekti valimine, lähtudes ehitatava süsteemi eripärast. Loogiliseks aluseks on kujutusvajadused – mis on ebaselge? milliseid süsteemi aspekte tahame kujutada?

Näiteks ülaltoodud meetodis soovitatakse:

single processor: drop deployment view

single process: drop process view

very small program: drop implementation view.

Vaateid võib lisada ja ära jätta, vastavalt vajadusele. Lisaks ülaltoodud viiele vaatele soovitavad meetodi autorid vajadusel kasutada andmevaadet (Data view), turvavaadet (Security view) jt.

Arhitektuuri mõistete süsteem

Maier (2002) esitab arhitektuuri ja vaate seosed kokkuvõtlikult väga hästi aksiomaatiliste lausete abil:

• „A system has 1 architecture

• _ An architecture is described by 1 or more architecture descriptions_

• _ An architecture description is composed of 1 or more of stakeholders, concerns, viewpoints, views, and models_

• _ A stakeholder has 1 or more concerns_

• _ A concern has 1 or more stakeholders_

• _ A viewpoint covers 1 or more concerns and stakeholders_

• _ A view conforms to 1 viewpoint_

• _ A viewpoint defines the method of a model_

• A view has 1 or more models and a model is part of 1 or more views.

• A viewpoint library is composed of viewpoints.”

18. Tarkvara arhitektuur – mida käsitleb?

Tarkvara arhitektuuriga otsustatakse (Booch):

• struktuuri elemendid ning liidesed—mis koos moodustavadki süsteemi

• süsteemi käitumine—koostöö struktuurielementide vahel

• dekompositsioon alamsüsteemideks

• arhitektuurilised stiilijuhised.

Tarkvara arhitektuur käsitleb samuti järgmisi küsimusi (Booch):

• süsteemi funktsionaalsus, s.t. mida süsteem pakub (functionality)

• süsteemi jõudlus (performance)

• süsteemi häirekindlus (resilience)

• süsteemiarenduse vahe- ja lõpp-produktide taaskasutatavus (reuse)

• süsteemi mõistetavus (comprehensibility)

• majanduslikud ja tehnoloogilised piirangud ja kompromissid (economic and technology constraints and tradeoffs)

• esteetilised küsimused (aesthetic concerns).

Tarkvaralahenduse arhitektuur – elemendid

Mitte kõik lahenduse elemendid ei ole arhitektuur, ainult:

• peamised klassid

• olulised mehhanismid

• protsessorid ja protsessid

• kihid ja alamsüsteemid.

Diagramm

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.

Näiteks UML keel pakub 9 standardset diagrammitüüpi (vaadet):

Vaated süsteemi staatikasse:

• kasutusjuhu vaade Use case

• klassivaade Class

• objektivaade Object

• komponendivaade Component

• rakendusvaade Deployment

Vaated süsteemi dünaamikasse:

• järjestuse vaade Sequence

• koostöövaade Collaboration

• olekuvaade Statechart

• tegevusvaade Activity.

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:

• resilient

• simple

• approachable

• clear separation of concerns

• balanced distribution of responsibilities

• balances economic and technology constraints.

Arhitektuuri loomise “reegleid”

Kas arhitektuur ainult tekitatakse või tekib ka ise?

Thomas loetleb huvitava rea arhitektuuri loomise „reegleid”. Tasub tähele panna, et:

• 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).

Thomase soovitused:

• 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õtte väljendus.

• 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?”

Infosüsteemi strateegiline arhitektuur (üks lihtsa meetodi võimalus)

Probleemid:

• kuidas saavutada üldpilti organisatsiooni kui terviku toimimisest?
• kuidas saavutada üldettekujutust organisatsiooni osade koostoimimisest?
• kuidas saada ülevaadet organisatsiooni infosüsteemi koosseisust ja seisundist?
• kust saada alust infosüsteemi tasakaalustatud arendamiseks?

Mis on Infosüsteemi strateegiline arhitektuur? Organisatsiooni tasakaalustatud arengu jaoks strateegilise tähtsusega informatsiooniline produkt — integreeritud mudel — mis kirjeldab:

• organisatsiooni tegevuse eesmärke (missiooni)
• neid eesmärke teostavaid tegevusi (protsesse)
• informatsiooni, mida vajatakse tegevuses
• tehnoloogiaid, mis toetavad organisatsiooni toimimist
• arendusprotsesse, mis on vajalikud uute infotehnoloogiate rakendamiseks.

Infosüsteemi strateegilist arhitektuuri saab kasutada:

• strateegilisel planeerimisel
• tegevusprotsesside ümberkorraldamisel ja parendamisel
• tegevuse koordineerimisel struktuuriosade vahel
• sarnaste funktsioonide ühtlustamisel ja standardimisel
• protsesside automatiseerimisel
• uutele infotehnoloogiatele kasutusvõimaluste leidmisel
• ressursijaotuse ja organisatsiooni ümberkorraldamisel.

Mida annab infosüsteemi strateegiline arhitektuur?

• annab organisatsiooni kui sellise süsteemse määratluse
• soodustab kommunikatsiooni allüksuste vahel
• toetab IT ja teiste funktsioonide üksteisemõistmist
• aitab leida ja likvideerida dubleerivaid, ebaefektiivseid töölõike ja alamsüsteeme
• annab ülevaate keeruka süsteemi toimimisest ja arengust
• aitab optimaalselt jagada ressursse ja investeeringuid.

Arhitektuursed vaated

Strateegiline arhitektuur esitatakse nn. arhitektuursete vaadete abil.

Vaade on infosüsteemi arhitektuuri esitus ühes lõikes, ühes vaatepunktist või ühest aspektist lähtudes. Vaadete hulk ei ole piiratud. Tavaliselt piisab u. 3-10 vaatest. Neli peamist vaadet on:

• funktsiooni vaade
• informatsiooni vaade
• organisatsiooni vaade
• tehnoloogia vaade.

Võib öelda, et:

• funktsiooni vaade esitab ideelist struktuuri
• informatsiooni vaade esitab infostruktuuri
• organisatsiooni vaade esitab inimstruktuuri
• tehnoloogiavaade esitab taristinfrastruktuuri

arhitektuurne vaade: Funktsioonid. Käsitleb: tegevusvaldkondi, protsesse, tegevusi. Peamised tooted:

• missioonide, visioonide, organisatsiooni toimimispõhimõtete määratlused
• protsessimudelid, tegevuste taksonoomia
• õiguste ja vastutuse mudel.

Toetavad tooted:

• oluliste sündmuste mudelid, Olekudiagrammid
• süsteemi funktsionaalsuse kirjeldused.

arhitektuurne vaade: Informatsioon. Käsitleb: kogu informatsiooni, mida kasutatakse (laiemalt–luuakse, töödeldakse, edastatakse jne.) tööprotsessides, samuti selle informatsiooni struktuuri. Peamised tooted:

• info tüüpide kataloog
• infovahetuse kontseptuaalne mudel.

Toetavad tooted:

• CRUD maatriksid
• loogilised ja füüsilised andmemudelid
• detailsed infovahetuse mudelid.

arhitektuurne vaade: Organisatsioon. Käsitleb: organisatsiooni struktuuri, vastutus- ja toimimisalasid, töötajate liigitust, tegevuse paigutust. Peamised tooted:

• organisatsiooni skeem
• tegevuskohtade ja nendevahelise infovahetuse kontseptuaalne mudel

Toetavad tooted:

• tegevuskohtade ja nendevahelise infovahetuse detailsed mudelid.

arhitektuurne vaade: Tehnoloogia. Käsitleb: riistvara, tarkvara, arvuti- ja sidevõrke, kommunikatsioonivahendeid, tehnilisi ja tugiteenuseid, mis tervikuna moodustavad organisatsiooni toimimise keskkonna. Peamised tooted:

• tehnilise informatsiooni koondmudel
• oluliste standardite loetelu ja iseloomustus
• oluliste liideste kirjeldused

Arhitektuuri esitusviisid:

• loetelud
• tabelid
• diagrammid
• tekstid.

Lähteandmed infosüsteemi strateegilise arhitektuuri koostamiseks:

• regulatiivsed dokumendid (seadused, määrused, põhikirjad jne.)
• plaanid, aruanded jm. dokumentatsioon
• olemasolev infosüsteem
• visioonid
• küsitlused, intervjuud, rühmatöö.

Probleemid/harjutused

1 Vali olemasolev süsteem ja uuri selle arhitektuuri kirjeldust.

2 Kavanda arhitektuurne lahendus loodavale infosüsteemile. Vali otstarbekad esitusviisid (vaated, diagrammid) arhitektuuri esitamiseks.

Kirjandus

Booch, G. Software Architecture and the UML.

Maier, M. (2002) Systems Architecture: A Tutorial.

Maier, M., Rechtin (2001) The Art of Systems Architecting, second edition, CRC Press.

McDavid, D. (1999) A Standard for Business Architecture Description. IBM Systems Journal, 38, 1, 12-31.

The Open Group. Arhitektuuriraamistik TOGAF 9.1.

LISA. Arhitektuuri kirjeldamise nõuded ja praktika Eesti avaliku sektori infosüsteemides.

Riigi Infosüsteemi Amet (2014) Arhitektuuri kirjeldamise mall.

CC BY-NC-SA 4.0 Priit Parmakson 2017