Modulul 15

Integrare în întreprinderi și Arhitectura orientată spre servicii

BOUNDARYLESS INFORMATION FLOW
Fluxul de informații fără margini este viziunea grupului deschis și reprezintă accesul la
Informații integrate, care acceptă îmbunătățiri ale procesului de afaceri.
Pentru a implementa Boundaryless Information FlowTM, trebuie utilizate componente standard
deschise.
Aceste componente combină nu numai informații din diverse surse, dar asigură și livrarea sigură
a acestor informații ca și când sunt necesare. În acest fel, utilizatorii finali primesc informațiile
de care au nevoie la timpul necesar, fără a fi nevoie să vă faceți griji pentru sursa sau
securitatea sa.
Întreprinderile moderne au o serie de aplicații optimizate pentru funcționarea eficientă a
procese specifice. Departamentele pot transmite informațiile necesare altor departamente care
folosesc comunicarea umana, nu depinzand de fluxurile automate de informații. Astfel de
schimburi de informații ingreuneaza in a menține întreprinderea competitivă. Întreprinderile de
astăzi au nevoie de informații acceptate de aplicații pe o bază necesară cunoașterii.
Pentru a preveni suprasarcina de informații, informațiile ar trebui integrate astfel încât
informațiile corecte sunt disponibile utilizatorului final potrivit la momentul potrivit, printr-o
singură interfață. TOGAF® 9.1 acceptă astfel de fluxuri de informații fără margini cu III-RM care
arată impactul asupra arhitectura de aplicații a organizațiilor.

CERINȚE DE INTEROPERABILITATE
Cheltuielile-cheie ale acestui videoclip sunt:
Ɣ Nu aș putea să fac asta. Doar dacă toată lumea cunoaște limba semnelor.
Ɣ Exact, veți putea opera dacă poate exista o comunicare bidirecțională. Dacă explicați și ei
înțelegeți și dacă ei întreabă și puteți răspunde.Aceasta este interoperabilitatea.

Note de instructor
După ce a rulat banda desenată, instructorul este sfătuit să:
Ɣ Petreceți un minut în întărirea mesajului din banda desenată. În mod alternativ,
participanților li se poate cere să rezume povestea.
Ɣ Ajungeți la motivele prezentate în acest diapozitiv utilizând livrări cheie din videoclip.
Această activitate are drept scop reiterarea conceptului de interoperabilitate.
Activitate: Aceasta este o activitate de prezentare, în care participanții ar trebui să explice
interoperabilitatea folosind termenii lor.
Sugestii de instructor: Instructorul trebuie să informeze participanții că această activitate se
bazează pe concept
de interoperabilitate. Instructorul este sfătuit să:
Ɣ Împărțiți participanții în echipe.
Ɣ Dă 5 minute echipelor să se pregătească.
Ɣ Îndreptați participanții către soluție.
Ɣ Permiteți unei echipe să se prezinte și altora să critice.
Timpul alocat: 10 minute.

Definirea interoperabilității
Interoperabilitatea este capacitatea de a partaja informații și servicii.
Interoperabilitatea defineste gradul în care informațiile și serviciile sunt partajate între
întreprinderi, în cadrul întreprinderilor și între aplicații. Deciziile privind modul de interoperare
sunt cerințe cheie din perspectivă arhitecturală, în special într-o organizație complexă și / sau
afacere extinsă. Acestea au impact asupra structurilor și interfețelor fundamentale care sunt
necesare în toate domeniile arhitecturii. Interoperabilitatea necesară la nivel de afaceri propagă
cerințele de interoperabilitate la un nivel de sisteme de informații ,care la rândul lor propagă
cerințe de interoperabilitate la un nivel tehnologic.
Cerințele de interoperabilitate, prezentate în TOGAF® 9.1, oferă o tehnică de identificare a
cerințelor de integrare la mai multe niveluri. Flowurile de Informații sunt clasificate în niveluri
pentru a indica amploarea de interoperabilitate necesară între organizații și sisteme. În acest
fel, cerințele de interoperabilitate reprezintă un pas important către proiectarea și
implementarea Enterprise Architecture.

ADM detaliază cerințele de interoperabilitate după cum urmează:

Viziune de arhitectură -> Scenariile de afaceri surprind natura și aspectele de securitate ale
schimburilor de informații și servicii.
Arhitectura afacerilor -> Schimburile de informații și servicii sunt definite în continuare în
termeni de afaceri.
Arhitectura de date -> Date corporative și / sau Modelul schimbului de informații detaliază
conținutul schimburilor de informații.
Arhitectura aplicațiilor -> Specifica modul în care diferitele aplicații isi partajeaza informațiile și
serviciile.
Arhitectură tehnologică -> Specifica mecanismele tehnice adecvate pentru a permite schimbul
de informații și servicii.
Oportunități și soluții -> Selectează soluțiile reale.
Planificarea migrației -> Implementează interoperabilitatea, în mod logic.

CLASIFICARE
Cea mai importantă clasificare este legată de domeniile de arhitectură din TOGAF® 9.1. Este
următorul:
Ɣ Interoperabilitate operațională sau de afaceri - Este modul în care procesele de afaceri
trebuie împărtășite.
Ɣ Interoperabilitatea informațională - Este modul în care informațiile trebuie distribuite.
Ɣ Interoperabilitate tehnică - Este modul în care serviciile tehnice trebuie să fie partajate sau cel
puțin conectate unul celuilalt.

Un mod mai tehnic de clasificare a interoperabilității este următorul:

Ɣ Integrare de prezentare sau interoperabilitate - Un portal și o abordare obișnuită de aspect
utilizat pentru a accesa funcționalitatea de bază a setului de sisteme.
Ɣ Integrarea informațiilor sau interoperabilitatea - o ontologie corporatistă acceptată în mod
obișnuit este urmată de partajarea perfectă a informațiilor între aplicații.
Ɣ Integrarea aplicației sau interoperabilitatea - Utilizează datoriile pentru a conecta perfect
funcționalitatea și evitarea duplicarii.
Ɣ Integrare tehnică sau interoperabilitate - Utilizează metode comune și servicii partajate
pentru partajarea datelor pe platformele de aplicații și domeniile infrastructurii de comunicații.
Este important să fie urmată o modalitate constantă de definire a interoperabilității în
întreprindere.
Modelul de operare al întreprinderii este un aspect cheie pentru interoperabilitate.

Model de operare al întreprinderii

Modelul de operare al întreprinderii este un factor cheie care este luat în considerare în timp ce
se decid cerințele de interoperabilitate ale întreprinderii. Un model de operare nu necesită
procesul necesar de afaceri integrare și standardizare în cadrul unei întreprinderi. Acestea sunt
decizii fundamentale pentru organizații și au un impact puternic asupra structurii organizației,
precum și asupra tuturor domeniilor de arhitectură. O operare modelul descrie modul în care o
companie dorește să prospere și să crească. Oferind un sistem mai stabil și mai acționabil
viziunea companiei decât strategia, modelul de operare conduce proiectarea fundației pentru
execuție.
În studiul de caz universitar, de exemplu, facultățile au libertatea de a-și defini propriile procese
pentru educație și cercetare, atât timp cât rămân în cadrul politicilor și orientărilor stabilite la
nivel universitar. Procesele de susținere, precum și procesele de control sunt standardizate la
nivel universitar. În plus, informațiile care sunt necesare pentru aceste procese standardizate,
cum ar fi informațiile
despre angajați, tranzacții nanciare, comenzi de cumpărare și performanța și conformitatea
acestora
procesele sunt, de asemenea, standardizate la nivel universitar.
Modelul de operare al întreprinderii este de obicei determinat în faza de viziune a arhitecturii.
Dacă nu, asta
ar trebui să fie definitiv determinat în faza de arhitectură de afaceri. Multe întreprinderi
complexe sunt
mai mult de un model de operare, analog cu (sub) întreprinderi care există în cadrul
întreprinderii de nivel superior.

TOGAF® 9.1 citează schema de clasificare utilizată de Departamentul canadian de apărare

națională și Organizația Tratatului Atlanticului de Nord (NATO), ca exemplu de precizare a
interoperabilității. Au patru grade de interoperabilitate care sunt specificate după cum
urmează:
Ɣ Gradul 1 - Schimbul de date nestructurat presupune schimbul de date nestructurate
interpretate uman, cum ar fi textul liber găsit în estimările operaționale, analize și lucrări.
Ɣ Gradul 2 - Schimbul de date structurate presupune schimbul de date structurate interpretate
uman si destinate manipulării manuale și / sau automatizate, dar necesită compilare manuală,
primire,și / sau expediere de mesaje.
Ɣ Gradul 3 - Împărtășirea fără probleme a datelor implică schimbul automat de date între
sisteme bazat pe un model comun de schimb.
Ɣ Gradul 4 - Împărtășirea fără probleme a informațiilor este o extensie a gradului 3 la nivel
universal,interpretand informațiile prin procesarea datelor pe baza aplicațiilor de cooperare.

Conform TOGAF® 9.1, aceste grade de interoperabilitate ar trebui adaptate la contextul

organizațional. De asemenea, cerințele tehnice pot fi derivate din acestea care folosesc o
clasificare mai definită
sistem. Un exemplu de referință de gradul 3 cu patru sub-clasificări este următorul:
Ɣ 3A: Schimb formal de mesaje
Ɣ 3B: Schimb comun de date
Ɣ 3C: Schimb complet de date
Ɣ 3D: schimb de date în timp real

TOGAF® 9.1 recomandă ca, dacă este utilizat un mecanism precum Gradele de
interoperabilitate, atunci matricea care prezintă cerințele de interoperabilitate este un
instrument util. Matricea poate fi folosită și în cadrul de întreprindere și / sau în cadrul
întreprinderii extinse ca mod de detaliere a informațiilor și / sau serviciilor respective.
Tabelul din diapozitiv prezintă matricea de interoperabilitate a informațiilor despre afaceri.
Tabelul surprinde diferite grade de interoperabilitate între părțile interesate. De exemplu,
părțile interesate A necesită grad 2 interoperabilitatea cu părțile interesate B și D și
interoperabilitatea de gradul 3 cu părțile interesate C, E, F,iar G.
În mod ideal, această matrice ar trebui definită pentru a descrie matricea de interoperabilitate
a sistemelor informaționale.

Tabelul diapozitivului conține cerințele de interoperabilitate dintre sisteme. De exemplu,

sistemul A necesită interoperabilitate de gradul 2A cu sistemul B, 2B cu sistemul D și 3B cu
sistemul G.
După ce au fost definite cerințele de interoperabilitate, impactul asupra arhitecturii trebuie să
fie determinat. Aceasta necesită identificarea diferenței dintre cerințele de interoperabilitate și
linia de bază arhitectură.

Reconcilierea interoperabilității
Enterprise Architect este responsabilă de reconcilierea interoperabilității prin:
Ɣ Evitarea confl ictelor de interoperabilitate, în special în ceea ce privește reutilizarea.
Ɣ Obținerea de înregistrări de la părțile interesate relevante în caz de schimbări.
Responsabilitatea de a evita conținutul de interoperabilitate revine Enterprise Architects. Acest
lucru este mai ales important dacă întreprinderea intenționează să reutilizeze sistemele
comerciale existente în afara raftului (COTS). Interoperabilitatea in Afaceri este cea mai
semnificativă, deoarece are cel mai profund impact asupra oamenilor și organizațiilor. De
asemenea, nivelul de interoperabilitate comercială poate fi sever restricționat de nivelul de
interoperabilitate care este acceptat de aplicațiile impachetate. Adesea, astfel de aplicații au
propriile lor procesele de afaceri și interoperabilitatea asociată încorporate.
Modificarea procesele de business incorporate va necesita deseori atâta muncă încât avantajele
reutilizării soluțiilor vor fi pierdute.
Enterprise Architect este, de asemenea, responsabil pentru obținerea de înscrieri de la
arhitecții de afaceri și
sponsori de arhitectură, dacă cerințele de interoperabilitate ale afacerii sunt modificate.
Deținerea fără echivoc a interoperabilității este, de asemenea, o condiție prealabilă din
perspectiva SOA. Serviciile sunt menită să realizeze fluxuri de informații.

STUDIU DE CAZ
Obiectiv: Scopul este de a înțelege fluxurile de informații , o matrice de interoperabilitate a
sistemelor informaționale, și ce înseamnă să construiești de fapt artefacte care să le susțină.
Activitate: Prezentați matricea de interoperabilitate a sistemelor informaționale și identificați
unele servicii informaționale care sprijină fluxurile de informații.
Timp: 45 minute.
Pentru a finaliza cu succes activitatea, abordați următoarele sarcini:
Ɣ Determinați fluxurile de informații dorite între aplicațiile descrise în studiul de caz.
Ɣ Construiți o matrice de interoperabilitate a sistemelor informaționale.
Ɣ Identificați unele servicii de informații care suportă fluxurile de informații.
Ɣ Prezentați-le celorlalte grupuri.
Note de instructor
Sugestii pentru instructor: Instructorul este sfătuit să ceară participanților să determine
fluxurile de informații care există între diferitele sisteme ale universității și sa le foloseasca
pentru a construi matricea de informație a sistemelor interoperabilității și identificarea unor
servicii ale sistemului informațional. Scopul este să înțelegeți acești subiecți și relația lor și ce
înseamnă să construiți de fapt artefacte pentru a ii sprijini.
Această sarcină trebuie finalizată în termen de 45 de minute. Instructorul poate exercita
discreție alocarea de intervale de timp specifică sarcinilor, cum ar fi 25 minute pentru creare și
20 minute pentru prezentare.
Pentru această misiune, instructorul este sfătuit să ia în considerare următorii indicatori:
Înainte de prezentare
Ɣ Informează participanții că pot lua în considerare următorii indicatori:
• Gândiți-vă la informațiile care circula de la un sistem la altul, folosind textul din
descrierea studiului de caz ca sursă de inspirație. De exemplu, Sistemul deInformații al
studenților menține informații despre studenți și sistemul de management al învățării
folosește informații despre studenți. Aceasta implică faptul că informațiile despre studenți ar
trebui să fie de la primul la cel de-al doilea.
• Gândiți-vă la volumele și frecvența informațiilor schimbate și cum informațiile recente
trebuie să se bazeze pe așteptările lor ca o modalitate de a determina nivelul de integrare
este nevoie de o interfață orientată către servicii.

Note de instructor
Ɣ Serviciile sistemului de informații asigură implementarea fluxurilor de informații. De exemplu,
Sistemul de informații al studenților poate expune un serviciu care oferă informații despre
studenți și
care pot fi utilizate de alte sisteme, cum ar fi sistemul de management al învățării.
Ɣ Creați echipe noi sau continuați cu echipele existente.
Reamintiți-le participanților că studiul de caz este disponibil în Anexa A a Cartii de curs.
Ɣ Cereți participanților să analizeze și să discute provocările din cadrul echipei lor.
Ɣ Spuneți participanților că pot folosi tablouri și tablele albe pentru a face prezentarea lor.
Ɣ Fii deținătorul timpului pe durata sarcinii.
Ɣ Plimbați-vă și îndrumați echipele spre direcția corectă, dacă ele se sincronizează.
În timpul prezentării
Ɣ Îndepărtați participanții care nu sunt prezenți să ia notițe.
Ɣ Cereți participanților care nu prezintă prezența să discute opiniile lor după prezentare.
După prezentare
Ɣ Acționați ca instructor.
Ɣ Distribuie opinii, comentarii și sugestii de îmbunătățire.
Ɣ Cereți echipelor să-și împărtășească gândurile, comentariile și așa mai departe.
Răspunsuri cu exemple:
Sistemul de administrare al cercetării folosește informații despre angajați, inclusiv doctori, care
sunt de obicei stocate în sistemul HR. Aceasta implică o informație de la sistemul de resurse
umane la cercetare Sistem de administrare. Această informație nu se schimbă foarte des.
Numărul cercetătorilor este destul de limitat, iar necesitatea celor mai actualizate informații nu
este foarte mare. Acest lucru implică faptul că zilnic actualizarea acestor informații este
probabil suficientă. În această situație, un nivel mai mare de interoperabilitate ar fi implică
faptul că informațiile ar trebui să fie actualizate aproape în timp real. Acest lucru ar necesita un
serviciu în timp real,interfață orientată între aplicații. Pe de altă parte, un nivel mai scăzut de
interoperabilitate ar fi implicați că informațiile pot fi introduse manual în sistem. Acest lucru
poate fi acceptabil dacă există doar un număr foarte limitat de instanțe și actualizări. Având în
vedere că nu este necesară o interfață în timp real,interfața dintre sistemul de resurse umane și
sistemul de administrare a cercetării nu trebuie să se bazeze pe o interfață orientată către
servicii. Rețineți, însă, că din perspectivă funcțională un sistem informational serviciul care
oferă informații despre angajați există. Doar nu trebuie să fie pus în aplicare ca serviciu la nivel
tehnic.

MODEL DE REFERINȚĂ A INFRASTRUCTURII INFORMAȚIONALE INTEGRATE

Conductorii cheie de tehnici și afaceri
Cele două drivere principale de afaceri și tehnice pentru III-RM sunt următoarele:
Nevoia de flux de informații fără margini
Jack Welch a subliniat importanța limitelor permeabile între diverse aplicații.
De atunci, multe întreprinderi din întreaga lume - inclusiv mulți membri ai grupului Open - au
acceptat și au lucrat pentru a obține informațiile corecte către utilizatorul final la momentul
potrivit,în siguranță și în mod sigur.
Ɣ Necesitatea infrastructurii informaționale integrate
În anul 2001, The Open Group a publicat Scenariul întreprinderilor interoperabile pentru
întreprinderi.
Acest scenariu subliniază faptul că o întreprindere ar putea obține eficiențe semnificative
operaționale șiîmbunătățirea proceselor de afaceri diferite ale întreprinderii dacă personalul
are:
ż Informații integrate - Așa încât informațiile diferite sau potențial conflictuale nu sunt
distribuite pe diferite sisteme.
ż Acces integrat la informațiile respective - astfel încât personalul autorizat să poată avea
dreptul și acces la toate informațiile de care au nevoie, printr-o interfață convenabilă.
Conform TOGAF® 9.1, infrastructura care permite această viziune este denumită integrată
infrastructura informațională. Portalurile de întreprinderi moderne de zi sunt exemple de astfel
de infrastructură.
Componente
III-RM are următoarele componente principale:
Ɣ Taxonomie - Defineste terminologia și oferă o descriere coerentă a componentelor și
structura conceptuală a unei infrastructuri informaționale integrate.
Graphic Grafic III-RM asociat - Oferă o reprezentare vizuală a taxonomiei și a
interrelației componentelor, ca ajutor pentru o mai bună înțelegere.
III-RM este o arhitectură la nivel înalt care oferă un exemplu despre cum se poate realiza
Boundaryless Fluxul informațional. Descrie procesul de clustering și conectarea logicii diferitelor
aplicații astfel încât informațiile corecte să fie disponibile persoanei potrivite la momentul
potrivit.
III-RM detaliază, de asemenea, aplicațiile de afaceri și aplicațiile de infrastructură pentru a vă
ajuta la soluționarea nevoii de a proiecta o infrastructură informațională integrată care să
permita Fluxul de Informații fără margini. Aceasta este una dintre provocările cheie cu care se
confruntă astăzi Enterprise Architects.
Vederea la nivel înalt a III-RM detaliază derivarea sa din modelul de referință tehnică (TRM),
graficul III-RM asociat și componentele principale.
III-RM este un model al componentelor aplicației și al software-ului serviciilor de aplicații care
sunt esențiale pentru o infrastructură informațională integrată.
III-RM are următoarele componente:
Ɣ Aplicații pentru infrastructură
ż Instrumente de dezvoltare, care susțin dezvoltarea și desfășurarea aplicațiilor.
ż Utilități de gestionare, care susțin gestionarea aplicațiilor.
Ɣ Platforma de aplicații
Oferă servicii de asistență pentru aplicații din domenii, cum ar fi locația, directorul,
workflowurile ”, date gestionare și schimb de date.
Ɣ Aplicații de afaceri
ż Aplicațiile furnizorului de informații, care sunt responsabile de gestionarea informațiilor.
ż Aplicații pentru consumatori de informații, care furnizează informații integrate utilizatorilor.
ż Aplicații de intermediere, care mediază cererile de la aplicațiile consumatorilor de informații
către și pentru orice număr de aplicații furnizate de informații, cumulând rezultatele.
Ɣ Interfețe
Sunt conexiunile dintre aplicații, inclusiv formatele, protocoalele și aplicația
interfețe de programare pe care se bazează.
Ɣ Calități
Sunt caracteristicile nefuncționale pe care trebuie să le prezinte aplicațiile.

Activitate
Cum se raportează III-RM la arhitectura de aplicații din organizația dvs.?
Note de instructor
Această activitate are ca scop corelarea componentelor III-RM cu arhitectura de aplicații.
Activitate: Discutați despre modul în care III-RM se raportează la arhitectura aplicației.
Sugestii de instructor: Instructorul trebuie să informeze participanții că această activitate se
bazează pe III-Componente RM. Participanții au aflat deja despre III-RM în diapozitivele
anterioare. instructorul este sfătuit să ceară participanților să coreleze III-RM cu arhitectura de
aplicații din cadrul lor organizații.
Timpul alocat: 5 minute.

ARHITECTURA ORIENTATĂ SPRE SERVICII

O introducere
Orientarea serviciilor: un mod de a gândi în termeni de servicii și dezvoltare bazată pe servicii și
rezultatele serviciilor.
Arhitectură orientată către servicii (SOA): un stil arhitectural care acceptă orientarea serviciilor.
Întreprinderile au probleme care gestionează niveluri crescânde de complexitate. Ei sunt mereu
în căutare de modalități de a crește agilitatea lor de afaceri. În plus, complexitatea de aplicații și
interfețe existente în o întreprindere face managementul schimbărilor mai dur. SOA simplifică
activitatea și interoperația din diferite părți ale acelei afaceri. SOA structurează capacitatea și
aplicațiile și standardizează comportamentul și interoperarea serviciilor.
Are următoarele caracteristici distinctive:
Ɣ Se bazează pe proiectarea serviciilor - care reflectă activitățile de afaceri din lumea reală
procesele de afaceri ale întreprinderii (sau între întreprinderi).
Serviciul de Reprezentare utilizează descrieri de afaceri pentru a oferi contextul (adică, procesul
de afaceri, obiectiv, regulă, politică, interfață de serviciu și componentă de serviciu) și
implementează servicii utilizând serviciul de orchestrație.
Ɣ Pune cerințe unice în infrastructură - se recomandă utilizarea implementărilor
standard deschise pentru a realiza interoperabilitatea și transparența locației.
Ɣ Implementările sunt specifice mediului - sunt restricționate sau activate de context și trebuie
fi descris în contextul respectiv.
Ɣ Necesită o guvernare puternică a reprezentării și implementării serviciilor.
Ɣ Necesită un „Test Litmus”, care determină un „serviciu bun”.
Arhitectură orientată către servicii și arhitectură de întreprinderi
Enterprise Architecture poate oferi contextul și capacitățile de analiză pentru:
Ɣ Afișați cum soluțiile SOA pot fi arhivate eficient pentru a sprijini capacitățile de afaceri
Ɣ Afișați ce servicii ar trebui construite și care ar trebui reutilizate
Ɣ Afișați cum ar trebui proiectate serviciile
Arhitectura Enterprise oferă cadre, instrumente și tehnici pentru a ajuta organizațiile cu
dezvoltarea și întreținerea SOA-urilor lor. Enterprise Architecture oferă abstractizări de
strategii de nivel și livrări, conectează diverse perspective la o singură problemă de afaceri,
identifica foile de parcurs clare pentru realizarea stării viitoare, sprijină evaluarea impactului,
analiza riscurilor / valorilor și a portofoliului de management, indentifica și documenteaza
principii, constrângeri, cadre, modele și standarde.
Astfel, arhitectura Enterprise devine o bază pentru o organizație orientată spre servicii. În plus,
Arhitectura întreprinderii poate oferi contextul și capacitățile de analiză pentru:
Ɣ Afișați cum soluțiile SOA pot fi arhivate eficient pentru a sprijini capacitățile de afaceri.
Ɣ Afișați ce servicii ar trebui construite și care ar trebui reutilizate.
Ɣ Afișați cum ar trebui proiectate serviciile.
TOGAF® 9.1 oferă îndrumări SOA pentru diferite etape ale ADM.
Detaliile pentru fază sunt următoarele:
Fază-> Detalii legate de arhitectură orientată către servicii
Faza preliminară Ɣ Adoptați orientarea serviciului ca principiu de arhitectură.

Ɣ Efectuați evaluarea maturității SOA.

Ɣ Adaptați guvernarea la SOA (de exemplu, utilizând SOA
Metoda vitalității guvernanței).
Ɣ Implementați Centrul de Excelență SOA.
Ɣ Populați depozitul de arhitectură cu resurse SOA.
Ɣ Cadrul de conținut specific organizației la SOA
blocuri de construcție și artefacte.
Faza de viziune arhitecturală Ɣ Adoptați terminologia SOA în viziunea arhitecturii.
Ɣ Creează conștientizare pentru principiile și implicațiile SOA
cu părțile interesate.

Faza de arhitectură a afacerilor Ɣ Dezvolta artefacte specifice SOA care se concentrează pe

afaceri

Servicii.

Arhitecturi sisteme informaționale

Fază

Ɣ Dezvolta artefacte specifice SOA, concentrându-se pe informații

servicii de sistem.
Ɣ Concentrați-vă pe preocupările specifice SOA în dezvoltarea de
artefacte.
Ɣ Efectuați o analiză a golurilor la nivelul sistemului informațional
Servicii.

Faza de arhitectură tehnologică Ɣ Dezvolta artefacte specifice SOA care se concentrează pe

platformă

Servicii.
Ɣ Nu sunt blocuri de construcție a infrastructurii specifice SOA. Utilizarea
Arhitectura de referință SOA Open Group și
Referință de infrastructură orientată către servicii în grup deschis
Modelul ca punct de plecare.
Ɣ Concentrați-vă pe preocupările specifice SOA în dezvoltarea de
artefacte.

Oportunități și fază de soluții Ɣ Identificați soluțiile SOA și managementul acestora

cerințe.

Ɣ Selectați opțiunile de livrare pentru servicii: externe, in-

casă sau achiziție.

Ɣ Dezvolta artefacte specifice SOA care se concentrează pe SOA

soluții.

Faza de planificare a migrației Ɣ Examinați aspectele specifice implementării SOA

model de guvernare.

Implementarea Faza de guvernare Ɣ Efectuați activitățile specifice SOA în implementare

model de guvernare.
Ɣ Operaționalizați partea de monitorizare a SOA
Metoda vitalității guvernanței.

Gestionarea schimbărilor de arhitectură

Fază

Ɣ Evaluează contribuția pe care ar putea-o aduce SOA și

ia în considerare adoptarea principiului orientării către servicii.