Skip to content
View paulkarikari's full-sized avatar
🎯
Focusing
🎯
Focusing

Organizations

@DevlessTeam

Block or report paulkarikari

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Maximum 250 characters. Please don't include any personal information such as legal names or email addresses. Markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
paulkarikari/README.md

Paul Karikari

Principal Engineer & Solution Architect- Data & AI | Azure Databricks | Financial Services

LinkedIn

Azure Databricks Certified Terraform Python SQL

I am the person teams call when a Databricks program is technically promising but operationally fragile.

I design and deliver data and AI platforms that survive real-world pressure: architecture board scrutiny, security controls, audit evidence requests, and production support at 2am. I have built systems for major institutions including NatWest, and I care deeply about making high-stakes platforms dependable, explainable, and repeatable.

I am hands-on in delivery, not just design. I work directly in Databricks, Python, SQL, and Terraform to translate architecture into working pipelines, governed data products, and deployable infrastructure.

My style is practical and transparent. I work closely with architecture, engineering, risk, and control teams to turn complex requirements into clear decisions and shippable delivery plans.

Personal principle: make production boring, because boring is what trust looks like in regulated environments.

Client Outcomes

  • Faster architecture sign-off with clear, documented trade-offs.
  • Stronger governance posture through explicit controls and ownership.
  • Reduced platform drift via repeatable Terraform and delivery patterns.
  • Better audit readiness through evidence-oriented architecture artifacts.

How I Engage

I typically support one of three engagement types:

  • Architecture and readiness assessment: establish gaps, target state, and a delivery-ready roadmap.
  • Solution architecture pack delivery: produce full review-ready artifacts (vision, ADRs, NFRs, controls, operating model, readiness).
  • Platform delivery acceleration: convert architecture into implementation across data, infra, and operations, including direct engineering support.

Case Study

The project below is presented as a practical case study: business problem, architecture approach, and business relevance.

1) Fraud Detection Platform

  • Repository: fraud-detection-platform
  • Problem solved: fragmented fraud data pipelines created slow investigation cycles and weak governance traceability.
  • Architecture approach: governed Bronze/Silver/Gold model with explicit control boundaries and ADR-led decision flow.
  • Why it matters: shows architecture-to-delivery leadership for a high-scrutiny fraud domain.

My Decision Framework

Principles First

My architecture decisions are rooted in established frameworks, then adapted for real Databricks delivery. The principles I use are informed by the Well-Architected approach (reliability, security, operational excellence), DAMA-DMBOK (data governance and stewardship discipline), and TOGAF (architecture structure, traceability, and decision rigor).

I wrote my principles this way on purpose: they are practical enough for engineering teams to apply day-to-day, but structured enough for architecture, risk, and audit stakeholders to trust. They help me make trade-offs explicit and consistent across platform, data, controls, and operating model decisions.

This is the foundation I return to on every engagement: principles.

Artifacts That Turn Strategy Into Delivery

Over years of delivering in high-scrutiny environments, I have refined a structured artifact set that turns principle-led architecture into execution. These artifacts are how I move teams from ambiguity to accountable delivery: vision, ADRs, NFRs, control architecture, operating model, risk register, readiness checks, and evidence planning.

This is the pack I use to keep work review-ready and implementation-focused: solution_architecture_templates.

How I Work

  • I make ownership explicit so control failures are visible and actionable.
  • I document key decisions early to keep delivery aligned.
  • I build evidence into day-to-day delivery, not as a last-minute audit task.
  • I prioritize repeatable operating models over one-off heroics.

How I Can Help

If you are scaling Azure Databricks in a regulated environment, I can help with:

  • defining target architecture and getting it review-ready for architecture, security, and risk forums
  • embedding governance and controls directly into platform and data workflows
  • accelerating implementation through hands-on Databricks, SQL, Python, and Terraform delivery
  • aligning evidence and assurance so high-scrutiny delivery remains defensible in production

Let's Connect

Pinned Loading

  1. fraud-detection-platform fraud-detection-platform Public

    A solution architecture case study for a Tier-1 bank fraud domain.

    Python

  2. principles principles Public

    A defensible set of architectural and operating principles for regulated Databricks platforms on Azure.

  3. solution_architecture_templates solution_architecture_templates Public

    Reusable, review-ready templates for solution architecture documentation.

  4. chest-x-ray-image-classification-using-tensorflow chest-x-ray-image-classification-using-tensorflow Public

    Chest xray image classification using tensorflow

    Jupyter Notebook 4 1