Enterprise Architect

INTERVIEW= Onsite / Virtual
JOB TYPE= Hybrid


Core Technology Stack:

• Azure DevOps: Boards, Repos, Pipelines, Wikis, Analytics
• SharePoint: Knowledge and documentation repository
• Power BI: Executive and operational dashboards
• Power Automate: Process automation and notifications
• Teams: Collaboration and ADO integration

Skills and Training: Contractor is responsible at its own cost and expense to ensure
Assigned Personnel are trained and qualified for the Services they are to perform.

Roles and Responsibilities
State of Vermont Enterprise Architecture Approach
The Contractor EA will be considered a member of the ADS Strategic Programs Office,
Division of Enterprise Architecture. The Contractor EA will report to the Dep Director of
Enterprise Architecture or a delegate as appointed. The Contractor EA will be responsible
for the following:

• Weekly report to the Dep Director for Enterprise Architecture on the status of

projects.

• Attend an agreed-upon number of informational and status meetings and,

when appropriate, call and lead such discussions. Discussions may take the form
of project meetings. Discussions will include design sessions with State of Vermont
Enterprise Architects, business-sponsored meetings, appointments to Steering
Committees, Project Management, appointed State IT Executives, Agency Program
Managers, and other consultants designated by the State.

• The EA will use tools provided by the State of Vermont. These tools are: a stateissued

desktop or laptop computer, Microsoft Office applications, Microsoft Visio,
Azure DevOps, office space in either the State Office Complex, Waterbury or The
Enterprise Architecture Office, Montpelier.
The EA will have the requisite skills and experience to perform any or all of the following as
directed by the Dep Director for Enterprise Architecture or designee in support of State
technology initiatives:
Requisite Skills
a. Experience working within an Architecture Framework such as TOGAF or FEAF

b. Experience working within at least two Architecture Domains: Business
Architecture, Application Architecture, Information/Data Architecture, and
Technology Architecture
c. Excellent oral and written communication skills
d. Ability to work within a team
e. Ability to meet shifting deadlines

PROJECT DELIVERABLES
This effort includes the following major workstreams:
1. Governance Agile Integration
2. DataOps Modernization
3. Microsoft Stack Expansion (data governance tooling, automation, metadata,
ADO integration)
4. Legacy Workflow Retirement
5. Cross-Workstream EA Deliverables
The EA role intersects each workstream and ensures technical coherence, enterprise
alignment, and long-term sustainability.

1. Governance Agile Integration Workstream
1.1. Enterprise Governance Architecture

• Architecture to reflect core tooling and decision gates for workflows such as but not

limited to entity resolution, data quality automation, and statistical process controls
as part of upstream processes, as well as lineage, and downstream workflows to BI
products.

• Updated governance for operational data model reflecting roles, approval points,

decision flows, and escalation paths to prevent schema drift and to resolve drift if it
is at risk of occurring.

• Governance-Embedded Enterprise Architecture Decision Records (EADR)

Repository to function as a centralized, versioned store of architectural decisions,
tied to governance gates and cross-SOW evidence requirements.
1.2. Architecture Decision Framework

• Architecture Decision Records (ADRs) covering data governance tools (e.g.,

MDM/entity resolution, data quality and statistical process control thresholds),
ingestion frameworks, integration stack, metadata patterns, and platform alignment.

• Architectural Impact Assessments (AIA) required for any schema adjustments,

ingestion pattern updates, ER logic changes, or quality threshold changes.

• EA-Integrated Risk & Dependency Impact Matrix
• Ensures alignment with the RDI framework used by the Sponsor.

1.3. Agile-Enterprise Integration Architecture

• Operating model that integrates architectural checkpoints into ADO-based Agile

delivery.
Backlog structure recommendations that ensure architecture work is integrated into
ADO taxonomy and practice for managing work.

• End-to-End Traceability Architecture (E2E TA) to define how ADO Repos Pipelines

Data Governance Platform SPC/DQ Release form a governed traceability chain.
1.4. Architectural Compliance Standards

• Definition of Ready/Done and example acceptance criteria for all technical work,

aligned with governance compliance and enabling consistent auditability.

• EA Compliance Scoring Rubric Criteria for evaluating technical debt, governance

drift, metadata completeness, and lineage readiness.

• EA Release Gate Evidence Checklist for defining the architecture artifacts required

for DED/DAF acceptance.
1.5. SharePoint ADO Framework Architecture

• EA validation of metadata-driven SharePoint-ADO tagging framework.
• EA optimization recommendations for metadata-driven SharePoint-ADO tagging

framework to promote continuous improvement.

• EA-Owned "Evidence Catalog” Metadata Model to structure evidence types

(operational, governance, quality, stakeholder) and where they must be stored.

• Automated Compliance Dashboard Architecture to enable publishing ADO

governance metrics into an ADO or other BI visualization.

DataOps Modernization Workstream
2.1. Data Ingestion Architecture

• Target-state architecture for modern ingestion pipelines, consistent with the RHT

goal of modernizing ingestion.

• Standardized ingestion patterns (batch, streaming, API-based), including resiliency

and data quality enforcement.

• Ingestion Reliability Architecture Package to include pipeline reliability patterns,

MTTR models, telemetry requirements, SPC integration.
2.2. Entity Resolution Architecture

• Master data and identity framework tied to priority datasets outlined in recent

check-ins.

• Entity Resolution Evidence Framework to include required artifacts for match rule

validation, survivorship logic evaluation, precision/recall trend analysis.

• Detailed architecture for implementing entity resolution through data governance

platforms and tooling.
2.3. Data Quality, Lineage & Metadata Architecture

• Metadata & Lineage Quality Framework defining maturity thresholds, lineage

completeness scoring, metadata freshness SLAs.
Lineage Propagation Pattern Library of required l ineage r ules f or i ngestion E R
semantic layer BI.

• Data governance platform or tooling-based lineage patterns and metadata modeling

linked to statewide tools.

• Standardized data quality rules integrated into DataOps pipelines.

2.4. Semantic Layer Architecture

• Semantic Governance Pattern Templates for dataset certification, sharing, RLS

enforcement, and lineage mapping back to ingestion.

• Shared datasets, certified semantic models, row-level security, and enterprise

Power BI architecture.
2.5. Patterns & Reusable Modules

• Blocker Prevention Patterns identification with templates for telemetry validation,

schema evolution control, and dependency management.

• Reusable DataOps templates and pipelines to accelerate onboarding of embedded

engineers and analytics staff.

Microsoft Stack Expansion Workstream
3.1. Data Governance Platform Architecture Package

• Full platform rollout architecture (catalog, lineage, MDM integration, roles, scanning

strategy).

• Cross-Platform Metadata Synchronization Architecture with required alignment

rules across data governance platform, Azure Data Factory, and entity resolution
tools.

• Governance Evidence Automation Pathways to ensure automatic evidence

extraction and packaging where applicable.

• Data Governance Platform–ADO integration guidance for governance workflows.

3.2. ADO Architecture & Integration

• Architecture for ADO project structure enabling traceability of all deliverables and

knowledge management practice.

• E2E Architecture Traceability Mapping (ADO-Centric) to capture required fields,

tags, and relationships for full traceability from backlog release.

• EA-Driven ADO Work Taxonomy Extensions to ensure Architecture product backlog

items, governance tasks, evidence tasks are included in relevant ADO workflows.
3.3. Automation & Workflow Architecture

• Low/no-code workflow patterns using Power Platform where appropriate.
• Patterns for approvals, reviews, governance tasks, and automated validation.
• EA-Approved Power Automate Governance Triggers to automate lineage checks,

readiness checks, comms gating, and dependency escalations wherever
practicable.

Cloud Resource & Security Architecture

• Azure resource hierarchy and governance aligned with ADS guidance.
• Federated Security & Data Access Architecture to ensure alignment with PHI/PII

access restrictions, governance workflow, and cross-team roles.

• Access model for PHI/PII data across datasets and teams.

4. Legacy Workflow Retirement Workstream
4.1. Legacy System Inventory & Architecture Assessment

• Historical Architecture Evidence Baseline to capture the lineage, metadata, and

technical debt state of each legacy asset before migration.

• Catalog and assess all legacy workflows and datasets connecting to scope.

4.2. Transition State Architecture

• Intermediate architectures enabling gradual migration of logic, pipelines, and data

models.

• Compatibility models for systems that must coexist temporarily.
• Architecture Sustainability & Technical Debt Prevention Plan to prevent reinjection of

deprecated patterns and align modernization outcomes.
4.3. Decommissioning Architecture

• EA-Governed Sunsetting Criteria to establish formal architectural thresholds

(lineage completeness, metadata conformity, evidence requirements) before
decommissioning or sunsetting legacy platforms or workflows.

• Risk mitigation and fallback strategies.
• Alignment with statewide data and cloud modernization mandates.

4.4. Cutover Architecture

• Cutover Evidence Framework detailing exact artifacts required for cutover readiness

(e.g., lineage diffs, DQ baselines, reliability snapshots).

• Validated cutover plans, roll-back architecture, and monitoring/observability model

during transitions.
5. Cross-Workstream EA Deliverables Supporting All Four Areas
5.1. Enterprise Architecture Blueprint

• Reference Architecture to provide a unified architecture tying ingestion, ER,

metadata automation, governance, SPC/DQ, semantic layer, and BI workflows.
5.2. Technical Roadmaps

• Outcome-Based EA Roadmap Integration which maps Sponsor Strategic Anchors

(e.g., evidence, rhythm, role purity) to architectural milestones and technical
milestones.

• Sequencing guidance for data governance platform, ingestion modernization, and

MDM.

Architecture Governance Reviews

• EA Evidence Review Packets to include but not limited to lineage, SPC anomaly

trends, ER metrics, DQ validation — formatted for the Sponsor's requested review
cadence model.

• Solution reviews for each major deliverable across all workstreams.
• Architectural Decision Record updates based on tool selection and implementation

decisions.
5.4. Training & Onboarding Architecture

• EA-Authored Architecture Runbooks for ingestion, ER, governance, Quality/SPC,

metadata, ADO integration.

• Architecture playbooks enabling embedded engineers, analysts, and governance

roles to integrate seamlessly into GMCB's work.
5.5. Stakeholder Alignment Deliverables

• Architecture briefing materials for ADS and GMCB leadership.
• Alignment materials for statewide cloud, metadata, and integration platforms.
• "Day in the Life of Data” Architecture Narrative to function as a visual walkthrough of

data f rom s ubmission i ngestion E R governance S PC/DQ BI
communications.

Alignment with Objectives: Does the proposal clearly
address the purpose and objectives outlined?

• Work Plan Detail: Is there a comprehensive work

breakdown structure, timeline, and Gantt chart for tasks
and deliverables?