Project Engineering Analytics Hub

Overview

Project Engineering Analytics Hub is an internal web-based engineering analytics portal built to support drilling and fluids engineering teams through a single, centralized platform. I designed and developed it to bring together operational dashboards, document generation, data exploration, laboratory workflows, and supporting utilities that would otherwise exist across disconnected spreadsheets, reports, siloed databases, and manual processes.

The goal of the platform was not just to display data. It was to create a usable internal system where engineers and operational stakeholders could move from data access to analysis, reporting, workflow execution, and document output without constantly switching between tools. In practice, that meant combining read-only analytics, interactive workflow tools, document generation, file access, and supporting reference pages into one production application.

This project represents a blend of software engineering, data integration, operational design, and user-focused workflow development. It was built as a serious internal platform rather than a lightweight reporting layer, and it reflects the kind of work where application architecture, data systems, and practical operational usability all need to come together.

Context

Engineering teams needed better access to operational data, clearer visibility into field activity, and more efficient ways to generate reports and documents. At the same time, key workflows were spread across multiple systems, with some information living in analytical warehouses, some in structured relational databases, some in file storage, and some in processes that were still heavily manual.

This created a familiar problem in operational environments: the data existed, the reporting needs existed, and the workflows existed, but there was no cohesive system tying them together in a way that made engineers more efficient. Users often had to context-switch between dashboards, spreadsheets, emails, storage locations, and custom outputs just to complete a single line of work.

Project Engineering Analytics Hub was built to solve that fragmentation by consolidating engineering analytics and workflow execution into a single internal portal.

Problem

Before the platform was in place, the engineering reporting and workflow environment suffered from several key limitations:

• Operational data lived across multiple systems and was not easily unified in a single experience
• Reporting and document creation required too much manual effort
• Self-service access to data was limited or cumbersome
• Lab-related processes and supporting document workflows were not fully integrated with engineering tools
• Users had to move between separate tools for analysis, reporting, lookup, file access, and communication
• The overall experience lacked a coherent application layer designed around how engineers actually worked

The challenge was not simply to create dashboards. It was to build an internal portal that connected data access, analytics, reporting, supporting workflows, and document outputs into one place.

Objective

The objective of Project Engineering Analytics Hub was to create a centralized, production-grade internal application capable of supporting:

• Interactive engineering dashboards
• Operational data exploration and filtering
• Report and document generation workflows
• AI-assisted narrative generation in formal outputs
• Laboratory-related views and request workflows
• File lookup and document retrieval
• Supporting team and configuration pages
• Enterprise authentication and permissions
• Reliable integration across analytical, relational, and storage systems

The platform needed to be accessible, maintainable, responsive, and practical for real internal users. It also needed to support both analytical consumption and active workflow execution, which meant it had to function as more than a dashboard site.

What I Built

I built Project Engineering Analytics Hub as a modular Flask-based internal portal with a server-rendered multi-page architecture and a broad set of integrated engineering and operational capabilities.

At a high level, the system included four major functional areas: dashboards, workflow tools, laboratory features, and supporting utility/configuration pages.

Dashboards

I developed multiple engineering-focused dashboards to provide interactive visibility into operational data. These included:

• A Project Engineer Dashboard for interactive operational analysis, including offset mapping, operational tables, depth-related tracking, and cascading filters
• A Concentrations Tracker using spreadsheet-style grid interactions and charting for engineering metrics
• A Losses Tracker with geographic visualization, tabular analysis, and export workflows
• An Engineering Archive providing searchable and filterable access to historical engineering data

These dashboards were designed to give users direct access to operational information without requiring direct database access or BI authoring expertise. The emphasis was on self-service visibility, filtering, map-based exploration, and exportable views.

Workflow Tools

Beyond analytics, I built interactive tools that supported engineering-specific workflows and report generation. These included:

• A Well Recap workflow for generating professional Word and PDF recap documents from operational data, including interval narratives, cost summaries, and embedded chart outputs
• Mud Tracking Projections workflows that generated projections reports and supported downstream sharing and communication
• A Well Cleansing Tool for analyzing data quality issues, cost discrepancies, and record-level problems through visualizations and structured analysis views

These features were important because they moved the portal beyond passive analytics. The application became a place where engineers could actively execute workflow tasks, generate deliverables, and investigate issues.

Laboratory Module

I also incorporated laboratory-related functionality into the portal so that engineering and lab-adjacent workflows could live in one environment rather than in disconnected systems. This included:

• A Current Lab Projects view for active project tracking
• A Historical Lab Projects archive with filtering and date-range search
• A Lab Request Form for structured multi-section submission workflows
• A Lab File Lookup interface for navigating and previewing stored lab documents

This laboratory integration helped bridge operational engineering work and supporting lab processes, which is often where fragmented internal tooling creates friction.

Supporting Pages and Utilities

In addition to core dashboards and tools, I built supporting pages that made the portal a more complete internal system, including:

• A landing page with feature-based navigation
• A searchable Team Directory
• A Report Specs configuration interface for report-related parameters
• A Contact page with geographic visualization and organizational information

These pieces helped the portal function as a true internal application rather than a disconnected collection of screens.

System Architecture

Architecture and Design

From an architectural standpoint, Project Engineering Analytics Hub was designed as a modular Flask application using the application-factory pattern and blueprint-per-feature organization. This made it easier to separate concerns, structure features independently, and keep the application maintainable as it grew.

A major design principle of the platform was keeping route handlers thin and placing business logic into service layers. That separation helped maintain clarity between request handling, operational logic, and downstream data or storage interactions.

SQL was externalized into feature-specific query files rather than embedded directly inside application code. This made query management cleaner, improved maintainability, and allowed data access logic to stay closer to the features it supported.

The application also used a unified query execution model that abstracted multiple data access paths behind a common interface. This mattered because the system relied on both Databricks SQL and Azure SQL, and users needed a seamless experience even though the underlying data lived across different systems.

On the frontend, the application followed a server-rendered multi-page design rather than a SPA architecture. Each page loaded the specific libraries it needed, which kept the application more modular and allowed feature-heavy views to remain relatively self-contained. Shared infrastructure, layout components, and common service layers helped create consistency across the portal.

Data and System Integrations

One of the most important aspects of the project was its integration across multiple systems. The platform connected to:

• Databricks SQL as a primary analytical warehouse for drilling, fluid, cost, and operational data
• Azure SQL for structured relational records supporting lab, team, and related application data
• Azure Blob Storage for stored documents, files, and generated outputs
• Microsoft Graph for email workflows, user lookup, and Microsoft ecosystem integrations
• Azure AD for identity, authentication, and group-based access control
• OpenAI for automated narrative generation used in report outputs

This cross-system integration was a major part of the project's value. The application did not just present isolated data. It acted as a working layer between analytical sources, structured databases, file systems, identity systems, and user-facing workflows.

Authentication and Access Control

The portal used a layered authentication model built around Microsoft identity infrastructure. Interactive login flows were supported through Azure AD and MSAL, while production authentication could be reinforced through infrastructure-level support in Azure Container Apps.

Permissions were structured through Azure AD groups, enabling feature gating and controlled access to parts of the application. This was important because different user groups needed different levels of access across dashboards, workflow tools, and lab-related features.

Session persistence and caching were supported through Redis, which helped maintain user state and reduce unnecessary repeated work across integrations.

AI and Automation

One of the notable aspects of the platform was its use of AI-assisted narrative generation within operational reporting workflows.

In the Well Recap process, I integrated OpenAI-based generation to produce natural-language interval summaries that could be embedded into formal document outputs. This was not treated as a novelty feature. It was used to reduce manual reporting effort and support more scalable document generation workflows.

To keep this practical and efficient, AI responses were cached so that repeated generation would not create unnecessary calls or latency. This reflects the broader theme of the project: automation was used to support a real operational workflow, not just to showcase a feature.

Frontend and User Experience

Although the application was server-rendered, the frontend was still highly interactive. I used page-specific libraries and utilities to support charting, mapping, data grids, filtering, export workflows, and richer user interaction patterns.

The user experience was designed around internal usability rather than aesthetic minimalism alone. That meant prioritizing:

• Filterable and searchable interfaces
• Export and document-generation paths
• Map-based data exploration where appropriate
• Table and grid experiences for operational data
• Consistency across pages and feature modules
• Responsive behavior for varied device sizes

A major design priority was accessibility. The application included support for ARIA attributes, skip links, screen-reader awareness, high-contrast considerations, and reduced-motion support. This made the portal more robust and usable across a wider range of internal users and environments.

Deployment and Operations

I containerized the application and deployed it to Azure Container Apps using Docker-based builds and Azure-native deployment flows. This created a more repeatable and scalable hosting model than traditional manually managed server environments.

Operational readiness was supported through:

• Multi-stage container builds
• Health and readiness probes
• Diagnostic endpoints
• Container scaling support
• Deployment scripting through Azure CLI and related tooling
• Revision management and traffic shifting

This matters because the project was not just an internal prototype. It was built and operated as a production application with real reliability and deployment concerns.

My Role

I was responsible for the overall design and development of the platform across the application stack. My role included:

• Application architecture
• Backend design and service-layer implementation
• Dashboard and workflow feature design
• Integration with analytical, relational, file, email, and identity systems
• Document generation workflows
• AI-assisted reporting features
• Deployment and production operations patterns
• Usability and accessibility considerations across the portal

This was a broad ownership role that combined software engineering, data integration, operational product thinking, and internal workflow design.

Technical Scope

The platform involved a wide range of technologies and engineering concerns, including:

• Python and Flask for backend application development
• Jinja-based server-rendered frontend architecture
• JavaScript-driven interactive UI features
• Databricks SQL and Azure SQL integration
• Plotting, mapping, and grid-based data interaction
• Document generation across Word, PDF, and spreadsheet workflows
• Azure-based authentication and hosting
• Microsoft Graph integrations
• OpenAI-assisted narrative generation
• Redis-backed sessions and caching
• Containerized deployment and health-oriented operations

The significance of the project lies not just in the size of the stack, but in how all of these elements were brought together into one cohesive internal system.

Key Engineering Themes

Centralization of Engineering Workflows

The portal consolidated multiple analytical and operational processes into a single application, reducing fragmentation and context switching.

Beyond Dashboarding

This was not only an analytics project. It included active workflows, reporting automation, file interactions, and structured internal process support.

Modularity and Maintainability

The application was designed with modular backend organization, externalized query files, reusable service layers, and shared frontend infrastructure to support long-term maintainability.

Practical AI Integration

AI functionality was incorporated where it directly supported operational output, specifically in reporting workflows, rather than being added as a disconnected feature.

Enterprise-Oriented Integration

The platform connected identity, analytics, relational data, storage, and communication systems in a way appropriate for a production internal business application.

Outcome

Project Engineering Analytics Hub created a centralized operational portal that improved how engineering teams accessed data, explored operational conditions, generated documents, interacted with supporting lab workflows, and worked through internal reporting tasks.

The platform delivered value through:

• Stronger consolidation of engineering analytics and workflow tools
• Reduced manual effort in report and document generation
• Better self-service access to operational data
• Improved integration between engineering and lab-adjacent workflows
• More scalable internal tooling for analysis, reporting, and document management
• A stronger technical foundation for continued workflow modernization

Why This Project Matters

This project is a strong example of how software engineering, data systems, reporting automation, and internal product design can come together in a single platform.

It shows the kind of work I am strongest at: building systems that sit between raw operational data and real user workflows. Rather than focusing only on backend processing or only on dashboards, the platform addressed the full internal experience—data access, workflow execution, document output, user interaction, and system integration.

That pattern is highly transferable to healthcare and other process-heavy environments. Many of the most valuable systems in those domains are not public-facing products. They are internal platforms that improve operational visibility, reduce process friction, standardize outputs, and make specialized teams more effective.