1 / 105

Architecture des Systèmes d'Information

Architecture des Systèmes d'Information. Qui suis je ?. Présentation générale. Prénom et Nom : Layth SLIMAN Titres et diplômes Doctorat en Informatique.  Mastère en informatique, spécialité Système d’Information. Diplôme d’Ingénieur généraliste en Informatique. Fonctions

nairi
Download Presentation

Architecture des Systèmes d'Information

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architecture des Systèmes d'Information

  2. Qui suis je?

  3. Présentation générale Prénom et Nom : Layth SLIMAN Titres et diplômes • Doctorat en Informatique. •  Mastère en informatique, spécialité Système d’Information. • Diplôme d’Ingénieur généraliste en Informatique. Fonctions • 2010- présent: Enseignant-chercheur, EFREI- Paris. • Jusqu'à 2010: Chercheur, INSA Lyon.

  4. Les données sont la matière première pour le SI. Avant d’obtenir une info. Des données doivent être crées et/ou collectées, stocker puis traitées, analysées, représentées et diffusées. Le système d’information est caractérisé par ces fonctions: « génération, stockage , présentation, échange, interprétation, transformation, des informations. » Information system

  5. Vision du SI centrée sur les applications • Les applications sont développées de façon isolée et les fonctionnalités fournisses sont utilisable seulement dans les applications qui les produisent. • Les langages, les formats de données et les protocoles ont créé des barrières technologiques difficiles à dépasser. • Les entreprises ont perdues leurs flexibilité et agilité vis-à-vis des changements dans le marché. • Le SI est devenu un problème plutôt qu’une solution.

  6. Architecture 1/2 • “An architecture is the fundamentalorganization of a system embodied in its components, theirrelationships to eachother, and to the environment, and the principlesguidingits design and evolution.”IEEE STD 1471-2000 Elle est utilisée pour: • Prendre des décisions d’achat. • Aider à choisir les solutions. • Analyser les besoins. • Guider l’intégration. • Développer des nouveaux composants. • Construire le système. • Comprendre et guider les changements.

  7. Architecture 2/2 • Elle focalise sur la création des nouveaux systèmes sensés outiller une entreprise ou un métier. • Un rôle clé de l’architecture est d’aider à superviser, et coordonner les développement des composants toute en gardant une vue d’ensemble malgré la complexité du système. • En plus, l’architecture aide à guider le changements dans les systèmes existants. Le changement dans un système déjà créé est la plus part du temps plus compliqué que la création d’un nouveau système.

  8. Définition d’un Système d’Information On peut prendre comme point de départ un site web tel que celui de la SNCF, AIRFRANCE. Ces sites web ne sont que la partie visible de l'iceberg. L'iceberg, ici, c'est le : Système d‘Information (SI) Le SI reçoit et centralise des informations provenant de différentes sources (financières, clients, fournisseurs …) les traite, les transforme, les stocke puis il les répartit en fonction des besoins des utilisateurs ou des services.

  9. Systèmes d’information d’entreprise Les Systèmes d’Information d’entreprise offrent un cadre unifié autour duquel s’articulent tous les services de l’entreprise. L’étude de l’architecture d’un SI couvre les aspects suivants: Méthodologiques (architecture, modélisation, alignement métier et stratégique) Opérationnels (gestion de projet, aide à la décision..) Technologiques (gestion des données, intégration, sécurité, qualité de services).

  10. Les couches d'un SI

  11. La couche métier Englobe l'ensemble des problématiques liées à l'exécution des tâches liées au métier que le système d'information est censé outiller. Il s'agit de la définition des « Processus métier » les « Procédures » les « Règles métier » et les « Objets métiers » qui doivent être représentés dans le système d'information Concepts clefs : BPM, Modélisation Opérationnelle…

  12. Conception fonctionnelle Cette couche précise comment accomplir les actes « métier » que le système d'information est sensé exécuter. Elle s’intéresse aux « fonctions » de la solution logicielle et pas à la nature des applications informatiques. Ces fonctions ont encore une sémantique métier identifiable. Concepts clefs : Modélisation fonctionnelle

  13. La couche d'architecture du Système Essaie de comprendre quels composants logiciels peuvent s'assembler pour produire les actes métiers désirés ou attendues. Cette couche considère l'ensemble du système d'information comme une unité qu'il faut décomposer en modules. Ces modules sont des "produits" du marché ou des nouveaux développements qu'il faudra réaliser. Concepts clefs :Conception Logicielle, Intégration, Urbanisation, SOA, Middleware.

  14. Architectes des SI? Il sont des « technologues » ayant une bonne connaissance du métier de l’entreprise d’un coté, et une connaissance structurelle et approfondie de l'offre en matière de solutions et de composants de solutions. Leur rôle est multiple : Spécifier les besoins liés à un métier ou une entreprise. Rechercher et/ou concevoir des produits "candidats" à la réalisation de chaque partie de la solution. Vérifier l’ adéquation aux besoins des produits retenus. Superviser l’intégration de ces produits, ceci veut dire : Garantir que les informations peuvent circuler entre les différents produits. Garantir que les traitements peuvent être déclenchés de façon cohérente dans les différentes parties de la solution vis-à-vis la logique métier. Enfin, proposer un pilotage globale de toutes ses parties.

  15. Le rôle du SI Collecte: c’est l'ensemble des tâches consistant à détecter, sélectionner, acheminer, extraire et filtrer les données brutes issues des sources multiples et potentiellement hétérogènes. Déclenchement et supervision: déclencher les fonctions du système en se basant sur les données collectées et en suivant la logique métier tout en garantissant le bon fonctionnement de l’ensemble. Intégration: concentrer les données collectées dans un espace unifié, homogène, normalisée et fiable. Diffusion: met les données à la disposition des utilisateurs et des applications, selon le profil, le métier et les besoins. Aide à la décision : transforme les données en conclusions fiables sur les faits actuels et sur les prévisions futures en appliquant des techniques d'analyse sophistiquées.

  16. Compétences requises Modélisation des Systèmes d’Information Gestion de projet Outils et techniques de: Intégration, Interopérabilité, Collaboration Ingénierie Logicielle et Qualité Technologies des SI Bases De Données avancées Gestion des risques Sécurité et Control d’accès

  17. Les qualités de l’architecte SI Polyvalence (Métier, Technique, Technologique..etc.) Esprit d’analyse et de synthèse Grande curiosité Rigueur Savoir communiquer, argumenter…

  18. Les cadres d’architecture Qu’est ce que c’est un cadre d’architecture (Architecture Framework)? • “A framework which guides the representation of the information system via views of models.” IEEE

  19. Architecture Framework • “An architecture framework is a tool… It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. • It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.” [TOGAF 8, OpenGroup]

  20. Objective/ DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION Planner Scope (What) (How) (Where) (Who) (When) (Why) (Contextual) Enterprise Abstractions Model (Conceptual) Owner Perspectives System Designer Technology Model Model (Logical) (Physical) Builder Detailed Model (Out of Context) Subcontractor Functioning Enterprise Exemples de deux cadre d’architecture Zachmanis a conceptual description of IS:

  21. abstractions DATA What FUNCTION How NETWORK Where PEOPLE Who MOTIVATION Why TIME When perspectives List of Things - Important to the Business List of Processes - the Business Performs List of Organizations - Important to the Business List of Events - Significant to the Business List of Business Goals and Strategies List of Locations - in which the Business Operates SCOPE Planner contextual Entity = Class of Business Thing Function = Class of Business Process Node = Major Business Location People = Class of People and Major Organizations Ends/Means=Major Business Goal/Critical Success Factor Time = Major Business Event e.g., Logistics Network e.g., Semantic Model e.g., Business Process Model e.g., Work Flow Model e.g., Master Schedule e.g., Business Plan ENTERPRISE MODEL Owner Process = Business Process I/O = Business Resources conceptual Entity = Business Entity Rel. = Business Relationship Node = Business Location Link = Business Linkage People = Organization Unit Work = Work Product Time = Business Event Cycle = Business Cycle End = Business Objective Means = Business Strategy e.g., Application Architecture e.g., Logical Data Model e.g., Distributed System Architecture e.g., Human Interface Architecture e.g., Processing Structure e.g., Business Rule Model SYSTEM MODEL Designer logical Time = System Event Cycle = Processing Cycle Entity = Data Entity Rel. = Data Relationship Process.= Application Function I/O = User Views Node = IS Function Link = Line Characteristics People = Role Work = Deliverable End = Structural Assertion Means =Action Assertion e.g., Physical Data Model e.g., System Design e.g., Technical Architecture e.g., Presentation Architecture e.g., Control Structure e.g., Rule Design TECHNOLOGY CONSTRAINED MODEL Builder Node = Hardware/System Software Link = Line Specifications physical Time = Execute Cycle = Component Cycle People = User Work = Screen/Device Format End = Condition Means = Action Entity = Tables/Segments/etc. Rel. = Key/Pointer/etc. Process= Computer Function I/O =Data Elements/Sets e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification e.g. Data Definition e.g. Program DETAILED REPRESEN- TATIONS Subcontractor out-of-context Node = Addresses Link = Protocols People = Identity Work = Job Time = Interrupt Cycle = Machine Cycle End = Sub-condition Means = Step Entity = Field Rel. = Address Process= Language Statement I/O = Control Block FUNCTIONING ENTERPRISE DATA Implementation FUNCTION Implementation NETWORK Implementation ORGANIZATION Implementation SCHEDULE Implementation STRATEGY Implementation John A. Zachman, Zachman International Zachman Framework

  22. Activities/ Tasks Operational Elements Operational View Identifies What Needs To Be Done And Who Does It Information Flow Standards Rules Data Flow Systems Systems View Technical Standards View Relates Systems and Characteristics to Operational Needs Prescribes Standards and Conventions X Y X Z Communications Conventions Y Y X DoDAF An Integrated Architecture with Three Views

  23. DODAF Products • DoDAF describes a set of 26 work products to ensure uniformity and standardization in the documentation and communication of architecture • The 26 DODAF views are designed to document the entire architecture, from requirements to implementation

  24. DODAF Products - Views • The list of products is refined into four views: • All Views (AV): is the overarching information describing the architecture plans, scope, and definitions • Operational View (OV): focuses on the behaviours and functions describing the enterprise mission aspects • System View (SV): describes the system and applications supporting the mission functions • Technical Standards View (TV): describes the policies, standards and constraints

  25. DODAF Products

  26. DODAF Products

  27. DODAF Products

  28. DODAF Products - Essential • The current DODAF version indicates a subset of work products that should be developed at a minimum (essential) AV-1: Overview and Summary Information AV-2: Integrated Dictionary OV-2: Operational Node Connectivity Description OV-3: Operational Information Exchange Matrix OV-5: Operational Activity Model SV-1: System Interface Description TV-1: Technical Standards Profile

  29. AV-1 & AV-2

  30. OV-2 – Operational Node Connectivity Description

  31. OV-3 – Operational Information Exchange Matrix • Table Headers Specified in Framework: • Name of Operational Needline Supported (from OV-2) • Name of Information Exchange • Nature of Transaction (Mission/Scenario, Language, Content, Size/Units, Media, Collaborative or One-Way?) • Purpose or Triggering Event • Information Source (ID of Producing Node Element, Owning Organization of Node, Name of Producing Activity, UJTL ID) • Information Destination (ID of Receiving Node Element, Owning Organization of Node, Name of Receiving Activity, UJTL ID) • Performance Requirements (Frequency, Timeliness, Throughput, Other) • Information Assurance Attributes (Classification Restrictions, Criticality/Priority, Integrity Checks Required, Assured Authorization to Send/Receive) • Threats (Physical, Electronic, Political/Economic) • Operational Environment (Weather, Terrain, Policy/Doctrine Constraints)

  32. OV-5 – Operational Activity Model

  33. SV-1 – System Interface Description

  34. TV-1 – Technical Standards Profile

  35. References DoDAF elements of this presentation are obtained from: DoD Architecture Framework Overview, Alessio Mosto, 2004 36

  36. Thank you for your attention!

  37. IS Architecture and IS Modelling

  38. What is Modelling? • Modelling is a way of simplifying the real world to enable us to solve problems. • We do it all the time and so easily that we don’t even notice we are doing it. • For example, a city map is a model of a city, a program is a model of how a task is achieved, and even a calendar is a model of a month. People use these models to solve problems, such as ‘What is the shortest route?’ ‘How long until my birthday?’

  39. Modelling and Architecture • Relation to Architecture? • Architecture is a definition of a specific information system via models. • How does this relate to an information system implementation? • The model guides the implementation. • The modelsdescribe parts or aspects of a system. A set of modelsthattogetherdefine the essentials of a system iscalled the architecture of the system.

  40. Conceptual Model It all begins with the framework Enterprise 1 defines Architecture Framework Stakeholder 1..* Mission 1..* 1..* scopes represents holds fulfills 1..* 1..* 1..* Architecture guides Requirement Information System implements 1..* documents documents System Description Architecture Description guides 1..* 1 1 1 specifies contains 1..* View 1..* describes 1..* 1..* comprise Artifacts Model 1..* 1..* The model documents the architecture

  41. Framework Components A logical structure for classifying and organizing the models of an enterprise Architecture Framework A formal definition of an enterprise system represents Architecture Contains the views that are used to describe the architecture documents Architecture Description 1 1 One or more abstractions e.g., Planner, Owner, Designer, Builder, Subcontractor specifies 1..* View The basic elements 1..* Representations of the Data, Function, Network, People, Time, and Motivation describes 1..* comprise Artifacts Model 1..* 1..*

  42. Conceptual Description of: Objective/ DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION Planner Scope (What) (How) (Where) (Who) (When) (Why) (Contextual) Enterprise Abstractions Model (Conceptual) Owner Perspectives System Designer Technology Model Model (Logical) (Physical) Builder Detailed Model (Out of Context) Subcontractor Functioning Enterprise

  43. Modelling Approaches DoDAF Architecture Framework: Guiding architecture CIMOSA, PERA Architecture Integration: integration of the different enterprise views. GRAI, IDEF3, BPMN ProcessModelling:behavioural aspects, Decisional System. IDEF0 Functional Modelling:high-level activities of process. . UML,IDEF4, IDEF1, IDEF1X • IT Oriented: information and application modelling.

  44. Enterprise Modeling Using IDEF0 IDEF stands for Integration Definition for Process Modelling, a methodology used to model businesses and their processes so they can be understood and improved it aims at: • Create description of enterprise for the purpose of gaining understanding, and of being able to answer questions about the enterprise. • Used to describe enterprise and its environment prior to, or in conjunction with, defining requirements. • Used to precisely define boundaries of system (i.e., what is in and out of scope for the project under consideration). • Model the enterprise from a particular "viewpoint", or perspective, so as to keep the activity focused on the goal of effort and on pertinent characteristics of interest in enterprise. • Create a description of the enterprise with a single subject, single purpose (exemplified by questions to be answered about the enterprise), and single viewpoint. • Note that, during Project “scoping” activity, the viewpoint is most likely that of looking at the enterprise from the standpoint of the client-server application to be deployed in the enterprise.

  45. IDEF0 Notations • Input objects (can be transformed or modified by the activity) like data or raw material. • Control inputs (procedures, rules or constraints) used to define how the activity will be executed. These inputs cannot be modified by the activity. • Output objects (data or materials) are the physical or informational objects produced or modified by the activity. • Mechanisms: represent the necessary means to support the execution of the activity (human resources, machines or applications).

More Related