1 / 44

DYA|Software Architectuuraanpak voor bedrijfskritische applicaties Overzicht

DYA|Software Architectuuraanpak voor bedrijfskritische applicaties Overzicht. NGI 20110524 v2. Robert Deckers . Speerpunten DYA|Software. Uitgaan van “goede architectuur” Van organisatiebreed tot applicatie Één passend consistent geheel Afstemmen op specifieke situatie.

emmett
Download Presentation

DYA|Software Architectuuraanpak voor bedrijfskritische applicaties Overzicht

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. DYA|SoftwareArchitectuuraanpak voor bedrijfskritische applicatiesOverzicht NGI 20110524 v2 Robert Deckers

  2. Speerpunten DYA|Software • Uitgaan van “goede architectuur” • Van organisatiebreed tot applicatie • Één passend consistent geheel • Afstemmen op specifieke situatie

  3. De DYA fundering DYA |Infrastructuur |Governance |Principes |Software |Business

  4. Wat te doen?

  5. Goede architectuur is… niet altijd • Snelle systemen • Kostenbewust • Simpel • Homogeenapplicatielandschap • Technologie-onafhankelijk • Toekomstbestendig situatieafhankelijk • Voorspelbare • projecten • Flexibel • Herbruikbaar • Modulairopgebouwd • Gebruiksvriendelijkesystemen • Betrouwbare systemen • Service georiënteerd • Onderhoudbaresystemen • Vergroot de winst

  6. ROI Art. 4.11 t Correct, Consistent, geCommuniceerd Correct : het past in de omgeving Eindgebruiker Businessmanager Goede Architectuur zorgt voor:  Sturing van architectuuractiviteiten  Toetsbare architectuur  Goed systeem Overheid Systeem Consistent : het zit goed in elkaar Architectuur Project Software engineer Tester HRM Functioneelbeheer functionaliteit Componentenbouwer Programmamanager Netwerkbeheer geCommuniceerd : iedereen weet wat hij moet weten

  7. Checklist

  8. CorrectheidValidatie (voorbeeld) • Hoe (h)erkennen de stakeholders de beschreven belangen? • Hoe zijn de andere uitgangspunten over de omgeving gecontroleerd op geldigheid? • Hoe wordt de prioritering van belangen gevalideerd? Met name door de systeemeigenaar.

  9. 10 vragen van de manager aan de architect • Wie zijn de stakeholders en wat is het belangrijkste concern van elke stakeholder? • Wat zijn de vijf belangrijkste concerns waar de architectuur invulling aan moet geven? • Wat zijn de vijf moeilijkste kwesties waar de architectuur een oplossing voor biedt? Welke stakeholderconcerns zijn daarmee gediend? • Wat is de belangrijkste rol die elke stakeholder speelt bij de totstandkoming van de architectuur? • Wat is de afbakening van de architectuur? In het bijzonder met betrekking tot: Toepassingsgebied, Technologie, Ontwikkel- en beheerproces, Levensduur • Wat zijn de vijf belangrijkste afwegingen in de architectuur en hoe zijn deze vastgelegd, uitgedragen en bewaakt? • Op welke manier is de consistentie van de vijf belangrijkste eisen en hun oplossing aangetoond? • Welke architectuurviews zijn er om te redeneren, uit te leggen, uit te rollen, te beschrijven, etc.? Aan welke stakeholders zijn deze gericht? • Op welke manier zijn de stakeholders op de hoogte gebracht van de manier waarop de architectuur hun eisen (niet) inwilligt en wat er van hen verwacht wordt / welke acties zij moeten ondernemen? • Wat is er zo geweldig aan de architectuur wat ik niet mag vergeten? Wat moet ik echt weten van de architectuur dat ik niet gehoord heb in de antwoorden op de vorige vragen?

  10. Wat doet softwarearchitectuur? • Hoofdontwerp : functioneel, technisch, aanpakArchitectuurprincipes Bieden van oplossingsrichting voor belangrijkste eigenschappen die het moeilijkste te realiseren zijn Business doelen - Uniek - Juiste kwaliteit Niet standaard , Wat ging er vorige keer fout? Meerdere afdelingen – disciplines - systemen

  11. Speerpunten DYA|Software • Uitgaan van “goede architectuur” • Van organisatiebreed tot applicatie • Één passend consistent geheel • Afstemmen op specifieke situatie

  12. De softwarearchitect en de anderen Informatie analist, Business architect, Requirementsengineer Toepassing Business behoefte, Rol in bedrijfsproces, Functionaliteit, Kwaliteit constructie Softwarearchitect Softwarearchitect Software engineer, Ontwerper, Tester, Infrastructuur architect Programmamanager, Projectleider, Ontwikkelmanager realisatie Component, InterfaceOntwerppatroon, Infrastructuur Planning, Ontwikkelproces, Risico, Benodigde kennis

  13. Integratie met enterprise-architectuur Businessdoelen DYA|Software App 2 App 3 Business- architectuur Technische architectuur Informatie- architectuur App 1 App 4 App 5 Prod/ dienst Orga- nisatie Gege- vens Appli- catie Middle- ware Plat- form Net- werk Proces Om- geving • Bedrijfsbrede oplossingen • Pad van strategie naar applicatie Algemene principes Component 5 Comp 1 Comp 2 Comp 3 Comp 4

  14. Deelarchitecturen binnen enterprisearchitectuur Netwerk Computer Dataopslag Product/ dienst Business-architectuur Infrastructuur-architectuur Levert Doorloopt Proces Organisatie Infrastructuur Draait op Organiseert Bewaart Applicatie-architectuur Bewerkt Medewerker Applicatie Dataobject Bestuurt Voert uit Representeert Voert uit Bewerkt Bedrijfs-functie Bedrijfsobject Informatiearchitectuur

  15. Architecten in alle soorten en maten IT-architect, Lead architect, Enterprise architect, Applicatiearchitect, Informatiearchitect, Business architect, Infrastructuurarchitect, Softwarearchitect, Systeemarchitect, Solution architect, Productarchitect, Projectarchitect, Security architect, Modelling architect, …, Blablarchitect Welke architect ben jij? • Waarvan ben je de architect? • In welke discipline ben je architect? • Binnen welk organisatiebereik ben je architect?

  16. Familie: applicaties met dezelfde genen App 2 App 3 App 2 Familieleden App 1 App 4 App 5 App 1 • Homogeen  beheerbaar • Hergebruik  sneller en beter Gebruik centrale component Component 5 App 7 App 6 App 7 App 8 App 9 App 6 Ontwerp/realisatiepatronen

  17. Speerpunten DYA|Software • Uitgaan van “goede architectuur” • Van organisatiebreed tot applicatie • Één passend consistent geheel • Afstemmen op specifieke situatie

  18. Architectuurredeneermodel informatieanalist gebruikerbusinessarchitect / -manager requirements engineer T Omgeving Grens Systeem Klantbehoefte Omgeving Grens Systeem Toepassing • consistente architectuur • afgewogen beslissingen • stakeholders op een lijn Functie Ontwerp Aanpak Realisatie Constructie Realisatieproces/-organisatie Technologie programmeurinfrastructuurarchitectontwerper tester projectleiderprogrammamanager ontwikkelmanager

  19. Speerpunten DYA|Software • Uitgaan van “goede architectuur” • Van organisatiebreed tot applicatie • Één passend consistent geheel • Afstemmen op specifieke situatie

  20. Verschillende belangen T Green image Snel nieuwe producten Klantbehoefte Voldoet aan standaard X Toepassing Betrouwbaar Leveren via telefoon, post, loket en internet • Specifiek en Prioriteer  • Focus bij afwegingen • Neuzen richten Softwaresysteem Eerder zijn dan de concurrent Componenten moeten herbruikbaar zijn Realisatie Constructie In India maken Realisatieproces/-organisatie Gebaseerd op open source Technologie Iteratief ontwikkelen personeel delen met project X Draait ook op een mobieltje Oude systeem geleidelijk uitfaseren

  21. Verschillende representaties • Stem communicatie af op doelgroep  • Draagvlak • Vertaling naar acties van doelgroep

  22. Verschillende oplossingen buy – make – outsource – cloud - open sourceagile – waterfall - … • Bewuste afgewogen keuzes  • Architectuur realiseerbaar • Later traceerbaar

  23. view adresseert gaat over concern uitspraak aspect afgeleid van beïnvloedt stakeholder neemt beslissing model verwerkt in Belangrijke taken en concepten

  24. InhoudDYA|Software Visie Organisatiebredesoftwarearchitectuur Architectuurredeneermodel Familie-architecturen Goede Architectuur softwarearchitectuur en softwarearchitect Beheren en beheersen Taken van de architect

  25. williekeurigeview desktop interface web interface Software realiseren is mensenwerk Klantbehoefte voortgangs-rapportage Realisatie-informatie-systeem Architectuur requirements-specificatie Realisatieproces/-organisatie Technologie functioneelontwerp code ontwerp-patroon test- plan Domein specifieke talenAspect oriëntatie Model driven development Klant Customer Cliënt Relatie Koper architectuurprincipe project-plan

  26. voor architecten: T Klantbehoefte Verbreding voor de techneut: Architectuur in de context Verdieping voor de raamwerk/proces fan: Architectuur voor hier en nu • Systematiek • Integraal • Situatiespecifiek Realisatieproces/-organisatie Technologie

  27. staat voor resultaat

  28. Hierna backupslides

  29. Definitie softwarearchitectuur De softwarearchitectuur van een systeem is een geheel van uitspraken dat richting geeft aan ontwerp, realisatie en evolutie van software in zijn omgeving Architectuuruitspraken betreffen: • Elementen • Structuur • Richtlijnen voor creëren van structuur en elementen

  30. De weg naar goede architectuur T Klantbehoefte • Architectuur beheren en beheersen • Afgewogenbeslissingen • Borgen van gemeenschappelijkheiden variatie • Doen! Proces Organisatie Infrastructuur Toepassing Correct Consistent geCommuniceerd Appcomp 4 Appcomp1 Appcomp 5 Softwaresysteem Realisatie Constructie Medewerker Applicatie Dataobject Centrale component Realisatieproces/-organisatie Technologie Comp 1 Comp 2 Comp 3 Comp 4 Bedrijfs-functie Bedrijfsobject

  31. De software-architect en DYA|Software Verkennen Communiceren Afwegen Overzien Prioriteiten Actie Keuze Samenhang

  32. Signalen voor DYA|Software T De gebruikers accepteren het systeem niet Klantbehoefte Welke impact heeft de fusie op onze IT? Toepassing We weten niet of het aan de norm/standaard voldoet Verkeerde kwaliteit Softwaresysteem Waarom duren die wijzigingen zo lang? De onderdelen passen niet goed op elkaar Realisatie Constructie Verkeerde mensen in het (verkeerde) project Realisatieproces/-organisatie Past niet in de standaard infrastructuur Technologie Het huidige architectuurraamwerk biedt geen houvast Wat betekent die nieuwe technologie voor ons? Waarom hebben we het niet gekocht?

  33. The Winchester Mystery House In 38 jaar gebouwd: 147 bouwers 0 architecten géén bouwtekening aanwezig In het huis: 160 kamers 40 slaapkamers 6 keukens 2 kelders 950 deuren Waarbij: 65 blinde deuren 13 trappen in het plafond 24 dakramen in de vloer gasleiding langs plafond elke kamer anders

  34. CorrectheidBewuste afweging van belangen • Wat is de prioritering van de verschillende belangen? • Welke afwegingen zijn gemaakt in de architectuur? • Hoe zijn de afwegingen terug te traceren naar de stakeholderbelangen en de prioritering? • Op welke andere omgevingsinformatie zijn de afwegingen gebaseerd? • Waaruit blijkt of de stakeholders de afweging begrijpen?

  35. CorrectheidVoldoende omgevingsanalyse • Wat is de afbakening van het systeem? • Denk aan afbakening in klantbehoefte, kwaliteit, functionaliteit, technologie, realisatie en levensduur. • Welke elementen uit de omgeving worden beschouwd? Wat neem je wel/niet mee? • Concurrenten, marktontwikkelingen, technologische ontwikkelingen, mogelijke partners, aangrenzende systemen, gerelateerde projecten. • Wie zijn de stakeholders? Wat zijn hun belangen? • Wat is belangrijke omgevingsinformatie? Denk hierbij aan inputdocumenten, marktinformatie, wetgeving,… • Hoe wordt de omgevingsinformatie (per item) gebruikt als input voor de architectuur?

  36. CorrectheidValidatie • Hoe (h)erkennen de stakeholders de beschreven belangen? • Hoe zijn de andere uitgangspunten over de omgeving gecontroleerd op geldigheid? • Hoe wordt de prioritering van belangen gevalideerd? Met name door de systeemeigenaar.

  37. ConsistentieBewuste vastlegging • Wat hoort wel en niet tot de architectuurbeschrijving? • Hoe is de architectuur vastgelegd? • Hoe wordt de architectuur beheerd?

  38. ConsistentieVoldoende aantoonbaar realiseerbaar • Hoe wordt ervoor gezorgd dat de architectuur toegepast wordt tijdens realisatie? • Hoe wordt aangetoond of het systeem volgens de architectuur te bouwen is? • Hoe wordt aangetoond of het systeem volgens de architectuur gebouwd is?

  39. ConsistentieVerificatie op tegenstrijdigheden • Welke terminologie wordt gebruikt in de architectuurbeschrijving? • Hoe wordt ervoor gezorgd dat de terminologie begrepen wordt? • Hoe wordt de architectuur geanalyseerd op tegenstrijdigheden? • Hoe is duidelijk dat elke architectuuruitspraak aansluit op een omgevinguitspraak? • Passen ze op een stakeholderbelang of uitgangspunt over de omgeving? • Hoe is duidelijk dat de belangrijkste architectuuruitspraken dezelfde belangen dienen?

  40. CommunicatieBewust uitgevoerd • Hoe wordt de communicatie gecoördineerd? • Hoe wordt de communicatievorm en inhoud gepland/vastgelegd? • Hoe is bekend wie waarvan op de hoogte is? (zou moeten zijn)

  41. CommunicatieVoldoende verankering • Hoe is duidelijk of de belangrijkste/invloedrijkste stakeholders betrokken zijn in de communicatie? • Wie erkent de architectuur en wie niet? • Wat wordt gecommuniceerd over: • architectuurvisie, • voorspelde gevolgen, • behaalde successen • Hoe wordt de architectuur ingebed in ontwikkelproces/-straat?

  42. Communicatie: Vertaalbaar naar acties • Welke rol speelt de architectuur in de activiteiten van de stakeholders? Wat moet elke stakeholder met de architectuur doen? • Hoe is duidelijk of de stakeholders informatie van voldoende diepgang hebben? (om de juiste acties te kunnen ondernemen) • Hoe weet je of de architectuur goed vertaald is? Wat gebeurt er als dat niet zo is?

More Related