Wat is Software Architectuur / een Software Architect?

Steeds vaker krijg ik vragen over hoe je een Software Architect kunt worden en wat een goede Software Architect is. In deze Basiskennis-reeks probeer ik hier antwoord op te geven/vinden.

Voor mij staat op de eerste plaats dat men, op een creatieve en eigenwijze manier, antwoord moet kunnen gegeven op de vragen:

• Wat is architectuur (en wat is het niet);
• Wat is Software Architectuur (en wat is het niet);
• Wat doet een Software Architect (en wat doet hij niet);
• Wanneer heb ik een Software Architect nodig (en wanneer niet)?
  

Wat is architectuur (de essentie)

Iedere



VanDale:



1 bouwkunst
2 bouwstijl
3 conceptuele structuur en het functionele gedrag van computer en systeemprogramma's of de beschrijving daarvan

Architecten zijn "Professionele remmers" (twee architectuur principes)

Zojuist viel mijn oog op de achterkant van een "DYA" boek waarop staat: "Architecten staan te boek als professionele remmers" en architecturen worden geassocieerd met papieren tijgers".
Terecht of onterecht, maar ik moest direct denken aan een aantal (door gerenomeerde ICT dienstverleners) in huis ontwikkelde "Frameworks" die de organisatie in eerste instantie een flinke voorsprong gaven en vervolgens steeds meer remmend gingen werken.

Door de gesprekken die ik hierover met betrokkenen gevoerd heb zijn twee van mijn architectuur uitgangspunten nogmaals bevestigd:

• "Anticipation of technology change": de enige constante is verandering: Technologieen komen en gaan en de architectuur moet daar op voorbereid zijn, zowel technisch als organisatorisch. Bij elke grote nieuwe technologische verandering (bijvoorbeeld linq of de beschikbaarheid van .net in SQL Server) eist een realistisch impact analyse op de bestaande architectuur. Doe je dat niet dan is het een kwestie van tijd totdat de organisatie de steeds meer de remmende kracht van de architectuur gaat voelen.

• "Eenvoud": hoe 'mooi' een architectuur ook is het succes wordt altijd bepaald door de praktijk. Deze praktijk wordt maar al te vaak uit het oog verloren. Een voorbeeld hiervan is dat vaak zaken die eenvoudig waren of eenvoudig lijken bijzonder complex en tijdrovend zijn geworden terwijl complexe zaken iets eenvoudiger werden. Voor de organisatie/gebruikers leidt dit snel, en begrijpelijk, tot frustratie en ongebegrip. Voor mij geldt: eenvoudige zaken dienen ten alle tijden eenvoudig te blijven. En hier dient continue door alle processen en fasen heen aandacht voor te blijven.

Architectuur is een teken van beschaving

Architectuur is een teken van beschaving.

Dit geldt voor de fysieke wereld van steden, gebouwen, landschappen en interieuren.Dit geldt echter nog veel meer voor de digitale wereld, de wereldvan digitale services, het digitale informatieverkeer, applicaties,computers, netwerken en werkplekken.

Door: Daan Rijsenbrij

IEEE is bezig met een standaard voor Software Architectuur beschrijvingen

Onlangs ben ik er bij toeval achtergekomen dat het "Institute of Electrical and Electronics Engineers(IEEE)" onder de code "IEEE 1471" bezig is met het ontwikkelen van een standaard voor het beschrijven van Software Architecturen.

Mijns inziens een prachtige stap vooruit opweg naar meer volwassenheid op dit terrein.

Het echte document is afgeschermt maar de homepage van deze standaard staat hier.

Wat ik wel heb kunnen vinden is dit:

• Een presentatie van de standaard (pdf formaat)
• Een samenvatting van de standaard (pdf formaat)

De inhoudsopgave heb ik hieronder opgenomen die is namelijkwel openbaar, en opzichzelf al nuttig.

---

1. Overview

1.1 Scope
1.2 Purpose
1.3 Intended users
1.4 Conformance to this recommended practice
2. References
3. Definitions
4. Conceptual framework

4.1 Architectural description in context
4.2 Stakeholders and their roles
4.3 Architectural activities in the life cycle

4.3.1 Scenario: architecture of single systems
4.3.2 Scenario: iterative architecture for evolutionary systems
4.3.3 Scenario: architecture of existing systems
4.3.4 Scenario: architectural evaluation
4.4 Uses of architectural descriptions
5. Architectural description practices

5.1 Architectural documentation
5.2 Identification of stakeholders and concerns
5.3 Selection of architectural viewpoints
5.4 Architectural views
5.5 Consistency among architectural views
5.6 Architectural rationale
5.7 Example use
Annex A Bibliography
Annex B Notes on terminology
Annex C Examples of viewpoints

C.1 The structural viewpoint in software architecture
C.2 Behavioral viewpoint
C.3 Physical interconnect viewpoint
C.4 Link bit error rate viewpoint
Annex D Relationship to other standards

D.1 Use with 12207.0-1996

D.1.1 Decomposition and allocation viewpoint
D.2 Use with reference model of open distributed processing

Mijn favoriete citaten over Software

"Software Engineering: the practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate and maintain them".

My RSS Feeds

Below a list of my most usefull rss feads I have subscribed to:

Compositie vs Aggretatie vs Associatie

Laatst tijdens een review van een technischontwerp kwamen we op het onderwerp: uml-associaties.

Het valt mij al een tijdje op dat de drie verschillende soorten associaties willekeurig worden gebruikt. Niet geheel terecht want het juist gebruik van een associatie kan op een overzichtelijke manier zeer nuttige informatie aan het diagram toevoegen over de aard van de relaties.

Maar wat was het verschil tussen Composition vs Aggregation vs Association ook alweer en hoe leg je het op een eenvoudige manier uit?

Om te beginnen een voorbeeld:

• Associatie: zoals leraar zich tot student verhoudt
• Compositie: zoals een automotor zich tot de auto verhoudt
• Aggregatie: zoals een auto zich tot een autoradio met slede verhoudt

De uitleg:

Associatie: twee gelijkwaardige entiteiten die een relatie met elkaar hebben. Iedere entiteit heeft zijn eigen levenscyclus. Zoals auto en de persoon die de auto bestuurt.

Aggregatie: twee ongelijkwaardige entiteiten die een relatie met elkaar hebben. De ene entiteit is eigenaar van de andere. Als we de eigenaar vernietigen dan wordt de afhankelijke niet vernietigd maar de afhankelijke kan maar bij een eigenaar horen. Bijvoorbeeld afdeling en een persoon die afdelingshoofd is. Iedere entiteit heeft zijn eigen levenscyclus.

Compositie: twee ongelijkwaardige entiteiten die een relatie met elkaar hebben. De ene entiteit is de eigenaar van de andere. Als we de eigenaar vernietigen dan wordt de afhankelijke ook vernietigd. Alleen de eigenaar heeft een eigen levenscyclus. Bijvoorbeeld huis en kamers: een kamer hoort altijd bij 1 huis en als we het huis vernietigen, vernietigen we de kamer ook. Een kamer kan niet uit een huis worden gehaald.

Een stiefkind genaamd "Javascript Exceptiehandling"

Is het jou weleens opgevallen dat het gebruikelijk is om bij webapplicaties keurig de "serverside" foutmeldingen af te vangen maar dat dit nooit het geval is met "clientside" foutmeldingen?

Deze "serverside" afhandeling bestaat meestal uit de volgende functionaliteit:

• notificieren, vaak per e-mail, over de foutmelding en haar details (innerexceptions, details etc.)
• rapporteren over de hoeveelheid en soort foutmeldingen;
• automatisch aanmaken van een "bug" melding in het "bugtrackingsysteem"

Foutmeldingen die echter "clientside" optreden wat dit betreft volledig overgelslagen. Geheel onterrecht als je het mij vraagt want we kennen allemaal de situatie waarbij we niet verder kunnen met het gebruik van een website door een javascript fout. En dat kost de klant geld!

"Worst Case Scenario": een nieuwe "servicepack" voor Internet Explorer waardoor de javascript code achter een bestelknop niet meer werkt.

Vooralsnog kan ik niet anders dan de conclusie trekken dat de oorzaak hiervan ligt in onwetendheid. Dus hieronder een korte schets van zo'n oplossing.

Oplossing

• Zorg dat bij iedere pagina een de "window.onerror" een eventhandler heeft;
• Deze eventhandler moet dan via xmlHttp een request sturen naar een "ClientSideError.aspx" pagina met alle informatie over de "exceptie"-details;
• Daar moet deze foutmelding op ongeveer dezelfde manier worden afgehandeld als een serverside foutmelding (opslaan, notificeren, rapporteren, bugmelding aanmaken)

Ik heb weleens gedacht om hier een standaard oplossing van te maken, in de trant van een JavascriptErrorReporter (merk op dat het woord Javascript hier niet helemaal juist is maar des te herkenbaarder). Voor alsnog niet de tijd voor genomen, maar wie weet.