Geotab

Geotab connects over 4 million vehicles worldwide. Behind the customer-facing products is a sprawling internal technology landscape that Enterprise Architecture tracks and governs in Ardoq, the central system of record.

When Ardoq is accurate, it powers planning, risk assessment, and intake approvals. When it's not, teams fall back to spreadsheets and direct messages.

I joined as a Systems Engineering Intern on the EA team with a broad mandate: improve data quality, restructure the application inventory, extend automation, and figure out why adoption had stalled.

On paper, that sounded like a cleanup project. In practice, the inventory had structural problems, automation only covered part of the picture, and stale data had pushed people back to spreadsheets.

I started with the application inventory: thousands of entries across the Ardoq workspace. Many lacked owners, lifecycle states were months out of date, and organizational units didn't match the source of truth in Google BigQuery. Duplicate entries under slightly different names fragmented search results.

Where Workato automations ran, names, titles, and manager information stayed accurate. Fields that depended on manual input (ownership, lifecycle states, naming) had drifted significantly, slowing intake reviews and eroding trust in the system.

Without strong governance, clear ownership, and automated synchronization, inventories drift and teams stop relying on them.

Inconsistent data lowered perceived usefulness. Manual updates raised perceived effort. Automation didn't cover enough fields, ownership rules weren't enforced, and no workflow required people to keep entries current.

Contributors responded by bypassing the tool and asking someone directly. That pointed to a structural problem, not a training gap.

Everything was listed at the same level with no grouping, no parent-child relationships, and no distinction between business applications and developer tooling. My first major project was giving the inventory a proper architecture.

Many entries in the inventory were individual products that belonged to larger suites, but they were scattered as standalone records. Adobe Creative Cloud, Atlassian, Salesforce, Google Workspace: each had their child products listed independently with no connection to the parent.

I mapped every suite and its children across the full inventory, then restructured them in Ardoq as Application Groups: single parent entries with proper component relationships. This meant reviewers could now assess an entire suite at a glance during licensing or vendor reviews instead of piecing together individual components.

A more subtle structural problem was that developer tools were mixed in with business applications. GitHub libraries, internal frameworks, build tools: these are used by dev teams to build applications, but they aren't “business applications” in the same sense as Salesforce or Figma. Treating them the same distorted the portfolio and made it harder to get an accurate picture of the organization's software spend.

I worked on separating these into a distinct Technology Products workspace, creating grouping folders and defining what qualified as a technology product versus a business application. This was fairly open-ended and required judgment calls about categorization, but the result was a cleaner separation that gave both the EA team and engineering leadership a more accurate view of what they were actually managing.

Restructuring got the hierarchy right. It didn't stop manual fields from drifting. That's what the Workato recipes were for.

I extended the existing Workato recipes to sync org data from Dayforce into Ardoq on a weekly schedule. Employee and org fields stayed aligned with HR without manual updates, and a decommission workflow kept lifecycle states current when applications were retired.

But automation only covered part of the picture. Active lifecycle states, ownership assignments, and naming conventions still depended entirely on manual input. The pattern was consistent: where automation existed, data quality was high. Where it didn't, drift accumulated.

Partial automation actually increases inconsistency because the manual gaps become failure points. People assumed Ardoq was accurate because some fields were always right, which made the inaccurate fields more dangerous. The lesson wasn't that manual processes are bad. It's that partial automation is worse than no automation because it creates a false sense of completeness.

Beyond the inventory and automation work, I helped the team adopt AI tooling to reduce manual effort and surface insights that weren't visible before.

I built dashboards using Atlassian ROVO AI to give the team visibility into the software request service desk. Instead of manually scanning Jira tickets, the team could now see request patterns at a glance: which tool categories had the most submissions, where duplicate requests were clustering, and how change requests flowed through the review process.

The CR request analysis was particularly revealing. Certain categories (screen capture tools, PDF editors, design plugins, browser extensions) saw repeated submissions from different teams, often for tools that already existed in the portfolio or had approved alternatives. This data directly informed the recommendation to integrate Ardoq checks into the software intake workflow.

I also worked on deploying AI assistants for the team. I set up a Gemini-based assistant for day-to-day workflows and explored an AI onboarding agent to help new contributors navigate Ardoq, follow naming conventions, and avoid common data quality mistakes.

These were smaller initiatives, but they reflected a broader pattern: the EA team's challenges weren't just about data cleanup. They were about reducing the cognitive load on a small team managing a system that the entire organization depended on. Every hour saved through automation or AI was an hour that could go toward governance and strategic work instead of manual maintenance.