Korte intro: ik werk als een vliegende keep in een metaalbedrijf waar men ook een flinke IT tak heeft. Mijn roots liggen in software bouw. Dat was vroeger, geleidelijk verschoof m’n interesse en ben ik vooral bedrijfskundig bezig.
Tldr; ik ben benieuwd naar interessante inzichten. Softwarebouw gaat stroef, optimalisatie wordt gezocht in het proces en niet in de techniek terwijl daar volgens mij ook veel te winnen is.
Een aanzienlijk deel van de IT inspanning die we op dit moment hebben zit in interfaces en maatwerk. Meestal zijn dat losse applicaties die business logic van diverse API’s combineren. Sommige van die apps hebben ook nog een stevige reken- of datatransformatiecomponent. De stack is azure based met als streven ontkoppeling via een service bus en overwegend C# microservices.
Maar het loopt niet lekker. Uitlopende planningen, budgetoverschrijdingen en dergelijke. Als tegenbeweging zie je dat er ook her en der amateuroplossingen in elkaar geknutseld worden die niet altijd even doordacht in elkaar zitten. Denk daarbij aan veel te ingewikkelde rommelige SQL die voor business logic speelt waar niemand meer uit kan komen en dat soort dingen. Kortom het verhaal van de man met de hamer die alleen maar spijkers ziet.
Procesmatig wordt er al flink aan de weg getimmerd. Een tijdje geleden zijn we net zoals zo’n beetje overal met een losse interpretatie van agile aan de slag gegaan en dat lijkt wel aardig te werken. Waar het blijft wringen is dat de implementatietijd voor relatief simpele dingen te lang is.
Naar mijn mening bestaat de huidige situatie uit twee uitersten: of we bouwen een aan elkaar getapede golfplaten bouwsels (de SQL/PowerApps/access/weetikveel oplossingen) en anders bouwen we een stenen huis met marmer en eikenhout (c# microservice apps). Er zit niet zoiets als een houten schuurtje tussenin. Die mis ik, want met name bij interfaces en datatransformaties heb je gaandeweg veel voortschrijdend inzicht.. eigenlijk moet je dat eerst als een prototype kunnen testen om het design te laten rijpen. Als ik nu echter een redelijk rechttoe-rechtaan interface zou laten bouwen (klantorder aanmaken in systeem a zorgt automatisch voor een klantorder in systeem b) ben ik minimaal een week of meer kwijt. Dat is niet te verkopen en het is een drijvende kracht om die houtje-touwtje oplossingen veel te ver door te drijven. Wat weer z’n eigen problemen oplevert.
Bij een recent project heb ik het anders aangepakt. Ik heb met Python een paar scripts gemaakt die een brondatabase uitlezen, wat transformeerden, en webservices van het doelpakket aanriepen. Voordelen: snel klaar, wat moeilijkheidsgraad betreft betrekkelijk eenvoudig en de onderliggende SQL is veel overzichtelijker dan bij allemaal in elkaar geknoopte stored procedures. En wijzigingen zijn best door een beetje technisch aangelegde functionele gebruikers te doen zodat de logica goed kan rijpen. Deze oplossing is vanzelfsprekend niet zo bullet proof als een ‘echte’ interface en daarom moet goed bekeken worden of het hogere risico aansluit bij de mate waarin iets bedrijfskritisch is.
Zodra het te verantwoorden is dat er echt gebouwd wordt ligt er werkende code als referentie waardoor het ondubbelzinnig is hoe de nieuwe code moet gaan werken, dus ik hoop dat dat tzt de implementatiesnelheid ook ten goede komt. Nu ben ik er wel wat huiverig voor nog een aanvullende prutsoplossing te introduceren. Volgens mij zit dit wel op het goede evenwicht tussen simpel en degelijk, maar mocht iemand betere suggesties hebben sta ik daar zeker voor open.
Maar wat me vooral verbaast is dat ik hier redelijk alleen in lijk te staan. De meeste collega’s zitten volledig in een van de twee uitersten. En waar zoals gezegd wel aandacht is voor verbeteringen wat betreft proces zie ik zowel binnen ons bedrijf als online eigenlijk zo goed als geen aandacht voor het wat meer ‘agile’ maken van de techniek zelf.
Volgens mij is dit probleem voor ons toch totaal niet uniek, hoe gaat dat bij jullie?
Tldr; ik ben benieuwd naar interessante inzichten. Softwarebouw gaat stroef, optimalisatie wordt gezocht in het proces en niet in de techniek terwijl daar volgens mij ook veel te winnen is.
Een aanzienlijk deel van de IT inspanning die we op dit moment hebben zit in interfaces en maatwerk. Meestal zijn dat losse applicaties die business logic van diverse API’s combineren. Sommige van die apps hebben ook nog een stevige reken- of datatransformatiecomponent. De stack is azure based met als streven ontkoppeling via een service bus en overwegend C# microservices.
Maar het loopt niet lekker. Uitlopende planningen, budgetoverschrijdingen en dergelijke. Als tegenbeweging zie je dat er ook her en der amateuroplossingen in elkaar geknutseld worden die niet altijd even doordacht in elkaar zitten. Denk daarbij aan veel te ingewikkelde rommelige SQL die voor business logic speelt waar niemand meer uit kan komen en dat soort dingen. Kortom het verhaal van de man met de hamer die alleen maar spijkers ziet.
Procesmatig wordt er al flink aan de weg getimmerd. Een tijdje geleden zijn we net zoals zo’n beetje overal met een losse interpretatie van agile aan de slag gegaan en dat lijkt wel aardig te werken. Waar het blijft wringen is dat de implementatietijd voor relatief simpele dingen te lang is.
Naar mijn mening bestaat de huidige situatie uit twee uitersten: of we bouwen een aan elkaar getapede golfplaten bouwsels (de SQL/PowerApps/access/weetikveel oplossingen) en anders bouwen we een stenen huis met marmer en eikenhout (c# microservice apps). Er zit niet zoiets als een houten schuurtje tussenin. Die mis ik, want met name bij interfaces en datatransformaties heb je gaandeweg veel voortschrijdend inzicht.. eigenlijk moet je dat eerst als een prototype kunnen testen om het design te laten rijpen. Als ik nu echter een redelijk rechttoe-rechtaan interface zou laten bouwen (klantorder aanmaken in systeem a zorgt automatisch voor een klantorder in systeem b) ben ik minimaal een week of meer kwijt. Dat is niet te verkopen en het is een drijvende kracht om die houtje-touwtje oplossingen veel te ver door te drijven. Wat weer z’n eigen problemen oplevert.
Bij een recent project heb ik het anders aangepakt. Ik heb met Python een paar scripts gemaakt die een brondatabase uitlezen, wat transformeerden, en webservices van het doelpakket aanriepen. Voordelen: snel klaar, wat moeilijkheidsgraad betreft betrekkelijk eenvoudig en de onderliggende SQL is veel overzichtelijker dan bij allemaal in elkaar geknoopte stored procedures. En wijzigingen zijn best door een beetje technisch aangelegde functionele gebruikers te doen zodat de logica goed kan rijpen. Deze oplossing is vanzelfsprekend niet zo bullet proof als een ‘echte’ interface en daarom moet goed bekeken worden of het hogere risico aansluit bij de mate waarin iets bedrijfskritisch is.
Zodra het te verantwoorden is dat er echt gebouwd wordt ligt er werkende code als referentie waardoor het ondubbelzinnig is hoe de nieuwe code moet gaan werken, dus ik hoop dat dat tzt de implementatiesnelheid ook ten goede komt. Nu ben ik er wel wat huiverig voor nog een aanvullende prutsoplossing te introduceren. Volgens mij zit dit wel op het goede evenwicht tussen simpel en degelijk, maar mocht iemand betere suggesties hebben sta ik daar zeker voor open.
Maar wat me vooral verbaast is dat ik hier redelijk alleen in lijk te staan. De meeste collega’s zitten volledig in een van de twee uitersten. En waar zoals gezegd wel aandacht is voor verbeteringen wat betreft proces zie ik zowel binnen ons bedrijf als online eigenlijk zo goed als geen aandacht voor het wat meer ‘agile’ maken van de techniek zelf.
Volgens mij is dit probleem voor ons toch totaal niet uniek, hoe gaat dat bij jullie?