AWS આર્કિટેક્ચરલ નિર્ણય રેકોર્ડ પ્રક્રિયા

https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html

આર્કિટેક્ચરલ નિર્ણય રેકોર્ડ (ADR) એ એક દસ્તાવેજ છે જે ટીમ જે સોફ્ટવેર આર્કિટેક્ચર બનાવવાનું આયોજન કરી રહી છે તેના કોઈ મહત્વપૂર્ણ પાસા વિશે ટીમ કરે છે તે પસંદગીનું વર્ણન કરે છે. દરેક ADR આર્કિટેક્ચરલ નિર્ણય, તેનો સંદર્ભ અને તેના પરિણામોનું વર્ણન કરે છે. ADR ની સ્થિતિઓ હોય છે અને તેથી તે જીવનચક્રને અનુસરે છે. ADR ના ઉદાહરણ માટે, પરિશિષ્ટ જુઓ.

ADR પ્રક્રિયા આર્કિટેક્ચરલ નિર્ણય રેકોર્ડનો સંગ્રહ ઉત્પન્ન કરે છે. આ સંગ્રહ નિર્ણય લોગ બનાવે છે. નિર્ણય લોગ પ્રોજેક્ટ સંદર્ભ તેમજ વિગતવાર અમલીકરણ અને ડિઝાઇન માહિતી પૂરી પાડે છે. પ્રોજેક્ટ સભ્યો પ્રોજેક્ટ સંદર્ભની ઝાંખી મેળવવા માટે દરેક ADR ની હેડલાઇન પર નજર ફેરવે છે. તેઓ પ્રોજેક્ટ અમલીકરણો અને ડિઝાઇન પસંદગીઓમાં ઊંડા ઉતરવા માટે ADR વાંચે છે.

જ્યારે ટીમ ADR સ્વીકારે છે, ત્યારે તે અપરિવર્તનશીલ બને છે. જો નવી સમજ માટે અલગ નિર્ણય જરૂરી હોય, તો ટીમ નવો ADR પ્રસ્તાવિત કરે છે. જ્યારે ટીમ નવો ADR સ્વીકારે છે, ત્યારે તે અગાઉના ADR નું સ્થાન લે છે.

ADR પ્રક્રિયાનો વ્યાપ

પ્રોજેક્ટ સભ્યોએ સોફ્ટવેર પ્રોજેક્ટ અથવા ઉત્પાદનને અસર કરતા દરેક આર્કિટેક્ચરની દૃષ્ટિએ મહત્વપૂર્ણ નિર્ણય માટે ADR બનાવવો જોઈએ, જેમાં નીચેનાનો સમાવેશ થાય છે (Richards અને Ford 2020):

• માળખું (ઉદાહરણ તરીકે, માઇક્રોસર્વિસિસ જેવી પેટર્ન)

• બિન-કાર્યાત્મક જરૂરિયાતો (સુરક્ષા, ઉચ્ચ ઉપલબ્ધતા અને ખામી સહનશીલતા)

• નિર્ભરતાઓ (ઘટકોનું જોડાણ)

• ઇન્ટરફેસ (API અને પ્રકાશિત કરારો)

• બાંધકામ તકનીકો (લાઇબ્રેરીઓ, ફ્રેમવર્ક, સાધનો અને પ્રક્રિયાઓ)

• કાર્યાત્મક અને બિન-કાર્યાત્મક જરૂરિયાતો ADR પ્રક્રિયાના સૌથી સામાન્ય ઇનપુટ છે.

ADR ની સામગ્રી

જ્યારે ટીમ ADR ની જરૂરિયાત ઓળખે છે, ત્યારે ટીમનો એક સભ્ય પ્રોજેક્ટ-વ્યાપી ટેમ્પલેટ પર આધારિત ADR લખવાનું શરૂ કરે છે. (ઉદાહરણ ટેમ્પલેટ માટે ADR GitHub સંસ્થા જુઓ.) ટેમ્પલેટ ADR નિર્માણને સરળ બનાવે છે અને ખાતરી કરે છે કે ADR બધી સંબંધિત માહિતી નોંધે છે. ઓછામાં ઓછું, દરેક ADR એ નિર્ણયનો સંદર્ભ, નિર્ણય પોતે અને પ્રોજેક્ટ અને તેના ડિલિવરેબલ્સ માટે નિર્ણયના પરિણામો વ્યાખ્યાયિત કરવા જોઈએ. (આ વિભાગોના ઉદાહરણો માટે, પરિશિષ્ટ જુઓ.) ADR માળખાનું સૌથી શક્તિશાળી પાસું એ છે કે તે નિર્ણયના કારણ પર ધ્યાન કેન્દ્રિત કરે છે, ટીમે તેનો અમલ કેવી રીતે કર્યો તેના પર નહીં. ટીમે નિર્ણય શા માટે લીધો તે સમજવાથી અન્ય ટીમ સભ્યો માટે નિર્ણય અપનાવવો સરળ બને છે, અને નિર્ણય લેવાની પ્રક્રિયામાં સામેલ ન હોય તેવા અન્ય આર્કિટેક્ટને ભવિષ્યમાં તે નિર્ણયને રદ કરતા અટકાવે છે.

ADR અપનાવવાની પ્રક્રિયા

દરેક ટીમ સભ્ય ADR બનાવી શકે છે, પરંતુ ટીમે ADR માટે માલિકીની વ્યાખ્યા સ્થાપિત કરવી જોઈએ. ADR ના માલિક એવા દરેક લેખકે ADR ની સામગ્રીને સક્રિય રીતે જાળવવી અને જણાવવી જોઈએ. આ માલિકી સ્પષ્ટ કરવા માટે, આ માર્ગદર્શિકા નીચેના વિભાગોમાં ADR લેખકોને ADR માલિકો તરીકે ઉલ્લેખે છે. અન્ય ટીમ સભ્યો હંમેશા ADR માં યોગદાન આપી શકે છે. જો ટીમ ADR સ્વીકારે તે પહેલાં તેની સામગ્રી બદલાય, તો માલિકે આ ફેરફારો મંજૂર કરવા જોઈએ.

ટીમ આર્કિટેક્ચરલ નિર્ણય અને તેના માલિકને ઓળખે પછી, ADR માલિક પ્રક્રિયાની શરૂઆતમાં ADR ને પ્રસ્તાવિત સ્થિતિમાં પૂરો પાડે છે. પ્રસ્તાવિત સ્થિતિમાંના ADR સમીક્ષા માટે તૈયાર છે.

ત્યારબાદ ADR માલિક ADR માટે સમીક્ષા પ્રક્રિયા શરૂ કરે છે. ADR સમીક્ષા પ્રક્રિયાનો ધ્યેય નક્કી કરવાનો છે કે ટીમ ADR સ્વીકારે છે, નક્કી કરે છે કે તેને ફરીથી કામની જરૂર છે, અથવા ADR ને નકારે છે. પ્રોજેક્ટ ટીમ, માલિક સહિત, ADR ની સમીક્ષા કરે છે. સમીક્ષા બેઠક ADR વાંચવા માટેના સમર્પિત સમય સાથે શરૂ થવી જોઈએ. સરેરાશ, 10 થી 15 મિનિટ પૂરતી હોવી જોઈએ. આ સમય દરમિયાન, દરેક ટીમ સભ્ય દસ્તાવેજ વાંચે છે અને અસ્પષ્ટ વિષયોને ચિહ્નિત કરવા ટિપ્પણીઓ અને પ્રશ્નો ઉમેરે છે. સમીક્ષા તબક્કા પછી, ADR માલિક દરેક ટિપ્પણી વાંચી સંભળાવે છે અને ટીમ સાથે ચર્ચા કરે છે.

જો ટીમને ADR સુધારવા માટે કાર્યવાહી બિંદુઓ મળે, તો ADR ની સ્થિતિ પ્રસ્તાવિત જ રહે છે. ADR માલિક કાર્યવાહીઓ ઘડે છે, અને ટીમના સહયોગથી, દરેક કાર્યવાહીમાં જવાબદાર વ્યક્તિ ઉમેરે છે. દરેક ટીમ સભ્ય કાર્યવાહી બિંદુઓમાં યોગદાન આપી શકે અને ઉકેલી શકે છે. સમીક્ષા પ્રક્રિયા ફરીથી ગોઠવવાની જવાબદારી ADR માલિકની છે.

ટીમ ADR ને નકારવાનું પણ નક્કી કરી શકે છે. આ કિસ્સામાં, ADR માલિક સમાન વિષય પર ભવિષ્યની ચર્ચાઓ અટકાવવા માટે નકારવાનું કારણ ઉમેરે છે. માલિક ADR ની સ્થિતિ નકારાયેલ માં બદલે છે.

જો ટીમ ADR મંજૂર કરે, તો માલિક ટાઇમસ્ટેમ્પ, સંસ્કરણ અને હિતધારકોની યાદી ઉમેરે છે. ત્યારબાદ માલિક સ્થિતિને સ્વીકૃત માં અપડેટ કરે છે.

ADR અને તેઓ બનાવે છે તે નિર્ણય લોગ ટીમે લીધેલા નિર્ણયોનું પ્રતિનિધિત્વ કરે છે અને તમામ નિર્ણયોનો ઇતિહાસ પૂરો પાડે છે. જ્યાં શક્ય હોય ત્યાં ટીમ કોડ અને આર્કિટેક્ચરલ સમીક્ષાઓ દરમિયાન ADR નો સંદર્ભ તરીકે ઉપયોગ કરે છે. કોડ સમીક્ષાઓ, ડિઝાઇન કાર્યો અને અમલીકરણ કાર્યો કરવા ઉપરાંત, ટીમ સભ્યોએ ઉત્પાદનના વ્યૂહાત્મક નિર્ણયો માટે ADR જોવા જોઈએ.

સારી પ્રથા તરીકે, દરેક સોફ્ટવેર ફેરફાર સાથીદાર સમીક્ષાઓમાંથી પસાર થવો જોઈએ અને ઓછામાં ઓછી એક મંજૂરીની જરૂર હોવી જોઈએ. કોડ સમીક્ષા દરમિયાન, કોડ સમીક્ષકને એવા ફેરફારો મળી શકે જે એક કે વધુ ADR નું ઉલ્લંઘન કરે. આ કિસ્સામાં, સમીક્ષક કોડ ફેરફારના લેખકને કોડ અપડેટ કરવા કહે છે, અને ADR ની લિંક વહેંચે છે. જ્યારે લેખક કોડ અપડેટ કરે છે, ત્યારે સાથીદાર સમીક્ષકો તેને મંજૂર કરે છે અને તે મુખ્ય કોડ બેઝમાં મર્જ થાય છે.

ADR સમીક્ષા પ્રક્રિયા

ટીમે ADR ને સ્વીકાર્યા અથવા નકાર્યા પછી તેમને અપરિવર્તનશીલ દસ્તાવેજો તરીકે ગણવા જોઈએ. હાલના ADR માં ફેરફારો માટે નવો ADR બનાવવો, નવા ADR માટે સમીક્ષા પ્રક્રિયા સ્થાપિત કરવી અને ADR ને મંજૂર કરવો જરૂરી છે. જો ટીમ નવા ADR ને મંજૂર કરે, તો માલિકે જૂના ADR ની સ્થિતિ બદલાયેલ માં બદલવી જોઈએ.