Maturity Models

Als het gaat om leren en groeien dan staat bij mij met stip op nummer 1 de "Maturity Models".

Veel te vaak wordt gedacht dat we uniek zijn en de enige zijn in "deze" positie.
Maar als we het juiste "maturity model" erbij weten te pakken dan is onze positie snel herkenbaar, logisch te verklaren (we moeten nu eenmaal kruipen voor we kunnen gaan lopen) en dan zijn handvatten om te verbeteren direct een stuk concreter.

In deze reeks ga ik opzoek naar de verschillende "Maturity Models" die ons als Software Architecten kunnen helpen om onszelf en de organisatie te doen groeien.

Architectuur beschrijving (Basiskennis deel 2)

Wat kun je doen als je een softwareontwikkelaar bent en Software Architect wilt worden?



Als ervaren Software Architect is het belangrijk dat je kennis en ervaring hebt met het "formeel" beschrijven van een architecturen. Als "Software Architect"-wanna-be kun je daarom beginnen met het beschrijven van de op jullie I.C.T. afdeling bestaande architectuur volgens zo'n formele methode.



Maar daar is helemaal geen tijd voor?

Tijd is een kwestie van prioriteit. En, vanaf nu, is het een prioriteit voor jou! Waarschijnlijk is iedereen op jouw werk zich bewust van het feit dat er te weinig op papier staat en kent de nadelen ervan inmiddels. Aan de andere is de beleving van velen dat documenteren veel tijd kost en altijd in de spreekwoordelijke "la" verdwijnt. Maar omdat jij ambitieus bent is deze situatie wat architectuur betreft snel te doorbreken.

• Stap 1: pak een klein deelgebied, maak een inhoudsopgave en werk deze voor 25% uit in je eigen tijd; Geef in het bijzonder aandacht aan de inleiding waarin je beschrijft wat de nut en noodzaak is van dit document voor jouw organisatie/afdeling (hoe concreter hoe beter);


• Stap 2: maak op je werk op de rustige momenten het document voor 50% af;


• Stap 3: laat het document aan je manager zien, vraag hem om zijn aanvullingen en mening en verwerk deze en vertel hoeveel tijd je nog nodig hebt om het af te ronden. Denk ook aan andere personen dan je manager die zouden kunnen optreden als "sponsor" van je activiteiten.


• Stap 4: vertel welke andere deelgebieden ook zouden moeten worden beschreven.

Welke formele methode moet ik gebruiken?

• Dya: voordelen: meest pragmatisch, Nederlands. Als je een technische functie hebt zou ik me beperken tot de Technisch Architectuur beschrijving;
• IEEE 1471: "Recommended Practice for Architecture Description of Software-Intensive Systems". Voordelen: meest korte en bondige standaard, maar vanuit de "stakeholder" gedachte kan deze aanpak om mee te beginnen te breed zijn. Stel jezelf de volgende vraag: ben ik voldoende op de hoogte "waarom" de dingen gedaan zijn/worden zoals we ze doen/deden? Of worden de beslissingen voornamelijk "adhoc" genomen?
• TOGAF: De grootste en meest complete van de drie maar ook de meest lastige om je weg in te vinden. Vanuit het vrij technische startpunt is met name het "Technical Reference Model" aardig om mee te beginnen.
• Natuurlijk ben je erg eigenwijs en kun je natuurlijk ook opzoek gaan naar je "eigen" standaard: Zachman, Rup (ook een hele interessante!), E2AF etc. etc. )

Tip: zorg dat je op termijn de hoofdlijnen van alle drie de modellen kent door ze aandachtig door te lezen. Op "feestjes" kun je in ieder geval een beetje mee komen en wordt je niet meer bij de eerste de beste architecten "slang" omver geblazen.

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.