Sa framework

938 views
877 views

Published on

Si illustra come è possibile descrivere una Enterprise Architecture utilizzando il tool Sustem Architect, ex Popkin, ex Telelogic, ora IBM-Rational.

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
938
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • È un framework orientato all’allineamento tra sistemi e business, che non considera gli aspetti strategici e di pianificazione.In Structure Aspect confluiscono la colonna People/Who e la colonna Network/Were;In Behavior Aspect confluisce la colonna Function/How;In Information Aspect confluisce la colonna Data/What;Le colonne Time/When e Motivation/Why non vengono prese in considerazione.Le righe Contextual e Conceptual confluiscono nel Business layer;La riga Logical nello Application Layer;Le righe Physical e Detailed Representation nel Technology layer.
  • Data Object è qualsiasi elemento passivo di un processo le cui caratteristiche sono identificate da dati. Oggetti con caratteristiche simili possono essere ricondotti ad una sola Entity che li descrive tutti mediante gli Attributi, che sono quelle caratteristiche (senza valore) che tutti i data objects hanno in comune (ovviamente con valore diverso).Nell’esempio, la caratteristica “etichetta” del Box B non è condivisa dai data objects Box A e Box C e pertanto non è un attributo dell’entità Box che li identifica e di cui sono “istanze”.
  • LEGENDA: Verde = Data Store Viola = Data Structure Giallo = Data Element
  • I Business Actors possono essere o personale interno (Person) o Stakeholders (persome che influiscono sull’organizzazione senza farne parte, eg fornitori, clienti, ecc.).Sono chiamati actors perché svolgono un ruolo nell’ambito di un processo (Behavior).Dal punto di vista organizzativo i ruoli vengono raggruppati in Organizational Units.
  • Sa framework

    1. 1. Architecture<br />Modeling<br />con System Architect<br />
    2. 2. Così come si modella un Sistema si può modellare anche un’Organizzazione … <br />… perché un’Organizzazione è un Sistema, composto da elementi culturali, di processo e tecnologici, concepito allo scopo di realizzare finalità organizzative.<br />Sistema:<br />Insieme di elementi interdipendenti<br />
    3. 3. Business Strategy Modeling<br />Business Operations Modeling<br />Object Oriented Analysis and Design<br />Structured Analysis & Design<br />Flowcharts<br />Contenuto Semantico<br />Tempo<br />EVOLUZIONE DELLA MODELLAZIONE<br />Non esistono notazioni<br />Business Process Modeling<br />Notazione BPMN<br />Notazione UML<br />SADT – IDEF0<br />IPO<br />
    4. 4. PERCHÉ VOGLIAMO MODELLARE UN’ORGANIZZAZIONE?<br />Un modello viene realizzato per…<br />Rappresentare la realtà in modo condivisibile<br />Catturare conoscenze celate nella realtà<br />Trasformare la realtà usando solo energia intellettuale<br />Simulare la realtà<br />Definire un “ideale” cui la realtà deve tendere<br />… migliorare la realtà<br />
    5. 5. Allineamento dei Sistemi<br />Informativi<br />Requirements<br />Management<br />Analisi<br />Del Valore<br />Aggiunto<br />QFD<br />Analisi dei Costi<br />ABC<br />MODELLOORGANIZZATIVO<br />WFM/<br />TTM<br />Analisi<br />GIBO/BPR<br />Configuration<br />Management<br />Gestione<br />della Qualità<br />Miglioramento<br />Layouts<br />Potenziamento<br />del Personale<br />Riassetto<br />delle Strutture<br />Organizzative<br />A COSA SERVE UN MODELLO ORGANIZZATIVO?<br />
    6. 6. PUNTI DI VISTA<br />VISIONE<br />ORGANIZZAZIONE<br />VISIONE<br />PIANIFICAZIONE<br />Ruoli<br />Agenti Esterni<br />Strutture <br />Organizzative<br />Eventi<br />Stati<br />Transizioni<br />Locations<br />Sistemi<br />Reti<br />Strategie<br />Obiettivi<br />Requirements<br />VISIONE<br />INFRASTRUTTURE<br />VISIONE<br />STRATEGICA<br />Funzioni<br />Processi<br />Dati<br />Item<br />Entità<br />VISIONE <br />INFORMATICA<br />VISIONE<br />FUNZIONALE <br />
    7. 7. COSA OCCORRE PER MODELLARE UN’ORGANIZZAZIONE?<br />UML<br />IDEF<br />BPMN<br />Frameworks<br />ARCHITETTURA<br />NOTAZIONI<br />System<br />Architect<br />Repository<br />STRUMENTO<br />CONTENUTI<br />Business<br />Model<br />
    8. 8. ARCHITETTURA<br /> È ben nota la definizione di SystemArchitecture:<br /> “Disegno concettuale della Struttura (entità e loro relazioni) e del Behavior (funzioni e loro relazioni) di un Sistema”<br /> Come è ben noto che in assenza di una System Architecture si ha ........<br />
    9. 9. “SPAGHETTI” ARCHITECTURE<br />
    10. 10. DEFINIZIONE DI ENTERPRISE ARCHITECTURE<br />Quando un’Organizzazione è considerata alla stregua di un Sistema, la sua architettura prende il nome di Enterprise Architecture che, per analogia, è il disegno concettuale della Struttura (ruoli e unità organizzative) e del Behavior (processi) dell’Organizzazione/Sistema.<br />
    11. 11. Serve un’Architettura?The Winchester “Mystery” House<br /> 38 anni di lavori – 147 costruttori 0 architetti<br /> 160 stanze – 40 camere da letto, 6 cucine, 2 seminterrati, 950 porte<br /> 65 porte su pareti cieche, 13 scale abbandonate, 24 lucernari su pavimento<br /> Non esiste un solo disegno architettonico<br />
    12. 12. FRAMEWORK:La griglia di Zachman<br />
    13. 13. GRIGLIA DI ZACHMAN :Le “Colonne”<br />
    14. 14. SIGNIFICATO DELLE “RIGHE”<br />Questa riga non fa parte della griglia di Zachman<br />
    15. 15. FRAMEWORK SEMPLIFICATO 3x3<br />
    16. 16. GRIGLIA DI ZACHMAN: Semplificazione a tre Livelli (2/2)<br />SINTESI DELLA CONOSCENZA <br />EFFICACIA ORGANIZZATIVA<br />EFFICIENZA OPERATIVA<br />
    17. 17. GLI STRUMENTI PER BM:Rapport Gartner 2002<br />(Aris)<br />
    18. 18. LO STRUMENTO: Caratteristiche di System Architect<br />Supportaimolteplicipuntidi vista Organizzazioneli<br />Tecnichedimodellazione standard e integrate<br />È configurabile<br />È intuitivo<br />Ha un Repository Integrato<br />Web Export, Web Design<br />Reporting, Simulation, ABC, Balanced Scorecard<br />Knowledge Management<br />Reference Models/Specific Models<br />Interfacce con DOORS, Workflow e strumenti CASE<br />Export/Import basatosu XML<br />
    19. 19. LO STRUMENTO: System Architect supporta la Griglia di Zachman<br />
    20. 20. LO STRUMENTO: Le Matrici di Correlazione<br />
    21. 21. I CONTENUTI:System Architect Encyclopedia<br />Repository<br /><ul><li>Diagrammi
    22. 22. Definizioni
    23. 23. Reports
    24. 24. Matrici</li></li></ul><li>I CONTENUTI: Associatività tra gli elementi dell”Encyclopedia”<br />
    25. 25. ACCESSO MULTI-USER CONDIVISO<br />
    26. 26. DIRITTI DI ACCESSO<br />
    27. 27. REVERSE ENGINEERING<br />
    28. 28. LE NOTAZIONI:es. Modellazione dei Processi<br />IDEF<br />BPMN<br />Flow Chart<br />Organization Chart<br />DFD – Data Flow Diagram<br />UML<br />Use cases<br />Activity diagram<br />Sequence/Collaboration<br />Alcune delle Notazioni più comuni<br />
    29. 29. METODOLOGIE: IDEF<br />Integrated Computer-aided Manufacturing Definition<br />Approccio consolidato da oltre 25 anni<br />È l’unica notazione conforme a Federal Information Processing Standards (FIPS)<br />FIPS Publication 183<br />
    30. 30. METODOLOGIE: La Famiglia IDEF<br />È composta da moltissime metodologie studiate per scopi<br />Ben precisi. Le più usate sono:<br />IDEFØ,usata per modellare Function / Activities<br />IDEF3,usata per modellareiprocessi<br />IDEF1x,usata per modellarei DB<br />
    31. 31. METODOLOGIE:DFD - Data Flow Diagram<br />Le notazioni più utilizzate sono:<br />Yourdon/DeMarco and Coad<br />Gane and Sarson<br />Ward and Mellor<br />
    32. 32. Contenuto<br />delle<br />"Colonne"<br />
    33. 33. DATA ("What")<br />“Gli elementi passivi”<br /> Data Elements<br /> Data Structures <br /> Data Objects<br /> Entities<br /> Meta Objects<br />
    34. 34. DATA OBJECTS<br />
    35. 35. DOCUMENT MANAGEMENT<br />DATA MODELING<br />Folder<br />Data Store<br />CONOSCENZA<br />Context<br /> Add Experience<br />Documento<br />Data Structure<br />INFORMAZIONE<br />Concept<br />Form<br /> Add Structure<br />DATO<br />Instance<br />Dato<br />Data Element<br />STRUTTURAZIONE DEI DATI<br />
    36. 36. ESEMPIO DI DATA MODEL<br />
    37. 37. EVOLUZIONE DELLA CONOSCENZA<br />SINTESI DELLA CONOSCENZA<br />Constraint<br />WISDOM<br />Classification<br /><ul><li> Ontology
    38. 38. Patterns</li></ul>Human<br />Intelligence<br />Add Insight<br />
    39. 39. Stage in the evolution of knowledge discovery<br />
    40. 40. BUSINESS INTELLIGENCE<br />
    41. 41. DEFINIZIONE DI DATABASE:Insieme di Entities Correlate<br />Logical Database<br />
    42. 42. Documento<br />Struttura Dati <br />INTEGRAZIONE SYSTEM ARCHITECT<br />(non semantico)<br />Livello<br />Contestuale<br />Livello<br />Concettuale<br />Process<br />Model<br />
    43. 43. FUNCTION("How")<br />“Behavior”<br /> Funzioni<br /> Processi<br />BPM.ppt<br />
    44. 44. BUSINESS CONCEPT DIAGRAM<br />
    45. 45. SISTEMI E PROCESSI<br />
    46. 46. NETWORK("Where")<br />“Locations e Interfacce”<br /> Locations<br /> Application Interfaces<br /> Nodi<br /> Reti<br /> Tecnologie<br />
    47. 47. NETWORK E LOCATIONS<br />Reparto<br />CdL<br />Server CdL<br />Location Model View<br />Trasporti<br />Magazzino<br />Location<br />Node<br />Network<br />
    48. 48. PEOPLE("Who")<br />“L’Elemento Attivo”<br /> Ruoli<br /> Stakeholders<br /> Unità Organizzative<br />
    49. 49. ROLE CONCETTO PIVOT<br />
    50. 50. TIME ("When")<br />“La Pianificazione”<br /> Eventi<br /> Stati<br /> Transizioni<br />
    51. 51. ITEM E STATI<br />
    52. 52. PROCESSO = TRASFORMAZIONE DI ITEM<br />Richiested’Acquisto<br />MateriePrime<br />Offerta<br />Requisiti<br />Acquisizione<br />Ordine<br />Progettazione<br />Acquisti<br />Produzione<br />Ordine<br />Documentazione<br />Prodotto<br />Fornitura<br />Prodotto<br />
    53. 53. OBJECT STATE TRANSITION<br />
    54. 54. MOTIVATION("Why")<br /> Strategie<br /> Obiettivi<br /> Requiements<br /> Rules<br />BSC.ppt<br />“Le Strategie”<br />

    ×