Arkitektura e softuerit

Arkitektura e softuerit trajton natyrshëm pasiguri, dhe madhësia e komponenteve arkitekturore mund të ketë një ndikim të rëndësishëm në rezultatet e një sistemi, si në mënyrë pozitive, ashtu edhe negative. Neal Ford dhe Mark Richards propozojnë një qasje përsëritese për të adresuar sfidën e identifikimit dhe përcaktimit të masës së duhur të komponenteve. Kjo metodë përqendrohet në rafinimin e vazhdueshëm ndërsa ekipet zhvillojnë një kuptim më të thelluar dhe të nuancuar të sjelljes dhe kërkesave të sistemit.ërsëritëse për të adresuar sfidën e identifikimit dhe madhësisë së duhur të komponentëve. Kjo metodë thekson përsosjen e vazhdueshme ndërsa ekipet zhvillojnë një kuptim më të hollësishëm të sjelljes dhe kërkesave të sistemit. 

Qasja zakonisht përfshin një cikël me disa faza: 

* Një strategji ndarjeje e nivelit të lartë vendoset, e cila shpesh kategorizohet si teknike ose e bazuar në domen. Përcaktohen udhëzime për njësinë më të vogël kuptimplote të lëvizshme, të referuara si "kuanta". Ndërsa këto vendime themelore merren herët, ato mund të rishikohen më vonë gjatë ciklit nëse është e nevojshme.
* Komponentët fillestarë identifikohen bazuar në strategjinë e përcaktuar.
* Kërkesat u caktohen komponentëve të identifikuar.
* Rolet dhe përgjegjësitë e secilit komponent analizohen për të siguruar qartësi dhe për të minimizuar mbivendosjen.
* Karakteristikat arkitekturore, të tilla si shkallëzueshmëria, toleranca ndaj defekteve dhe mirëmbajtja, vlerësohen.
* Komponentët mund të ristrukturohen bazuar në reagimet nga ekipet e zhvillimit.

Ky cikël shërben si një kornizë e përgjithshme dhe mund të përshtatet në fusha të ndryshme.

## Fushat 
Ekzistojnë mendime të ndryshme lidhur me fushën e arkitekturës së softuerit:

* **Struktura makroskopike e sistemit** : Kjo i referohet arkitekturës si një abstraksion në nivel më të lartë të një sistemi softuerik që përbëhet nga një koleksion komponentësh llogaritës së bashku me lidhës që përshkruajnë ndërveprimin midis këtyre komponentëve.
* **Gjërat e rëndësishme – çfarëdo qoftë kjo** : Kjo i referohet faktit që arkitektët e softuerit duhet të merren me ato vendime që kanë ndikim të madh mbi sistemin dhe palët e interesuara.
* **Ajo që është thelbësore për të kuptuar një sistem në mjedisin e tij** 
* '''Gjërat që njerëzit i perceptojnë si të vështira për t'u ndryshuar** :Meqenëse projektimi i arkitekturës ndodh në fillim të ciklit jetësor të një sistemi softuerik, arkitekti duhet të përqendrohet në vendime që "duhet" të jenë të sakta herën e parë. Duke ndjekur këtë logjikë, çështjet e projektimit arkitektonik mund të mos jenë më arkitekturore pasi tëkapërcehet pakthyeshmëria e tyre. Ky kuptim ka çuar në hulumtime të konsiderueshme mbimenaxhimin e njohurive të arkitekturës softuerike.

Nuk ka një kufi të qartë midis arkitekturës së softuerit dhe projektimit apo inxhinierisë së kërkesave. (shih fushat përkatëse më poshtë). Ata janë pjesë e një "zinxhiri qëllimshmërie" nga synimet në nivel të lartë deri te detajet në nivel të ulët.

## Karakteristikat 
Arkitektura e softuerit përmban elementët e mëposhtëm:

**Shumë palë të interesuara:** Sistemet softuerike duhet të plotësojnë nevojat e një shumëllojshmërie palësh të interesuara si menaxherët e biznesit, pronarët, përdoruesit dhe operatorët. Këto palë kanë shqetësimet e tyre specifike për sistemin. Balancimi i këtyre shqetësimeve dhe demonstrimi i adresimit të tyre është pjesë e projektimit të sistemit. Këto përshkrime të veçanta quhen pamje arkitekturore (shih për shembull modelin e pamjes arkitekturore 4+1).

**E drejtuar nga cilësia:** qasjet klasike projektimit të softuerit (p.sh. Jackson Structured Programming) janë udhëhequr nga funksionaliteti i kërkuar dhe rrjedha e të dhënave përmes sistemit, por kuptimi aktual 

**Kufizimet njohëse:** Një vëzhgim i bërë për herë të parë në një artikull të vitit 1967 nga programuesi kompjuterik Melvin Conway, ku organizatat që projektojnë sisteme janë të kufizuara të prodhojnë projekte që janë kopje të strukturave të komunikimit të këtyre organizatave. Fred Brooks e prezantoi këtë ide tek një audiencë më e gjerë kur citoi këtë artikull dhe këtë ide në The Mythical Man-Month, duke e quajtur atë Ligji i Conway.

## Stili i arkitekturës së softuerit vs Modeli i arkitekturës së softuerit 
**Modeli i Arkitekturës së Softuerit** i referohet një zgjidhjeje të ripërdorshme dhe të provuar për një problem që përsëritet në nivel sistemi, duke trajtuar çështje që lidhen me strukturën e përgjithshme, mënyrën se si ndërveprojnë komponentët dhe tiparet cilësore të sistemit. Modelet e arkitekturës së softuerit funksionojnë në një nivel më të lartë abstraksioni sesa modelet e dizajnit të softuerit, duke zgjidhur sfida më të gjera në nivel sistemi. Edhe pse këto modele zakonisht ndikojnë në çështje të përmasave sistemore, dallimi midis modeleve arkitekturore dhe stileve arkitekturore nganjëherë mund të jetë i paqartë. Një shembull i tillë është **Circuit Breaker (ndërprerës qarku)**.

**Stili i Arkitekturës së Softuerit'* i referohet një organizimi strukturor të nivelit të lartë që përcakton organizimin e përgjithshëm të sistemit, duke specifikuar se si organizohen komponentët, si bashkëveprojnë dhe kufizimet në këto bashkëveprime. Stilet e arkitekturës zakonisht përfshijnë një fjalor të llojeve të komponentëve dhe lidhësve, si dhe modele semantike për interpretimin e karakteristikave të sistemit. Këto stile përfaqësojnë nivelin më të përgjithshëm të organizimit të sistemit. Shembujt përfshijnë Arkitekturën e Shtresuar, Mikroshërbimet dhe Arkitekturën e Drejtuar nga Ngjarjet .  
## Anti-modelet 
Anti-modelet arkitekturore që vijojnë mund të lindin si pasojë e vendimeve të arkitektëve. Këto anti-modele zakonisht zhvillohen sipas një sekuence progresive, ku adresimi i një problemi mund të shkaktojë shfaqjen e një problemi tjetër.  Aftësia për të verifikuar që një sistem i ardhshëm softuerësh plotëson nevojat e palëve të interesuara pa qenë nevoja ta ndërtojmë atë përfaqëson një kursim të konsiderueshëm të kostos dhe reduktim të rrezikut. Janë zhvilluar një sërë teknikash për të kryer analiza të tilla, si ATAM ose duke krijuar një përfaqësim vizual të sistemit të softuerit.
* *Ofron një bazë për ripërdorimin e elementeve dhe vendimeve.*

## Historia 
Krahasimi midis projektimit të softuerit dhe arkitekturës civile u bë për herë të parë në fund të viteve 1960, por termi "arkitekturë e softuerit" nuk u përdor gjerësisht deri në vitet 1990. Disiplina e shkencave kompjuterike është përballur me probleme që lidhen me kompleksitetin që nga krijimi i saj. Problemet e hershme të kompleksitetit u zgjidhën nga zhvilluesit duke zgjedhur strukturat e të dhënave te duhura, zhvilluar algoritme dhe duke aplikuar konceptin e ndarjes së shqetësimeve. Edhe pse termi "arkitekturë e softuerit" është relativisht i ri në industri, parimet themelore të kësaj fushe janë aplikuar herë pas here nga pionierët e inxhinierisë së softuerit që nga mesi i viteve 1980. Përpjekjet e hershme për të kapur dhe shpjeguar arkitekturën e një sistemi ishin të paqarta dhe të ç’organizuara, shpesh karakterizuar nga një grup diagramesh kutish dhe vijash.

Është përgjegjësi e arkitektit të softuerit të përputhë me karakteristikat arkitekturore (të njohura si kërkesat jo-funksionale) me kërkesat e biznesit. Për shembull: Këto aktivitete kryesore të arkitekturës kryhen në mënyrë iteruese në faza të ndryshme të ciklit të zhvillimit të softuerit, si dhe gjatë evolucionit të një sistemi.

**Vlerësimi i Arkitekturës** është procesi i përcaktimit të shkallës në të cilën dizajni aktual ose një pjesë e tij plotëson kërkesat e nxjerra gjatë analizës. Të dhënat ose kërkesat për aktivitetin e analizës mund të vijnë nga çdo numër i palësh të interesuara dhe përfshijnë elementë të tillë si:

* çfarë do të bëjë sistemi kur të jetëperkthe n në funksion (kërkesat funksionale)
* Sa mirë do të performojë sistemi gjatë ekzekutimit për kërkesat jofunksionale gjatë kohës së zhvillimit, si mirëmbajtshmëria dhe transferueshmëria, të përcaktuara në standardin ISO 25010:2011
* koha e zhvillimit të kërkesave jofunksionale si mirëmbajtja dhe transferueshmëria e përcaktuar në standardin ISO 25010:2011

Rezultatet e aktivitetit të analizës janë ato kërkesa që kanë një ndikim të matshëm në arkitekturën e një sistemi softuerik, të quajtura kërkesa të arkitekturorisht të rëndësishme.

**Sinteza ose dizajni arkitekturor** është procesi i krijimit të një arkitekture. Duke pasur parasysh kërkesat e arkitekturorisht të rëndësishme të përcaktuara nga analiza, gjendjen aktuale të projektimit dhe rezultatet e çdo aktiviteti vlerësimi, dizajni është krijuar dhe përmirësuar. Kornizat për krahasimin e teknikave diskutohen në korniza të tilla si *Raporti SARA''

**Evolucioni i arkitekturës** është procesi i mirëmbajtjes dhe përshtatjes së një arkitekture ekzistuese të softuerit për të përmbushur ndryshimet në kërkesa dhe mjedis. Meqenëse arkitektura e softuerit ofron një strukturë themelore për një sistem softuerik, evolucioni dhe mirëmbajtja e saj do të ndikojnë domosdoshmërisht në strukturën e saj themelore. Prandaj, evolucioni i arkitekturës merret si me shtimin e funksionaliteteve të reja, ashtu edhe me mirëmbajtjen e funksionaliteteve ekzistuese dhe sjelljes së sistemit.

Arkitektura kërkon aktivitete mbështetëse kritike. Këto aktivitete mbështetëse zhvillohen gjatë procesit kryesor të arkitekturës së softuerit. Ato përfshijnë menaxhimin dhe komunikimin e njohurive, arsyetimin dhe marrjen e vendimeve në dizajn, si dhe dokumentimin.

### Aktivitete mbështetëse të arkitekturës 
Aktivitetet mbështetëse të arkitekturës së softuerit kryhen gjatë aktiviteteve kryesore të arkitekturës së softuerit. Këto aktivitete ndihmojnë arkitektin e softuerit për të kryer analiza, sintezë, vlerësim dhe evolucion. Për shembull, gjatë fazës së analizës, një arkitekt duhet të mbledhë njohuri, të marrë vendime dhe të dokumentojë.

* **Menaxhimi dhe komunikimi i njohurive** është veprimi i eksplorimit dhe menaxhimit të njohurive që janë thelbësore për projektimin e një arkitekture softuerike. Një arkitekt softuerik nuk punon në izolim. Ata marrin hyrje, si kërkesa funksionale dhe jo-funksionale, dhe kontekste dizajni nga një gamë e gjerë palësh të interesuara dhe ofrojnë rezultate për këto palë. Njohuritë për arkitekturën e softuerit shpesh janë të pashprehura dhe mbahen në mendjet e palëve të interesuara. Aktiviteti i menaxhimit të njohurive për arkitekturën e softuerit konsiston në gjetjen, komunikimin dhe ruajtjen e këtyre njohurive.
* Meqenëse çështjet e dizajnit të arkitekturës së softuerit janë komplekse dhe të ndërlidhura, një mungesë njohurish në arsyetimin e dizajnit mund të çojë në një projektim të pasaktë të arkitekturës së softuerit. 
* Shembuj të aktiviteteve të menaxhimit dhe komunikimit të njohurive përfshijnë kërkimin për modele dizajni, prototipizimin, pyetjen e zhvilluesve dhe arkitektëve me përvojë, vlerësimin e dizajneve të sistemeve të ngjashme, ndarjen e njohurive me dizajnues të tjerë dhe palë të interesuara, dhe dokumentimin e eksperiencës në një faqe wiki.
* **Arsyetimi i dizajnit dhe marrja e vendimeve** është aktiviteti i vlerësimit të vendimeve të dizajnit. Ky aktivitet është thelbësor për të tre aktivitetet kryesore të arkitekturës së softuerit. Ai përfshin mbledhjen dhe shoqërimin e konteksteve të vendimeve, formulimin e problemeve të vendimeve të dizajnit, gjetjen e opsioneve të zgjidhjes dhe vlerësimin e kompromiseve para se të merret një vendim. Ky proces ndodh në nivele të ndryshme të hollësisë së vendimeve gjatë vlerësimit të kërkesave të rëndësishme arkitekturore dhe vendimeve për arkitekturën e softuerit, si dhe gjatë analizës, sintezës dhe vlerësimit të arkitekturës së softuerit. Shembuj të aktiviteteve të arsyetimit përfshijnë kuptimin e ndikimeve të një kërkese ose një dizajni në atributet e cilësisë, pyetjen e problemeve që mund të shkaktojë një dizajn, vlerësimin e opsioneve të mundshme të zgjidhjes dhe vlerësimin e kompromiseve midis zgjidhjeve.
* Dokumentimi është akti i regjistrimit të dizajnit të krijuar gjatë procesit të arkitekturës së softuerit. Dizajni i sistemit përshkruhet duke përdorur disa pamje që shpesh përfshijnë një pamje statike që tregon strukturën e kodit të sistemit, një pamje dinamike që tregon veprimet e sistemit gjatë ekzekutimit, dhe një pamje të vendosjes që tregon se si një sistem vendoset në hardware për ekzekutim. Pamja 4+1 e Kruchten sugjeron një përshkrim të pamjeve të përdorura shpesh për dokumentimin e arkitekturës së softuerit
* Dokumentimi i Arkitekturave të Softuerit: Pamje dhe Përtej ka përshkrime të llojeve të shenjave që mund të përdoren brenda përshkrimit të pamjes
* Shembuj të aktiviteteve të dokumentimit janë shkrimi i një specifikimi, regjistrimi i një modeli të dizajnit të sistemit, dokumentimi i një arsyeje për dizajnin, zhvillimi i një pikëpamje, dhe dokumentimi i pamjeve.

## Temat e arkitekturës së softuerit 
### Përshkrimi i arkitekturës së softuerit 
Përshkrimi i arkitekturës së softuerit përfshin parimet dhe praktikat e modelimit dhe përfaqësimit të arkitekturave, duke përdorur mekanizma si gjuhët e përshkrimit të arkitekturës, pikëpamjet earkitekturës dhe kornizat e arkitekturës.

### Gjuhët e Përshkrimit të Arkitekturës 
Një gjuhë përshkrimi i arkitekturës (ADL) është çdo mjet shprehjeje që përdoret për të përshkruar një arkitekturë softuerike (ISO/IEC/IEEE 42010 ). Shumë ADL-ve të përdorimit të veçantë janë zhvilluar që nga vitet 1990, përfshirë AADL (standard SAE), Wright (zhvilluar nga Carnegie Mellon), Acme (zhvilluar nga Carnegie Mellon), xADL (zhvilluar nga UCI), Darwin (zhvilluar nga Imperial College London), DAOP-ADL (zhvilluar nga Universiteti i Málaga), SBC-ADL (zhvilluar nga Universiteti Nacional Sun Yat-Sen), dhe ByADL (Universiteti i L'Aquila, Itali).

### Pikëpamjet e arkitekturës 
parapamje|264x264px| Modeli me pamje arkitektonike 4+1.
Përshkrimet e arkitekturës së softuerit zakonisht organizohen nëpërmjet pikave të shikimit, të cilat janë analoge me llojet e ndryshme të planeve të ndërtimit në arkitekturën e ndërtesave. Çdo pikë shikimi adreson një grup shqetësimesh të sistemit, duke ndjekur konventat e pikës së pikëpamjes së saj, ku një pikëpamje është një specifikim që përshkruan shënimet, modelimin dhe teknikat e analizës për të përdorur në një pikë shikimi që shpreh arkitekturën në fjalë nga perspektiva i një grupi të caktuar të palëve të interesuara dhe shqetësimet e tyre (ISO/IEC/IEEE 42010). Pika e shikimit specifikon jo vetëm shqetësimet që janë përfshirë (dmth., që do të adresohen), por edhe paraqitjen, llojet e modeleve të përdorura, konventat e përdorura dhe çdo rregull të konsistencës (përputhjes) për të mbajtur një pikëpamje të konsoliduar me pikëpamjet e tjera.

### Kornizat e arkitekturës 
Një kornizë arkitekture kap "konventat, principet dhe praktikat për përshkrimin e arkitekturave të vendosura brenda një domeni të caktuar aplikimi dhe/ose një komuniteti të palëve të interesuara" (ISO/IEC/IEEE 42010). Një kornizë zakonisht zbatohet nëpërmjet një ose më shumë pikëpamjeve ose ADL-ve.

### Stilet dhe modelet arkitekturore 
Një model arkitekture është një zgjidhje e përgjithshme, e ripërdorshme për një problem të zakonshëm në arkitekturën e softuerit brenda një konteksti të caktuar. Modelet arkitekturore shpesh dokumentohen si modele të projektimit të softuerit.

Duke ndjekur arkitekturën tradicionale të ndërtimit, një "stil arkitektonik softuerik" është një metodë e veçantë ndërtimi, e karakterizuar nga tiparet që e bëjnë të dallueshëm" (stili arkitektonik).

Një stil arkitektonik përcakton: një familje sistemesh në terma të një modeli të organizatës strukturore; një fjalor komponentësh dhe lidhësish, me kufizime se si mund të kombinohen ata. 

Stilet arkitekturore janë "paketa" të ripërdorshme vendimesh dizajni dhe kufizimesh që zbatohen në një arkitekturë për të nxitur cilësitë e dëshiruara të zgjedhura.

Ka shumë modele dhe stile arkitekturore të njohura, disa prej të cilave janë:

* Blackboard
* Broker pattern
* Klient-server (2-tier, 3-tier, *n*-tier, kompjuterizimi në re paraqet këtë stil)
* Baza e komponentëve
* Data-centric
* Ngjarje të drejtuara (ose thirrje implicite)
* Modeli  interpreter
* Arkitektura e shtresuar (ose shumë-shtresore)
* Master-slave
* Arkitektura e Mikroshërbimeve
* Modeli-pamje-kontrollues 
* Aplikacioni Monolitik
* Peer-to-peer (P2P)
* Tubat dhe filtrat
* Plug-ins
* Arkitektura reaktive
* Transferimi i shtetit të përfaqësimit (REST)
* Bazuar në rregulla
* Orientuar në shërbim
* Arkitektura pa ndarje
* Arkitektura hapësinore
* Arkitektura pa server

Disa i trajtojnë modelet arkitekturore dhe stilet arkitekturore si të njëjta, disa i trajtojnë stilet si specializime të modeleve. Ajo që kanë të përbashkët është se si modelet, ashtu edhe stilet janë idiomë për arkitektët që t’i përdorin, ato "sigurojnë një gjuhë të përbashkët" duke përfshirë metodën agile DSDM e cila kërkon një fazë "Themelimesh" gjatë së cilës vendosen "mjaftueshëm" themele arkitekturore. *IEEE Software* i kushtoi një numër të veçantë ndërveprimit midis shkathtesise dhe arkitekturës.

### Erozioni i arkitekturës së softuerit 
Erozioni i arkitekturës së softuerit i referohet një hendeku gradual midis arkitekturës së synuar dhe asaj të zbatuar të një sistemi softuerik me kalimin e kohës. Një rast i famshëm i erozionit të arkitekturës është dështimi i shfletuesit të internetit Mozilla.  Mozilla është një aplikacion i krijuar nga Netscape me një bazë të koduar komplekse që u bë më e vështirë për t'u mbajtur për shkak të ndryshimeve të vazhdueshme. Për shkak të dizajnit fillestar të dobët dhe erozionit të rritur të arkitekturës, Netscape kaloi dy vjet duke renovar shfletuesin e internetit Mozilla, duke treguar se sa e rëndësishme është menaxhimi i erozionit të arkitekturës për të shmangur përpjekjet e shtrenjta për riparime, humbjen e kohës dhe kostos.

Erozioni i arkitekturës mund të urojë performancën e softuerit, të rrisë ndjeshëm kostot evolutive dhe të degradojë cilësinë e softuerit. Janë propozuar qasje dhe mjete të ndryshme për të zbuluar erozionin e arkitekturës. Këto qasje klasifikohen kryesisht në katër kategori: të bazuara në konsistencë, të bazuara në evolucion, të bazuara në defekte dhe qasje të bazuara në vendimmarrje. Përveç kësaj, masat që përdoren për të adresuar erozionin e arkitekturës përmbajnë dy lloje kryesore: masa parandaluese dhe masa rregulluese. Ekzistojnë praktika për të rikuperuar arkitekturën e softuerit si analizë statike e programit. Kjo është një pjesë e temave të mbuluara nga praktika e inteligjencës softuerike .

## Fushat e lidhura 
### Dizajni 
Arkitektura është dizajn, por jo i gjithë dizajni është arkitektonik. arkitektonik. Në praktikë, arkitekti është ai që tërheq vijën midis arkitekturës së softuerit (dizajni arkitektonik) dhe dizajnit të detajuar (dizajni jo arkitektonik). Nuk ka rregulla ose udhëzime që përshtaten për të gjitha rastet, megjithëse ka pasur përpjekje për të formalizuar dallimin. Sipas Hipotezës *së intensionit/lokalitetit*, dallimi ndërmjet dizajnit arkitekturor dhe atij të detajuar përcaktohet nga *Kriteri i Lokalitetit*, sipas të cilit një deklaratë rreth dizajnit të softuerit është jo-lokal (arkitektonik) nëse dhe vetëm nëse një program që plotëson se mund të zgjerohet në një program që nuk është. Për shembull, stili klient-server është arkitektonik (strategjik) sepse një program që është ndërtuar mbi këtë princip mund të zgjerohet në një program që nuk është klient-server - për shembull, duke shtuar nyje peer-to-peer.

### Inxhinieria e kërkesave 
Inxhinieria e kërkesave dhe arkitektura e softuerit mund të shihen si qasje plotësuese: ndërsa arkitektura e softuerit synon 'hapësirën e zgjidhjes' ose 'si', inxhinieria e kërkesave adreson 'hapësirën e problemit' ose 'çfarë'. Inxhinieria e kërkesave përfshin nxjerrjen, negociatën, specifikimin, validimin, dokumentimin dhe menaxhimin e kërkesave. Të dyja, inxhinieria e kërkesave dhe arkitektura e softuerit përqendrohen në shqetësimet, nevojat dhe dëshirat e palëve të interesuara.

*Ka një mbivendosje të konsiderueshme midis inxhinierisë së kërkesave dhe arkitekturës së softuerit, siç tregohet, për shembull, nga një studim mbi pesë metoda industriale të arkitekturës së softuerit që përfundon se &amp;quot;inputet (qëllimet, kufizimet, etj.) zakonisht janë të pasqaruara, dhe zbulohet ose kuptohen më mirë pasi arkitektura fillon të shfaqet&amp;quot; dhe se ndërsa "shumica e shqetësimeve arkitekturore shprehen si kërkesa për sistemin, ato gjithashtu mund të përfshijnë vendime të detyrueshme të projektimit"*. Qasjet si modeli Twin Peaks synojnë të shfrytëzojnë lidhjen sinergjike midis kërkesave dhe arkitekturës.

### Llojet e tjera të "arkitekturës" 
; Arkitektura kompjuterike
: Arkitektura kompjuterike synon strukturën e brendshme të një sistemi kompjuterik, për sa i përket komponentëve të harduerit bashkëpunues si CPU - ose procesori - autobusi dhe memoria.

; Arkitektura pa server
: Arkitektura pa server është një paradigmë kompjuterike cloud që shpesh keqkuptohet si pa server. Ajo në thelb i kalon përgjegjësitë e menaxhimit të serverit nga zhvilluesit tek ofruesit e shërbimeve në re. Kjo u mundëson bizneseve të ekzekutojnë kodin e tyre të pasëm në infrastrukturën e re, duke eliminuar nevojën për menaxhimin e serverëve fizikë. Qasja e drejtuar nga ngjarjet e arkitekturës pa server mbështetet në funksione të vogla, specifike për detyra që ekzekutohen sipas kërkesës. Këto funksione njihen si Funksion si Shërbim (FaaS), dhe ato ofrojnë efikasitet në kosto përmes një modeli tarifimi sipas përdorimit dhe shkallëzimit dinamik të burimeve bazuar në kërkesën e aplikacionit.

; Arkitektura e sistemeve
: Termi arkitekturë e sistemeve është përdorur fillimisht për arkitekturën e sistemeve që përbëhen nga hardueri dhe softueri. Shqetësimi kryesor që trajtohet nga arkitektura e sistemeve është integrimi i softuerit dhe harduerit në një pajisje të plotë dhe që funksionon siç duhet. Në një kuptim tjetër të zakonshëm – shumë më të gjerë – termi i referohet arkitekturës së çdo sistemi kompleks që mund të jetë teknik,, socioteknike ose social.

; Arkitektura e ndërmarrjes
: Qëllimi i arkitekturës së ndërmarrjes është të "përkthejë vizionin dhe strategjinë e biznesit në ndërmarrje efektive". Kornizat e arkitekturës së ndërmarrjeve, të tilla si TOGAF dhe Korniza Zachman, zakonisht dallojnë midis shtresave të ndryshme të arkitekturës së ndërmarrjeve. Edhe pse terminologjia ndryshon nga korniza në kornizë, shumë përfshijnë të paktën një dallim midis një shtrese *biznesi*, një *shtrese* *aplikimi* (ose *informacioni*) dhe një *shtrese teknologjike*. Arkitektura e ndërmarrjeve trajton ndër të tjera përputhjen midis këtyre shtresave, zakonisht në një qasje nga lart-poshtë.

## Referime 
## Leximi i mëtejshëm 
* 
*  - This book covers the fundamental concepts of the discipline. The theme is centered on achieving quality attributes of a system.
*  - This book describes what software architecture is and shows how to document it in multiple views, using UML and other notations. It also explains how to complement the architecture views with behavior, software interface, and rationale documentation. Accompanying the book is a wiki that contains an example of software architecture documentation.
* 
* 
* 
* 
*  - On the distinction between architectural design and detailed design.
* 
* 

## Lidhje të jashtme 
* Shpjegim mbi IBM Developerworks
* Koleksioni i përkufizimeve të arkitekturës së softuerit në Institutin e Inxhinierisë së Softuerit (SEI), Universiteti Carnegie Mellon (CMU)
* Shoqata Ndërkombëtare e Arkitektëve të IT (IASA Global), e njohur më parë si Shoqata Ndërkombëtare për Arkitektët e Softuerit (IASA)
* SoftwareArchitecturePortal.org – uebsajti i Grupit të Punës IFIP 2.10 mbi Arkitekturën e Softuerit
* SoftwareArchitectures.com  – një burim i pavarur informacioni mbi disiplinën
* Arkitektura e Softuerit , kapitulli 1 i disertacionit REST të Roy Fielding
* Kur arkitektura e mirë shkon keq
* Zhvillimi i drejtuar nga arkitektura spirale - SDLC i bazuar në modelin Spiral synon të zvogëlojë rreziqet e arkitekturës joefektive
* Studime të rastit të arkitekturës së softuerit të jetës reale