Cloud implementation · AWS · Azure · Google Cloud
Your decision-making partner for cloud, across every industry.
PHledger embeds forward-deployed engineers who help you choose the right cloud and architecture, then build and run it with you on AWS, Azure or Google Cloud, with an open-source-first approach. AI recommends. Your people decide. Every change is tested before it ships.
01 — AI foundations
Foundations first. Then AI that reaches the business goal.
AI only delivers when the data beneath it is managed, current and shipped through reliable pipelines. PHledger FDEs recommend the path, your people decide, and we build it test-first.
Read it from the bottom up: each layer is the foundation for the one above it.
Business goal
TOGAFStart from the goal and align the architecture
TOGAF's Architecture Development Method ties the business goal to business, data, application and technology architecture, with a target state, the gaps and a roadmap your leaders sign off.
AI
FDE recommendsAI that recommends, people who decide
Models, LLM applications and agents run on managed, current data. A PHledger FDE reviews each recommendation against the evidence, and your people confirm before anything acts.
Data management
DAMA-DMBOKManaged data on Databricks and Snowflake, in real time through Kafka
DAMA-DMBOK disciplines (governance, quality, metadata, security, integration) applied on Databricks and Snowflake, with real-time events streamed in through Kafka so AI acts on what is true now.
Delivery
Terraform + DevOpsCI/CD and infrastructure as code underneath it all
Terraform builds every environment and DevOps pipelines test and promote each change, so the platform is repeatable, auditable and safe to change. The tests run before anything reaches production.
TOGAF
The Open Group Architecture Framework
How we use TOGAF
- Architecture Vision: the business goal, stakeholders and success measures, agreed before any technology is chosen.
- Business, data, application and technology architecture: the baseline, the target and the gaps between them.
- Opportunities, solutions and migration planning: a sequenced roadmap, with build, buy or migrate decided per workload.
- Implementation governance: architecture compliance checks built into CI/CD, not left in slide decks.
DAMA-DMBOK
DAMA Data Management Body of Knowledge
How we use DAMA-DMBOK
We score your maturity across the 11 knowledge areas, fix first the few that block your business goal, and build the controls into the platform instead of into binders.
The 11 knowledge areas
- Data governance
- Data architecture
- Data modelling & design
- Data storage & operations
- Data security
- Data integration & interoperability
- Document & content management
- Reference & master data
- Data warehousing & business intelligence
- Metadata management
- Data quality
Where each discipline lives
Governance & security
Databricks
Unity Catalog access policies and audit logs
Snowflake
Roles, masking policies and row access policies
Kafka (real time)
ACLs, with encryption in transit and at rest
Metadata & lineage
Databricks
Unity Catalog lineage and OpenLineage
Snowflake
Object tags and access history
Kafka (real time)
Schema registry and an event catalogue
Data quality
Databricks
dbt tests and unit tests in CI
Snowflake
Coalesce tests and data-quality checks
Kafka (real time)
Schema contracts and dead-letter topics
Integration & interoperability
Databricks
Structured Streaming from Kafka into Delta Lake
Snowflake
The Kafka connector with Snowpipe Streaming
Kafka (real time)
Kafka Connect and change data capture
Architecture & modelling
Databricks
Bronze, silver and gold layers on Delta Lake
Snowflake
Layered schemas with dimensional or Data Vault models
Kafka (real time)
Event models and topic design
Reference & master data
Databricks
Golden records in the lakehouse
Snowflake
Golden records in the warehouse
Kafka (real time)
Published as events to every consumer
Infrastructure asset management
Databricks
Terraform manages workspaces, the Unity Catalog metastore, catalogs, schemas, grants, clusters and jobs as code
Snowflake
Terraform manages databases, schemas, warehouses, roles, grants and resource monitors as code
Kafka (real time)
Terraform manages topics, ACLs and connectors, with remote state and drift detection on every plan
Q — A common question
How does Databricks combine OLTP and OLAP?
Through the LTAP architecture. It does not force both workloads into one engine, but instead uses Lakebase (PostgreSQL) to handle transactions and the Lakehouse to handle analytics, while unifying them at the storage layer. When Lakebase writes data to object storage, it automatically transcodes it into columnar format (Delta/Iceberg). Analytical engines read the columnar copy directly, and only request an LSN from PostgreSQL to ensure freshness. This eliminates the need for traditional CDC pipelines and achieves a 'single data copy, two engines' without mutual interference.
- LSN
- A progress marker in PostgreSQL, used to ensure read consistency.
- Parquet
- A columnar file format, responsible for physical storage.
- Delta and Iceberg
- Table formats built on Parquet that provide ACID transactions and time travel.
Within Databricks, Delta is the default choice. When cross-platform interoperability is needed, Iceberg is the universal choice.
LTAP is rolling out in stages, and some capabilities are still in beta or preview. We confirm what is generally available in your region and test it on your own workload before you rely on it.
02 — Decision partner
How we help you decide
Cloud decisions are rarely about technology alone. We put cost, risk, skills and timing on one page, then you choose.
Which cloud, and how many
Single cloud, multi-cloud or hybrid. We score AWS, Azure and Google Cloud against your workloads, skills, existing contracts and regulators, not against a vendor's roadmap.
Build, buy or migrate
Rehost, replatform, refactor, replace or retire: one decision per workload, with effort, risk and payback on a single page.
Cost and FinOps
Total cost of ownership before you commit. Unit-cost tracking, budgets, rightsizing and commitment discounts after.
Risk, security and compliance
Data residency, identity, encryption, resilience and audit evidence mapped to the rules you actually face, for example APRA CPS 230 and CPS 234, the Privacy Act, or IRAP for government work.
AI readiness
Which workloads should use managed AI services, which need your own models, and what data and guardrails must exist first.
03 — Implementation
From decision to production
Delivered inside your accounts, subscriptions and projects, with your engineers beside ours.
- 01
Assess and decide
Workload inventory, target-architecture options and a recommendation your leaders can sign off.
- 02
Landing zone and guardrails
Accounts, identity, networking, policy and logging, all defined as code.
- 03
Migrate and modernise
Move, replatform or rebuild in waves, each with a rehearsed rollback.
- 04
Data and AI platform
Lakehouse or warehouse, pipelines, machine learning and LLM applications on data you trust.
- 05
Run, secure and optimise
Monitoring, security operations, FinOps and runbooks handed over to your team.
04 — Cloud platforms
What each cloud brings
The major platform-specific technologies on AWS, Azure and Google Cloud, side by side.
Amazon Web Services
The broadest service catalogue and the largest partner ecosystem. A strong default for cloud-native builds, global scale and mature third-party tooling.
Sydney and Melbourne regions
Microsoft Azure
The natural fit when you already run Microsoft 365, Entra ID, Windows, .NET or SQL Server. Strong hybrid and enterprise governance, with Fabric and Power BI for analytics.
Sydney, Melbourne and Canberra regions
Google Cloud
Leads on data analytics and AI with BigQuery, Vertex AI and Gemini, and on Kubernetes-native, open-source-friendly engineering.
Sydney and Melbourne regions
Compute & containers
AWS
- Amazon EC2
- AWS Lambda
- Amazon ECS
- Amazon EKS
- AWS Fargate
- AWS Batch
Azure
- Azure Virtual Machines
- Azure App Service
- Azure Functions
- Azure Kubernetes Service (AKS)
- Azure Container Apps
- Azure Batch
GCP
- Compute Engine
- Google Kubernetes Engine (GKE)
- Cloud Run
- App Engine
- Batch
Storage & databases
AWS
- Amazon S3
- Amazon EBS
- Amazon EFS
- Amazon RDS
- Amazon Aurora
- Amazon DynamoDB
- Amazon ElastiCache
Azure
- Azure Blob Storage
- Azure Data Lake Storage
- Azure Files
- Azure SQL Database
- Azure Cosmos DB
- Azure Database for PostgreSQL
GCP
- Cloud Storage
- Cloud SQL
- AlloyDB for PostgreSQL
- Cloud Spanner
- Firestore
- Bigtable
- Memorystore
Data & analytics
AWS
- Amazon Redshift
- AWS Glue
- Amazon Athena
- Amazon Kinesis
- Amazon MSK
- AWS Lake Formation
Azure
- Microsoft Fabric
- Azure Synapse Analytics
- Azure Data Factory
- Azure Event Hubs
- Microsoft Purview
- Power BI
GCP
- BigQuery
- Dataflow
- Pub/Sub
- Cloud Composer
- Dataplex
- Looker
Hadoop & Spark
AWS
- Amazon EMR
- Amazon EMR Serverless
- Amazon EMR on EKS
- AWS Glue
- Amazon S3
Azure
- Azure HDInsight
- Azure Databricks
- Azure Synapse Spark pools
- Microsoft Fabric
- Azure Data Lake Storage
GCP
- Dataproc
- Dataproc Metastore
- BigQuery
- Cloud Composer
- Cloud Storage
Kafka & streaming
AWS
- Amazon MSK
- Amazon MSK Serverless
- Amazon MSK Connect
- Amazon Kinesis
- Amazon Managed Service for Apache Flink
Azure
- Azure Event Hubs
- Azure Stream Analytics
- Confluent Cloud
- Azure HDInsight
- Azure Data Explorer
GCP
- Managed Service for Apache Kafka
- Pub/Sub
- Dataflow
- Confluent Cloud
- Datastream
AI & machine learning
AWS
- Amazon Bedrock
- Amazon SageMaker
- Amazon Q
- Amazon Textract
- Amazon Rekognition
- Amazon Transcribe
Azure
- Azure OpenAI Service
- Azure Machine Learning
- Azure AI Search
- Azure AI Document Intelligence
- Azure AI Speech
- Copilot Studio
GCP
- Vertex AI
- Gemini
- Vertex AI Model Garden
- Vertex AI Agent Builder
- Document AI
- Vertex AI Search
Integration & DevOps
AWS
- AWS CloudFormation
- AWS CDK
- AWS CodePipeline
- AWS Step Functions
- Amazon EventBridge
- Amazon SQS
- Amazon SNS
- Amazon API Gateway
- Terraform
Azure
- Azure DevOps
- GitHub Actions
- Bicep
- Azure Logic Apps
- Azure Service Bus
- Azure Event Grid
- Azure API Management
- Terraform
GCP
- Cloud Build
- Artifact Registry
- Cloud Deploy
- Infrastructure Manager
- Workflows
- Eventarc
- Apigee
- Terraform
Security & governance
AWS
- AWS IAM Identity Center
- AWS Organizations
- AWS Control Tower
- AWS KMS
- Amazon GuardDuty
- AWS Security Hub
- AWS Config
- AWS CloudTrail
Azure
- Microsoft Entra ID
- Azure Policy
- Azure Resource Manager
- Azure Key Vault
- Microsoft Defender for Cloud
- Microsoft Sentinel
- Azure Monitor
GCP
- Cloud IAM
- Organization Policy Service
- VPC Service Controls
- Cloud KMS
- Security Command Center
- Google Security Operations
- Cloud Logging
- Cloud Monitoring
Networking & hybrid
AWS
- Amazon VPC
- AWS Transit Gateway
- AWS Direct Connect
- Amazon Route 53
- Amazon CloudFront
- AWS Outposts
Azure
- Azure Virtual Network
- ExpressRoute
- Azure Front Door
- Azure Firewall
- Azure Arc
- Azure Local
GCP
- Virtual Private Cloud
- Cloud Interconnect
- Cloud Load Balancing
- Cloud CDN
- Cloud DNS
- Google Distributed Cloud
Blockchain & ledger
AWS
- Amazon Managed Blockchain
- Managed Blockchain Access
- Managed Blockchain Query
- AWS KMS
- Amazon EKS
Azure
- Azure Confidential Ledger
- Azure Key Vault Managed HSM
- Azure Confidential Computing
- Azure Kubernetes Service (AKS)
- Azure Virtual Machines
GCP
- Blockchain Node Engine
- Cloud KMS
- Cloud HSM
- Confidential Computing
- Google Kubernetes Engine (GKE)
Databricks and Snowflake run on all three clouds, so choosing a lakehouse or warehouse does not lock you to one provider.
05 — Data platform stacks
Hadoop to lakehouse, ledger to warehouse
The same technologies run on all three clouds. We help you pick the stack and prove it on your own data before you commit.
Hadoop
ModerniseStill running on-premises Hadoop: HDFS, Hive, YARN, HBase? We assess what is still worth keeping, then move storage to cloud object storage and jobs to Spark, SQL engines or a lakehouse, workload by workload.
On the three clouds
Amazon EMR runs Hadoop, Hive and Spark on S3 instead of HDFS, and EMR Serverless removes cluster management.
Azure HDInsight for a like-for-like move, with Azure Databricks or Microsoft Fabric as the destination.
Dataproc for lift-and-shift Hadoop and Spark on Cloud Storage, with BigQuery as the destination for SQL workloads.
How we test it
Row-count and checksum reconciliation between old and new, plus side-by-side job output comparison before cut-over.
Spark
ProcessThe engine for large-scale batch, streaming and machine-learning pipelines: PySpark, Spark SQL and Structured Streaming, tuned for cost as well as speed.
On the three clouds
Amazon EMR, EMR Serverless and AWS Glue run Spark without you managing clusters.
Azure Databricks, Synapse Spark pools and Microsoft Fabric notebooks.
Dataproc for managed Spark clusters, or Spark stored procedures inside BigQuery.
How we test it
Unit tests on transformation functions with small fixtures, data-quality assertions on outputs, and performance regression runs on a representative sample.
Kafka
StreamApache Kafka as the event backbone: real-time ingestion, change data capture and event-driven integration between systems, with schemas, retention and replay designed in from the start.
On the three clouds
Amazon MSK and MSK Serverless run open-source Kafka without broker management, and MSK Connect hosts Kafka Connect connectors.
Azure Event Hubs exposes a Kafka-compatible endpoint, and Confluent Cloud is available through Azure.
Google Cloud Managed Service for Apache Kafka, or Confluent Cloud, with Pub/Sub where a Kafka API is not needed.
How we test it
Producer and consumer contract tests against a schema registry, replay of recorded events, and load tests that include broker failure and consumer-lag alerts.
Databricks + dbt
LakehouseDatabricks for the lakehouse, with Delta Lake, Unity Catalog, MLflow and Databricks SQL, and dbt as the tested, version-controlled SQL transformation layer on top.
On the three clouds
Databricks on AWS with S3 storage, and Unity Catalog governing access across workspaces.
Azure Databricks, tightly integrated with Microsoft Entra ID and Azure Data Lake Storage.
Databricks on Google Cloud with Cloud Storage and BigQuery integration.
How we test it
dbt tests (unique, not-null, relationships, accepted values) and dbt unit tests run in CI on every pull request. A failure blocks the merge.
Snowflake + Coalesce
WarehouseSnowflake as the governed cloud warehouse, with Snowpark, Cortex AI and secure data sharing, and Coalesce for column-aware visual transformation and modelling that your analysts can read.
On the three clouds
Snowflake on AWS, with S3 external stages and Snowpipe ingestion.
Snowflake on Azure, with Blob Storage stages and Entra ID single sign-on.
Snowflake on Google Cloud, with Cloud Storage stages.
How we test it
Coalesce node and column tests plus data-quality checks, run against a cloned development database before promotion. Time Travel makes rollback quick.
Terraform
Infrastructure as codeOne infrastructure-as-code workflow across all three clouds, so landing zones, networks and platforms are reviewed, tested and repeatable. Open-source tooling by default, with OpenTofu, the open-source fork, where licence terms matter to you.
On the three clouds
The AWS provider, with remote state in S3 and one account per environment.
The AzureRM and AzAPI providers, with state in Blob Storage and one subscription per environment.
The Google provider, with state in Cloud Storage and one project per environment.
How we test it
Format, validate and lint checks, a plan review on every pull request, the native terraform test framework, and policy-as-code scans before anything is applied.
Blockchain
TrustOnly where several parties need a shared, tamper-evident record: provenance, audit trails, settlement or tokenised assets. We run a small pilot first, and if a database does the job we say so.
On the three clouds
Amazon Managed Blockchain for nodes and network access, with the rest of the application on standard AWS services.
Azure Confidential Ledger for tamper-proof records, and public or consortium chains on virtual machines or AKS.
Blockchain Node Engine for managed Ethereum nodes, with blockchain datasets analysed in BigQuery.
How we test it
Smart-contract unit tests and testnet trials before mainnet, plus a security review and a cost comparison against a conventional database.
06 — Open source first
Open by default, portable by design
We default to open-source and open-standard technology so you keep your options, your data and your exit. We use managed cloud services where they save you time, and we say so workload by workload.
Data & streaming
- Apache Spark
- Apache Kafka
- Apache Iceberg
- Delta Lake
- Apache Airflow
- Trino
Transformation & quality
- dbt Core
- Great Expectations
- OpenLineage
- Apache Superset
Infrastructure & delivery
- OpenTofu
- Terraform
- Kubernetes
- Helm
- Argo CD
- OpenTelemetry
- Prometheus
- Grafana
AI & machine learning
- MLflow
- Ray
- vLLM
- PyTorch
- Hugging Face
No lock-in by design
Open formats, portable code and a written exit plan, so changing provider is a project, not a hostage situation.
Managed when it saves time, open when it keeps you free
Decided per workload, with cost and switching effort side by side.
We do not resell software
Licences are passed through at cost and we take no vendor commissions.
Contribute back
With your permission, reusable fixes and tooling go back to the upstream projects.
07 — Solutioning & testing
Test-driven by design. Proven by trial and error.
We solution with you, then run delivery as an AI production and testing manager: people define what good looks like, AI builds against it, and nothing ships until the tests, and a person, say yes.
Our role
AI production and testing manager
An embedded senior engineer who owns the production line for AI-built work: writes the acceptance tests first, directs AI agents to build, reviews every output and signs off each release. You get the speed of AI with a named human accountable.
The loop
- 01
Write the tests first
Acceptance criteria, data-quality checks, cost and latency budgets and security controls, written before any build starts.
- 02
Let AI build
AI drafts the infrastructure as code, pipelines and application code against those tests.
- 03
Test in a sandbox
Unit, integration, data-quality, load, failure and security tests run in a non-production account, subscription or project, never first in production.
- 04
Learn from failures
Short trial-and-error cycles: try an option, measure it, keep it or discard it. Every attempt is logged: what we tried, what broke and what we changed.
- 05
A person confirms
A named person reviews the AI recommendation and the test evidence, then approves promotion. If a gate fails, the release rolls back.
Sandbox first
Separate non-production environments on each cloud: AWS accounts, Azure subscriptions and Google Cloud projects.
Tests as code
Tests live in the repository and run in CI/CD, so pipelines gate every change automatically.
Pilot before you commit
Time-boxed experiments that compare options on your real data, with success criteria agreed up front.
Drills, not hopes
Budget alerts, failure injection and backup restore tests, so resilience and cost control are proven rather than assumed.
08 — Model economics
The right model for each task, at the right price
No single model is both the cheapest and the best at everything. For in-house training and the AI workloads it builds, we route each task to the model that passes the tests at the lowest cost, mixing Chinese open-weight models with frontier models from Anthropic, OpenAI and Google.
Frontier models
- Claude
- ChatGPT
- Gemini
For hard reasoning, long documents, agentic coding and anything high-stakes or customer-facing. The strongest quality and the most mature tooling, at a higher price per token.
- Complex analysis
- Agentic coding
- Customer-facing answers
- Final review
Cost-efficient open-weight models
- DeepSeek
- Kimi
- Qwen (Qianwen)
- GLM
For high-volume, lower-risk work with a clear definition of done. Typically a fraction of frontier cost for comparable quality on well-defined tasks, and the weights can run inside your own tenancy.
- Drafting and summaries
- Classification and extraction
- Practice questions and exercises
- Code scaffolding
How we optimise the price
- 01
Measure on your tasks
We build a test set from your real tasks and score every candidate model on quality, cost and speed. List prices change often, so we measure rather than assume.
- 02
Route by risk and difficulty
Start with the cheapest model that can pass. Escalate to a frontier model when a test or confidence check fails, and keep high-stakes work on frontier models from the start.
- 03
Cache, batch and trim
Prompt caching, batch processing, shorter context and smaller models for simple steps often cut the bill more than switching models does.
- 04
Self-host where volume pays
When usage is high and steady, open-weight models served with vLLM inside your own AWS, Azure or Google Cloud tenancy can beat per-token pricing.
- 05
Stay free to switch
A gateway layer with a common API keeps every model swappable, so you follow price and quality as they move instead of being locked in.
In-house training
A budgeted AI tutor for every learner
In your in-house training, each learner gets an AI tutor, an exercise generator and a code reviewer. Routine help runs on cost-efficient models and the hard questions escalate to frontier models, so the cost per learner is tracked and capped.
Guardrails
Where a model runs matters as much as what it costs
Some hosted APIs process data overseas, and some governments and regulators restrict specific AI tools. We classify your data first. Sensitive or regulated data stays on models running in your own tenancy or region, only low-risk data goes to external APIs, and we check current guidance before any model is approved.
Model usage is passed through at cost with no mark-up, inside a monthly budget cap you set.
09 — Pricing model
Pay for outcomes you can test
Indicative rates in Australian dollars, excluding GST. Every engagement is confirmed in a written statement of work before it starts.
Decision sprint
A$18,000
fixed fee, 2 weeks
Choosing a cloud, a stack or a migration path
- Workload inventory and a TOGAF-aligned target architecture
- AWS, Azure and Google Cloud compared on your workloads
- A DAMA-DMBOK data management baseline across the 11 knowledge areas
- Cost model, risk register and exit plan
- Decision memo: an AI recommendation, signed off by your people
- A pilot plan with the success tests written first
Embedded FDE
A$26,000
per engineer per month, 3-month minimum
Building capability while delivering
- A senior forward-deployed engineer inside your team
- Skills transfer through pairing, reviews and workshops
- An AI production and testing manager on your delivery
- A monthly decision and test report
- Runbooks and documentation kept current
Fixed-scope build
From A$60,000
fixed price, paid per tested milestone
A defined platform or migration
- Fixed price agreed after a decision sprint
- Acceptance tests written first and shared up front
- Payment released as each milestone passes its tests
- Infrastructure as code, pipelines and runbooks are yours
FDE training cohort
A$2,400
per participant, 4 weeks
Upskilling your team on real work
- Hands-on cohort on Databricks, dbt, Snowflake, Kafka or Terraform
- Real work from your backlog, built beside our engineers
- Code review and test-first coaching throughout
- An open-source toolchain your team keeps using
- AI tutor and practice tools on a cost-optimised mix of models, with a per-learner budget
Pay for passing tests
Fixed-scope work is paid as milestones pass the acceptance tests we agree up front.
Licences at cost
Cloud and software licences are passed through at cost, with no mark-up and no vendor commission.
Open source first
Open-source tooling means no licence fees from us and nothing that locks you in.
Caps and exits
Monthly spend caps, a 30-day exit on retainers, and all code and runbooks are yours.
Rates are indicative and confirmed in a written statement of work. Cloud consumption is billed by the cloud provider.
10 — All industries
Every industry, one way of working
The clouds are the same. The decisions are not. This is what we typically help each sector decide.
Financial services
Typical decision
Meeting operational-resilience and information-security rules without slowing delivery.
Health & aged care
Typical decision
Keeping sensitive health records in-region while using AI to cut paperwork.
Government & public sector
Typical decision
Choosing IRAP-assessed services and sovereign options for protected workloads.
Education & training
Typical decision
Scaling learning platforms and analytics across campuses on a fixed budget.
Retail & e-commerce
Typical decision
Absorbing peak-season spikes and personalising without runaway cost.
Manufacturing
Typical decision
Bringing factory and IoT data to the cloud for quality and maintenance prediction.
Logistics & transport
Typical decision
Real-time tracking and route optimisation across partners and regions.
Energy & resources
Typical decision
Handling high-volume sensor data and edge-to-cloud monitoring.
Property & construction
Typical decision
Unifying asset, building and project data for performance and compliance.
Professional services
Typical decision
Turning documents and knowledge into searchable, governed AI assistants.
Telecommunications & media
Typical decision
Streaming and analytics at scale with predictable unit costs.
Agriculture & food
Typical decision
Combining weather, supply-chain and yield data for planning decisions.
11 — Start with a brief
Tell us about your query
A few short questions give us an initial understanding before we talk. Skip any you are unsure about; only your name, contact and goal are needed.
Tell us your industry and where you are on the cloud journey
Greenfield, mid-migration, or trying to cut a cloud bill: we will come back with a first view of the options and how we would test them.
› AI recommends, your people decide. No workload moves without a signed-off plan.