aceia dintre noi însărcinați cu lucrul pe teme de nivel superior, cum ar fi arhitectura și strategia întreprinderii, se tem când li se pune întrebarea simplă — „ce faci?”Când livrabilele nu au tangibilitate și claritate, răspunsurile la această întrebare îl lasă pe întrebător amețit și aproape îmi pare rău pentru respondent. Un termen comun aruncat în răspuns, ca substituent pentru incertitudine și incompletență, este arhitectura de referință.
acest termen poate însemna multe lucruri sau orice pentru oameni diferiți. Dacă este lăsat nedefinit, dă impresia de fluffiness și neclaritate care generează frustrare și deșeuri. Cei însărcinați cu implementarea vă pot pune la îndoială capacitatea de a fundamenta concepte și gândire în realitate și concretență. Prin urmare, definițiile sunt utile. Iată definiția mea pentru o arhitectură de referință:
articularea considerațiilor, opțiunilor și standardelor cunoscute pentru a ghida proiectarea unui produs, soluție sau sistem, pe baza observațiilor din sondaje, experiență și experimentare, într-un limbaj și un format vizual familiar publicului țintă.
adevărul este că, odată ce intenția, valoarea și contextul utilizării sunt clarificate pentru un anumit public, a avea o definiție formală nu contează.
adevărata întrebare este—
„ce vrem să facem?”
în al doilea rând—
„ce vrem să facă oamenii (oricine ar fi ei)?”
având răspunsuri clare la aceste întrebări sunt începutul de-fuzzing sensul și livrarea de arhitectura de referință. Intenția, conținutul, publicul și valoarea trebuie să fie clare. Cuvântul „referință” sugerează că rezultatul oferă îndrumări și standarde din observare, experiență și experimentare, spre deosebire de o definiție a ceea ce urmează să fie construit. O „arhitectură” sugerează că este structurată, coerentă și verificabilă.
există diverse definiții ale arhitecturii de referință găsite pe Internet, dar regula de claritate de mai sus (intenție, conținut, audiență, valoare) poate fi găsită în fiecare. Luați în considerare o definiție alternativă la a mea care apare ca rezultat de top într-o căutare google:
(1) clarificați mediul și formatul a ceea ce urmează să fie livrat, de exemplu, „un document”. Aceasta informează instrumentele necesare, natura muncii care trebuie efectuată și setul de competențe al contribuitorilor care trebuie implicați. Modalități Alternative de livrare ar putea fi o prezentare sau o bază de cunoștințe capabilă de interogare.
(2) sunt de acord cu privire la structura și amploarea a ceea ce urmează să fie livrat, de exemplu, „un set de documente”. Un livrabil ar putea fi insuficient, dar scara domeniului de sistem în cauză ar putea necesita ca livrabilul să fie descompus în mai multe documente.
(3) identificarea publicului principal și a părților interesate, de exemplu, „manager de proiect”. Înțelegeți tipul și formatul informațiilor pe care le consumă în mod regulat. Status-quo-ul ar putea juca, de asemenea, un rol aici. În unele cazuri, arhitectura de referință este” transmisă „liniilor de raportare ca politică, în timp ce în alte cazuri este tratată ca un” frumos de a avea”, cu speranța că descrie cea mai bună cale și alternative care trebuie luate în considerare.
(4) identificați alte părți interesate care ar putea avea nevoie să utilizeze arhitectura de referință. Este necesar să creați vizualizări sau straturi diferite? Există nevoie și spațiu pentru instruirea altora cu privire la modul de interpretare și aplicare a arhitecturii de referință?
(5) clarificați ce ar trebui să facă publicul/ cititorul cu documentul, de ex. „consultați cele mai bune practici.”Rezultatele ar trebui să ofere ceea ce spun pe copertă, inclusiv dovezile și linkurile către surse pentru validare. O arhitectură de referință ar putea oferi ,de asemenea,” învățare ” din experimentare într-o manieră coerentă și acționabilă.
(6) clarificați domeniul relevant. O arhitectură de referință fără un domeniu specific este o filozofie a principiilor directoare de nivel superior, mai degrabă decât o arhitectură. O arhitectură, chiar și o arhitectură de referință, trebuie să fie legată de domeniu. Cu cât acest domeniu este mai mic, cu atât arhitectura de referință este mai relevantă și mai acționabilă.
(7) valoarea preconizată a arhitecturii de referință trebuie comunicată, deoarece acest lucru ajută publicul să-și judece scopul și limitările, de exemplu „selectați cea mai bună metodă de livrare.”Echipele de implementare știu atunci unde să meargă atunci când trebuie luată această decizie.
(8) având exemple din domeniu și menționând tehnologiile relevante, ajută la clarificarea contextului arhitecturii de referință.
(9) alternativele și sursele componentelor și capabilităților care trebuie luate în considerare la punerea în aplicare ar trebui să fie bine documentate și corelate.
o arhitectură de referință nu este neapărat un blocant înainte de începerea unui proiect tehnologic. Acesta poate fi dezvoltat în paralel sau după livrare, servind ca documentație a unui postmortem și lecții învățate. Dacă este creat înainte de începerea unui proiect, atunci este nevoie de sondaje, încercări și experimente pentru a informa bunele practici. Mai jos este o taxonomie sugerată a posibilelor clase de arhitectură de referință, în funcție de audiență, soluție și decalajul actual de cunoștințe din cadrul unei organizații sau al unei echipe de proiect.
acronimul pentru cele cinci aspecte diferite ale unei arhitecturi de referință este muzica, care s-a dovedit a fi memorabilă în conversații la orice nivel organizațional sau domeniu de înțelegere:
- embership: listarea și clasificarea elementelor de arhitectură considerate relevante pentru domeniu.
- sage: povești de utilizator, cazuri de afaceri, procese, fluxuri de lucru și mijloace de explicare a activităților din domeniu.
- tructură: modul în care diferitele elemente dintr-un domeniu sunt interconectate pentru a sprijini utilizarea.
- nteraction( sau integrare): interfețele și mesajele schimbate între elementele arhitecturii în timpul utilizării.
- ontrols: constrângerile și politicile utilizate pentru a guverna interacțiunile.
acum, acest lucru nu sugerează că toate arhitecturile de referință trebuie să livreze 25 de documente sau subsecțiuni, acoperind fiecare dintre zonele identificate. Acest lucru ilustrează că există probabil 25 de domenii diferite în care considerațiile, opțiunile și responsabilitățile trebuie să fie articulate într-o organizație sau proiect. Acest lucru se va schimba în funcție de publicul dvs. Nu există neclaritate sau fluffiness în arhitecturile de referință. Acestea sunt rezultatul efortului exploratoriu și sunt rezultatele tangibile ale cercetării aplicate pe termen scurt.