Waarom is het aan te raden om maatwerk software te ontwikkelen onder een expliciet vastgelegde software architectuur? Hoe kan MetaFactory de software architect èn de software ontwikkelaars daarbij ondersteunen? Met een geautomatiseerd proces voor het vastleggen, gebruiken en verbeteren van je software architectuur!
Je hebt software nodig
Je wilt bijvoorbeeld het klantcontacten-proces verbeteren of je interne processen stroomlijnen en daar heb je software voor nodig. Dan kan je een aantal alternatieven overwegen: je kan een standaard systeem aanschaffen en implementeren; je kan een low code oplossing bouwen; of je kiest voor maatwerk. Als je kiest voor maatwerk software dan heb je de zekerheid dat je in staat bent om jouw processen maximaal te ondersteunen. Je doet namelijk geen concessies aan de beperkingen die standaard software of low code oplossingen je opleggen.
Software architectuur, als je kiest voor maatwerk software
Als je kiest voor maatwerk software, dan loont het om na te denken over de gewenste software architectuur. Zeker als je vaker kiest voor maatwerk en als systemen langere tijd mee moeten. In je software architectuur leg je vast hoe en waarin je data opslaat, welke talen en frameworks je gebruikt, hoe je gegevens ontsluit voor de gebruikers, hoe interfaces werken, hoe je de software test en documenteert, hoe je omgaat met nieuwe versies van de tools, software en frameworks et cetera.
Software architectuur is dus iets anders dan enterprise-architectuur, informatie-architectuur, of applicatie-architectuur. Deze laatste begrippen richten zich meer op de verhouding business-IT en op het functionele en de (meta)data. Zie verder wikipedia. Software architectuur gaat over de ontwerpbeslissingen rond de software zelf. Ook kom je in plaats van software architectuur de term systeemarchitectuur tegen.
Kies software architectuur oplossingen die modern zijn, maar bewezen, die populair zijn en waarom niet: die goedkoop zijn. Dat kan open source zijn, maar hoeft zeker niet. Door je keuzes expliciet te maken krijg je grip op je beveiliging, je productiviteit van het software ontwikkelproces en bevorder je de overdraagbaarheid.
Hoe beheers je de software architectuur?
Hoe beheers je de software architectuur? Wat je hiervoor nodig hebt is een software architect. Die rol kan vervuld worden door een lead software developer, een dedicated functionaris of zelfs een compleet software architectteam. Je hebt procedures, voorbeeld-programma’s, standaard componenten, handboeken en werkwijzen nodig om de software architectuur te beschrijven en over te dragen aan onder andere de software ontwikkelaars, testers en database beheerders. Je moet voortdurend zorgen dat niet iedere keer het wiel, net even anders, wordt uitgevonden en je na je eerste project al een systeem hebt zonder solide technische basis. De investering in het definiëren, toepassen en bewaken van een software architectuur betaalt zich op termijn dubbel en dwars uit.
Een gekozen software architectuur is echter niet in beton gegoten. Software ontwikkelaars doen nieuwe inzichten op. Nieuwe talen, frameworks en tools worden ontwikkeld en bestaande verbeteren. Gebruikers komen met eisen en wensen die moeilijk met de gekozen software architectuur gerealiseerd kunnen worden. Hier ontstaat dus een spanningsveld:
Om de software ontwikkeling beheersbaar te houden, om grip te houden op beveiliging, productiviteit, onderhoudbaarheid en overdraagbaarheid ontstaat de wens om software te bouwen conform een gekozen software architectuur enerzijds. Maar anderzijds wil en moet je ook moderniseren en aan technisch onderhoud doen. Je software architectuur krijgt dus een update, of een nieuw versienummer als je wilt. Nieuwe software kan je dan ontwikkelen conform de laatste versie van je software architectuur. Maar wat doe je met je al gebouwde software, die functioneel doet wat het moet doen en gebouwd is conform een vorige versie van je software architectuur, of nog erger zonder software architectuur? Is er budget, tijd en capaciteit om aan technisch onderhoud te doen? Een bij veel bedrijven nadrukkelijk gevoelde nu-straks klem. Als je technisch onderhoud verwaarloost gaan de totale IT kosten uiteindelijk fors stijgen waardoor je minder nieuwe functionaliteit kan realiseren. De boel wordt op termijn onbeheersbaar.
Hoe leg je de software architectuur vast en hoe draag je het over?
Hoe werkt het bouwen van software onder software architectuur in de praktijk?
- Hoe leg je de software architectuur vast?
- Hoe draag je kennis rond de software architectuur over aan bouwteams?
- Hoe faciliteer je bouwteams om conform de software architectuur software te ontwikkelen?
- Hoe leg je verbetersuggesties vanuit de bouwteams voor de software architectuur vast?
- Hoe integreer je verbeteringen aan de software architectuur in reeds gebouwde software?
Software architectuur wordt nu veelal vastgelegd in kookboeken, wiki’s en voorbeeld programma’s. Het charisma en natuurlijk leiderschap van de software architect dragen bij aan de acceptatie van de software architectuur. Tech sessies worden georganiseerd om de software architectuur over te dragen. Collega’s helpen elkaar bij de implementatie. Verbetersuggesties worden geïnventariseerd, besproken, geprioriteerd of afgewezen. De kookboeken, wiki’s en voorbeeld programma’s worden bijgewerkt. En we beginnen weer van voor af aan. Een ambachtelijke werkwijze, die veel discipline vergt van alle betrokkenen.
Om verbeteringen aan de software architectuur in te kunnen bouwen in reeds opgeleverde software heb je bijzondere product owners nodig. En budget. De roep om nieuwe functionaliteit en het credo if it ain’t broke, don’t fix it leiden vaak tot systemen waarbij je technisch voortschrijdend inzicht terug ziet in verschillende oplossingen voor vergelijkbare problemen. En dat vergroot op termijn weer de complexiteit en vermindert de onderhoudbaarheid van systemen.
Hoe kan de Code Composer de software architect helpen?
De Code Composer assisteert bij het vastleggen en aanpassen van je software architectuur èn genereert broncode gebaseerd op deze software architectuur. Het resultaat is dat het hierboven beschreven ambachtelijke proces ondersteund wordt met een geautomatiseerd systeem:
- De software architectuur wordt vastgelegd in de Code Composer. Dit kan een software architect met een bouwteam doen, of als gewerkt wordt conform SAFe® door het New technology initiative Dev Team
- Maak – nog steeds – een kookboek hoe bouwteams de software architectuur, vastgelegd in de Code Composer, kunnen gebruiken
- Bouwteams ontwikkelen software met behulp van de Code Composer en het kookboek
- Als bouwteams aanpassingen doen aan de software architectuur, die is vastgelegd in de Code Composer, ziet de software architect dat automatisch in bijvoorbeeld Git.
- De software architect kan de software architectuur wijzigingen accepteren of verwerpen.
- En last but not least … reeds gebouwde software kan opnieuw gegenereerd worden conform de nieuwste software architectuur, wat de complexiteit vermindert en de onderhoudbaarheid en kwaliteit van het systeem vergroot.
Kortom een geautomatiseerd proces van het vastleggen, gebruiken en verbeteren van je software architectuur!
Wanneer is het lonend om je software architectuur vast te leggen in de Code Composer?
Kortgezegd: vanaf 100.000 regels broncode. Hoe groter het systeem, hoe meer profijt je van de Code Composer gaat hebben. De Code Composer werkt ook uitstekend als er meerdere systemen gebouwd moeten worden conform dezelfde software architectuur. In deze blog gaan we nader in op de keuze tussen een standaard low code pakket, handmatige software ontwikkeling en de Code Composer.
Emergent design of een planned design?
Wil je vóór aanvang van je project je gehele software architectuur vastleggen: planned design? Of start je op een agile/scrum-achtige aanpak en laat je de software architectuur zich al werkende weg vormen: emergent design? Het maakt voor de Code Composer niet uit. Zowel emergent design als planned design lenen zich uitstekend voor het gebruik van de Code Composer. Bij een planned design leg je eerst je software architectuur vast voordat je met MetaFactory applicaties gaat bouwen. Bij een emergent design leg je je software architectuur beetje bij beetje vast in de Code Composer. Het is nooit te laat om de Code Composer te introduceren in je softwareproject. Want ook als je klaar bent komt vroeg of laat de behoefte aan technisch onderhoud.
Overigens is het ook bij een planned design aan te raden om eerst delen van de applicatie met de hand te bouwen en op basis daarvan de software architectuur te beschrijven en vast te leggen in de Code Composer. Dat werkt naar onze ervaring het beste.
Hoe leg je de software architectuur vast in MetaFactory en hoe maak je er vervolgens een werkend systeem van?
Zo leg je de software architectuur vast in MetaFactory:
- Bedenk een technisch gewenste oplossing.
- Probeer deze uit door hiervoor handmatig een stuk software te schrijven. Ben je tevreden over de werking van je code?
- Vertaal je handmatig geschreven software dan naar MetaFactory code instructies. We hebben tools die je hierbij assisteren.
- Genereer de software met behulp van de Code Composer en de door jou gemaakt code instructies. Is de gegenereerde software hetzelfde als je handmatig geschreven software?
- Gefeliciteerd, dan werken de code instructies goed en heb je je software architectuur in de Code Composer vastgelegd!
- Nu kan je de Code Composer gebruiken om de gewenste technische oplossing steeds opnieuw toe te passen.
- En heb je voortschrijdend inzicht? Pas de code instructies aan en genereer alle reeds gemaakte broncode opnieuw. Jouw nieuwste inzichten zijn overal eenduidig vastgelegd. Achterstallig technisch onderhoud is hierdoor verleden tijd.
De beste resultaten verkrijgen we als senior software developers van MetaFactory enige tijd assisteren bij het opzetten van de gewenste software architectuur in de Code Composer. Zij ondersteunen de software architect en de bouwteams bij het gebruik van de Code Composer. Zie deze blog en kijk eens naar deze video.
Interesse? Neem nu contact met ons op.
