A mature healthcare technology provider – with an established CRM platform serving hundreds of pharmaceutical organisations across EMEA – was preparing aggressive US market entry, with LatAm to follow. The platform wasn’t ready: compliance gaps against SOC‑2 Type II and HIPAA, scalability limits in the aging PHP monolith, and a fixed market-entry deadline that couldn’t move. I was brought in to define the technical direction end-to-end, manage the Platform team directly, and deliver a validated architecture with a working proof of concept – in under three months.
Healthcare CRM modernisation
SOC-2 Type II · HIPAA · GxP
PHP monolith → Go microservices
US market entry
TOGAF + BTABoK
Hexagonal architecture
Fixed deadline
SOC-2 Type II · HIPAA · GxP
PHP monolith → Go microservices
US market entry
TOGAF + BTABoK
Hexagonal architecture
Fixed deadline
ClientConfidential – EU healthcare tech provider
ProductEnterprise pharma CRM, 600+ organisations
MarketsEMEA → US → LatAm expansion
Timeframe~3 months (assessment + roadmap + PoC)
My roleSenior Architect + Platform team lead
OutcomeArchitecture approved, PoC delivered, roadmap live
3
compliance frameworks: SOC-2, HIPAA, GxP
660+
legacy DB tables reverse-engineered
<3 mo
assessment → architecture → PoC
4×
throughput gain in Go pilot vs PHP
~10
autonomous Go services in target design
The Real Challenge
A platform built for EMEA that must serve the US, but compliance is a completely different conversation
EMEA compliance – primarily GDPR – is familiar territory for a European healthcare tech company. The US is a fundamentally different regulatory environment. SOC-2 Type II certification, HIPAA technical safeguards, and GxP validation requirements for pharma workflows each impose distinct architecture constraints. The platform’s existing design had not been built with these in mind. Retrofitting compliance onto a mature monolith without a clear architecture plan is one of the fastest ways to accumulate technical debt that blocks the very market entry you’re trying to achieve.
A PHP monolith with 660+ tables, no documentation, and a team overloaded with maintenance
The existing platform had been built incrementally over many years into a tightly coupled PHP monolith with over 660 database tables. The internal team was spending the majority of their capacity on maintenance, leaving no headroom for the modernisation work the business needed. The codebase had not been systematically documented. Reverse-engineering the coupling hotspots and data flows – building a reliable “as-is” map – was itself a significant piece of work that had to be done before any architecture decisions could be made responsibly.
A fixed market-entry deadline, competing with an established market leader
The US pharma CRM market has a dominant incumbent (Veeva Systems) with deep compliance credibility, offline sync capabilities, and regional localisation. Entering this market without demonstrable compliance readiness, a credible architecture story, and performance parity is not commercially viable. The business had fixed market-entry timelines. This meant the architecture work had to produce a validated, concrete direction – not a theoretical plan – within weeks, not months. A working proof of concept was mandatory, not optional.
What I Did
1
Stakeholder alignment and quality-attribute definition
Before touching any architecture decisions, I ran structured stakeholder and capability mapping workshops using BTABoK – linking CRM features to revenue, compliance obligations, and field-rep efficiency. I then elicited and formalised approximately 15 quality-attribute scenarios covering availability (99.0% uptime SLA), latency (p95 <200ms), offline sync, extensibility, customisability, and regionalisation across 3+ deployment regions. These scenarios became the acceptance criteria for all subsequent architectural choices – not aspirational targets but binding constraints. This step prevented the most common failure mode in legacy modernisation: designing a target architecture that looks right on paper but doesn’t address what the business actually needs.
2
Current-state assessment – reverse-engineering a 660-table monolith
Performed a deep current-state analysis using TOGAF ADM frameworks – cataloguing coupling hotspots, database schema dependencies, and BPMN process flows. With 660+ tables and no systematic documentation, this required both technical depth and structured methodology. The output was an “as-is” architecture with a risk register: every identified pattern that would break during modernisation was captured before the target design was proposed. This step is what separates responsible architecture engagement from speculative target-state design. You cannot strangulate a monolith safely without a reliable map of it.
3
Target architecture definition – hexagonal Go microservices, event-driven, compliance-native
Applied Domain-Driven Design strategic decomposition to define approximately 10 autonomous Go services across bounded contexts: Accounts, HCP (Healthcare Professional), HCO (Healthcare Organisation), Samples, and Compliance. Each service uses hexagonal architecture to isolate domain logic from adapters – enabling independent compliance testing and validation. Event-driven communication via Apache Kafka was selected to support the near-real-time pharma supply chain workflows the platform needed. The architecture addressed Veeva’s competitive strengths directly: offline mode handled via a progressive web app cache layer, regional compliance via per-region Kubernetes clusters. Every technology selection – Go 1.22, PostgreSQL, Kafka, Terraform/K8s, Prometheus/Grafana – was captured in Architecture Decision Records with explicit business rationale.
4
Proof of concept – working pilot service, CI/CD, and benchmark results
Led the Platform team directly to build the “Accounts” service as the reference implementation – the bounded context with the highest data coupling and therefore the clearest validation value. The service was built with a domain core, port/adapter structure, REST and gRPC adapters, PostgreSQL repository, Kafka producer, and unit and contract tests at >80% coverage. Alongside the service: reusable Terraform modules (VPC, RDS, EKS), a multi-stage GitHub Actions pipeline replacing CircleCI, and Helm-based Kubernetes deployment. The Go pilot was benchmarked against the equivalent PHP endpoint – producing over 4× throughput improvement and approximately 60% reduction in p95 latency. Chaos testing was incorporated to validate against the availability quality-attribute scenarios.
5
Governance framework and phased migration roadmap
Delivered an Architecture Playbook covering service templates, coding standards, ADR workflow, and a mandatory threat-model and quality-attribute checklist for every new service. Mapped data flows to GxP/GDPR controls with audit logging and validation SOPs. Grouped the remaining migration into three waves – Customer 360, Territory Management, Analytics – each with go/no-go criteria bound to quality-attribute KPIs. The final output was an executive briefing comparing the target platform against Veeva on feature parity, differentiators (real-time analytics, open stack), and a 6-month migration roadmap with budget model.
What This Engagement Demonstrates
⚖️
Compliance-first architecture in regulated markets – SOC-2, HIPAA, GxP simultaneously
Most architects treat compliance as a layer added after the architecture is designed. In regulated healthcare this is backwards. SOC-2 Type II audit requirements, HIPAA’s technical safeguards (encryption in transit and at rest, access logging, breach notification architecture), and GxP validation protocols each impose constraints that affect data model design, service boundaries, audit trail architecture, and deployment topology. Getting compliance architecture right from the start determines whether the US market entry is credible or whether it produces a platform that can’t pass the audits the market requires.
🏗️
Legacy monolith assessment – before proposing any target architecture
The most dangerous thing an architect can do with a legacy system is propose a target architecture without understanding the source. A 660-table PHP monolith with implicit coupling, missing documentation, and a maintenance-overloaded team is a minefield. The structured reverse-engineering and “as-is” architecture work – using TOGAF ADM and BPMN to capture what actually exists – was the prerequisite that made everything else reliable. Every migration proposal, every decomposition boundary, every ADR was grounded in what the system actually did, not what we assumed it did.
✅
Validation through a working PoC – not a whiteboard architecture
Architecture plans that don’t include working validation are proposals, not architecture. The proof of concept here – a fully implemented Go service in a hexagonal pattern, with CI/CD pipeline, Kubernetes deployment, chaos testing, and benchmark results – removed the uncertainty that theoretical plans always leave behind. The 4× throughput improvement and 60% latency reduction weren’t estimates: they were measured results from production-equivalent code. For a business making a market-entry decision, the difference between a credible architecture story and speculation is exactly this kind of evidence.
⏱️
Delivering structured architectural work under a fixed, immovable deadline
The entire scope – stakeholder alignment, current-state assessment of a complex legacy system, target architecture definition, PoC delivery, governance framework, and 6-month migration roadmap – was compressed into under three months. This required a sequence that minimised business risk: quality goals first (prevents rework), pilot before scale (validates technology with minimum blast radius), tool-assisted governance (TOGAF in Visual Paradigm ensures traceability). Understanding the right order, and what can run in parallel versus what is a hard dependency, is as much a product of architectural experience as the technical content itself.
📋
Direct team management during architecture execution – not just advisory
The architecture work was done under real delivery pressure, not in an advisory capacity. The Platform team was moved under my direct management for the duration – which meant I was simultaneously responsible for the architectural direction and for the team that built the proof of concept validating it. This combination of ownership – architecture plus execution – is what produced validated results in the timeframe required. An architecture without a team to implement it, and a team without architectural direction, each fail in predictable ways.
Senior Architecture Skills This Project Evidences
Regulated market compliance architecture
Designed architecture with SOC-2 Type II, HIPAA technical safeguards, and GxP validation requirements as first-class constraints – not retrofit. Compliance mapping matrix and audit logging SOPs delivered as programme artefacts.
Legacy system assessment — TOGAF + BTABoK
Reverse-engineered a 660-table PHP monolith using TOGAF ADM. Produced capability maps, BPMN process flows, coupling hotspot catalogue, and risk register before proposing any target architecture. Foundation that made subsequent decomposition reliable.
Domain-Driven Design decomposition
Applied DDD strategic design to define ~10 autonomous bounded contexts (Accounts, HCP, HCO, Samples, Compliance). Each context small enough for an independent team, clear enough to have its own compliance scope.
Hexagonal + event-driven architecture
Hexagonal architecture for domain isolation (core domain with ports/adapters for REST, gRPC, Postgres, Kafka). Event-driven via Kafka for near-real-time pharma supply chain workflows. Validated with a working Go reference service at >80% test coverage.
PoC delivery with measured results
Working Go pilot vs PHP baseline: >4× throughput improvement, ~60% p95 latency reduction. Full CI/CD pipeline (GitHub Actions replacing CircleCI), Terraform IaC modules (VPC, RDS, EKS), Kubernetes Helm deployment, chaos testing. Evidence, not estimates.
Quality-attribute scenario definition
Elicited and formalised ~15 binding quality-attribute scenarios (availability 99.0%, latency p95 <200ms, offline sync, extensibility, 3-region localisation). Scenarios became acceptance criteria for all architectural decisions – not aspirational targets.
Competitive architecture positioning
Explicitly addressed incumbent (Veeva) competitive strengths: offline mode via PWA cache layer, regional compliance via per-region K8s clusters, real-time analytics via Kafka. Architecture defined to match compliance credibility while adding performance and open-stack advantages.
Architecture + direct team leadership
Platform team moved under direct management for programme duration. Simultaneously responsible for architectural direction and for the team building the PoC validating it. Not an advisory role — full accountability for both architecture quality and execution results.
The Core Insight from This Project
Market expansion exposes platform limitations that normal operations keep invisible.
A platform that works well in one regulatory environment, serving a familiar customer base, on
hardware it has outgrown gradually – can appear perfectly healthy right up until you try to take
it somewhere new. The US market didn’t create the problems in this platform. It revealed them.
The second insight: compliance architecture and product architecture are the same decision.
You cannot design a HIPAA-compliant system by adding compliance features to a system that wasn’t
designed for it. Service boundaries, data isolation, audit trail architecture, and access control
models all need to be correct from the start – which is why the compliance requirements were
formalised as quality-attribute scenarios before the target architecture was drawn.
The third: a pilot with measured results removes more risk than a perfect architecture document.
The 4× throughput result from the Go reference service did more to build stakeholder confidence
in the migration direction than any diagram could have. In a company making a significant market
entry bet, evidence matters more than elegance.
Who This Is Relevant For
You’re expanding into the US market from EMEA
GDPR compliance does not transfer to the US. SOC-2, HIPAA, and sector-specific regulations (GxP, FedRAMP, PCI-DSS depending on your market) require architecture decisions that cannot be retrofitted cheaply. The right time to address this is before you enter the market, not after your first enterprise prospect fails to pass you through their vendor security review.
Your platform is a mature monolith that has outgrown itself
Scaling a monolith is not just a performance problem. It is a team problem, a compliance problem, a deployment problem, and a cost problem simultaneously. When your engineering team spends more than half their capacity on maintenance, the platform’s architecture is holding back the business – regardless of how well it runs today.
You need a roadmap, not just an assessment
Architecture assessments that produce a gap list without a migration roadmap are not actionable. What the business needs is a sequenced plan – with wave structure, go/no-go criteria, cost model, and compliance checkpoints – that engineering teams can actually execute and finance teams can actually fund.
You’re competing against an established market leader with compliance credibility
In regulated markets, compliance credibility is a competitive moat. Entering against an incumbent like Veeva or Epic requires demonstrable parity on the compliance dimensions prospects care about, and differentiation on the dimensions the incumbent doesn’t excel at. Architecture has to serve both simultaneously.
You need validated decisions, not whiteboard architecture
Executive stakeholders – rightly – don’t trust architecture diagrams alone. A reference implementation that demonstrates the performance, compliance pipeline, and deployment automation of the proposed direction removes the uncertainty that theory cannot. For large strategic bets, evidence is the architecture artefact that matters most.
Your architect needs to lead delivery, not just advise
The combination of architectural ownership and direct team management – where the same person is accountable for both the design and the team proving it – produces faster, higher-quality results than an advisor and an engineering team operating with a layer of translation between them.
Preparing a platform for a new regulated market, or modernising a legacy product under deadline pressure?
In 30 minutes I can tell you whether your situation maps to what I do — what the real architectural and compliance risks are, and what a structured approach would look like for your specific platform and market.
No pitch. A direct conversation about your platform, its constraints, and where the complexity actually lives.