Silviu Macedon
Founder & Principal Architect
Ondernemingen transformeren door architectuurexcellentie
Ik heb Fintexis opgericht vanuit een heldere overtuiging: goede architectuur is de basis van elke succesvolle technologie-investering in de enterprise. Te veel organisaties worstelen met systemen die niet kunnen schalen, integraties die breken en technologiebeslissingen die zonder strategische context worden genomen.
Wij bestaan om dat te veranderen. Ons team van gecertificeerde architecten werkt samen met organisaties om technologiearchitecturen te ontwerpen, valideren en evolueren die robuust en schaalbaar zijn en aansluiten op de bedrijfsstrategie.
End-to-end architectuuradvies
Wij bieden allesomvattende architectuurdiensten die de volledige levenscyclus beslaan -- van strategische planning en ontwerp tot implementatiebegeleiding en continue evolutie. Ons werk omvat vijf kerndisciplines:
Enterprise-architectuur
Afstemming van business en technologie, capability modeling en architectuurgovernance
Meer informatieSoftware-architectuur
Microservices, API-ontwerp, domain-driven design en event-driven systemen
Meer informatieSolution-architectuur
Integratieontwerp, technische due diligence en architecture decision records
Meer informatieCloud-architectuur
Cloudmigratie, landing zones, multi-cloudstrategie en platform engineering
Meer informatieSecurity-architectuur
Zero Trust-ontwerp, threat modeling, IAM en compliance-architectuur
Meer informatiePractitioners, geen slidedecks
Elke architect in uw project heeft de systemen die hij ontwerpt zelf gebouwd en beheerd. Wij leveren werkende architectuur, geen theoretische frameworks.
Resultaten boven uren
We structureren opdrachten rond meetbare deliverables en bedrijfsresultaten, niet rond declarabele uren. U weet wat u krijgt.
Kennisoverdracht ingebouwd
Uw teams worden sterker bij elke opdracht. We bouwen uw interne capaciteit op naast de architectuur zelf.
Door de sector gecertificeerde expertise
TOGAF, ISAQB, ArchiMate, AWS, Azure, Kubernetes -- onze certificeringen worden onderbouwd door toepassing in de praktijk, in diverse sectoren.
Silviu Macedon
Founder & Principal Architect
"Architectuur gaat niet over het nemen van technologiebeslissingen. Het gaat over het maken van de juiste afwegingen, zodat technologie de business dient -- vandaag en morgen."
Drie rollen, drie vragen.
Dezelfde architectuurbeslissing ziet er anders uit, afhankelijk van waar u verantwoordelijk voor bent. Dit betekent zij voor elk van u.
Verlaagt dit risico en kosten — en hoe snel?
- Architectuurbeslissingen gekoppeld aan commerciële uitkomsten, niet aan technologievoorkeur
- Leveranciersonafhankelijkheid beschermt uw onderhandelingspositie en uw uitstapopties
- Een beoordeling in 30–45 dagen levert een begrote routekaart voordat u budget vastlegt
Hoe bestuur ik een portfolio dat ik niet heb ontworpen?
- Een gemodelleerd applicatielandschap en capaciteitenkaart om op te plannen
- Technische schuld zichtbaar gemaakt en geprioriteerd op bedrijfsimpact, niet op ouderdom
- Bestuur dat personeelsverloop overleeft — beslissingen vastgelegd, niet onthouden
Houdt dit stand bij de oplevering?
- Patronen gekozen voor uw domein, gedocumenteerd in C4, arc42 en decision records
- Beveiliging en kwaliteit ingebouwd, niet er de week voor een audit aan geplakt
- Wij bouwen de teams die de systemen bouwen — de capaciteit blijft bij u
De twee stille moordenaars van enterprise-technologie
In bijna twee decennia enterprise-opdrachten falen de projecten die mislukken zelden door verkeerde technologiekeuzes. Ze falen omdat architectuurrisico onzichtbaar bleef tot het een crisis werd, en omdat technische schuld zich mocht opstapelen totdat ze het vermogen van de organisatie om te veranderen verlamde.
van de enterprise-IT-budgetten gaat, volgens sectorraming, naar het onderhoud van bestaande systemen in plaats van het bouwen van nieuwe capabilities
van de productie-incidenten is, volgens sectoronderzoek, te herleiden tot bekende, niet-gemitigeerde architectuurrisico's
de kosten van het remediëren van technische schuld versus het voorkomen ervan tijdens het initiële ontwerp
Architectuurrisico is een bedrijfsrisico
Elke architectuurbeslissing draagt risico met zich mee. De vraag is niet of er risico bestaat — het is of het wordt geïdentificeerd, gekwantificeerd en beheerd. De meeste organisaties ontdekken hun architectuurrisico's op de harde manier: tijdens een productiestoring, een mislukte audit, een gemist marktvenster of een fusie-integratie die onverenigbare systemen blootlegt.
Onze aanpak van architectuurrisico
Risico-identificatie op architectuurniveau
Gekwantificeerd risico — geen onderbuikgevoel
Risicomitigatie ingebouwd in de architectuur
Continue risicomonitoring
Technische schuld is echte schuld — en ze stapelt zich op
Technische schuld is het meest misverstane begrip in enterprise-technologie. Het is niet louter 'rommelige code'. Het is de cumulatieve kost van elke shortcut, elke uitgestelde beslissing, elke workaround die tijdelijk bedoeld was. Net als financiële schuld stapelt ze zich op. Anders dan financiële schuld wordt ze zelden gemeten, gerapporteerd of bestuurd. Organisaties die technische schuld negeren, besparen geen geld — ze lenen van hun toekomstige zelf tegen een rente die ze niet kunnen zien.
Hoe wij technische schuld aanpakken
Inventarisatie en classificatie van schuld
Scoring van bedrijfsimpact
Schuldreductie geïntegreerd in delivery
Architectuurgovernance om nieuwe schuld te voorkomen
"De organisaties die op de lange termijn winnen, zijn niet die met de nieuwste technologie. Het zijn die welke hun architectuurrisico's proactief beheren en technische schuld met dezelfde discipline behandelen als financiële schuld. Dit is een kernonderdeel van elke architectuuropdracht die we leveren."
Security door architectuur. Kwaliteit door discipline.
Security en kwaliteit zijn geen features die u aan het eind toevoegt. Het zijn eigenschappen die voortkomen uit architectuurbeslissingen die aan het begin worden genomen. Wanneer security wordt aangebouwd en kwaliteit erin wordt getest, zijn beide broos. Wanneer ze worden ingebouwd, worden ze structureel — veerkrachtig, verifieerbaar en duurzaam.
Security is een architectuurbeslissing
De meeste securityinbreuken misbruiken geen exotische zero-day-kwetsbaarheden. Ze misbruiken architecturale zwakheden: te ruime toegangscontroles, onversleutelde data at rest, ontbrekende invoervalidatie, overmatig vertrouwen tussen services en authenticatiemechanismen die werden aangebouwd in plaats van ingebouwd. Wij behandelen security als een eersteklas architectuurzorg — aanwezig in elke ontwerpbeslissing, niet achteraf gereviewd.
Zero Trust als architectuurprincipe
Threat modeling tijdens het ontwerp, niet erna
Security-architectuur voor gereguleerde sectoren
Veilige software supply chain
Kwaliteit is geen testen — het is architectuur
Testen vindt defecten. Architectuur voorkomt ze. De meest effectieve kwaliteitsstrategie is er een waarbij de architectuur hele categorieën bugs onmogelijk maakt — via strong typing, immutability, duidelijke modulegrenzen en goed gedefinieerde contracten. Testen wordt dan een verificatie van de architecturale intentie, geen vangnet voor structurele zwakte.
Architecture fitness functions
Quality gates in elke fase
Contract-first-development
Observability als kwaliteitsbevorderaar
Waar security en kwaliteit elkaar ontmoeten
Security en kwaliteit zijn geen aparte zorgen — ze versterken elkaar. Een goed ontworpen systeem is inherent veiliger omdat de grenzen duidelijk zijn, de datastromen gedefinieerd zijn en het gedrag observeerbaar is. Een veilig systeem is inherent van hogere kwaliteit omdat het randgevallen afhandelt, invoer valideert en gracieus faalt. Wij ontwerpen ze als één discipline.
Immutable infrastructure elimineert configuratiedrift — tegelijk een winst voor security en betrouwbaarheid
Sterke API-contracten voorkomen zowel integratiebugs als injectie-aanvallen met één ontwerpbeslissing
Geautomatiseerde compliancecontroles dienen als quality gates die tevens auditors tevredenstellen
Observability-pijplijnen detecteren zowel prestatiedegradatie als security-anomalieën uit dezelfde data
Architecture decision records creëren verantwoording voor zowel kwaliteitsafwegingen als keuzes in securityhouding
Cloud is geen bestemming.
Het is een architectuurbeslissing.
Elke organisatie zit op een cloudreis — maar niet elke organisatie zou op dezelfde reis moeten zitten. We hebben ondernemingen miljoenen zien verspillen aan het migreren van workloads die on-premise hadden moeten blijven, en transformerende kansen zien missen door te conservatief te zijn. Cloudstrategie moet gedreven worden door bedrijfsvereisten, workloadkenmerken en total cost of ownership — niet door leveranciersmarketing of sectortrends.
Onze aanpak van cloud-architectuur
We bevelen niet 'ga naar de cloud' aan. We ontwerpen de juiste cloudstrategie voor elke workload, elk bedrijfsdomein en elke regelgevende context. Soms betekent dat public cloud. Soms hybride. Soms betekent het precies blijven waar u bent.
Workloadgedreven cloudstrategie
Niet elke workload hoort thuis in de cloud, en die welke daar wél thuishoren, horen zelden in dezelfde cloud — of zelfs hetzelfde servicemodel. We classificeren elke workload op zijn computeprofiel, datagevoeligheid, latentievereisten, compliancebeperkingen en kostenkenmerken. Het resultaat is een precieze plaatsingsstrategie: welke workloads migreren, welke moderniseren, welke blijven, en in welke volgorde. Geen blanco lift-and-shift. Geen cloud om de cloud.
Multi-cloudgovernance en porteerbaarheid
Multi-cloud is een realiteit voor de meeste ondernemingen — hetzij door strategie, hetzij door overname. We ontwerpen governanceframeworks die uniforme zichtbaarheid bieden over cloudproviders heen: consistent identiteitsbeheer, gecentraliseerde policyhandhaving, cross-cloud networking en gestandaardiseerde deploymentpijplijnen. Waar passend ontwerpen we porteerbaarheidslagen met containerisatie, infrastructure-as-code en cloud-agnostische serviceabstracties, zodat overstappen tussen providers een realistische optie blijft in plaats van een theoretische.
Typische cloudkostenreductie die haalbaar is via architectuuroptimalisatie
Vendor lock-in door ontwerp — elke cloudaanbeveling bevat een exitstrategie
Standaardhouding — pure cloud alleen wanneer de business het vereist
Legacy is geen technologieprobleem.
Het is een bedrijfsbeperking.
Elke onderneming draagt legacy met zich mee — systemen die goed ontworpen waren voor hun tijd, maar nu het vermogen van de organisatie om zich aan te passen, te integreren en te concurreren beperken. Het antwoord is nooit 'alles herschrijven'. Het antwoord is een gedisciplineerde, bedrijfsgeprioriteerde moderniseringsstrategie die incrementele waarde levert terwijl het risico bij elke stap wordt beheerd.
Modernisering zonder de big bang
We hebben te veel ondernemingen volledige herschrijvingen zien proberen die jaren duurden, een veelvoud van het budget kostten en minder opleverden dan wat ze vervingen. Onze aanpak is fundamenteel incrementeel: ontleed het probleem, prioriteer op bedrijfswaarde, lever continu en valideer bij elke mijlpaal.
Moderniseringsassessment en domeinmapping
Voordat we ook maar één regel code veranderen, brengen we het bestaande landschap in kaart: bedrijfscapabilities, systeemgrenzen, datastromen, integratiepunten en organisatorische afhankelijkheden. We gebruiken domain-driven discovery om bounded contexts binnen monolithische systemen te identificeren en beoordelen de moderniseringsprioriteit van elk domein op basis van bedrijfswaarde, veranderfrequentie, operationeel risico en concentratie van technische schuld. Het resultaat is een heatmap die u precies vertelt waar u eerst moet investeren.
Strangler-fig-patroon — bewezen op schaal
We zijn sterke voorstanders van de strangler-fig-aanpak: legacy-capabilities incrementeel vervangen door nieuwe services naast het bestaande systeem te bouwen, verkeer geleidelijk te routeren en legacy-componenten pas buiten gebruik te stellen nadat de nieuwe service zich in productie heeft bewezen. Dit elimineert het 'big bang'-risico volledig. Op elk punt in de moderniseringsreis heeft u een werkend systeem. Als prioriteiten verschuiven, kunt u de modernisering pauzeren en heeft u nog steeds alle tot dan toe geleverde waarde vastgelegd.
De moderniseringsparadox
De systemen die het meest aan modernisering toe zijn, zijn vaak juist die welke de organisatie het meest vreest te veranderen — omdat ze het meest kritiek, het minst begrepen en het sterkst gekoppeld zijn. Onze methodologie is specifiek ontworpen voor deze realiteit: we verlagen risico door incrementele delivery, we bouwen begrip op door domeindiscovery en we ontkoppelen via architecturale patronen — niet via wishful thinking.
AI zonder architectuur
is slechts een duur experiment.
Elke organisatie wil AI. Weinige hebben de architecturale basis om het op schaal in te zetten. We zien steeds hetzelfde patroon: briljante proof-of-concept-modellen die de productie niet bereiken omdat de onderliggende datapijplijnen broos zijn, de serving-infrastructuur niet bestaat, de monitoring ontbreekt en het governanceframework nooit is ontworpen. Wij zorgen dat uw architectuur AI-ready is — niet alleen AI-nieuwsgierig.
Van experiment naar enterprise-AI
We bouwen geen AI-modellen. We ontwerpen het platform, de datafundering en de operationele infrastructuur waarmee AI en ML kunnen evolueren van geïsoleerde experimenten naar bestuurde, schaalbare, productiewaardige capabilities.
AI-ready data-architectuur
AI is slechts zo goed als de data die het consumeert. We ontwerpen data-architecturen die de fundering bieden die AI vereist: feature stores voor consistente modelinvoer, dataversiebeheer voor reproduceerbaarheid, realtime streaming-pijplijnen voor modellen die live data nodig hebben, en datakwaliteitsframeworks die problemen opvangen voordat ze modeluitvoer corrumperen. Of uw datastrategie nu een lakehouse, data mesh of federated model volgt, wij zorgen dat de architectuur zowel analytische als AI-workloads ondersteunt zonder duplicatie of drift.
MLOps en modellevenscyclusbeheer
Een model in productie krijgen is het makkelijke deel. Het gezond houden in productie is waar de meeste organisaties falen. We ontwerpen MLOps-platformen die de volledige modellevenscyclus beheren: experiment tracking, geautomatiseerde trainingspijplijnen, modelversiebeheer, A/B-testinfrastructuur, canary-deployments, prestatiemonitoring en geautomatiseerde retraining-triggers. De architectuur zorgt dat modeldeployment net zo gedisciplineerd en herhaalbaar is als applicatiedeployment.
Van de AI-projecten bereikt nooit de productie, volgens sectorraming — architectuur is het belangrijkste knelpunt
Governance-architectuur vanaf dag één ontworpen voor naleving van regelgeving
Van datafundering via MLOps tot productie-inferentie — volledig gearchitectureerd
U kunt geen goed systeem ontwerpen
zonder de organisatie te ontwerpen die het bouwt.
In 1967 stelde Melvin Conway vast dat organisaties systemen ontwerpen die hun eigen communicatiestructuren weerspiegelen. Zes decennia later blijft dit inzicht — bekend als de Wet van Conway — de meest ondergewaardeerde kracht in software-architectuur. We hebben het in elke opdracht bewezen gezien: de architectuur die een team produceert, wordt beperkt door de organisatie die haar produceert. Wilt u de architectuur veranderen, dan moet u ook bereid zijn de organisatie onder de loep te nemen.
De Wet van Conway is geen suggestie — het is een natuurkracht
Heeft uw organisatie vier teams, dan krijgt u een architectuur met vier componenten — ongeacht of vier componenten het juiste ontwerp is. Zijn uw teams georganiseerd per technologielaag (frontend, backend, database), dan krijgt u een gelaagde architectuur — zelfs wanneer een domeingerichte architectuur de business beter zou dienen. De Wet van Conway werkt of u het erkent of niet. De vraag is of u ermee ontwerpt of ertegen vecht.
Monolithische organisaties produceren monolithische systemen, zelfs wanneer ze microservices voorschrijven
Cross-team-afhankelijkheden in het organigram worden integratieknelpunten in de architectuur
De Inverse Conway Maneuver
Als de Wet van Conway ons vertelt dat de organisatiestructuur de architectuur beperkt, vertelt de inverse Conway maneuver ons om de organisatie bewust te ontwerpen om de architectuur te produceren die we willen. Dit is geen organisatietheorie — het is een architectuurstrategie.
Team Topologies als architectuurinput
We gebruiken het Team Topologies-framework om teamstructuren te ontwerpen die op natuurlijke wijze de gewenste systeemarchitectuur produceren. Stream-aligned teams zijn end-to-end eigenaar van bedrijfsdomeinen. Platformteams bieden self-service-infrastructuur. Enabling teams versnellen capaciteitsopbouw. Complicated-subsystem teams beheren specialistische domeinen. De teamstructuur wordt de architectuurblauwdruk — niet per ongeluk, maar door ontwerp.
Domeingerichte teamgrenzen
We helpen organisaties teams te herstructureren rond bedrijfsdomeinen in plaats van technologielagen. Wanneer een team eigenaar is van een complete bedrijfscapability — van API via bedrijfslogica tot data — wordt de architectuur op natuurlijke wijze domeingericht, losjes gekoppeld en onafhankelijk uitrolbaar. De organisatiegrens wordt de systeemgrens, en de Wet van Conway werkt vóór u in plaats van tegen u.
"De beste architectuur ontstaat wanneer de organisatie die haar bouwt bewust is ontworpen om haar te produceren. Al het andere is hopen dat de Wet van Conway voor uw bedrijf een uitzondering maakt. Dat zal ze niet doen."
Architectuurassessment
in 30 – 45 dagen
Onze kenmerkende opdracht levert binnen 30 tot 45 dagen een uitgebreide, bruikbare beoordeling van uw huidige architectuurlandschap. Geen discovery-fases van maanden. Geen theoretische rapporten die stof verzamelen. U ontvangt een heldere diagnose, een geprioriteerde roadmap en concrete vervolgstappen die uw teams onmiddellijk kunnen uitvoeren.
Zo beginnen de meeste van onze klantrelaties -- en het is ontworpen om op zichzelf staande waarde te bieden, of u ons nu verder inschakelt of niet.
Assessmenttijdlijn
Week 1 -- Discovery
Stakeholderinterviews, systeeminventarisatie, documentatiereview en in kaart brengen van beperkingen
Week 2 – 3 -- Diepgaande analyse
Assessment van architectuurkwaliteit, inventarisatie van technische schuld, schaalbaarheids- en securityevaluatie, risicoanalyse
Week 4 – 5 -- Ontwerp en roadmap
Doelarchitectuuropties, afwegingsanalyse, geprioriteerde aanbevelingen, transformatieroadmap
Week 6 -- Directiepresentatie
Presentatie van bevindingen aan de leiding, overdracht van gedetailleerd rapport, Q&A en afstemming over vervolgstappen
Wat u ontvangt
Wij bouwen de teams die uw systemen bouwen
Goede architectuur vereist goede teams. We ontwerpen niet alleen systemen -- we evalueren, selecteren en bereiden de mensen voor die ze zullen bouwen en onderhouden. Elke resource die we plaatsen, wordt grondig beoordeeld op de specifieke technische en culturele vereisten van uw project.
Onze kandidaten komen niet uit een database. Het zijn beproefde professionals uit ons uitgebreide netwerk, persoonlijk doorgelicht door onze senior architecten op technische diepgang, architecturaal denken en delivery-trackrecord. Wanneer ze bij uw project komen, zijn ze klaar vanaf dag één.
Ons doorlichtingsproces
Technische deep-dive-assessment
Architecturale probleemoplossingsoefeningen, systeemontwerpinterviews en code review-evaluaties uitgevoerd door onze senior architecten.
Projectspecifieke kalibratie
We matchen kandidaten op uw technology stack, domeincontext, teamdynamiek en deliverymethodologie -- geen generieke vaardigheidsmatrices.
Architectuurafstemmingstraining
Vóór inzet wordt elk teamlid gebrieft over uw architectuurprincipes, -standaarden en decision records, zodat ze vanaf de eerste sprint bijdragen.
Continu architecturaal toezicht
Onze architecten blijven betrokken om te waarborgen dat de delivery van het team afgestemd blijft op de architecturale intentie, met regelmatige reviews en coachingsessies.
Rollen die wij invullen
Solution- en software-architecten
Systeemontwerp, technisch leiderschap, ADR's
Senior en lead engineers
Java, .NET, Node.js, Go, cloud-native
DevOps- en platform-engineers
Kubernetes, CI/CD, IaC, observability
Security-engineers
AppSec, IAM, compliance-automatisering
Technical project- en delivery leads
Agile delivery, technische coördinatie
Geen detacheringsbureau
Wij zijn in de eerste plaats architecten. Elke kandidaat wordt geëvalueerd door een architectuurbril -- niet alleen op codeervaardigheid, maar op het vermogen om systeemcontext te begrijpen, gegronde afwegingen te maken en bij te dragen aan architecturale kwaliteit. Het verschil is meetbaar vanaf de eerste week.
Laten we uw architectuuruitdagingen bespreken
Elke opdracht begint met het begrijpen van uw context. Plan een vrijblijvend gesprek om te verkennen hoe we kunnen helpen.