Sisteme informationale economice (4)

Arhitecturi de intreprindere. Modele arhitecturale (II)

ASE, CSIE, an III

1

Modele arhitecturale (MA). Descriere

Modelul Zachman
Enterprise Architecture Planning (EAP) Extended Enterprise Architecture Framework (E2AF) Treasury Enterprise Architecture Framework (TEAF)
2

Modele arhitecturale (MA)

Definitie cadrul folosit pentru construirea EA i cu ajutorul cruia este descris modul de organizare a view-urilor asociate ei.
Componenta principii, servicii, standarde, concepte, componente, moduri de vizualizare i configuraiile.
3

Modelul Zachman (1)

John Zachman:pentru a nu lsa afacerea s se descompun, conceptul de arhitectura sistemelor informaionale devine din ce n ce mai puin o opiune i din ce n ce mai mult o necesitate.

Istoric John Zachman publica prima variant a modelului n 1987 in revista IBM Systems . in 1990 apare o varianta actualizata a modelului. ultima versiune reprezinta n prezent un model pe care importante organizaii la nivel mondial l folosesc pentru a-i construi infrastructura informaional. folosit cu precdere pentru sisteme informaionale din mediul de afaceri i n industrie este considerat un model de referin pentru dezvoltarea EA.
4

Modelul Zachman (2)

Modelul Zachman (3)

Rol MA propune s realizeze un model holistic al unei infrastructuri informaionale pentru o ntreprindere pe baza a cinci puncte de vedere: contextual conceptual logic fizic detaliat caracteristicilor actuale ale companiei (!). Atenia se concentreaz pe faptul c toate aspectele caracteristice unei ntreprinderi trebuie s fie bine realizate i organizate.

Modelul Zachman (4)

What (Ce): descrierea datelor ( de ex. obiectele de afaceri, datele de sistem, tabele relaionale, definirea de cmpuri) How (Cum): descrierea functionala (de ex. procesele de afaceri, funciile aplicaiilor software, etc);

Where (Unde): descrierea retelei, indic locaiile i interconexiunile din cadrul ntreprinderii (ex: rspunsuri includ localizarea geografic a principalelor locaii, separarea seciilor n cadrul unei reele logistice, adresarea memoriei n cadrul sistemului, alocarea nodurilor de sistem, etc.)
Who descrierea persoanelor implicate When descrierea alocarii timpului Why descrierea motivatioanla
7

Modelul Zachman (5)

Contextual (Why) Goal List obiective de nivel inalt ale organizatiei (How) Process List lista tuturor proceselor cunoscute (What) Material List lista tuturor entitatilor organizationale (Who) Organizational Unit & Role List lista tuturor unitilor organizaiei, sub-unitilor i rolurile identificate aferente (Where) Geographical Locations List locatii importante pentru organizaie; pot fi mari i mici (When) Event List lista de factori declanatori i cicluri importante pentru organizaie
8

Modelul Zachman (6)

Conceptual (Why) Goal Relationship Model identific ierarhia de obiective care sprijin obiectivele primare (How) Process Model ofer descrieri de proces, procesele de intrare, procesele de iesire (What) Entity Relationship Model identific i descrie entitatile organizationale i relaiile dintre ele (Who) Organizational Unit & Role Relationship Model identifica rolurile si unitatile intreprinderii precum si relatiile dintre acestea. (Where) Locations Model identifica locatiile intreprinderii si relatiile dintre ele. (When) Event Model identific i descrie evenimentele singulare si periodice in raport cu timpul

Modelul Zachman (7)

Logical (Why) Rules Diagram identifica si descriu regulile care aplica anumite constrangeri asupra proceselor si entitatilor fara a tine cont de implementarea fizica si tehnica (How) Process Diagram identifica si descriu procesele de tranzitie exprimate prin verbe si substantive, fara a tine cont de implemetarea fizica si tehnica (What) Data Model Diagram identifica si descrie entitatile si relatiile dintre ele tinand cont de implementarea fizica si tehnica (Who) Role Relationship Diagram identifica si descrie rolurile precum si relatiile dintre acestea tinand cont de tipurile de rezultate ce se obtin din colaborari. Nu se va tine cont de implementarile fizice si tehnice. (Where) Locations Diagram identifica si descrie locatiile folosite pentru accesarea, manipulare si transferul proceselor fra a tine cont de implementarile fizice si tehnice. (When) Event Diagram identifica si descrie legaturile dintre evenimente sub forma de secvente si cicluri fara a tine cont de implementarile fizice si tehnice.
10

Modelul Zachman (8)

Physical (Why) Rules Specification exprimate in limbaj formal. Constau in numele regulii si o structura logica folosita pentru specificarea si testarea starii regulii. (How) Process Function Specification exprimata intr-un limbaj tehnic specific, elementele aferente proceselor ierarhice sunt legate prin apelarea proceselor. (What) Data Entity Specification exprimata intr-un format specific tehnologiei folosite. Fiecare entitate este definita prin nume, descriere si atribute. Sunt indicate si legaturile dintre entitatile de date. (Who) Role Specification exprim ce trebuie atributii are fiecare rol i fluxul de lucru la nivel de detaliu. (Where) Location Specification exprima componentele de infrastructura fizica si legaturile lor (When) Event Specification exprima transformarile starilor evenimentelor ce prezinta interes pentru intreprindere.

11

Enterprise Architecture Planning (EAP)

definit ca fiind un cadru de lucru comercial care ofer ndrumare pentru primele dou linii ale modelului Zachman (contextual si conceptual) publicat prima dat n 1992
Rol este acela de a asigura realizarea de sisteme informaionale i informatice de o calitate ridicat prin: adoptarea unui model de afaceri stabil definirea dependenelor dintre date nainte de implementarea sistemului.

12

Enterprise Architecture Planning (EAP) (2)

Principii
datele ntreprinderii trebuie s fie accesibile din orice locaie i oricnd este nevoie sistemele informatice trebuie s fie adaptate astfel nct s fac fa nevoilor de schimbare impuse de dinamica afacerii n cadrul ntreprinderii trebuie s existe standarde ridicate, iar datele trebuie s aib un grad mare de integritate toate sistemele de date din cadrul ntreprinderii trebuie s fie integrate

13

Enterprise Architecture Planning (EAP) (3)

Iniierea planificrii Modelarea afacerii Arhitectura de date Tehnologiile i sistemele curente Arhitectura de aplicaii Arhitectura tehnologic

Nivel 1 Nivel 2 Nivel 3 Nivel 4

Moduri de implementare
Fig. 3 Modelul EAP

14

Enterprise Architecture Planning (EAP) (4)

Structur. Nivelul 1: reprezint activitile necesare iniierii proiectului. Activitile specifice impun folosirea unei metodologii adecvate, indicnd: cine ar trebui s fie implicat ce set de instrumente s fie utilizat. Nivelul 2: construiete o baz de cunotine a proceselor de afaceri i a informaiilor necesare. Aceast vizeaza: modelarea afacerii tehnologiile si sistemele curente Nivelul 3: se realizeaz planurile pentru viitoarea arhitectur. Acesta include: arhitecturii de date prin descrierea tipurilor de date de care are nevoie de afacerea. arhitectura aplicaiilor definete: principalele aplicaii necesare gestionrii datelor i proceselor afacerii. arhitectura tehnologic identific platformele tehnologice necesare realizrii unui mediu adecvat pentru datele i arhitecturile aplicaiilor. Nivelul 4: alocat implementrii. Defineste secvena pentru: implementarea aplicaiilor, crearea unui calendar pentru desfurarea etapelor necesare implementrii, pregtirea unei analize cost/beneficiu 15 definirea unei foi de parcurs pentru trecerea de la starea actual la starea dorit.

Extended Enterprise Architecture Framework (E2AF)

Istoric. dezvoltat n 2002 de ctre Institutul de dezvoltare a arhitecturii ntreprinderii (The Institute For Enterprise Architecture Developments (IFEAD)) din Olanda influentat si de modelele arhitecturale Zachman si EAP (Enterprise Architecture Planning
Scop dezvoltarea proceselor i activitilor ce duc la extinderea EA dincolo de limitele iniiale, definind astfel un mediu colaborativ pentru toate entitile implicate n procesul de colaborare.

16

Extended Enterprise Architecture Framework (E2AF) (3)

Principii crearea i meninerea unei viziuni comune agreate att din punct de vedere al afacerii, ct i din punct de vedere al IT-ului. Astfel se poate realiza o corelare/aliniere continu ntre afacere i IT ;
realizarea unei activiti holistice care s reflecte cu acuratee strategia de afaceri a ntreprinderii; creterea agilitii (a timpului de reacie) prin reducerea complexitii proceselor ; creterea flexibilitii n ceea ce privete colaborarea cu stakeholderii externi ;
17

Extended Enterprise Architecture Framework (E2AF) (4)

18

Fig 4. Modelul E2AF

Extended Enterprise Architecture Framework (E2AF) (5)

Structur concept cu implicaii puternice n ceea ce privete nelegerea oricrui aspect i n orice moment de timp, n ceea ce privete ntreprinderea i evoluia sa. Pe baza acestui model, se pot lua decizii pentru crearea de extensii i pentru realizarea de schimbri.
practicile folosite i modul de abordare: E2AF se bazeaz pe conceptul descris n standardul IEEE 1471-2000. Versiunea E2AF n care se dorete reprezentarea doar a unor aspecte, cum ar fi cel economic, legal, etic sau altele care sunt importante pentru organizaie (Fig. 5)
19

Extended Enterprise Architecture Framework (E2AF) (6)

Fig. 5 Modelul E2AF particularizat bazat pe

20

standardul IEEE 1471-2000

Treasury Enterprise Architecture Framework (TEAF)

Istoric Modelul TEAF deriv din modelele americane Treasury (TISAF) realizat n anul 1997 i FEAF. Prima variant a modelului TEAF a aprut n anul 2000. Scop sa ofere ndrumare pentru managementul i dezvoltarea EA pentru trezorerii ; sa satisfaca cerinele OMB (Office of Management and Budget) al SUA ; sa sprijine birourile i departamentele trezoreriei SUA n a implementa propriile EA ; sa arte beneficiile ncorporrii instrumentelor pentru EA n operaiile curente de afaceri ; s ofere o structur pentru realizarea EA i pentru managementul activelor sale.

21

Treasury Enterprise Architecture Framework (TEAF) (2)

Principii respectarea legilor i reglementrilor n vigoare ; obiectivele de business trebuie s fie definite naintea dezvoltrii soluiilor de IT ; valoarea total a afacerii este principalul factor care primeaz pentru deciziile luate legate de tehnologiile folosite ; EA este parte integrant a procesului de management al investiiilor ; deciziile arhitecturale trebuie s vizeze maximizarea interoperabilitii ; standardizarea va fi folosit pentru a ndeplini cerinele i pentru a indentifica funciile de baz ce pot fi folosite ; informaia i infrastructura sunt active foarte importante care trebuie controlate i securizate .
22

Treasury Enterprise Architecture Framework (TEAF) (3)

Structura infrastructura organizational informational functional
Cum, unde i cnd ?
Funcional

Ce, ct de mult, i ct de des ? Cine i de ce ? Suport

Informaional

Organizaional

Infrastructur

23

Treasury Enterprise Architecture Framework (TEAF) (4)

Matricea TEAF a punctelor de vedere arhitecturale i a principalilor actori existeni n model. folosit pentru a oferi o structur simpl i uniform a ntregului cadrul de lucru. const n patru puncte de vedere arhitecturale (view-uri):
funcional informaional organizaional infrastructur

i din patru perspective ale actorilor:

cel cel cel cel care care care care planific EA, o deine, o proiecteaz, o construiete

24

Treasury Enterprise Architecture Framework (TEAF) (5)

View-uri
Functional Planificator Proprietar Proiectant Implementator Functii, procese si activitati de afaceri care manevreaza informatii utile operatiilor de afaceri Toate informatiile necesare realizarii operatiilor de afaceri pentru intreprindere, precum si relatiile dintre acestea
Perspective

Informational

Organizational

Infrastructura

Componentele Structura hardware, software, organizationala a infrastructura, solutiile intreprinderii, de telecomunicatii si principalele operatii serviciile care realizate de constituie mediul departamentele operational in cadrul acesteia, tipuri de careia afacerea se angajati, locatii de lucru poate desfasura

Fig. 7 Matricea TEAF

25