De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

Bas Kruiswijk Amersfoort 21 april 2009 Minicollege Architectuur.

Verwante presentaties


Presentatie over: "Bas Kruiswijk Amersfoort 21 april 2009 Minicollege Architectuur."— Transcript van de presentatie:

1 Bas Kruiswijk Amersfoort 21 april 2009 Minicollege Architectuur

2 © Twynstra Gudde Minicollege Architectuur 2 Overzicht Deel 1: Introductie architectuur –Introductie architectuur –Begripsbepaling: wat is architectuur en waarom is het zo belangrijk? –Verschillende soorten architectuur –Twee aanvliegroutes naar SOA –Enterprisearchitectuur –Softwarearchitectuur –De architect

3 © Twynstra Gudde Minicollege Architectuur 3 Wat is architectuur? Visualiseren en structureren van complexe systemen De belangrijkste elementen van een complex systeem Samenhang Flexibiliteit Toekomstvisie Principes, uitgangspunten, spelregels Kwaliteit Beschrijving van wat fundamenteel is Relatie met de omgeving “Grand design” Beschrijvend én voorschrijvend

4 © Twynstra Gudde Minicollege Architectuur 4 Wat is architectuur? Een paar quotes –A way to think about, visualize, structure and shape complex systems (Van Waes) –The most important elements of a (complex) system, and the relationships between them (Van Waes) –Manageable and realizable description of what is fundamental in a certain area of interest (Ligthart & Vis) –Overall structure of a complex system, embodied in its components, their relationships to each other and to the environment, and principles guiding its design and development over time

5 © Twynstra Gudde Minicollege Architectuur 5 Waarom is architectuur zo belangrijk? –Communicatie tussen alle belanghebbenden –Het biedt inzicht en overzicht –Belicht verschillende aspecten in samenhang –Helderheid in principes en uitgangspunten –Scheppen van kaders en richtlijnen –Beperking van ontwerpvrijheid –Sturend voor ICT-projecten en technologiekeuzes –Basis voor flexibiliteit en integratie –Definieert gemeenschappelijke basis om systemen te integreren –Blauwdruk voor de ontwikkeling van toekomstige systemen –Beheersing van ICT-uitgaven –Alleen doen wat past in de architectuur –Waarborgen van toekomstvastheid van investeringen

6 © Twynstra Gudde Minicollege Architectuur 6 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 systeemn –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

7 © Twynstra Gudde Minicollege Architectuur 7 ‘Dé’ architectuur bestaat niet –Verschillende reikwijdte –Verschillend niveau van detaillering –Verschillende aspecten van een complex systeem

8 © Twynstra Gudde Minicollege Architectuur 8 De reikwijdte van een ICT-architectuur Schaalverschillen Source: Gartner Group

9 © Twynstra Gudde Minicollege Architectuur 9 Verschillende niveaus van detaillering –Voor het overbrengen van een boodschap heb je niet veel detail nodig –Voor verschillende belanghebben zijn verschillende detailleringsniveaus vereist –Uiteindelijk moet een architectuur worden vertaald naar een ontwerp, en dan is voldoende detaillering wel belangrijk

10 © Twynstra Gudde Minicollege Architectuur 10 Verschillende aspecten –De componenten waaruit de architectuur is opgebouwd –Processen, producten en diensten, functionaliteiten, gegevens, applicaties, infrastructuur –De deelaspecten die inzichtelijk worden gemaakt –Structuur, gedrag, locatie, verantwoordelijkheid, doelstellingen –Of andere specifieke invalshoeken –Beveiliging, kosten, kwaliteit, strategisch belang

11 © Twynstra Gudde Minicollege Architectuur 11 We onderscheiden drie typen architectuur –Voor het overzicht maken we onderscheid in drie ‘typen’ architectuur ReikwijdteFocusDoel EnterprisearchitectuurBedrijfStrategieCommunicatie Softwarearchitectuur (Verzameling van) systemen Ontwerp en realisatieSpecificatie Servicegeoriënteerde architectuur Conceptuele basis Combinatie van organisatorische en technische aspecten Reikwijdte zowel organisatiebreed als individuele systemen

12 © Twynstra Gudde Minicollege Architectuur 12 Drie ‘typen’ architectuur Enterprise- architectuur Software- architectuur Service- georiënteerde architectuur Individuele systeemscope Gericht op ontwerp, realisaties en specificatie Organisatiebrede scope Gericht op strategie en communicatie Conceptuele basis

13 © Twynstra Gudde Minicollege Architectuur 13 Overzicht Deel 2: Enterprisearchitectuur –Introductie architectuur –Enterprisearchitectuur –Waarom is enterprisearchitectuur zo belangrijk? –Centrale concepten: views, viewpoints, stakeholders –Het ‘oerraamwerk’ voor enterprisearchitectuur: Zachman –Andere architectuurraamwerken –Softwarearchitectuur –De architect

14 © Twynstra Gudde Minicollege Architectuur 14 Enterprisearchitectuur Enterprise- architectuur Software- architectuur Service- georiënteerde architectuur Individuele systeemscope Gericht op ontwerp, realisaties en specificatie Organisatiebrede scope Gericht op strategie en communicatie Conceptuele basis

15 © Twynstra Gudde Minicollege Architectuur 15 Enterprisearchitectuur Waarom is het zo belangrijk? (1) –Veel ICT-projecten mislukken –Het merendeel (50% - 70%) van technologie-implementaties mislukt 1 –75% van alle pogingen om automatisering op de werkvloer te introduceren, is mislukt 1 –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’ teweeg 2 –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 success 3 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

16 © Twynstra Gudde Minicollege Architectuur 16 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

17 © Twynstra Gudde Minicollege Architectuur 17 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

18 © Twynstra Gudde Minicollege Architectuur 18 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

19 © Twynstra Gudde Minicollege Architectuur 19 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

20 © Twynstra Gudde Minicollege Architectuur 20 Het modelleren van de enterprisearchitectuur Enterprise (domain) Architecture description (representation) Architecture (conception) stake holder

21 © Twynstra Gudde Minicollege Architectuur 21 Views and viewpoints View Architecture Viewpoint Stakeholder

22 © Twynstra Gudde Minicollege Architectuur 22 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

23 © Twynstra Gudde Minicollege Architectuur 23 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

24 © Twynstra Gudde Minicollege Architectuur 24 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

25 © Twynstra Gudde Minicollege Architectuur 25 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. ”

26 © Twynstra Gudde Minicollege Architectuur 26 Gebaseerd op het bouwen van een huis ‘onder architectuur’ RepresentationNature / 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 BuildingPhysical building

27 © Twynstra Gudde Minicollege Architectuur 27 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

28 © Twynstra Gudde Minicollege Architectuur 28 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)

29 © Twynstra Gudde Minicollege Architectuur 29 Zachman raamwerk De aspecten –Data (What) –Function (How) –Network (Where) –People (Who) –Time (When) –Motivation (Why)

30 © Twynstra Gudde Minicollege Architectuur 30

31 © Twynstra Gudde Minicollege Architectuur 31

32 © Twynstra Gudde Minicollege Architectuur 32

33 © Twynstra Gudde Minicollege Architectuur 33 TOGAF The Open Group 1 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 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. 1)

34 © Twynstra Gudde Minicollege Architectuur 34 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

35 © Twynstra Gudde Minicollege Architectuur 35 TOGAF ADM: Architecture Development Methodology

36 © Twynstra Gudde Minicollege Architectuur 36 DYA Dynamische architectuur - het DYA-model –Visie van Sogeti op het omgaan met architectuur –DYA is dus in eerste plaats een methode

37 © Twynstra Gudde Minicollege Architectuur 37 DYA Het DYA-architectuurraamwerk Objecten Abstractieniveaus

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

39 © Twynstra Gudde Minicollege Architectuur 39 NORA Architectuurmatrix –Kapstok van (deel)architecturen om best-practices aan op te hangen

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

41 © Twynstra Gudde Minicollege Architectuur 41 Voorbeeld: Architectuurraamwerk TG –4 deelarchitecturen –Business, Informatie, Applicatie, Techniek –Onderlinge samenhang 1.Aplicaties ondersteunen bedrijfsprocessen 2.Bedrijfsprocessen worden ondersteund door informatievoorziening 3.Informatievoorziening wordt gerealiseerd door applicaties 4.Applicaties maken gebruik van technische infrastructuur –4 typen vraagstukken –Integratievraagstuk –Functioneel vraagstuk –Toekomstvisie –Migratievraagstuk

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

43 © Twynstra Gudde Minicollege Architectuur 43 Voorbeeld van een businessarchitectuur

44 © Twynstra Gudde Minicollege Architectuur 44 Kantoor automa- tisering Kennis bank MedewerkersRelaties ObjectenProjecten Kerngegevens Scenarioplanning Eindwaarde variant 2 Eindwaarde variant 3 Risicocalculatie Eindwaarde variant 1 Rekenmodel Planning & control Financiële administratie Specifieke toepassingen Objecten beheer Presentatie & Communicatielaag InternetExtranet Actuele documenten Post - registratie Document- flow Archief Intranet Gebouwen- exploitatie Administratie Plan- exploitatie Administratie Grond- exploitatie Administratie Erfpacht administratie Onroerend goed administratie Uren administratie Personeels administratie Relatie beheer Kartografie Representa- vormen object Project administratie Project planning Voorbeeld van een informatie- architectuur (1)

45 © Twynstra Gudde Minicollege Architectuur 45 Voorbeeld van een informatie- architectuur (2)

46 © Twynstra Gudde Minicollege Architectuur 46 Voorbeeld van een informatie- architectuur (3)

47 © Twynstra Gudde Minicollege Architectuur 47 Relatie tussen business- en informatiearchitectuur 289GROT1f Presentatie, kantoorautomatisering en communicatie Object/medewerker/relaties ProjectadministratieErfpacht adm. GrondexploitatieOnr. goed adm. Gewenste ondersteunende functies: Financiële administratiePlanning en control PKL/RPE/ Uitvoeren economische projecten 5.1 Uitvoeren economische projecten 5.2 Uitvoeren ruimtelijke projecten 5.2 Uitvoeren ruimtelijke projecten 6.1 Monitoren afgeronde ruimtelijke en economische projecten 6.1 Monitoren afgeronde ruimtelijke en economische projecten 6.2 Beheren erfpacht- contracten 6.2 Beheren erfpacht- contracten 6.3 Beheren onroerend goed * Beheren onroerend goed * 2 Kansen ter verbetering van het woon/werk-, verblijf- en leefklimaat van de stad Rotterdam Tevreden gebruikers van de stad Rotterdam Goedgekeurde projecten (definitief) Gerealiseerde projecten 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 Verwerven Ontwikkelen en planbegeleiding Tijdelijk beheren Markt bewerken Uitgeven/verhuren Evalueren Overdragen Partners aanschakelen en binden Draagvlak creëren Verwerven & beheren middelen (geld, inspanning, ruimte, etc.) voor uitvoering Markt bewerken Uitvoeren geplande activiteiten Evalueren Overdragen Nazorg verlenen Account- management uitvoeren Registreren Factureren Indexeren Verwerken mutaties: - heroverwegingen - splitsing - wijzigen bestemmingen - etc Registreren Factureren Indexeren Verwerken mutaties 1.1Signaleren kansen (antennefunctie) 1.2Vertalen kansen naar beleid (i.s.m. partners) 1.3Toetsen aan gemeentelijke kaders (inclusief Rijks- en provinciale overheid) 1.3Voorstel ter politieke besluitvorming (m.n. gemeenteraad) 1.4Go/No Go 2.1Vertalen beleid naar programma’s (i.s.m. partners) 2.2Toetsen haalbaarheid: - financieel - politiek - mensen (capaciteit) - middelen (bijvoorbeeld grond gebouwen) - maatschappelijk draagvlak - etc. 2.3Uitwerken programma- beheersing: - tempo - haalbaarheid - efficiency - flexibiliteit - doelgerichtheid 2.4Voorstel ter politieke besluitvorming uitwerken 2.5Go/No Go-besluit nemen Goedgekeurde projecten (kaders) Goedgekeurde 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 6. Beheren en monitoren resultaat *1 2. Ontwikkelen programma’s 2. Ontwikkelen programma’s 5. Uitvoeren projecten 5. Uitvoeren projecten 4. Voorbereiden projecten 4. Voorbereiden projecten 3. Onderzoeken projecten 3. Onderzoeken projecten 1. Beleids- ontwikkeling 1. Beleids- ontwikkeling Stedelijke ontwikkeling op het gebied van ruimte en economie Stedelijke ontwikkeling op het gebied van ruimte en economie

48 © Twynstra Gudde Minicollege Architectuur 48 Relatie tussen business- en applicatiearchitectuur

49 © Twynstra Gudde Minicollege Architectuur 49 Relatie tussen informatie- en applicatie- architectuur

50 © Twynstra Gudde Minicollege Architectuur 50 Applicatiearchitectuur

51 © Twynstra Gudde Minicollege Architectuur 51 Overzicht Deel 3: Softwarearchitectuur –Introductie architectuur –Enterprisearchitectuur –Softwarearchitectuur –Waarom is softwarearchitectuur zo belangrijk? –Software engineering als de basis –Van modules naar objecten, componenten en services –Generieke voorzieningen voor integratie –Softwarearchitecturen: van monolieten naar client/server, drie- en meerlaagse architecturen –Andere softwarearchitectuurbenaderingen: UML, Patterns en Model Driven Architecture –De architect

52 © Twynstra Gudde Minicollege Architectuur 52 Softwarearchitectuur Enterprise- architectuur Software- architectuur Service- georiënteerde architectuur Individuele systeemscope Gericht op ontwerp, realisaties en specificatie Organisatiebrede scope Gericht op strategie en communicatie Conceptuele basis

53 © Twynstra Gudde Minicollege Architectuur 53 Softwarearchitectuur begint met software engineering –Software engineering is in de informatica het vakgebied dat zich bezighoudt met (de totstandkoming van) ‘goede’ software (qua product en proces) –Wat is ‘goede’ software eigenlijk? –Correct, betrouwbaar, robuust –Performance –Gebruikersvriendelijk –Verifieerbaar –Onderhoudbaar –Herbruikbaar –Portable –Begrijpelijk –Interoperabiliteit –Productiviteit

54 © Twynstra Gudde Minicollege Architectuur 54 Software engineering principes Top 3 (?) –Separation of concerns –Vanwege de inherente complexiteit van softwaresystemen zorgen dat verschillende aspecten gescheiden kunnen worden aangepakt (bijvoorbeeld functionaliteit en performance) –Modulariteit –Reduceer de complexiteit door het totaal op te delen in kleinere, relatief zelfstandige delen die zelfstandig kunnen worden ontworpen, ontwikkeld en geïmplementeerd –Modules hebben een hoge interne cohesie en een lage externe koppelingsgraad –Anticiperen op veranderingen –In het ontwerp, de ontwikkeling en de implementatie van software rekening houden met waarschijnlijke veranderingen

55 © Twynstra Gudde Minicollege Architectuur 55 Modules en objectoriëntatie –Modules –Groepering van functionaliteit en gegevensverzamelingen –Hoger abstractieniveau dan functies, eenheid van (overigens beperkt) hergebruik –Min of meer zelfstandig realiseerbaar en implementeerbaar –Objectoriëntatie –Eigenlijk een programmeerconcept –Objecten zijn een directere representatie van objecten in de reële wereld –Objecten combineren structuur (statische aspect) en gedrag (dynamische aspect) in een ontwerp- en programmeerconcept –Scheiding van interface en implementatie

56 © Twynstra Gudde Minicollege Architectuur 56 Objectoriëntatie Scheiding van interface en implementatie implementatie van het object De van buitenaf zichtbare beschrijving van de functie van het object en hoe deze te gebruiken De van buitenaf niet-zichtbare interne realisatie van het object middels werkende software interface

57 © Twynstra Gudde Minicollege Architectuur 57 Componenten –Gebaseerd op de concepten van objectoriëntatie –Gericht op het samenstellen van applicaties uit componenten: component based developement –Componenten hebben vergeleken met objecten enkele extra eigenschappen –Distribueerbaar (platformonafhankelijk, koppelbaar aan middleware) –Op run-time te (de)activeren (disconnectable) –Bruikbaar (herkenbaar, inspecteerbaar, configureerbaar) door ontwikkeltools om applicaties te assembleren

58 © Twynstra Gudde Minicollege Architectuur 58 Services –In technische zin een doorontwikkeling van object- en componenttechnologie –Brede adoptie van (internet)standaarden voor webservices –Platformonafhankelijk –Basisconcept van (bijna) alle ontwikkelplatforms –Diensten aan gebruikers staan centraal –Niet (alleen) de softwareconstructie staat centraal, maar de dienst die geleverd wordt –Niet (alleen) relevant voor ontwikkelaars, maar ook voor gebruikers / organisaties –Applicaties worden minder relevant – het gaat om services

59 © Twynstra Gudde Minicollege Architectuur 59 Service Dienstinhoud (implementatie) Dienstaanvraag (request) Dienstbeschrijving (interface) Dienstresultaat (respons) De van buitenaf zichtbare beschrijving van dienst De interne realisatie van de dienst middels werkende software request respons

60 © Twynstra Gudde Minicollege Architectuur 60 Programmeertalen en modulariteit 1 e generatie machine 2 e generatie assembler 3 e generatie gestructureerd 4 e generatie abstract 5 e generatie functioneel ModulairObject- georiënteerd Component- gebaseerd Service- georiënteerd C++ Java Visual Basic C# COBOL C Oracle forms SQL LISP Prolog J2EE.Net

61 © Twynstra Gudde Minicollege Architectuur 61 Monolitische en modulaire softwarearchitectuur

62 © Twynstra Gudde Minicollege Architectuur 62 Client/Server architectuur Client Server Client Centraal Decentraal

63 © Twynstra Gudde Minicollege Architectuur 63 Gedistribueerde drie- en meerlaagse softwarearchitectuur Presentatie Businesslogica Data Presentatie Processervices Data Samengestelde services Basisservices

64 © Twynstra Gudde Minicollege Architectuur 64 Integratie van applicatie ontwikkelingen in de tijd geplaatst (1) Applicatie 1 Applicatie 2 Applicatie 3 Applicatie 4 Client Server Client Server Client Server Generieke faciliteiten Doorgaans bulkuitwisseling Corporate databases 1:1 Interfaces Gemeenschappelijke databases specifiek generiek

65 © Twynstra Gudde Minicollege Architectuur 65 Integratie van applicatie ontwikkelingen in de tijd geplaatst (2) Business- logica Generieke middleware Synchroon (services) Asynchroon (berichten) Presentatie Data Business- logica Presentatie Data Business- logica Presentatie Data Middleware (generieke servicebus) Business- logica Middleware Presentatie Data Business- logica Presentatie Data Webservices (technologie neutraal) Middleware Berichtuitwisseling gebaseerd op webservice- standaarden (SOAP) Technologische of organisatorische grens specifiek generiek

66 © Twynstra Gudde Minicollege Architectuur 66 Integratie van applicatie ontwikkelingen in de tijd geplaatst (3) Business- logica Presentatie Data Business- logica Data Business- logica Data Portaal voor geïntegreerde werkprocesondersteuning Orkestratie Business- logica Presentatie Data Business- logica Presentatie Data Business- logica Presentatie Data Portaal voor geïntegreerde toegang en authenticatie Portaal Authenticatie, single sign-on personalisatie look-and-feel Portaal Authenticatie, single sign-on Personalisatie specifiek generiek

67 © Twynstra Gudde Minicollege Architectuur 67 Andere benadering m.b.t. softwarearchitectuur –4+1 View model (Kruchten, UML) –Design patterns –Model Driven Architecture

68 © Twynstra Gudde Minicollege Architectuur 68 Het 4+1 View-model –In het 4+1 View-model worden vier views onderkend die samen de architectuur van een systeem beschrijven. Elke view geeft daarbij weer wat, bezien vanuit het perspectief van een bepaalde belanghebbende, fundamenteel is. Logical view Process view Component view Physical view Use cases

69 © Twynstra Gudde Minicollege Architectuur 69 The 4+1 Views –Logical view –Logische opbouw van het systeem –Objecten en hun onderlinge relaties –Component view –Wijze waarop de objecten (in de logical view) zijn samengesteld tot componenten of zijn gecombineerd tot services –Process view –De ‘runtime’-componenten, de ‘executables’ –De onderdelen waaruit de te implementeren applicatie bestaat –Physical view –De benodigde hardware en andere fysieke componenten om het systeem daadwerkelijk te kunnen laten werken –De vijfde view (de +1-view) –Illustreert de samenhang vanuit de invalshoek van het beoogde gebruik van het systeem in de vorm van ‘use cases’

70 © Twynstra Gudde Minicollege Architectuur 70 Design patterns –Geïntroduceerd door ‘The gang of four’: Gamma, Helms, Johnson,’ Vlissides, in ‘Design Patterns, Elements of Reusable Object- Oriented Software’ –Herbruikbare oplossingen, templates voor ontwerpproblemen –Ervaring en kennis van ‘goede’ architectuuroplossingen herbruikbaar gemaakt –Goed gedocumenteerd –Doel, wanneer gebruiken, voorbeeld van gebruik etc. –Bijvoorbeeld –Scheiding van presentatie, interactie en logica (model-view-controller of Observer pattern) –Verbergen van een verzameling interfaces (Facade pattern)

71 © Twynstra Gudde Minicollege Architectuur 71 Model Driven Architecture –Architectuurbenadering gericht op interoperabiliteit –Genereren van model tot implementatie (Extreme Non- Programming) –Platform Independent Model –Modelleert functionaliteit en gedrag, zonder technologische beperkingen –Gebruikmakend van gangbare middleware features –Extra details toegevoegd om vertaling naar Platform Specific Model mogelijk te maken –Platform Specific Model –Toepassing van een profile op het Platform Independent Model, om dit sterk geautomatiseerd te kunnen vertalen naar Platform Specific Model –Uiteindelijk automatisch genereren van software uit het model Computation Independent Model Platform Independent Model Platform Specific Model mapping

72 © Twynstra Gudde Minicollege Architectuur 72 Overzicht Deel 4: De architect –Introductie architectuur –Enterprisearchitectuur –Softwarearchitectuur –De architect –Zijn relatie met de klant –Zijn relatie met de projectleider –Zijn relatie met de ontwikkelaar

73 © Twynstra Gudde Minicollege Architectuur 73 De architect? Vraag Business Oplossing ICT Klant ArchitectOntwerper Bouwer Schetsen Uitzoeken Blauwdruk CommunicatieSpecificatieSupervisie Beeldvorming Uitleggen ‘wilde’ visualisaties

74 © Twynstra Gudde Minicollege Architectuur 74 Architecten in projecten (1) De architect loopt voor de muziek uit

75 © Twynstra Gudde Minicollege Architectuur 75 Architecten in projecten (2) De architect moet kiezen tussen verschillende petten

76 © Twynstra Gudde Minicollege Architectuur 76 Architecten in projecten (3) Er is gebrek aan urgentie voor architectuur

77 © Twynstra Gudde Minicollege Architectuur 77 Architecten in projecten (4) Je moet de architect op zijn blauwe ogen geloven

78 © Twynstra Gudde Minicollege Architectuur 78 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. Bas Kruiswijk


Download ppt "Bas Kruiswijk Amersfoort 21 april 2009 Minicollege Architectuur."

Verwante presentaties


Ads door Google