Enterprise Solutions Architect

Enterprise Solution Architect

Full-Time W-2 | Fully Remote (U.S.) | Federal Civilian Practice

The Problem We're Hiring You to Solve

Most architects know systems. A few know mortgage. Almost none understand it from both sides of the table: the lender and servicer technology that originates and manages loans, and the federal agency that guarantees those loans and holds industry accountable.

We are hiring one of the few. You will own the enterprise and solution architecture for the modernization of a federal home loan benefit program, translating statute, policy, and two decades of accumulated business rules into a modern platform while the 20-year-old legacy system keeps running underneath it. If you can hold the loan lifecycle and the oversight lens in your head at the same time, keep reading.

The Opportunity

This program is replacing the technology behind a nationwide home loan guaranty operation. That means origination-adjacent workflows, servicing oversight, loss mitigation, claims, grants, analytics, and the data exchanges that connect a federal agency to thousands of external lender and servicer users.

The target platform is Salesforce-centered, supplemented by serverless capabilities in a government cloud. The legacy platform stays alive, integrated, and secure until the modern one absorbs its functions and the bridges between them come down.

Your job sits at the point where all of it must cohere. Requirements arrive as business needs, policy decisions, and process flows. Development teams need buildable designs with traceability, data models, integration specifications, and test strategies.

The customer needs an architect who can explain why a design decision protects the program, not just how it works. And the whole effort runs on a fast clock: intake requests turn into executable plans in days, releases ship monthly, and architecture decisions that stall become delivery risks with your name on them.

This is not an ivory-tower architecture role. Your designs get built, deployed, and measured within weeks of leaving your hands, and you stay accountable for whether they hold up in production.

Why the domain requirement is real. Plenty of strong architects can design an integration. Very few can look at a servicing data exchange and know which fields carry regulatory weight, why the agency needs lineage on a particular data element, or where a workflow change quietly breaks a downstream claim calculation. This program moves too fast to teach you mortgage while you architect it. We need someone who walks in fluent.

What You'll Own

The target-state architecture. Define and defend one coherent enterprise architecture across the product line: legacy systems, the modern platform, and everything bridging them. Teams and the customer should make decisions against your picture of where the program is going, not their own private versions of it.

Solution designs that survive contact with development. Turn approved requirements into complete solution packages: architecture and state diagrams, data models, API and interface specifications, integration designs, and test strategies with full traceability back to the business need. The bar is that development builds from your package without re-litigating it.

The configure-versus-customize line. The program mandates out-of-the-box and configuration-first solutions, with custom code as an approved exception. You decide what is configured, what is customized, and why, and you defend those calls to the customer's change authority with evidence.

Data architecture and lineage. Own the logical and physical data models, data dictionaries, and the migration and bridging strategy that moves a 20-year accumulation of loan data into the modern platform without breaking the processes still running on the old one. Design data governance enforcement in, not around.

Industry-facing integration architecture. Design the APIs, batch exchanges, and system-to-system transfers that connect the agency to lenders, servicers, and partner systems. Fluency in mortgage data standards such as MISMO is part of the job. Resilience, self-recovery, and monitoring are design requirements, not operational afterthoughts.

The legacy decommissioning roadmap. Sequence which functions move when, design the bridge services that keep both platforms consistent during the transition, and plan the retirement of every bridge you create.

Fast, credible solution judgment. New needs enter through a formal intake process that produces an executable plan, with scope and level of effort, in days. Your architecture instincts have to be right at speed, and honest about uncertainty when they cannot be.

Security and compliance as design inputs. Zero Trust alignment, accessibility, data protection, and authorization evidence get engineered into your designs from the first diagram, because retrofitting them is how federal programs lose months.

The architecture bar for the program. Run design reviews, mentor engineers and analysts on architectural thinking, document the standards, and hold the line on them, including against pressure from delivery deadlines.

AI-Native Architecture

AI is part of how PhoenixTeam works, and this role has more to gain from it than most.

We are looking for someone who already uses tools like Claude Code, Cursor, or GitHub Copilot, or comparable AI tools, as a working part of their practice.

For an architect on this program, the leverage looks like: analyzing legacy code and data structures to recover business rules that exist nowhere else, accelerating the production of data models, interface specifications, and architecture documentation, pressure-testing designs against edge cases before development finds them, and prototyping integration patterns in hours instead of weeks.

You will also help decide where AI belongs inside the solutions themselves, and where it does not, given federal security, data, and authorization boundaries.

Two things anchor all of it. Judgment stays human: you know when AI output is wrong, incomplete, or inappropriate for a federal system of record, and you review accordingly. And boundaries are non-negotiable: federal environments govern what tools may touch government code, systems, and data. Use AI wherever it creates leverage, and understand the security, data, privacy, and authorization boundaries governing where and how it can be used.

What Great Looks Like

Twelve months in, we would expect to see

The program has one architecture, and people use it. Your target-state model is the reference for customer decisions, intake sizing, and development sequencing, and it stays current as reality moves.

Solution packages flow into development without rework. Designs carry full traceability, teams build from them directly, and re-litigation of settled architecture decisions has become rare.

Legacy knowledge is captured, not trapped. Business rules that lived only in old code and long memories are documented, validated with the customer, and reflected in the modern designs, with AI-assisted analysis doing real work in the extraction.