Architecture Decision Record

Arkitektura-erabakien erregistroa (ADR)

Arkitektura-erabakiak erregistratzeko txantiloiak, adibideak eta gidak.

Arkitektura-erabakien erregistroa (ADR) hartutako arkitektura-erabaki garrantzitsu bat bere testuinguru eta ondorioekin batera jasotzen duen dokumentua da.

Itzulpenak: العربية, বাংলা, Cymraeg, Dansk, Deutsch, English, Lietuvių, Gaeilge, Lëtzebuergesch, मराठी, Hausa, ગુજરાતી, Euskara, भोजपुरी, Basa Jawa, فارسی, ਪੰਜਾਬੀ, Malti, Latviešu, Slovenščina, Slovenčina, Hrvatski, Български, Čeština, Magyar, Ελληνικά, Română, Polski, Español, Eesti, Suomi, Français, हिन्दी, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Nederlands, Português, Русский, Svenska, Kiswahili, ไทย, Türkçe, اردو, Tiếng Việt, 中文

Egin zeure ikerketa zorrotza baliabide hauekin, sistema kritikoetan erabili aurretik.

Edukia:

Txantiloiak:

Adibideak:

Zer da arkitektura-erabakien erregistroa?

Arkitektura-erabakien erregistroa (ADR) hartutako arkitektura-erabaki garrantzitsu bat bere testuinguru eta ondorioekin batera jasotzen duen dokumentua da.

Arkitektura-erabakia (AD) eskakizun esanguratsu bati erantzuten dion softwarearen diseinu-aukera bat da.

Arkitektura-erabakien egunkaria (ADL) proiektu jakin baterako (edo erakunde baterako) sortu eta mantentzen diren ADR guztien bilduma da.

Arkitekturaren ikuspegitik esanguratsua den eskakizuna (ASR) software-sistema baten arkitekturan eragin neurgarria duen eskakizuna da.

Hori guztia arkitektura-ezagutzaren kudeaketa (AKM) gaiaren barruan sartzen da.

Dokumentu honen helburua ADR-en ikuspegi azkar bat ematea da: nola sortzen diren eta non bilatu informazio gehiago.

Laburdurak:

  • AD: arkitektura-erabakia

  • ADL: arkitektura-erabakien egunkaria

  • ADR: arkitektura-erabakien erregistroa

  • AKM: arkitektura-ezagutzaren kudeaketa

  • ASR: arkitekturaren ikuspegitik esanguratsua den eskakizuna

ADR-ak erabiltzen hasteko modua

ADR-ak erabiltzen hasteko, hitz egin zure taldekideekin arlo hauei buruz.

Erabakien identifikazioa:

  • Zein premiazkoa eta zein garrantzitsua da AD?

  • Orain hartu behar al da, ala itxaron daiteke gehiago jakin arte?

  • Bai esperientzia pertsonalak eta kolektiboak, bai diseinu-metodo eta praktika aitortuek erabakiak identifikatzen lagun dezakete.

  • Egokiena erabaki-zeregin zerrenda bat mantentzea da, produktuaren zeregin zerrendaren osagarri gisa.

Erabakiak hartzea:

  • Erabakiak hartzeko hainbat teknika daude, orokorrak zein software-arkitekturari espezifikoak, esaterako elkarrizketa-mapak egitea.

  • Taldeko erabakiak hartzea ikerketa-gai aktiboa da.

Erabakiak ezartzea eta betearaztea:

  • AD-ak software-diseinuan erabiltzen dira; beraz, sistemaren interesdunei jakinarazi eta haiek onartu behar dituzte, sistema finantzatzen, garatzen eta erabiltzen dutenek.

  • Arkitekturaren aldetik agerikoak diren kodeketa-estiloak eta arkitektura-kezka eta -erabakietan zentratzen diren kode-berrikuspenak lotutako bi praktika dira.

  • AD-ak (berriz) aztertu behar dira software-sistema bat modernizatzean, software-bilakaeran.

Erabakiak partekatzea (aukerakoa):

  • AD asko errepikatzen dira proiektuetan.

  • Beraz, iraganeko erabakiei buruzko esperientziak, onak zein txarrak, aktibo berrerabilgarri baliotsuak izan daitezke, ezagutza-kudeaketako estrategia esplizitu bat erabiltzen denean.

Erabakien dokumentazioa:

  • Erabakiak jasotzeko txantiloi eta tresna asko daude.

  • Ikus komunitate arinak, adibidez M. Nygarden ADR-ak.

  • Ikus software-ingeniaritza eta arkitektura-diseinuko prozesu tradizionalak, adibidez IBM UMF-k eta CapitalOne-ko Tyree eta Akermanek iradokitako taula-diseinuak.

Informazio gehiagorako:

ADR-ak tresnekin erabiltzen hasteko modua

  • MySpec — Proiektuaren konstituzioa, arkitektura teknikoa eta ADR-ak Markdown garbian egituratzen dituen eta MCP bidez eskaintzen duen espezifikazio- eta arkitektura-erabaki automatizatuen plataforma.

ADR-ak tresnekin nahi duzun moduan has zaitezke erabiltzen.

Adibidez:

  • Google Drive eta lineako edizioa erabiltzea gustatzen bazaizu, Google Doc bat edo Google Sheet bat sor dezakezu.

  • Iturburu-kodearen bertsio-kontrola, adibidez git, erabiltzea gustatzen bazaizu, fitxategi bat sor dezakezu ADR bakoitzeko.

  • Proiektuak planifikatzeko tresnak, adibidez Atlassian Jira, erabiltzea gustatzen bazaizu, tresnaren plangintza-jarraipena erabil dezakezu.

  • Wikiak, adibidez MediaWiki, erabiltzea gustatzen bazaizu, ADR wiki bat sor dezakezu.

ADR-ak gitekin erabiltzen hasteko modua

git bertsio-kontrola erabiltzea gustatzen bazaizu, hona hemen iturburu-kodea duen software-proiektu tipiko baterako ADR-ak gitekin erabiltzen hasteko dugun modua.

Sortu direktorio bat ADR fitxategientzat:

$ mkdir adr

ADR bakoitzeko, sortu testu-fitxategi bat, adibidez choose-database.md:

$ vi choose-database.md

Idatzi nahi duzun guztia ADR-an. Ikus biltegi honetako txantiloiak ideien bila.

Egin commit ADR-a zure git biltegian.

ADR-etarako Claude Code skill-ak

Biltegi honek bi Claude Code skill eskaintzen ditu skills/ direktorioan, AA kodeketa-agente batek proiektu honek gomendatzen duen moduan ADR-ak idatzi eta mantendu ditzan:

  • architecture-decision-record-skill — helburu orokorrekoa, edozein proiektutan ADR bat idazten duen edonorentzat. Erabaki batek ADR bat behar duen erabakitzen laguntzen du, adr/ edo decisions/ direktorio bat prestatzen du, fitxategiaren izena ematen du, barne dauden hamaika eskeletoen artean txantiloi bat hautatzen du, eta Testuinguru/Erabakia/Ondorioak atal sendoak idazten ditu.

  • architecture-decision-record-maintainer-skill — biltegi honen mantentzaileentzat bereziki. Biltegiaren antolaketa, README/locales ispilatze-konbentzioa eta txantiloi, adibide edo tresna-esteka berri bat gehitzeko urrats zehatzak dokumentatzen ditu.

Skill bat erabiltzeko, kopiatu bere karpeta lanean ari zaren biltegiaren erroko .claude/skills/ direktorioan (edo ~/.claude/skills/ direktorioan proiektu guztietan eskuragarri egon dadin), eta eskatu Claude Code-ri ADR bat idazteko edo berrikusteko.

ADR-etarako fitxategi-izenen konbentzioak

ADR-ak testu-fitxategi tipikoetan sortzea aukeratzen baduzu, baliteke zure ADR fitxategi-izenen konbentzio propioa asmatu nahi izatea.

Formatu zehatza duen fitxategi-izenen konbentzioa erabiltzea nahiago dugu.

Adibideak:

  • choose-database.md

  • format-timestamps.md

  • manage-passwords.md

  • handle-exceptions.md

Gure fitxategi-izenen konbentzioa:

  • Izenak orainaldiko aditz-esapide inperatibo bat dauka. Horrek irakurgarritasuna errazten du eta gure commit-mezuen formatuarekin bat dator.

  • Izenak letra xehea eta gidoiak erabiltzen ditu (biltegi honen berdin). Irakurgarritasunaren eta sistemaren erabilgarritasunaren arteko oreka da.

  • Luzapena markdown da. Hori baliagarria izan daiteke formatua errazteko.

ADR onak idazteko iradokizunak

ADR on baten ezaugarriak:

  • Arrazoibidea: Azaldu zergatik hartu den AD jakin hori. Horrek testuingurua (ikus behean), aukera potentzial desberdinen alde onak eta txarrak, ezaugarrien alderaketak, kostu/onura eztabaidak eta gehiago izan ditzake.

  • Espezifikoa: ADR bakoitzak AD bati buruzkoa izan behar du, ez hainbati.

  • Denbora-zigiluak: Identifikatu ADR-ko elementu bakoitza noiz idatzi den. Hori bereziki garrantzitsua da denboran alda daitezkeen alderdietan, hala nola kostuetan, egutegietan, eskalatzean eta antzekoetan.

  • Aldaezina: Ez aldatu ADR batean lehendik dagoen informazioa. Horren ordez, zuzendu ADR-a informazio berria gehituz, edo ordeztu ADR-a beste ADR berri bat sortuz.

ADR bateko "Testuinguru" atal on baten ezaugarriak:

  • Azaldu zure erakundearen egoera eta negozio-lehentasunak.

  • Sartu zure taldeen osaera sozialean eta trebetasunetan oinarritutako arrazoibideak eta kontuan hartzekoak.

  • Sartu garrantzitsuak diren alde onak eta txarrak, eta deskribatu zure behar eta helburuekin bat datozen terminoetan.

ADR bateko "Ondorioak" atal on baten ezaugarriak:

  • Azaldu erabakia hartzearen ondoren zer gertatzen den. Horrek ondorioak, emaitzak, irteerak, jarraipenak eta gehiago izan ditzake.

  • Sartu ondorengo ADR-ei buruzko informazioa. Nahiko ohikoa da ADR batek ADR gehiagoren beharra eragitea, adibidez ADR batek aukera orokor handi bat egiten duenean eta horrek, aldi berean, erabaki txiki gehiagoren beharra sortzen duenean.

  • Sartu ekintzaren osteko berrikuspen-prozesuak. Taldeek ADR bakoitza hilabete beranduago berrikustea ohikoa da, ADR-ko informazioa praktikan gertatutakoarekin alderatzeko, ikasi eta hazteko.

ADR berri batek aurreko ADR baten lekua har dezake:

  • Aurreko ADR bat ordezkatzen edo baliogabetzen duen AD bat hartzen denean, ADR berri bat sortu behar da

ADR adibide-txantiloiak

Sarean bildu ditugun ADR adibide-txantiloiak:

ADR-etarako talde-lanerako aholkuak

Zure taldearekin erabaki-erregistroak erabiltzea pentsatzen ari bazara, hona hemen talde askorekin lan eginez ikasi ditugun aholku batzuk.

Zure taldekideak gidatzeko aukera duzu, "zer" derrigortu beharrean "zergatik"-ari buruz elkarrekin hitz eginez. Adibidez, erabaki-erregistroak taldeek adimentsuago pentsatzeko eta hobeto komunikatzeko modu bat dira; erabaki-erregistroek ez dute baliorik gertatu ondoren behartutako paperezko eskakizun bat baino ez badira.

Talde batzuek "erabakiak" izena nahiago dute "ADR-ak" laburdura baino. Talde batzuek "decisions" direktorio-izena erabiltzen dutenean, bonbilla piztu izan balitz bezala da, eta taldeak informazio gehiago sartzen hasten da direktorioan, esaterako hornitzaileen erabakiak, plangintza-erabakiak, programazio-erabakiak eta abar. Informazio mota horiek guztiek txantiloi bera erabil dezakete. Hipotesi gisa, jendeak azkarrago ikasten du hitzekin ("erabakiak") laburdurekin ("ADR-ak") baino, jendea gehiago motibatzen da lanean dauden dokumentuak idazteko "erregistro" hitza kentzen denean, eta, gainera, garatzaile eta kudeatzaile batzuek ez dute gustuko "arkitektura" hitza.

Teorian, aldaezintasuna ideala da. Praktikan, aldakortasunak hobeto funtzionatu du gure taldeentzat. Informazio berria lehendik dagoen ADR-an sartzen dugu, data-zigiluarekin eta informazioa erabakiaren ondoren iritsi zela dioen ohar batekin. Ikuspegi horrek guztiok eguneratu dezakegun "dokumentu bizia" sortzen du. Eguneraketa tipikoak gertatzen dira taldekide berrien, eskaintza berrien edo gure erabileren mundu errealeko emaitzen bidez informazioa jasotzen dugunean, edo hirugarrenen aldaketa geroztikoen ondorioz, esaterako hornitzaileen gaitasunak, prezio-planak, lizentzia-hitzarmenak eta abar.

ADR-etarako talde-lanerako galderak

Nork sor dezake ADR bat?

Pentsatu arlo hauetan: pertsona jakinak, rol jakinak, talde jakinak edo sail jakinak; pentsatu, halaber, ea ADR bat enkarga dezaketen pertsonarik, rolik, talderik edo sailik dagoen, hau da, beste norbaitek idatziko duen ADR bat eskatzea.

Adibide-erantzuna: Gure erakundeko edozein pertsonak, arkitektura-erabakien erregistroaren README orria irakurri badu, ADR bat proposa dezake, hau da, hura idazten hasi eta taldearekin parteka dezake.

Zerk justifikatzen du ADR bat sortzea?

Pentsatu arlo hauetan: zure erakundearen taldeen lan-moduak, zure software-sistemaren egitura, taldeen arteko koordinazioa, epe luzeko mantentzeko gaitasuna, kanpoko interfazeak, nork atera nahi duzun onura, eta antzekoak.

Adibide-erantzuna: ADR bat sortu nahi dugu etorkizuneko garatzaileek egiten ari garenaren "zergatia" ulertzea nahi dugunean.

Zerk justifikatzen du ADR bat ez sortzea?

Pentsatu arlo hauetan: arkitekturari buruzkoak ez diren erabakiak, edo txikiak direnak, hala nola arrisku minimokoak, bere kabuz osoak edo garatzaile bakarrekoak, edo beste nonbait guztiz estalita daudenak, adibidez estandarretan, politiketan edo dokumentazioan, edo behinekoak direnak, hala nola konponbide probisionalak, kontzeptu-frogak edo esperimentuak.

Adibide-erantzuna: ADR bat saltatu nahi dugu erabaki bat irismenean, denboran, arriskuan eta kostuan mugatua denean, edo beste nonbait estalita dagoenean.

Zein da ADR baten bizi-zikloa?

Pentsatu arlo hauetan: sortze-prozesua, ikerketa-prozesua, erabakitze-prozesua, ezartze-prozesua eta erretiratze-prozesua. Pentsatu nola jarraitu ADR baten bizi-zikloari denboran zehar, adibidez nola eraman ADR bat egoera batetik hurrengora, eta nola jakinarazi hori interesdunei.

Adibide-erantzuna: ADR batek bost bizi-ziklo fase izatea nahi dugu: Hastea → Ikertzea → Ebaluatzea → Ezartzea → Mantentzea → Erretiratzea.

Zein dira ADR baten bizi-zikloko urratsen irizpideak?

Pentsatu arlo hauetan: ADR baten onarpen-irizpideak, hau da, nola jakin bizi-zikloko urrats batetik hurrengora aurrera egiteko adina ona den? Arazoa argi azaldu al da? Alternatibak aztertu al dira? Konpentsazioak ondo ulertu eta dokumentatu al dira? Testuinguru garrantzitsu guztia dago? Interesdun garrantzitsu guztiak sartu al dira? Iritzi guztiak jaso al dira?

Adibide-erantzuna: ADR bat interesdunek bozka dezaten nahi dugu talde aktiboak 1) ikerketa amaitu duenean, 2) ebaluazioa amaitu duenean, 3) ADR proposamena interesdunei argitaratu dienean iruzkinak eskatuz eta astebeteko epearekin, 4) interesdun guztien iruzkinak sartu eta erantzun direnean.

Zein rol eta erantzukizunek elkarreragiten dute ADR batekin?

Pentsatu rol hauetan: proposatzailea, ikertzailea, ebaluatzailea, berrikuslea, onartzailea, mantentzailea eta antzekoak. Pentsatu erantzukizun hauetan: interesdunekin komunikatzea, itxaropenak betetzen direla ziurtatzea, webgunean edo intranetean partekatzea, eta lana aldian-aldian berrikustea, bereziki aldaketa garrantzitsuak gertatzen direnean.

Adibide-erantzuna: ADR bakoitzak beti kontaktu-pertsona nagusi bat, bigarren kontaktu-pertsona bat eta erantzukizuneko talde bat izatea nahi dugu; horiek arduratzen dira komunikazioez, argitalpenez, mantentzeaz, urtean behin gutxienez egiten den aldizkako berrikuspenaz eta, behar denean, azkenean erretiratzeaz.

Nola elkarreragiten du gobernantzak ADR batekin?

Pentsatu arlo hauetan: zure erakundearen lan-moduak, adostasuna, gatazka eta eskalatzea nola kudeatu nahi duzun, eta betetze-behar bereziak, adibidez alderdi juridikoei edo giza baliabideei dagozkienak. Badago ADR bati dagokionez besteek baino eragin handiagoa izan dezaketen arlorik, pertsonarik edo talderik, hala nola onartzeko, bozkatzeko edo betoa jartzeko gai direnak?

Adibide-erantzuna: ADR baten gobernantza lehentasun-ordena honetan dago: CEO, CTO, CLO, ADR bat ezartzen duen taldea, taldeko AD-ari buruz ezagutza gehien duten adituak. Beste inork ez du gobernantzarik ADR-an deskribatzen ez bada.

Zein printzipiok elkarreragiten dute ADR batekin?

Pentsatu arlo hauetan: zure erakundearen lan-moduak, azkar mugitzea vs. astiro mugitzea, erabaki-adostasuna vs. erabaki-gatazka, arrisku-lehentasunak vs. segurtasun-lehentasunak, eztabaida publikoa vs. eztabaida pribatua, eta antzekoak.

Adibide-erantzuna: Lidergo-printzipio hauek erabiltzen ditugu: ekintzarako joera, desadostasuna agertu eta konpromisoa hartzea, %70eko estimazioak nahikoak dira erraz atzera egin daitezkeen eta erraz isola daitezkeen erabakietarako, eta lan-modu publikoak, gure erakundearen konfidentzialtasun-hitzarmenean deskribatutako informazio konfidentzialaren salbuespenarekin.

ADR-etarako hurrengo urratsaren kontzeptuak

Arc42-k bi galdera erantzuten ditu modu pragmatikoan eta zure behar espezifikoetara egokitu daiteke. Zer dokumentatu/komunikatu beharko zenuke zure arkitekturari buruz? Nola dokumentatu/komunikatu beharko zenuke? Arc42-k arkitektura-erabakien erregistroak eta helburuei, murriztapenei, testuinguruei, kalitateari, arriskuei eta gehiagori buruzko orientazioa barne hartzen ditu.

C4 eredua software-arkitekturaren diagramak egiteko ikasteko erraza eta garatzaile-lagunkoia den ikuspegia da. C4 testuinguru, ontzi, osagai eta kodearen diagrama hierarkikoen multzoa da, sistemaren paisaiarako, dinamikoetarako eta hedapenerako diagrama osagarriekin.

Arkitektura-diagramak, ikuspegiak eta ikuspuntuak

Arkitektura-diagrama bati "arkitektura-ikuspegi" deitzen zaio.

"Arkitektura-ikuspegi" bat "arkitektura-ikuspuntu" baten instantzia da.

"Arkitektura-ikuspuntu" batek kezka zehatzak kontuan dituen audientzia zehatz bat du.

Arkitektura-ikuspuntuen adibideak, ikuspegien adibideak eta diagramen adibideak:

Lotutako diagramak:

  • Erabilera-kasuen diagramak (Use Case Diagram) erabilera-kasuak erakusten dizkie kudeaketari/bezeroei, eskakizunen aurretik datozenak, software-arkitekturaren aurretik datozenak.

  • Hedapen-diagramak (Deployment Diagram) software-osagaiak hedatzen diren hardware/ordenagailu fisikoak erakusten ditu.

  • Datu-fluxuaren diagramak (Data Flow Diagram) datuak sistematik nola mugitzen eta eraldatzen diren erakusten du.

  • Sekuentzia-diagramak (Sequence Diagram) HTTP bezalako protokoloek denbora-ardatzean nola funtzionatzen duten erakusteko erabiltzen da.

  • Jarduera-diagramak (Activity Diagram) software-sistema batek egiten duen jardueren lan-fluxua irudikatzen du, NPC AA bezala.

Erabakietarako fitness funtzioak kode gisa

Fitness funtzioak programazio-kodez idatzitako egiaztapen automatizatu objektiboak dira, erabakiak mantentzen ari direla egiaztatzen dutenak.

  • Fitness funtzioek erabakiak probagarri eta bermagarri egiten dituzte.

  • Erabakietarako fitness funtzioek asko lagun dezakete kalitatearen bermean, arau-prozesuetan eta gobernantza-helburuetan.

Nola lotzen diren fitness funtzioak erabakiekin

Erabaki-erregistro batek erabakia dokumentatzen du, eta fitness funtzio batek erabakia ziurtatzen du.

  • Adibide-erabakia: Gertaeren iturburu-bilketa (event sourcing) erabiltzen dugu ikuskaritza-eskakizunetarako.

  • Adibide-fitness funtzioa: Etengabeko integrazioko zerbitzaria erabiltzen dugu egoera-aldaketa guztiek gertaerak sortu behar dituztela probatzeko.

Zergatik laguntzen dute fitness funtzioek erabakietan

Neurketa objektiboak: Fitness funtzioek gainditu edo huts egiten dute, beraz lana ikusgai eta argia da.

Etengabeko erabilera: Fitness funtzioak zure arau bizidunak dira, commit eta build bakoitzean exekutatzen direnak.

Berregituratzeko konfiantza: Fitness funtzioek erabaki-arauen erroreak automatikoki harrapatzen dituzte.

Eskalagarria den gobernantza: Fitness funtzioek estandarrak ziurtatzen dituzte oztoporik sortu gabe.

Fitness funtzioek AA erabil dezakete?

Fitness funtzioek AA LLM-en abantaila har dezakete erabakietarako, zure lanari buruzko galderak eginez, esaterako zure planei, kodeari, eskemei, API-ei eta gehiagori buruz:

IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning.
IMPORTANT: Turn on extended thinking. Turn on expert advice. Turn on search.

This is a fitness function to evaluate if our work is
using all our decisions, and is correct and accurate.

- Our decisions are here: {url}
- Our work to evaluate is here: {url}

Explain any errors, problems, gaps, weaknesses. Be direct. Be decisive.

Arkitektura-unitate probak

ArchUnit: egiaztatu Java kodearen arkitektura-arauak edozein Java unitate-proba esparru arrunt erabiliz.

ArchUnitTS: egiaztatu TypeScript eta JavaScript kodearen arkitektura-arauak Jest, Vitest, Jasmine eta abar erabiliz.

Pull request-etarako erabaki-babesak

Decision Guardian-ek erabaki-erregistro egokiak une egokian azaleratzen ditu automatikoki — garatzaile bat erabaki horiek estaltzen dituen kodea aldatzen ari denean. Garatzaileek batu aurretik dokumentu-karpeta bat irakurriko dutelakoan egon beharrean, testuinguru garrantzitsua zuzenean pull request-ean agertzen da.

Erabaki-erregistro mota guztietarako funtzionatzen du: arkitektura-erabakiak, datu-erabakiak, betetze-erabakiak, erabaki kliniko eta medikoak, segurtasun-erabakiak eta gehiago.

Edozein CI sistemarekin (GitLab, Jenkins, CircleCI) eta pre-commit hook gisa funtzionatzen du. Kode irekia. MIT lizentzia.

ADR Guard GitHub Action bat da, zaintzapeko kode-bideak aldatzen direnean arkitektura-erabakien erregistro bat gehitu edo eguneratu gabe pull request-ak huts egiten dituena. Salbuespenak esplizituak dira: arrazoi batekin ADR-Exempt: lerro batek atea gainditzen du eta lanaren laburpenean idazten da. Txantiloiarekiko neutroa, mendekotasunik gabe. Kode irekia. MIT lizentzia.

Informazio gehiagorako

Sarrera:

Txantiloiak:

Sakonean:

Tresnak:

Enpresa-espezifikoko orientazioa:

Adibideak:

Bideoak:

Podcastak:

Liburuak:

Ikus gainera:

  • REMAP (Representation and Maintenance of Process Knowledge)

  • DRL (Decision Representation Language)

  • IBIS (Issue-Based Information System)

  • QOC (Questions, Options, and Criteria)

  • IBM’s e-Business Reference Architecture Framework

  • Decision Reasoning Format (DRF) - Erabakiak arrazoibide esplizituarekin, hipotesiekin, egoera kognitiboarekin eta konpentsazioekin irudikatzeko hornitzailearekiko neutroa den makinak irakur dezakeen YAML/JSON formatua. ADR-ak osatzen ditu erabakien dokumentazioari arrazoibide egituratua eta baliozkotu daitekeena gehituz.