Minicollege Architectuur

Overzicht Deel 1: Introductie architectuur Begripsbepaling: wat is architectuur en waarom is het zo belangrijk? Verschillende soorten architectuur Twee aanvliegroutes naar SOA Enterprisearchitectuur Softwarearchitectuur De architect

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

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

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

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

‘Dé’ architectuur bestaat niet Verschillende reikwijdte Verschillend niveau van detaillering Verschillende aspecten van een complex systeem

De reikwijdte van een ICT-architectuur Schaalverschillen   Source: Gartner Group

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

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

We onderscheiden drie typen architectuur Voor het overzicht maken we onderscheid in drie ‘typen’ architectuur Reikwijdte Focus Doel Enterprisearchitectuur Bedrijf Strategie Communicatie Softwarearchitectuur (Verzameling van) systemen Ontwerp en realisatie Specificatie Servicegeoriënteerde architectuur Conceptuele basis Combinatie van organisatorische en technische aspecten Reikwijdte zowel organisatiebreed als individuele systemen

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

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

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

Het modelleren van de enterprisearchitectuur Architecture (conception) stake holder Enterprise (domain) Architecture description (representation)

Views and viewpoints View View Architecture View Stakeholder Viewpoint

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

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

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

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

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

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

Modules en objectoriëntatie 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

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

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

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

Service request Dienstaanvraag (request) respons Dienstresultaat De van buitenaf zichtbare beschrijving van dienst request Dienstbeschrijving (interface) Dienstaanvraag (request) Dienstinhoud (implementatie) respons Dienstresultaat (respons) De interne realisatie van de dienst middels werkende software

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

Monolitische en modulaire softwarearchitectuur

Client/Server architectuur Decentraal Client Decentraal Decentraal Client Client Server Centraal

Gedistribueerde drie- en meerlaagse softwarearchitectuur Presentatie Presentatie Processervices Businesslogica Samengestelde services Basisservices Data Data

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

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

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

Andere benadering m.b.t. softwarearchitectuur 4+1 View model (Kruchten, UML) Design patterns Model Driven Architecture

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 Component view Use cases Process view Physical view

The 4+1 Views Logical view Component view Process view Physical 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’

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)

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 mapping Platform Independent Model mapping Platform Specific Model

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

‘wilde’ visualisaties De architect? Vraag Business Oplossing ICT Klant Architect Ontwerper Bouwer Communicatie Supervisie Specificatie Beeldvorming Uitleggen ‘wilde’ visualisaties Schetsen Uitzoeken Blauwdruk

Architecten in projecten (1) De architect loopt voor de muziek uit

Architecten in projecten (2) De architect moet kiezen tussen verschillende petten

Architecten in projecten (3) Er is gebrek aan urgentie voor architectuur

Architecten in projecten (4) Je moet de architect op zijn blauwe ogen geloven

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.