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.