Group Architect (Umhlanga) at Ignition Group

Description

Technical Direction and Design

Software architecture (primary focus)

• Owns domain boundaries and the decomposition of large service estates, and consolidates concepts that have been built more than once.
• Owns the standards for API and event contracts, including versioning, deprecation and schema ownership.
• Owns the data position: which system owns what, how it is reached across boundaries, and how personal information is protected.
• Owns the sanctioned technology set and its lifecycle, agreed with the Heads of Technology.
• Decides where business rules and process orchestration belong, and stops competing engines accumulating.
• Sets the approach for correctness-critical systems, for designing at scale, for building many products on shared foundations, and for isolating third-party failure.

Cloud and platform architecture

• Owns the target platform architecture and the identity, secrets, observability and resilience standards the central cloud team delivers against.
• Owns the group cloud position: where the estates converge, and where they stay different.

Delivery and Execution

• Builds reference implementations and proofs of concept, in application code as well as infrastructure.
• Reviews application and infrastructure changes with technical authority, including sitting with a team to refactor a boundary.
• Sets and approves the standards the group's application templates must meet. The development function builds the templates.
• Works in the group's delivery model, where AI assistants produce much of the code and humans are accountable for review.

Governance, Risk and Compliance

• Keeps the group-mandatory standard set deliberately small (Section 5) and justifies anything added to it.
• Owns the quality model: automated scanning is the hard gate, AI-assisted review is a quality pass, and AI is never the sole approval.
• Designs to POPIA, PCI-DSS and ISO 27001 obligations, with controls built into templates and the platform rather than relying on discipline.
• Treats cost as a design input and tests expensive choices against doing nothing.

Stakeholder and Business Partnering

• Convenes the group architecture forum with the Heads of Technology and business technology leads, where group standards are agreed rather than announced.
• Works with Heads of Technology as peers, winning adoption on merit and respecting that business units differ in domain, regulation and history.
• Presents architecture to leadership with options, cost, risk and a recommendation.
• Partners with Information Security, which supports the architecture function without owning delivery.

Continuous Improvement and Innovation

• Treats friction in the developer experience as an architectural defect, and acts on builder feedback.
• Drives down duplicated capability and technology version spread.
• Raises architectural capability across the engineering group.
• Evaluates new technology against what the group can realistically operate.

People Leadership

Not applicable: individual contributor role. (Cluster removed per template instruction.)

Requirements

• A relevant tertiary qualification is advantageous
• Architecture certifications such as TOGAF are neither required nor a differentiator.

Essential

• 10 or more years in software engineering, including substantial hands-on development.
• At least 2 years operating at architecture level, whatever the job title said. Staff and principal engineers who have owned architecture for a multi-team estate qualify. What matters is the evidence: has led a domain decomposition on a live system, and has set standards that teams outside their reporting line actually adopted.
• Deep distributed systems and application architecture: domain decomposition, service boundaries, API and event contract design, and data ownership.
• Event-driven architecture at estate scale, with experience of more than one paradigm. The group runs several in parallel and they need reconciling.
• Production depth in .NET, Java or Go, enough to review service code credibly and refactor a boundary alongside a team.
• Cloud architecture depth, including identity, secrets and least-privilege design, with enough multi-cloud literacy to form a group position.
• Currently hands-on in application code and infrastructure.
• Has modernised a legacy estate in practice, not only planned one, and can say what went wrong.
• Builds agreement across teams that do not report to them.

Advantageous

• Domain-driven design on a large estate · more than one of .NET, Java and Go breadth across correctness-critical, high-scale consumer and process-driven systems Kubernetes and managed container platforms at design level OpenTelemetry and observability strategy  PCI-DSS, POPIA or ISO 27001 experience South African market context  public writing, talks or open source.

SKILLS AND CAPABILITIES

• Domain decomposition that produces boundaries teams can actually work to.
• Contract design for APIs and events, with a clear position on versioning, delivery semantics, ordering and replay.
• Correctness-critical design where being wrong costs money or breaches a regulation: idempotency, reconciliation, auditability.
• Designing for scale and integration load: read paths, caching, edge delivery, and isolating third-party failure.
• Data architecture and ownership, including protecting personal information by design.
• Hands-on technical authority across application code and infrastructure, credible enough that engineers accept the review.
• Designing for AI-assisted delivery, and reliably spotting generated output that is plausible but wrong.
• Winning agreement without authority, and explaining trade-offs to leadership clearly.