Where should we be in three years?
Target architecture and modernisation
A target picture, a roadmap and documented decisions. Legacy systems move step by step, not in one risky jump.
Architecture that ships, scales and stays operable.
Independent architect for enterprise platforms and modernisation. More than 20 years, from writing code to leading platform teams and programmes. I design the target picture - and prove that it works.
- 20+ years
- building and modernising enterprise systems
- 15 years
- in insurance and financial services
- Architect and lead
- led platform and portal teams, set direction across multi-team programmes
- Monolith to SaaS
- a core platform turned into a cloud product line
Six questions I help answer
Where platform, application and process meet: for the leads who build the systems and the executives who carry the risk.
Can it run in the cloud, repeatably?
Cloud platforms and Infrastructure as Code
Kubernetes runtime standards and complete environments built from code, so every environment is the same and upgrades are boring.
Will it hold up on go-live day?
Reliability and observability
Rollouts without downtime, right-sizing on measured load, and one trace from the click to the database. Ready before go-live, not after the first incident.
Why is every front-end change slow?
Modular portals
From one big front end to modules that teams can build, test and release on their own.
Where do our rules actually live?
Process orchestration
Rules out of the database and into visible processes, with automation that hands over to a person when needed.
Can AI speed us up safely?
AI-assisted engineering
Clear rules, decision records and review, so a small team delivers like a larger one and the code stays understandable.
How far can we extend INSIS without blocking upgrades?
Deep experience with INSIS
I helped build INSIS from the inside, including its cloud runtime. Today I help insurers use it as a headless core behind their own portals, and extend it without losing the upgrade path.
- Headless with your own portals, or the standard INSIS screens: where each one pays off
- Customising where the platform expects it, so an upgrade stays a release, not a project
- Extensions as separate add-ons that plug into INSIS security and the API gateway, and scale on their own
- A cloud runtime that is right-sized and observable, set up by someone who helped build it
Teams and programmes, not only diagrams
Led platform and portal teams
As head of platform engineering and head of digital channels: technical direction, standards, and alignment with product, security and operations.
Programmes across many teams
Several cross-functional teams in a scaled agile programme, with one architecture and one plan across team boundaries.
At the table with the business
Strategy, regulatory requirements and pre-sales for large enterprise deals, with trade-offs explained in plain language.
How I bring this today
As an advisor to CTOs, programme leads and architecture boards, with a defined scope and alongside your own leadership.
Proof from past work
Three examples: an insurance software vendor, an insurer and a global consultancy.
A core platform becomes a SaaS product
- Situation
- An insurance suite ran as a monolith, installed separately for each customer.
- What I did
- Led the move to Kubernetes and designed the automation that builds complete environments from one model.
- Result
- A SaaS product line, with reproducible environments and lower operating cost.
Life insurance sales platform, nine years
- Situation
- A business-critical quote and application platform, connected to many back-end systems.
- What I did
- Technical lead for the delivery team, including the move to a modern web front end.
- Result
- One of the insurer's most important internal tools, evolved for almost a decade.
From prototype to an international product
- Situation
- Procurement consultants needed a decision-support tool.
- What I did
- Co-founded the company, designed the system and led the engineering team.
- Result
- Used in projects in Brazil, Spain, Italy and the United States.
Start small, decide on facts
Most engagements start with a short assessment with a fixed scope and a written result. You decide the next step on that basis.
01
Defined results
Packages with tangible outcomes: architectures, decision records, reviews, measurements.
02
Measure, then decide
Performance, cost and complexity are measured, not guessed.
03
Built to hand over
Your teams own the result. Standards, documentation and coaching are part of the work.
Typical engagements
Scoped work packages Remote-first from MunichArchitecture review
A second opinion on a system, plan or vendor proposal, or technical due diligence.
Target architecture and roadmap
Where you want to be and the steps to get there.
Modernisation advisory
Guidance for a programme over several months, with defined packages per phase.
Production readiness assessment
Is it ready for go-live, and what has to happen first.
Reference implementation
Working proof that an approach holds up under real conditions.
- Cloud platform
- KubernetesAKSAzureDockerHelmcdk8sOperatorsAutoscaling
- Automation and delivery
- Infrastructure as CodeCI/CDAzure DevOpsEnvironment automation
- Reliability and observability
- OpenTelemetryDynatraceDistributed tracingStructured loggingDisaster recoveryMulti-region
- Security and identity
- Entra IDKeycloakOAuth 2.0 / OIDCEncryption in transitKey managementData sovereignty
- Integration and back end
- Spring BootSpring Cloud GatewayRabbitMQRESTAPI gatewaysOracle
- Front end
- ReactNext.jsTypeScriptAngularServer-side renderingBackend-for-FrontendMicro-frontends
- Process and rules
- Camunda 8BPMNDMNRule engines
- Legacy to modern
- WebLogicASP.NETMonolith to containersHeadless core systems
Let's talk
Planning a modernisation, stuck with a platform problem, or looking for a second opinion? A short message is usually the fastest way to find out if I can help.
- mark@markmunte.com
- linkedin.com/in/mark-munte
- Location
- Munich, Germany
- Languages
- German, English, Portuguese