How would you architect an enterprise-wide automation platform used by many teams?
60-second answer
I'd build a platform, not a single framework: shared, versioned libraries for driver and browser management, authentication, test data, reporting and configuration, published as packages; opinionated project templates so a team can start in minutes; central infrastructure for execution, such as autoscaling browser grids, device clouds and ephemeral environments; a results service and dashboards that aggregate across teams; and clear ownership with a platform team, contribution guidelines and a community of practice. Teams own their tests; the platform team owns the foundations and measures adoption, run time and reliability.
Explanation
Architecture layers:
- Core libraries: config, logging, waits, data builders, API clients, auth.
- Adapters: UI (Playwright/Selenium), API, mobile, performance.
- Templates and generators:
create-test-project. - Execution platform: CI templates, grids, environments, secrets.
- Insights: results DB, flaky detection, coverage, cost.
- Governance: versioning, deprecation policy, support channel, docs.
Principles: paved road over mandates, backward compatibility, inner-source contributions.
Example
A 40-team organisation reduced onboarding from weeks to a day with a template repo and shared library; a central results service exposed flaky rate per team, which drove a 70% flakiness reduction in a year.
Sample code
@acme/test-core config, logging, retry, data builders
@acme/test-ui Playwright fixtures, auth, page helpers
@acme/test-api typed clients from OpenAPI, schema checks
@acme/ci-templates reusable GitHub Actions workflows
results-service ingest JUnit/Allure -> Postgres -> Grafana