înțelegerea valorii arhitecturilor de referință
arhitecților nu le place să facă nimic mai mult decât să argumenteze despre definiții. Dacă vă aflați vreodată cu timpul inactiv într-o cameră de arhitecți, încercați să cereți o definiție a „Serviciului” sau „arhitecturii” și să vedeți ce fel de corp la corp creativ puteți începe. Acestea fiind spuse, definițiile sunt într-adevăr foarte importante, astfel încât să putem avea un limbaj comun pentru a comunica intenția și beneficiul lucrurilor în care încercăm să convingem afacerile să investească. Din această perspectivă, o serie de concepte au apărut în ultimul deceniu sau cam asa ceva care au devenit de top de spirit pentru arhitecți de întreprindere auto-stil: cadre de arhitectură și arhitecturi de referință. În Zapflash-urile anterioare, am discutat despre cadrele de arhitectură, care lasă subiectul arhitecturilor de referință lăsate neatinse de ZapThink. Deoarece nu putem lăsa un argument bun în urmă, vom folosi acest ZapFlash pentru a explora ce arhitecturi de referință sunt toate și ce valoare trebuie să adauge la povestea arhitecturii orientate spre servicii (SOA).
ce este o arhitectură de referință?
o definiție acceptată în mod obișnuit pentru arhitectura de referință este că oferă o metodologie și/sau un set de practici și șabloane care se bazează pe generalizarea unui set de soluții de succes pentru o anumită categorie de soluții. Arhitecturile de referință oferă îndrumări cu privire la modul de aplicare a modelelor și/sau practicilor specifice pentru a rezolva anumite clase de probleme. În acest fel, servește drept „referință” pentru arhitecturile specifice pe care companiile le vor implementa pentru a-și rezolva propriile probleme. Nu se intenționează niciodată ca o arhitectură de referință să fie implementată așa cum este, ci mai degrabă utilizată fie ca punct de comparație, fie ca punct de plecare pentru eforturile arhitecturale ale companiilor individuale.
alții rafinează definiția arhitecturii de referință ca o descriere a modului de construire a unei clase de artefacte. Aceste artefacte pot fi încorporate în mai multe forme, inclusiv modele de proiectare, metodologii, standarde, metadate și documente de tot felul. Pe scurt, dacă aveți nevoie de îndrumări cu privire la modul de a dezvolta o arhitectură specifică bazată pe cele mai bune practici sau seturi autoritare de artefacte potențiale, ar trebui să vă uitați la o arhitectură de referință care acoperă domeniul arhitecturii pe care doriți să o construiți.
unul dintre cele mai populare exemple de arhitecturi de referință din IT este arhitectura Java Platform Enterprise Edition (Java EE), care oferă o arhitectură de referință stratificată și șabloane care abordează o serie de probleme tehnologice și de afaceri care au ghidat multe sisteme de întreprindere bazate pe Java.
arhitecturi de referință vs.cadre de arhitectură
în timp ce definiția(definițiile) de mai sus pot părea destul de tăiate și uscate, există multe în comun între conceptele de arhitecturi de referință și cadrele de arhitectură. Pentru unii, acest lucru este în cazul în care lucrurile devin dicey și definiții obține neclare. Cadrele de arhitectură, cum ar fi Zachman Framework, Open Group Architecture Framework (TOGAF) și Department Of Defense Architecture Framework (DoDAF) oferă abordări pentru a descrie și identifica intrările necesare pentru o anumită arhitectură, precum și mijloace pentru a descrie acea arhitectură. Dacă o anumită arhitectură este o carte de bucate care oferă îndrumări despre cum să rezolvați un anumit set de probleme cu o anumită abordare, un cadru de arhitectură este o carte despre cum să scrieți cărți de bucate. Deci, cadrele de arhitectură oferă arhitecților de întreprindere instrumentele de care au nevoie pentru a descrie și colecta în mod adecvat cerințele, fără a impune niciun tip de arhitectură specific. Mai precis, cadrele de arhitectură descriu un exemplu de taxonomie a tipurilor de „puncte de vedere” arhitecturale pe care un arhitect le-ar putea lua în considerare și de ce și oferă linii directoare pentru a face alegerea pentru dezvoltarea anumitor puncte de vedere.
aceasta diferă de conceptul de mai sus al unei arhitecturi de referință prin faptul că o arhitectură de referință merge cu un pas mai departe prin accelerarea procesului pentru un anumit tip de arhitectură, ajutând la identificarea abordărilor arhitecturale care vor satisface cerințele particulare și imaginând ce set minim acceptabil de artefacte arhitecturale sunt necesare pentru a îndeplini cerințele „celor mai bune practici” pentru o anumită arhitectură. Pentru a continua analogia noastră cu cărțile de bucate, dacă un cadru de arhitectură este o carte despre cum să scrieți cărți de bucate, atunci o arhitectură de referință este o carte care oferă îndrumări și cele mai bune practici despre cum să scrieți cărți de bucate axate pe pierderea în greutate, de exemplu. Acest lucru ar însemna că arhitectura specifică pe care o dezvoltați pentru organizația dvs. ar fi o carte de bucate specifică care oferă rețete de pierdere în greutate direcționate către organizația dvs. Într-adevăr, dacă vă încurcați cu definițiile, înlocuirea termenului „arhitectură” cu „carte de bucate” este utilă: cadre carte de bucate, cărți de bucate de referință, și carte de bucate special.
mai mult, majoritatea arhitecturilor de referință subliniază partea „șablon” a definiției unei arhitecturi de referință. Atât cadrele, cât și RAs oferă cele mai bune practici și, deși s-ar putea argumenta că RAs oferă mai mult o metodologie decât un cadru, RAs nu sunt încă caracterizate cu adevărat de componenta lor metodologică. Cele mai multe pot fi caracterizate prin componenta lor șablon, cu toate acestea. Din această perspectivă, modelele sunt exemple de șabloane în acest context. De fapt, mai multe arhitecturi de referință pentru același domeniu sunt permise și destul de utile. Arhitecturile de referință pot fi complementare oferind îndrumări pentru o singură arhitectură, cum ar fi SOA, din mai multe puncte de vedere.
valoarea unei arhitecturi de referință SOA
în multe privințe, proiectele SOA au nevoie disperată de arhitecturi de referință bine gândite. ZapThink vede un grad ridicat de variabilitate în proiectele SOA. Unii înfloresc și reușesc, în timp ce alții se zbat și eșuează. De multe ori motivul eșecului poate fi urmărit de practici arhitecturale proaste, achiziții premature de infrastructură și guvernanță și management inadecvat. Alteori eșecul este în primul rând organizațional. Cu toate acestea, ceea ce este comun în majoritatea succeselor este practicile arhitecturale bine documentate și/sau comunicate și o metodă sistematică de a învăța din greșelile cuiva și de a avea un cost redus de eșec.
mai mult, descoperim că mulți arhitecți își petrec o cantitate semnificativă din timpul lor cercetând, investigând, (re)definind, contemplând și argumentând deciziile arhitecturale. În multe cazuri, acești arhitecți reinventează roata, deoarece colegii lor din alte companii sau chiar din aceeași companie au petrecut deja acel timp și efort definindu-și propriile practici arhitecturale. Acest efort suplimentar nu este doar ineficient, ci împiedică compania să învețe din propriile experiențe și să aplice aceste cunoștințe pentru o eficiență sporită.
din această perspectivă, arhitecturile de referință SOA pot oferi un ajutor celor care se luptă cu eforturile lor SOA sau se gândesc să lanseze unul nou. Arhitecturile de referință SOA permit organizațiilor să învețe din succesele și eșecurile altor arhitecți și să moștenească cele mai bune practici dovedite. Arhitecturile de referință pot furniza informații arhitecturale lipsă care pot fi furnizate în avans membrilor echipei de proiect pentru a permite cele mai bune practici arhitecturale consecvente. În acest fel, arhitectura de referință SOA oferă o bază de active pe care eforturile SOA le pot trage de-a lungul ciclului de viață al proiectului.
într-adevăr, pentru a obține beneficiile SOA promise de reutilizare, redundanță redusă, costuri reduse de integrare și vizibilitate și guvernare sporite, companiile trebuie să își aplice eforturile SOA într-o manieră consecventă. Acest lucru înseamnă mai mult decât cumpărarea și stabilirea infrastructurii unui furnizor ca standard corporativ sau aderarea la cele mai recente stive de standarde WS -*. Arhitecturile de referință SOA pot servi drept bază pentru eforturile SOA disparate în întreaga organizație, chiar dacă utilizează diferite instrumente și tehnologii. Arhitecturile de referință SOA bune oferă cele mai bune practici și abordări SOA într-un mod independent de furnizor, tehnologie și standarde. Prin urmare, nu mergeți la vânătoare pentru unul de la furnizorul preferat de alegere. De fapt, dacă ați obținut arhitectura de referință SOA de la acel furnizor, ați putea dori să luați în considerare renunțarea la aceasta în locul a ceva mai neutru pentru furnizori.
în special, OASIS oferă o arhitectură de referință SOA (RA) care „modelează elementele arhitecturale abstracte pentru un SOA independent de tehnologiile, protocoalele și produsele care sunt utilizate pentru implementarea unui SOA. Unele secțiuni ale RA vor folosi elemente abstracte comune derivate din mai multe standarde.”Abordarea lor folosește conceptul de” modele ” pentru a identifica diferite metode și abordări pentru implementarea diferitelor părți ale imaginii arhitecturale. În timp ce arhitectura de referință OASIS SOA nu este cu siguranță singura valabilă din bloc, cu siguranță reprezintă un bun punct de plecare pentru cei care caută o arhitectură de referință SOA neutră din punct de vedere al furnizorului pe care să își bazeze propriile eforturi arhitecturale.
ZapThink Take
Enterprise architects are nevoie de tot ajutorul pe care îl pot obține pentru a se asigura că livrează arhitecturi fiabile, agile, rezistente, neutre din punct de vedere al furnizorilor organizației lor, care îndeplinesc cerințele în continuă schimbare ale afacerii. În timp ce cu siguranță arta și practica arhitecturii întreprinderii continuă să se maturizeze, companiile ar trebui să caute să împrumute cât mai multe bune practici și să învețe de la alții care au trecut deja pe calea EA și SOA. Dacă aveți de gând să învețe SOA, sau orice formă de EA pentru care contează, ca te duci de-a lungul, sau chiar mai rău, de la un furnizor, atunci riscați întregul succes al eforturilor SOA. Mai degrabă, folosiți arhitecturi de referință SOA (gratuit), astfel încât să puteți avansa într-un ritm mai rapid și un risc mai mic. Bernard de Chartres a spus-o cel mai bine în binecunoscuta zicală: „suntem ca niște pitici pe umerii giganților, astfel încât să putem vedea mai mult decât ei și lucrurile la o distanță mai mare, nu în virtutea vreunei clarități a vederii din partea noastră sau a oricărei distincții fizice, ci pentru că suntem purtați sus și ridicați de dimensiunea lor uriașă.”Stați pe umerii altor giganți ai arhitecturii întreprinderii și lăsați-i să vă sporească viziunea și succesul.