Job Vacancies at Juru Holdings

Job Description

• The Integration & API Platform team has completed the API Security Architecture Framework, a GTT architecture-forum-approved framework covering six canonical security patterns (P1–P6) and a clean-slate extended architecture (P7–P9). The extended architecture introduces SPIFFE/SPIRE workload identity, OAuth 2.1 / FAPI 2.0, Open Policy Agent (OPA) for policy enforcement.
• The framework's four-phase roadmap now moves from design into prototyping — proving the target architecture works in practice and understanding what it will take for existing API consumers, across the L&S, Group Functions and Bank clusters, to migrate onto it.
• This engagement is the next step in that roadmap: build a working prototype of the extended security architecture, and turn the abstract framework into a concrete, consumer-facing remediation plan.
• The initial target architecture the platform is aligning to fronts the API gateway with PingAccess for authentication enforcement: PingAccess authenticates inbound consumer traffic, and the gateway is configured to trust and accept traffic only from PingAccess, with the P7–P9 pattern set layered on top of that trust boundary.

Purpose of the Engagement

• Prototype the PingAccess-fronted gateway architecture as the initial target state — PingAccess enforcing authentication ahead of the gateway, and the gateway trusting only PingAccess-originated traffic — as the foundation for the fuller P7–P9 pattern set (SPIFFE/SPIRE identity issuance, OAuth 2.1 / FAPI 2.0 token flows, OPA policy decisions, and Vault-managed secrets/certificates).
• Assess consumer impact — determine what changes the migration requires of existing API consumers, by cluster and by application, and classify the effort and risk involved.
• Design remediation solutions — produce concrete, implementable remediation guidance mapped to the technology stacks consumers actually run, so consuming teams have a clear path to compliance rather than a framework document.

Scope of Work

In scope

• Prototype build: stand up a working reference implementation with PingAccess fronting the platform's incumbent Gravitee API gateway for authentication enforcement, the gateway configured to trust and accept traffic only from PingAccess, and the P7–P9 pattern set layered on top — all in a non-production environment.
• Consumer inventory & tech-stack discovery: working with cluster architects across L&S, Group Functions and the Bank cluster, inventory API consumers affected by the migration and identify each consumer's authentication method, language/runtime, and hosting model.
• Gap and impact analysis: for each consumer (or consumer archetype), document the delta between current-state and target-state authentication/identity requirements, and classify remediation effort (low / medium / high) and risk.
• Remediation playbooks: produce reusable, stack-specific remediation patterns (e.g. Java/Spring, .NET, Node.js, IBM ACE-based integration flows, and other stacks identified during discovery), each with sample configuration, code snippets, and a validation checklist.
• Rollout recommendation: propose a phased consumer migration sequence, informed by the P3/P5.1.5 HIGH-severity gap priority and the BP2027 roadmap.
• Documentation & knowledge transfer: prototype build notes and runbook, consumer impact report, remediation playbooks, and a walkthrough session with the platform team and cluster architects.

Out of scope

• Production rollout or execution of consumer remediation — this engagement produces the prototype, the impact assessment and the remediation designs, not the migration itself.
• Procurement, licensing or contract negotiation for any tooling used in the prototype.
• Security domains outside API authentication, identity and policy enforcement (e.g. network security, data loss prevention).

Key Deliverables

Deliverable Description

• Prototype environment   Working non-production prototype: PingAccess fronting Gravitee with gateway trust restricted to PingAccess-originated traffic, plus P7–P9 (SPIFFE/SPIRE, OAuth 2.1/FAPI 2.0, OPA, Vault) covering P3 and P5.1.5 patterns
• Consumer impact report  Consumer/application inventory with tech-stack profile, gap analysis, and effort/risk classification per cluster
• Remediation playbooks  Stack-specific remediation guidance with sample configuration and validation checklists
• Rollout recommendation Proposed phased migration sequence aligned to BP2027 roadmap and gap severity
• Build runbook & handover Prototype build/runbook documentation and knowledge-transfer session to the platform team

Required Skills & Experience

• Hands-on experience with PingAccess (or the broader Ping Identity suite) for gateway-fronting authentication enforcement and trust/network configuration.
• Hands-on implementation experience with OAuth 2.0/2.1, OIDC and FAPI 2.0 flows.
• Working knowledge of SPIFFE/SPIRE or equivalent workload-identity / mTLS frameworks.
• Policy-as-code experience with Open Policy Agent (OPA) and Rego, or a comparable policy engine.
• API gateway experience; familiarity with Gravitee is advantageous (Gravitee is the incumbent gateway).
• Demonstrated ability to assess and remediate API consumers across heterogeneous technology stacks.
• Experience in financial services or another regulated environment is advantageous.
• Strong stakeholder communication — able to translate architecture and security requirements into guidance consuming teams can act on.

Engagement Governance

• Reports to the Architect / Platform Owner for the Integration & API Platform.
• Works alongside the platform team and cluster architects (L&S, Group Functions, Bank) for consumer discovery and validation.
• Progress reviewed on a regular cadence against the deliverables in Section 4.
• All prototype artefacts, code and documentation are delivered as the client's property on completion or termination of the engagement.

Acceptance Criteria

• Prototype demonstrably enforces gateway trust restricted to PingAccess-originated traffic, plus the P3 and P5.1.5 target-state patterns, end to end in the non-production environment.
• Consumer impact report covers all in-scope consumers identified during discovery, with no unclassified consumers outstanding.
• At least one remediation playbook produced per distinct technology stack identified in the consumer inventory.
• Deliverables reviewed and formally accepted by the Architect / Platform Owner.

go to method of application »

Purpose of the Engagement

• Prove a containerisation pattern for migrating IBM ACE integration workloads onto AWS container services, implemented in Go and/or Java.
• Deliver pilot workload(s) into a running state on AWS, replacing or wrapping selected existing ACE integration flows.
• Produce reusable platform scaffolding and a migration playbook — reference architecture, CI/CD pipeline templates, and a Go-vs-Java decision framework — so the pattern can be applied across the remaining ~300-application estate.

Scope of Work

In scope

• Platform architecture: confirm target container platform (ECS and/or EKS) and compute model (Fargate vs EC2) for the pilot, building on the platform team's existing ECS-vs-EKS evaluation.
• Go vs Java decision framework: define selection criteria for choosing Go or Java per workload archetype (e.g. throughput, message-flow complexity, team familiarity, library/connector availability), and apply it to the pilot workloads.
• Pilot implementation: select 15 representative ACE workloads, reverse-engineer their integration logic, and re-implement or wrap them as containerised services.
• Platform scaffolding: base container images, CI/CD pipeline templates, configuration and secrets handling, and observability/logging integration for containerised workloads.
• Migration playbook: a documented, repeatable pattern (with worked examples from the pilot) that the wider ~300-application programme can follow.
• Documentation & knowledge transfer: architecture decision records (ADRs), runbooks, and a walkthrough session with the platform and integration teams.

Out of scope

• Migration of the full ~300-application estate — this engagement delivers the pilot and the reusable pattern, not the programme-wide rollout.
• Selection of the long-term target migration approach for the remaining ~300-application estate — that decision sits with the platform architecture team.
• Underlying AWS landing-zone, networking or IAM design outside what the pilot workloads require.

Roles & Responsibilities

Role                                                                  

• Senior Software / Platform Engineer (Lead)    

Responsibilities

• Owns the containerisation architecture and platform decisions (ECS vs EKS, Fargate vs EC2); defines the Go-vs-Java decision framework; builds platform scaffolding (base images, CI/CD templates, observability integration); defines the migration pattern and playbook; produces ADRs; provides technical direction and review for the Mid-level Engineer.

Key Deliverables

Deliverable                                                                 

• Platform reference architecture                     
• Go vs Java decision framework                       
• Pilot workload(s) in production-ready state     
• Platform scaffolding                                         
• Migration playbook                                         
• ADRs & handover                                             

Description

• Confirmed container platform/compute model for the pilot, with supporting rationale
• Documented selection criteria, applied to the pilot workloads
• Selected ACE workloads running as containerised services on AWS
• Base images, CI/CD pipeline templates, config/secrets and observability integration
•  Repeatable pattern with worked pilot examples, for use across the ~300-app estate

Required Skills & Experience

• Strong proficiency in Go and Java, with the judgement to choose between them per use case.
• Hands-on experience with AWS container services — ECS, EKS and Fargate — including production operation.
• Experience with, or fast ability to learn, IBM ACE / IIB integration flow concepts, sufficient to reverse-engineer existing flows.
• CI/CD pipeline design (e.g. GitHub Actions, AWS CodePipeline, or equivalent) and Docker/container fundamentals.
• Observability/APM integration experience; familiarity with Dynatrace is advantageous.
• Track record leading platform or application migrations at scale, ideally in a regulated/financial-services environment.
• Architecture decision records, runbooks and knowledge-transfer session

Engagement Governance

• Work is coordinated with the wider container modernisation initiative and the platform team's existing ECS/EKS evaluation.
• Progress reviewed on a regular cadence against the deliverables in Section 5.
• All code, configuration, pipelines and documentation produced are delivered as the client's property on completion or termination of the engagement.

Acceptance Criteria

• Pilot workload(s) running successfully in the target platform, functionally equivalent to the original ACE flow(s).
• Go vs Java decision framework documented and demonstrably applied to the workload selection.
• Migration playbook reviewed and confirmed as usable by the platform team for subsequent workloads.
• Deliverables reviewed and formally accepted by the Architect / Platform Owner.