Enterprise Architectuur

Slides:



Advertisements
Verwante presentaties
Use Case Modelling.
Advertisements

1 IT Management vs IT Governance in de Welzijnssector in Vlaanderen Studiedag: Efficiëntie en Effectiviteit 28/09/2012.
Stijn Hoppenbrouwers Software Engineering les 1 Algemene inleiding en Requirements Engineering.
de manier waarop een bedrijf onderweg wil zijn
Electronic Resource Management (ERM) Els Schaerlaekens Anet Gebruikersdag 15 juni 2011.
RUP Elaboration Analyse en Ontwerp Jef Bergsma.
Organisatie en sourcing van de DLWO Jacco Jasperse Informatie- en procesmanager Manager Dienst Informatievoorziening en Automatisering.
1 KM2.0 Bijeenkomst De Praktijk NUON: ‘Hoe gaan we om met vergrijzing?’
1 Demo of Praktijk Over de problematiek bij het ontwerpen van informatiesystemen Mark Dumay Afstudeervoordracht 15 oktober 2004.
Ronde (Sport & Spel) Quiz Night !
Keuzeondersteunend model voor inbouwpakketten bij herbestemmingsprojecten Eindcolloquium Wiebrand Bunt.
Gemeentelijke implementatie GFO Zaken
Klassieke AO Leseenheid1
Minicollege Architectuur
Marc de Roos Amersfoort 29 november 2007 ID-game een ervaring in samenspel.
1 Orientatie InformatieSystemen K.M.van Hee hgl. architectuur van informatiesystemen dir. Deloitte & Touche Bakkenist TU/e 2001.
Ontwerpen van Informatiesystemen met
Interaction diagrams: Sequence Diagram
1 Het probleem RO Milieu Landbouw SocZekerheid Etc. LerenWerkenWonenPensioenEtc. Overheids- organisatie Burger ??? Regelgeving per domein Vraag op levensmoment.
1 Voorwaarden hergebruik Modulair ontwerp Low coupling High cohesion.
Databases I (H. 1) Wiebren de Jonge Vrije Universiteit, Amsterdam Voorlopige versie 2003.
Informatie systemen en organisatie College 6 (hoofdstuk 5, 15 en 16 Ronald H. Ballou)
SPF SANTE PUBLIQUE, SECURITE DE LA CHAINE ALIMENTAIRE ET ENVIRONNEMENT 1 Journée d'étude e-HR: un rêve ou un cauchemar ? e-HR, Pistes voor de.
Geometrie en topologie Rob Kromwijk, 26 juli 2012.
College 4, jaar 2, Winter 2009 Inzoomen op Businessmodellen Aangepast programma Deeltijd Jaar 2 Docent Toine Nagel.
Schitterende Organisaties®
Bas Kruiswijk Amersfoort 12 september 2009 Service Oriented Architecture Deel 1: Basisconcepten.
Service Oriented Architecture
Service Oriented Architecture
Service Oriented Architecture
Minicollege Service Oriented Architecture
Bas Kruiswijk Amersfoort 2 november 2011 Softwarearchitectuur.
Bas Kruiswijk Amersfoort 20 september 2009 Service Oriented Architecture Deel 3b: Event Driven Architecture.
Implementatie van een service georiënteerde architectuur
Afstudeerpresentatie Richard Lekkerkerk,13 september 2011
Onsight Managed Security Services
Samen-bouwen … over paneelbouw en de rest!
Logistics: a driver for innovation Low costs High value Flexibility now and later Superior technology Timwood - T > No transport - I > No Inventory - M.
DigiDoc Een digitaal kantoor voor iedereen !. Ceci n’est pas du software?! 2.
Danny Greefhorst De relatie tussen Business- en Informatie Planning en enterprise-architectuur Danny Greefhorst
© Copyright Dragon1 - Alle rechten voorbehouden.
1 Jeroen de Vries Topologie. 2  Historische basis  Belangrijkste concepten  Topologie in de praktijk Inhoud:
Strategische Buurt Ontwikkeling
How Architecture helps to reduce costs November 2011.
ArchiValue: de APG-Case
Oktober 2004 Core Course Information Management dag 2 Agenda.
Cegeka & TenForce Ronde tafel 17/06/2014 Doelstellingenmanagement VO.
APP Platform Rivium, 5 maart 2013 Rik Vietsch.
Agenda Inleiding en Lagerhuis: Proces management en proces keten optimalisatie gaat ons helpen inzicht te krijgen in de impact van toekomstige veranderingen.
Introductie INFBIT01DT Schooljaar
Minor Project- en Programmamanagement
Relatie tussen Architectuur en Beheer. Inleiding  Architectuur:  Inzicht in samenhang en beheersing van verandering;  Actuele problematiek  Architectuur.
1 KPN Mobiel – Introductie Repository Object Browser & Designer 10 Designer 10g & Repository Object Browser Maandag 28 februari 2005 Lucas Jellema (AMIS)
Start Inhoud introductie BiSL Informatiesysteem, gegeven Informatiebeleid Positionering: Beheer informatiesystemen BiSL als informatiearchitectuur.
Certificering van assetmanagement
2013ASL BiSL Foundation Professionaliseren met BiSL ®
Gebruikers- ondersteuning Require- ments man. Educatie Monitoring Data- beheer Management- informatie Operationeel support Tactisch support Strategisch.
ArchiMate voor kennismodellen van NORA en haar dochters Marc Lankhorst 16 oktober 2013.
The Research Process: the first steps to start your reseach project. Graduation Preparation
TOGAF Albert Gjaltema / Tech. Consultant II 11 maart 2008 getronicspinkroccade.nl.
Van BiSL naar BiSL Next Lucille van der Hagen
Key Process Indicator Sonja de Bruin
Innovatie met IBM Cloud Orchestrator.
Bron: IT Serivce Management, Best Practices – deel
Strategisch support Management support Strategie Tactisch support
Bron: IT Serivce Management, Best Practices – deel
Bron: IT Serivce Management, Best Practices – deel
Stap drie bij projecten
Strategisch support Management support Strategie Tactisch support
Transcript van de presentatie:

Enterprise Architectuur

Enterprisearchitectuur Software- architectuur Service- georiënteerde architectuur Conceptuele basis Organisatiebrede scope Gericht op strategie en communicatie Individuele systeemscope Gericht op ontwerp, realisaties en specificatie

Enterprisearchitectuur Waarom is het zo belangrijk? (1) Veel ICT-projecten mislukken Het merendeel (50% - 70%) van technologie-implementaties mislukt1 75% van alle pogingen om automatisering op de werkvloer te introduceren, is mislukt1 Het gaat om meer dan ICT alleen Introductie van technologie vereist (belangrijke) veranderingen buiten het domein van de technologie, maar de introductie van technologie brengt die niet ‘automatisch’ teweeg2 Door alleen naar technologie te kijken krijg je die technologie niet ‘werkend’2 Meer financiële sturing helpt (meestal) niet Geen correlatie tussen ICT-investering en business success3 1. Rechting, E. – Systems Architecting of Organizations (2000) 2. Scott Morton, M.S. – The Corporation of the 1990s (1991) 3. Pisello, T., Strassmann, P. – IT Value Chain Management – Maximizing ROI from IT Investments Bron: dr.ir. J.A.P. Hoogervorst

Enterprisearchitectuur Waarom is het zo belangrijk? (2) Een integrale architectuurbenadering helpt wel! Succes van ICT-implementaties kan worden verhoogd door bedrijfs- organisatie, informatievoorzienings- en technische aspecten in samenhang te ontwerpen Op organisatiebrede schaal ‘Operationaliseer’ business-IT alignment (dus waar draagt ICT bij, en hoe?) Dat is enterprisearchitectuur

Enterprisearchitectuur Wat is het? Enterprisearchitectuur geeft inzicht in en een geïntegreerd overzicht van Bedrijfsprocessen (Informatievoorzienings)functionaliteiten Informatiesystemen/applicaties Technische infrastructuur in samenhang! Omvat ook de relaties met de omgeving Naast modellen omvat een enterprisearchitectuur ook de principes en uitgangspunten die het ontwerpen en de ontwikkeling door de tijd sturen Definieert het gemeenschappelijk ICT-platform, zoals middleware etc. Rechtvaardigt langetermijninvesteringen in ICT (bijvoorbeeld voor het gemeenschappelijk ICT-platform) Bewerkstelligt de gewenste flexibiliteit en integratie Is het belangrijkste, inhoudelijke communicatiemiddel in de ICT

Definitie van ICT-architectuur IEEE 1471 The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and development Dus: Fundamentele inrichting van een complex systeem Opbouw in componenten Hun onderlinge relatie én de relatie met de omgeving Principes t.a.v. ontwerp en ontwikkeling in de tijd IEEE 1471: Recommended Practice for Architectural Descriptions of Software-intensive Systems IEEE: Institute of Electrical and Electronics Engineers a non-profit, technical professional association a leading authority in technical areas ranging from computer engineering, biomedical technology and telecommunications, to electric power, aerospace and consumer electronics

Centraal begrip in definitie Views and viewpoints Dé architectuur van een complex systeem kan niet worden beschreven op een eendimensionale manier Geen enkel gezichtspunt biedt uitzicht op de gehele architectuur Je moet verschillende inzichten bieden aan de verschillende belanghebbenden (concerns of stakeholders) Vandaar de begrippen Viewpoint (gezichtspunt) Een manier van kijken, gericht op het belang van een bepaalde stakeholder View Wat je ziet, als je vanuit een bepaald gezichtspunt (viewpoint) kijkt

Views and viewpoints Stakeholders Beslisser View pont View View View Bouwer Gebruiker Architectuur Stakeholders

Architectuurraamwerken Gebaseerd op het concept van views en viewpoints Keuze voor te onderscheiden viewpoints, gerelateerd aan belangen van stakeholders Architectuurraamwerken Definiëren een set (deel)architecturen Benoemen de deelaspecten die per architectuur worden belicht En op welke stakeholders ze zijn gericht Definiëren (soms) de schematechniek e.d. Definiëren (soms) het proces van totstandkoming Definiëren (soms) een verzameling tools die kunnen worden gebruikt

Deelarchitecturen in een enterprise architectuur Business Architecture Relationship Information Architecture Relationship Application Architecture Relationship Technical Architecture

Deelarchitecturen in een enterprise architectuur Business Architecture Proposition and market Products and services Business processes Organization and governance Relationship Information Architecture Information-processing functionality Functional areas / objects Datamodel and data dictionary Rules – Standards – Principles - Guidelines Models Relationship Application Architecture Applications and interfaces Common infrastructural facilities Design principles and guidelines Data structure / databases Relationship Technical Architecture Hardware Network Physical locations Technical standards

Voorbeelden van architectuurraamwerken Theoretische raamwerken Zachman Architecture Framework (het ‘oerraamwerk’) TOGAF (The Open Group Architecture Framework) DYA (Sogeti) Praktische toepassingen Voorbeeld Centrum voor Werk en Inkomen Twynstra Gudde

Zachman raamwerk A framework for information systems architecture Gepubliceerd in IBM Systems Journal, 1987 Gebaseerd op hoe traditionele architectuur tot stand komt Toepassing van views en viewpoints ‘avant la lettre’ Een generieke set van architectuurbeschrijving Een verschillende architectuurbeschrijving voor elke stakeholder Daarnaast onderscheid in de verschillende aspecten Verschillende architectuurbeschrijvingen die verschillen ‘by nature’, dus niet alleen in de mate van detaillering

Some quotes... “The increased scope of design and levels of complexity of information systems implementations are forcing the use of some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the components of the system.” “Since the technology permits ‘distributing’ large amounts of computing facilities in small packages to remote locations, some kind of structure (or architecture) is imperative because decentralization without structure is chaos.” “What, in fact, is information systems architecture?” ... the words’ information systems architecture’ are already losing their meaning. ”

Gebaseerd op het bouwen van een huis ‘onder architectuur’ Representation Nature / purpose Bubble charts Basic concepts for building Gross sizing, shape, spatial relationships Architect/owner mutual understanding Initiate project Architect’s drawing Final building as seen by the owner Floor plans, cutaways, pictures Architect/owner agreement on building Establish contract Architect’s plans Final building as seen by the designer Translation of an owner’s view of a product Detailed drawings – 16 categories Basis for negotiation with general contractor Contractor’s plans Final building as seen by the builder Architect’s plans constrained by laws of nature and available technology “How to build it” description Directs construction activities Shop plans Subcontracter’s design of a part/section Detailed stand-alone model Specification of what is to be constructed Pattern Building Physical building

Observations Three fundamental architectural representations, one for each “player in the game” Owner: A product that will serve some purpose Designer: A design of a physical product Builder: A producable product Preliminary actions: Establish the ball park where all of the ensuing architectural activities take place Subsequent actions: Detailed, out-of-context representations These architectural representations differ in nature, independent of the level of detail

Zachman raamwerk De views van de stakeholders Reikwijdte (Scope - Ballpark view) Definitie van het speelveld: de organisatie en zijn doelen – de context waarin de informatiebehoefte geplaats moet worden Bedrijfsmodel (Model of the business - Owner’s view) Modelering en definitie van de organisatie in termen van structuur, functie en organisatie Informatiesysteemmodel (Model of the information system - Architect’s view) Modelering en beschrijving van informatiebehoefte in formelere informatiesysteemtermen Technologiemodel (Technology model - Designer’s view) Vertaling van informatiebehoefte in concrete, technologische oplossingen Gedetailleerd ontwerp (Detailed representations - Builder’s view) Gedetailleerde specificaties en programmacode Werkend, gerealiseerd systeem (Functioning system)

Zachman raamwerk De aspecten Data (What) Function (How) Network (Where) People (Who) Time (When) Motivation (Why)

TOGAF The Open Group1 Architecture Framework Architecture Development Method (ADM) An iterative sequence of steps to develop an enterprise-wide architecture The Enterprise Continuum During application of the ADM, assets are created or drawn from existing assets, used, modified and returned to the virtual repository that is the Enterprise Continuum Resource Base During application of the ADM, processes, templates, checklists and other items from the Resource Base are deployed as methods to develop the architecture 1) The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow™ will enable access to integrated information, within and among enterprises, based on open standards and global interoperability.

TOGAF De deelarchitecturen Business (or business process) architecture Defining the business strategy, governance, organization, and key business processes of the organization Applications architecture Providing a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization Data architecture Describing the structure of an organization's logical and physical data assets and the associated data management resources Technology architecture Describing the software infrastructure intended to support the deployment of core, mission-critical applications

TOGAF ADM: Architecture Development Methodology

DYA Dynamische architectuur - het DYA-model Visie van Sogeti op het omgaan met architectuur DYA is dus in eerste plaats een methode

DYA Het DYA-architectuurraamwerk Objecten Abstractieniveaus

DYA De 10 principes Architectuur is strategisch als ICT dat is Architectuur moet snelheid dienen Communicatie tussen business- en ICT-management staat centraal Het ontwikkelen van architectuur wordt gestuurd door businessdoelen Het architectuurniveau wordt verhoogd door mee te liften op de energiegolven van belangrijke veranderingstrajecten Architectuur wordt ontwikkeld volgens het ‘just enough’ en ‘just in time’- principe Een denk-/werkmodel ondersteunt het werken onder architectuur Verbanden moeten inzichtelijk zijn Er worden meerdere ontwikkelscenario's onderscheiden De architectuurprincipes en -processen moeten ingebed zijn in de organisatie

NORA Architectuurmatrix Kapstok van (deel)architecturen om best-practices aan op te hangen

Voorbeeld: Architectuurraamwerk CWI Bedrijf Informatie Applicatie Technische WAAROM Rapport business- architectuur Contextuele technische architectuur Contextuele applicatie- architectuur Contextueel SUWI-wet Gegevens- gebieden architectuur WAT BP2002 Basis bedrijfs- model Conceptuele applicatie- architectuur Conceptuele technische architectuur Conceptueel Architectuur van de bedrijfs ondersteuning HOE RWP (architectuur) Proces- model Logische applicatie- architectuur Informatie- systeem architectuur Logische technische architectuur Logisch WAARMEE CWI- werkprocessen Proces- simulatie Fysiek Infrastructuur

Voorbeeld: Architectuurraamwerk TG 4 deelarchitecturen Business, Informatie, Applicatie, Techniek Onderlinge samenhang Aplicaties ondersteunen bedrijfsprocessen Bedrijfsprocessen worden ondersteund door informatievoorziening Informatievoorziening wordt gerealiseerd door applicaties Applicaties maken gebruik van technische infrastructuur 4 typen vraagstukken Integratievraagstuk Functioneel vraagstuk Toekomstvisie Migratievraagstuk

Voorbeelden van enterprisearchitecturen Uit de ervaringen van Twynstra Gudde met enterprise- architectuur, verzameld in het boek ‘Architectuur in beeld’

Voorbeeld van een businessarchitectuur

Financiële administratie Specifieke toepassingen Kantoor automa- tisering Kennis bank Medewerkers Relaties Objecten Projecten Kerngegevens Scenarioplanning Eindwaarde variant 2 Eindwaarde variant 3 Risicocalculatie Eindwaarde variant 1 Rekenmodel Planning & control Financiële administratie Specifieke toepassingen beheer Presentatie & Communicatielaag Internet Extranet Actuele documenten Post - registratie Document- flow Archief Intranet e-mail Gebouwen- exploitatie Administratie Plan- Grond- Erfpacht administratie Onroerend goed Uren Personeels Relatie Kartografie Representa- vormen object Project planning Voorbeeld van een informatie- architectuur (1)

Voorbeeld van een informatie- architectuur (2)

Voorbeeld van een informatie- architectuur (3)

Relatie tussen business- en informatiearchitectuur 289GROT1f Presentatie, kantoorautomatisering en communicatie Object/medewerker/relaties Projectadministratie Erfpacht adm. Grondexploitatie Onr. goed adm. Gewenste ondersteunende functies: Financiële administratie Planning en control PKL/RPE/271299 5.1 Uitvoeren economische projecten 5.2 ruimtelijke 6.1 Monitoren afgeronde ruimtelijke en 6.2 Beheren erfpacht- contracten 6.3 onroerend goed *2 Kansen ter verbetering van het woon/werk-, verblijf- en leefklimaat van de stad Rotterdam Tevreden gebruikers van de stad Rotterdam Goedgekeurde (definitief) Gerealiseerde 3.1 Vertalen programma’s naar projecten (i.s.m. partners) 3.2 Toetsen haalbaarheid: - financieel - politiek - mensen - middelen - maatschappelijk draagvlak - etc. 3.3 Voorstel ter politieke besluitvorming uitwerken 3.4 Go/No Go-besluit nemen 4.1 Fasering aanbrengen (i.s.m. partners) 4.2 Uitwerken project- beheersing: - tijd - geld - kwaliteit - informatie - organisatie 4.3 Voorstel ter politieke besluitvorming uitwerken 4.4 Go/No Go-besluit nemen 4.5 Partners en belang- hebbenden informeren over genomen besluit 5.2.1 Verwerven 5.2.2 Ontwikkelen en planbegeleiding 5.2.3 Tijdelijk beheren 5.2.4 Markt bewerken 5.2.5 Uitgeven/verhuren 5.2.6 Evalueren 5.2.7 Overdragen 5.1.1 Partners aanschakelen en binden 5.1.2 Draagvlak creëren 5.1.3 Verwerven & beheren middelen (geld, inspanning, ruimte, etc.) voor uitvoering 5.1.4 Markt bewerken 5.1.5 Uitvoeren geplande activiteiten 5.1.5 Evalueren 5.1.6 Overdragen 6.1.1 Nazorg verlenen 6.1.2 Account- management uitvoeren 6.2.1 Registreren 6.2.2 Factureren 6.2.3 Indexeren 6.2.4 Verwerken mutaties: - heroverwegingen - splitsing - wijzigen bestemmingen 6.3.1 Registreren 6.3.2 Factureren 6.2.4 Verwerken mutaties 1.1 Signaleren kansen (antennefunctie) 1.2 Vertalen kansen naar beleid (i.s.m. partners) 1.3 Toetsen aan gemeentelijke kaders (inclusief Rijks- en provinciale overheid) 1.3 Voorstel ter politieke besluitvorming (m.n. gemeenteraad) 1.4 Go/No Go 2.1 Vertalen beleid naar programma’s (i.s.m. partners) 2.2 Toetsen haalbaarheid: - mensen (capaciteit) - middelen (bijvoorbeeld grond gebouwen) 2.3 Uitwerken programma-beheersing: - tempo - haalbaarheid - efficiency - flexibiliteit - doelgerichtheid 2.4 Voorstel ter politieke besluitvorming uitwerken 2.5 Go/No Go-besluit nemen (kaders) programma’s OBR beleid *1 Hoeft niet per definitie een gevolg te zijn van projecten *2 Bedrijfsruimte Huurcontracten Visrecht Pachten etc. 6. Beheren en monitoren resultaat *1 2. Ontwikkelen 5. 4. Voorbereiden 3. Onderzoeken 1. Beleids- ontwikkeling Stedelijke op het gebied van ruimte en economie

Relatie tussen business- en applicatiearchitectuur

Specifieke toepassingen Financiële administratie Kennis bank Kerngegevens Scenarioplanning Eindwaarde variant 2 Eindwaarde variant 3 Risicocalculatie Eindwaarde variant 1 Rekenmodel Specifieke toepassingen Presentatie & Communicatielaag Actuele documenten Archief Plan- exploitatie Administratie Representa- vormen object Personeels administratie Onroerend goed Erfpacht Gebouwen- Grond- Objecten beheer Project planning Uren Relatie Kartografie Medewerkers Relaties Projecten Kantoor automa- tisering Planning & control Financiële administratie Document- flow Post - registratie Internet e-mail Intranet Extranet Relatie tussen informatie- en applicatie- architectuur

Applicatiearchitectuur

Bas Kruiswijk bkr@tg.nl www.twynstragudde.nl Alle intellectuele eigendomsrechten met betrekking tot deze presentatie berusten bij Twynstra Gudde. Niets uit deze presentatie mag worden verveelvoudigd of openbaar gemaakt zonder schriftelijke toestemming van Twynstra Gudde.