Op het hoogste abstractieniveau lijken IT-systemen niet zo complex. Aan de ene kant zijn er schermpjes waarop informatie getoond wordt en/of ingevoerd kan worden. Aan de andere kant is er een database waar die gegevens in opgeslagen zijn/worden. Eventueel met nog wat koppelingen naar externe systemen.
Toch komt er veel meer bij kijken dan in eerste oogopslag misschien lijkt. Dat blijkt ook wel uit het feit dat deze problematiek (wij noemen dat 'architectural concerns') op 1000-en verschillende manieren opgelost kan worden. En daar ligt ook precies de oorzaak van een belangrijk probleem. Voorbeelden van deze 'architectural concerns' zijn:
- integriteit
- veiligheid
- prestatie
- robuustheid
- schaalbaarheid
- onderhoudbaarheid
- uitbreidbaarheid
- testbaarheid
- documentatie
Goed georganiseerde projecten beginnen met een haalbaarheidsstudie waarin de 'architectural concerns' bepaald worden en vervolgens een oplossing voor bedacht. Veel software architecten (vaak door zich zelf benoemde ontwikkelaars met een paar jaar ervaring) zijn niet in staat om alle 'architectural concerns' goed te inventariseren, laat staan daar adequate oplossingen voor kunnen bedenken. U kunt zich voorstellen dat dit een lang en moeizaam traject is, waar u uiteindelijk de rekening van oppakt. Slecht georganiseerde projecten beginnen meteen met hollen ... en lopen later genadeloos tegen de lamp. Nadat u hebt betaald.
Wij zijn goed voor meer dan 20 jaar aantoonbare ervaring in het ontwikkelen van deze systemen. We hebben tal van systemen neergezet die de toets der tijd ruimschoots hebben doorstaan. Met onze ervaring zagen we dat deze IT-systemen inderdaad complex zijn, maar de 'architectural concerns' iedere keer wel van dezelfde aard. Wij zijn toen de uitdaging aangegaan om te kijken of we niet iets van een 'referentie architectuur' konden opstellen, zodat we niet iedere keer opnieuw 'het wiel zouden moeten uitvinden'. Dat moest een architectuur zijn die aan onze eigen hoogste eisen zou moeten voldoen. We hosten zelf een paar grote systemen, en daar zitten geen hoofdpijndossiers tussen!
Dat is gelukt. Wij hebben deze architectuur weten te definiëren en durven te stellen dat meer dan 98% van alle systemen binnen deze architectuur vallen. En dat is dan ongeacht de bedrijfstak: logistiek, telecom, financiëel, utilities, publieke sector. We durven met iedereen de discussie aan die beweert dat dit niet zo zou zijn. Deze documentatie is vrijelijk te downloaden bij ons product Festa Engine (tab 'Resources').
Direct effect voor u is dat wij niet meer over de 'architectural concerns' hoeven na te denken en de haalbaarheidsstudie kunnen overslaan. Wij kunnen direct aan de slag met de realisatie van uw wensen. U profiteert hier concreet van al onze 'lessons learned'. Dat is voor u écht een zorg minder! Niks zo vervelend als u er in uw live-omgeving er achter komt dat:
- Data corrupt raakt in uw database
- Gegevens ongewild bij de verkeerde gebruikers terechtkomt
- Uw systeem gehacked wordt
- Het laden van schermen steeds langer op zich laat wachten naarmate het systeem groter wordt
- Het systeem om de haverklap uitvalt, dat wijzigingen naar loop van tijd steeds meer inspanning vergt
- U het systeem niet kunt opschalen als de load op uw systeem toeneemt
- Fouten in het systeem maar moeizaam kunnen worden opgelost (geen goede traceerbaarheid)
- IT-ers de uitspraak gaan bezigen: 'If it ain't broke, don't touch it'
- Het systeem alleen in de live omgeving fatsoenlijk te testen valt (mosterd na de maaltijd)
- Er geen (consistente) documentatie aanwezig is