Senior Solutions Architect — Application Modernisation

Dit ga je doen

About the role (32 prefer 40 hours)

We are modernising a portfolio of legacy line-of-business applications — spanning Oracle APEX / PL/SQL and mainframe workloads — into cloud-native Java / Spring Boot services with an Angular front end, running on AWS EKS. Mainframe migration and decommissioning is one of our major local IT initiatives. We are looking for a senior Solutions Architect who brings the right mindset to that challenge: someone who will dig into systems no one fully understands any more, recover how they actually behave, design the path to a modern target, and plan the orderly retirement of what they replace. You will be backed by AI tooling and internal accelerators we are actively building, and by mainframe SMEs — so the priority is investigative drive, sound architectural judgement and ownership, not prior depth in every legacy technology in the estate.

Where the centre of gravity sits

This is primarily an analysis, discovery and planning role spanning both the APEX and mainframe estates. The architect leads assessment, owns the target architecture, migration patterns, decommissioning plan, sequencing and risk picture, and partners with mainframe SMEs for deep COBOL-level analysis. Hands-on architecture and design governance are part of the job, but day-to-day build leadership is not the main focus — candidates looking for a pure delivery-lead role are unlikely to be a fit.

What you'll have behind you

You won't be doing this with grep and willpower alone. We are building AI tooling and internal accelerators to speed up legacy code comprehension, translation and parity testing, and you'll have access to mainframe SMEs for deep COBOL-level analysis. We want someone who treats those as force multipliers — and who has ideas about how to make them better.

Key responsibilities

Assessment & discovery (primary focus)

• Lead discovery of the legacy portfolio: inventory applications, map data and integrations, and document the business logic — much of it undocumented — embedded in the source systems.

• Reverse-engineer Oracle APEX applications (pages, processes, computations, validations, shared components and server-side PL/SQL) to recover the true behaviour of the system, not just the database schema.

• Analyse mainframe workloads in the same way — COBOL / PL-I programs, JCL batch flows, VSAM data and CICS transactions — working with mainframe SMEs to recover business rules and data lineage from code where documentation is thin.

• Assess each workload for complexity, coupling, data sensitivity and migration risk, and classify it against the right strategy: retire, rehost, replatform, or refactor / re-architect.

• Produce the assessment artefacts the programme runs on: application inventory, dependency and data-flow maps, integration catalogue, and effort / complexity estimates.

• Use AWS Schema Conversion Tool (SCT) and Database Migration Service (DMS) to assess Oracle → PostgreSQL schema and PL/SQL conversion effort and surface conversion blockers early.

Target architecture & migration strategy

• Define the end-to-end target architecture for migrating workloads to Java / Spring Boot microservices with an Angular front end, deployed to AWS EKS.

• Design scalable, resilient, secure cloud-native architectures following the AWS Well-Architected Framework; select appropriate services (Aurora PostgreSQL, EKS, API Gateway, SQS / SNS, EventBridge, Lambda, S3).

• Develop reusable migration patterns, reference architectures and blueprints — including the strangler-fig pattern for incremental cutover — so approaches are consistent across streams.

• Define the data and logic migration approach: schema conversion, relocation of PL/SQL business logic into services, and re-platforming of batch jobs.

• Sequence the migration into waves with explicit dependencies, producing a phased roadmap that keeps the business running throughout cutover.

Mainframe migration & decommissioning

• Choose the right per-workload strategy across the mainframe estate — rehost / replatform / refactor / retire — balancing risk, cost and the decommissioning timeline.

• Plan the orderly retirement of decommissioned systems: data archival and retention (including legal hold and GDPR retention rules), reference-data and history strategy, and clean exit criteria for parallel runs.

• Map the dependency web into each mainframe application (upstream feeds, downstream consumers, scheduled batch, shared datasets) so nothing is switched off while something still depends on it.

• Build the business case inputs for decommissioning — MIPS / licence / support-contract cost retirement and capacity release — to help prioritise the sunset sequence.

Behavioural parity, testing & risk

• Plan how behavioural equivalence between the legacy and target systems will be established and proven characterization / golden-master testing, shadow running, and output reconciliation. This is where modernisation programmes most often fail and is a core part of the role.

• Own a programme-level risk register: identify and mitigate technical risks, hidden dependencies and data-integrity concerns across migration phases.

• Define cutover and rollback safety strategies so each wave can be reversed without business impact.

Stakeholder engagement & documentation

• Work with business stakeholders, product owners and engineering teams to align migration goals with business priorities.

• Communicate complex architectural decisions clearly to both technical and non-technical audiences, up to CTO / CIO level.

• Produce and maintain Architecture Decision Records (ADRs), reference documentation and roadmaps.

• Partner with security, DevOps and data teams to ensure compliance, governance and operational readiness.

Delivery enablement & governance (secondary)

• Provide technical leadership and mentoring to delivery teams during implementation.

• Define standards for Spring Boot services, CI/CD (GitHub Actions), testing strategy and Infrastructure as Code (Terraform / AWS CDK).

• Run architecture reviews and approve designs submitted by delivery teams.

• Embed security posture (GHAS, Wiz or equivalent) and observability (Prometheus, Grafana) expectations into the target patterns from day one.