Iedereen die de ontwikkelingen bijhoudt op het gebied van software-ontwikkeling weet het: je kunt het onmogelijk allemaal bijhouden. Als ervaren ontwikkelaar, ontwerper of architect is de belangrijkste vraag keer op keer of je de laatste hype van de trend kunt onderscheiden en wat je er mee moet.
Zo’n vijftien jaar geleden was het niet ongebruikelijk om bij it-afdelingen van grote organisaties zogenaamde ‘ontwikkelstraten’ in te richten. De gedachte dat je software-ontwikkeling als een fabrieksmatig proces zou kunnen inrichten kom ik nog steeds wel eens tegen. Maar daar waar je vroeger af kon met open (of gesloten)-standaards zoals bijvoorbeeld een Java Enterprise-straat of je volgde de lijn van – pak ‘m beet – Microsoft of IBM, zo wordt vandaag de dag niet meer geopereerd.
Zelfs de implementatie van een eigen ontwikkelstandaard is vaak tevergeefs of van korte duur.
Mocht je proberen te varen op het kompas van grote jongens als IBM, Oracle en Microsoft, dan merk je vroeg of laat dat hun producten even heterogeen zijn als de open source- of internet-gemeenschap zelf. Bekende open source-websites als Apache, Sourceforge en Google Code hebben de weg geplaveid voor een site als Github waar de tech-wereld helemaal los gegaan is en jan en alleman projecten in allerlei soorten en maten plaatst.
Embrace change… met mate
In de wereld van de maatwerksoftware hebben we de laatste tien jaar te maken gekregen met een explosie van het aantal frameworks en libraries, waarbij enkel het maken van keuzes al een apart specialisme lijkt. Het adagium ‘embrace change’ dat oorspronkelijk bedoeld was voor de functionele requirements in een Agile softwaretraject krijgt zo een eigen betekenis. Een nieuwe tool met versie 0.7 lijkt nog niet rijp, maar als we al op versie 3.2 zitten dan is er vast al wel iets nieuws dat beter is. En uiteraard moet de nieuwe technologie ‘light weight’ zijn. Iets wat bij een versienummer van minder dan 1 misschien wel automatisch is, lijkt me zo.
Natuurlijk, open source is geweldig, en jawel, er bestaan zeer goede en toekomstvaste projecten, maar in sommige hoeken, zoals webtechnologie of Java, lijkt er elke dag een framework of tooltje bij te komen, waarvan het hele internet schreeuwt dat je niet zonder kan. Het is de taak van architecten om het it-landschap in de gaten te houden met oog voor zaken als onderhoudbaarheid, veiligheid en wendbaarheid. Dus zelfs als de werkvloer allerlei autonome Agile-teams heeft, zou je zeggen dat de architect enigszins defensief is als het gaat om het introduceren van nieuwe technologieën.
Complexiteit
Een organisatie die gebruik maakt van een ratjetoe aan technologieën zoals WebSphere, JBoss, Spring, Java Enterprise, .Net, MQ, Mule, Oracle Fusion, Tomcat, Scala, Groovy, Python, MySQL, Postgres, Cassandra, Neo4j, MongoDB, Hibernate, JSF, EJB, Maven, Node.js, Grunt, Bower, et cetera, heeft technisch gezien een complex landschap met overlap in producten. Vaak moet bovendien geintegreerd worden met uitgebreide business-pakketten als Siebel, SAP of Salesforce.
Een heterogeen landschap kan op zichzelf al duur in onderhoud zijn, maar wat het daarbovenop nog lastiger maakt is de combinatie van verschillende paradigma’s en dergelijke, zoals soa, model driven, api-driven, functioneel programmeren, reactive systems, cloud computing, et cetera. En dan heb ik het nog niet gehad over de verschillende proces methodieken, waarbij DevOps misschien wel een toverwoord is, maar daarmee nog niet een tovermiddel.
Paradox
De paradox is dat het voor het persoonlijk curriculum van de software-architect wel goed is om veel verschillende producten te gebruiken. Bovendien is het leuk om nieuwe technologie uit te proberen en ook is soms nieuwe technologie vaak net wat beter dan oude technologie. Dat is niet altijd zo, maar daar kom je natuurlijk pas achter als je het toch een keer gebruikt.
En zo kan het gebeuren dat je bij de start van een nieuw project, bijvoorbeeld een simpele webapplicatie, je zomaar een paar weken kwijt bent, omdat je niet kunt kiezen. Het is een soort framework fetisjisme. We zijn verslaafd aan frameworks en worden er opgewonden van. Daarnaast volgen we de nieuwe trends en stellen we onszelf dus telkens nieuwe vragen. Gebruiken we een applicatieserver of is dat alweer achterhaald? Gebruiken we een database? NoSQL toch wel? En wat gebruiken we eigenlijk voor de frontend? Een leuk hip framework ofzo? En welke versie dan eigenlijk? En is een nieuwe versie van zo’n framework of tool wel backwards compatibel? Laten we in ieder geval ‘lightweight’ beginnen, want ‘heavyweight’ wordt het vanzelf wel.
Ik ben er stil van. Normaal zeik ik de IT af, maar nu doet de auteur dit zelf.
Als we jou nou inhuren als IT architect, voor zegmaar een simpele website, ben je dan eerst een paar weken tijd kwijt met kiezen om daarna na hartelust de nieuwe lightweight techniek te gaan uitproberen ?
Toch maar Henri met z’n Azure only oplossing dan ?
Het ligt aan de teamsamenstelling in welke mate je voor ‘nieuwe’ dingen kiest.
Je moet jezelf blijven ontwikkelen als programmeur om bij te blijven, dus het liefste wil je -als het goed is- zelf leuke nieuwe dingen leren.
De business heeft echter liever proven technology, waarbij je niet eerst een learning curve hebt en dus uren verspilt.
Vaak maakt trouwens de keuze voor een bepaald framework niet eens veel uit, als je maar kiest.
Felix, Felix, je verliest je scherpte in humor, ook al met je reactie op on-premises.
Dit is een artikel waar ik me nu helemaal in kan vinden! Hij zeikt de IT totaal niet af, maar doet waarnemingen die ik ook doe.
Laatst was ik op een worskhop AngularJS en kregen we een zip met wat source code voor de opdrachten. Meer dan 50.000 files en zoveel diepe dir’s dan we het uiteindelijk in Windows via een Git client moesten doen omdat Windows het vanuit de Zip niet aankon…. en dat was een hele eenvoudige site (uiteraard met Bower, npm, the works).
Zoals een front-end developer van mij zei: “front-end is Javascript, en Javascript frameworks zijn ghetto’s”
En zo is het. In een tijd met de opkomst van Mac’s en Linux worden fat native clients steeds minder populair. Applicaties worden dus voor de browser geschreven naast de diverse mobile OS-sen zoals IOS / Android / Windows.
Daar is het Javascript wat de klok slaat. Om de tekortkoming te mitigeren en het gebruik een hefboom te geven zijn daar dus die frameworks voor alle uitdagingen, maar naast dat ze soms opkomen als sterren, storten ze soms naar beneden als meteoren. Leuk als je net een jaar ervaring opgedaan hebt en het blijkt dat je op een dood paard gewed hebt.
AngularJS heeft een *enorm* momentum maar de nieuwe (nog niet uit) 2.0 is niet backwards compatible met het huidige 1.4. Een enorme rode vlag toch kan ik sommige ontwikkelaars daarvan overtuigen.
Dan heb je nog het “heilige” wachten op de webcomponents.
“It’s a jungle out there” en zoals Peter van Eijk eens mooi quote : “The better your four wheel drive, the further out you get stuck in the jungle”
Persoonlijk wordt ik er helemaal beroerd van wat er allemaal op me af komt als software architect. Zoals Friso schrijft, soms voor korte projecten ben ik langer aan het kiezen dan het bouwen zelf.
De laatste tijd doen we aardig wat Python (JSON REST API’s / ReactJS / Flask / Django om maar wat te noemen en dat is nog niet de helft)
en besef ik me hoe heerlijk eenvoudig .NET eigenlijk is. Maarja, alles draait om front-end….
Dus nogmaals, top stuk Friso!
PS: Felix, ik ben zeer zeker geen Azure only. Ik gebruik veel meer AWS diensten, maar ook behoorlijk wat Azure. Azure is een warm bad, maar met AWS kun je veel meer en de billing van Azure is nu nog een draak, daarnaast is de Azure portal rete-traag en gebruik ik toch nog vaker de GUI dan de powershell.
@Felix
Ergens heeft de auteur een punt, paradox van de paradigma’s is dat we teveel losstaande oplossingen en te weinig inzicht hebben. Maar het is de business die vernieuwing wil en dat dit niet altijd een verbetering is zien we als 0.9 ‘lightweight’ versie tot een 11.2 ‘heavyweight’ versie evolueert. Toen we van Systems of Record waarbij we digitale substituut van bewerking of levering vastlegden naar Systems of Engagement gingen toen begon de ellende met het CRUD principe.
Schalen van bewerkingen als Create, Read, Update en Delete zijn namelijk nogal lastig als je één bron van waarheid wilt hebben. Ook Google begrijpt nu dat je de Read misschien makkelijk kun schalen maar dat het dus heel wat anders wordt voor de overige bewerkingen.
CRUD is achterhaald Ewout. Het is nu veelal Create en hooguit een Tombstone als logische delete. Wat bedoel je overigens met dat Google dit nu begrijpt? Volgens mij schaalt Google meer dan alleen read en doen ze dat prima, of doel je nu weer op het recht om vergeten te worden en bijbehorende processen?
Schaalbaar zijn in ACID is helemaal niet lastig, maar als je heel veel nodes hebt die door velen tegelijk verandert kunnen worden, dan heb je een uitdaging, maar veelal is ACID in de “open wereld” geen probleem en zijn businesses klein genoeg om 1 bron van waarheid te kunnen hebben voor kritische systemen zoals geldstromen.
En de business heeft weinig met dit fenomeen te maken, die weten al helemaal niet dat dit (JS frameworks) speelt en wat dit betekent.
@Henri
Hoe je het technisch invult is volgens mij dus precies waar het verhaal om gaat, als één principe niet past dan hebben we andere……
Henri wil helemaal geen Azure, AWS mag ook als het maar maar web frontend werkt, dat zuigt namelijk. IT vindt hij prachtig, al wordt hij beroerd van wat er wat er allemaal op hem afkomt als software architect. Net als Friso, die geeft ook adviezen.
Jullie zouden eens wat wat moeten presenteren op die IT girls day : Dames, IT is eerst wekenlang shoppen en dan met spullen thuis komen die je niet nodig had terwijl ze nog vroegen of het onsje lighter mocht zijn. Wellicht komt Ewout helpen. Die gaat uitleggen dat we teveel losstaande oplossingen en te weinig inzicht hebben. Maar das de schuld van de business. De software architecten hebben elkaar gevonden, ze weten het ook niet meer. Whats next ? “Software Architecture omarmt light weight”, want dan zakt je jeep die je zelf bestuurt, tenminste niet zo diep weg ? Een opinie waar men het hier blijkbaar mee eens is. Lezen en Schrijven en waarheden zijn lastig. Ik weet er alles van. Maar jammeren dat het allemaal zo moeilijk is en dat business en mehoden en zelfs “het hele Internet” 🙂 allemaal niet meewerken.. Hoe diep kun je zakken als IT architect ? Zet dat maar op je persoonlijk curriculum 😛
@Henri, thanks. Het Angular gebeuren vind ik ook een typerend voorbeeld. Met de nieuwe versie gooien ze allerlei concepten compleet op de schop terwijl vanwege het huidige momentum veel bedrijven vol gas op Angular hebben ingezet. Angular 2.0 kun je bijna als een ander framework beschouwen. En zo is het wel vaker met 2.0 versies trouwens. Ik ken nog steeds applicaties die op het oude struts 1 framework zijn gebaseerd omdat upgrade naar 2 zoveel werk behelst. En ook bijv. Maven of Play heeft zulke grote verschillen gekend.
@Felix “Lezen en Schrijven en waarheden zijn lastig.” – ik zou daar het woord ‘interpreteren’ aan willen toevoegen, want ik heb geen idee hoe ik je opmerkingen moet plaatsen. Poetisch is het in elk geval wel. Maar misschien was dat je bedoeling helemaal niet.
O, en ik zie dat Girl’s Day een Koreaans bandje is met schattige meisjes die net gisteren hun nieuwe single hebben aangekondigd: “Hello Bubble”. Mooie titel. https://youtu.be/KDJqNL-gZhI
Goh, hier doen we de mensheid ook geen plezier mee zo te lezen.
Blijkbaar beschikken informatie architecten ook over menselijke eigenschappen 😛
Keuzes , keuzes , keuzes… tja, dat is nu eenmaal uw specialisme!
Wacht, ik mis nog 1 belangrijk item, namelijk wat kost me dat?
Opdrachtgevers maakt het eigenlijk helemaal niks uit hoe de applicatie tot stand komt, als ie er maar snel komt , goed en gemakkelijk te onderhouden is , en niet al te veel kost, althans zo lijkt de tendens!
Ik meen me te herinneren dat er ooit iets is voorgesteld als het “Constructive Cost Model”. Welk framework-techniek u gebruikt vindt ik prima hoor, dat is uw voorkeur en keuze maar wat kost me uw keuze?
En, kunt u mij dat op voorhand, vertellen?