How I Organized My Projects Around Data Engineering, Analysis and Business Intelligence
Why I Reworked the Portfolio
I reworked my portfolio to explain the projects, decisions and evidence behind my work. A visitor should be able to see what I built, why I made particular choices and what the result can support. This account describes those editorial choices; it does not report measured hiring or visitor outcomes.
The portfolio home page presents my work through data engineering, data analysis and business intelligence. Those disciplines give me a way to organize the story. They also create a useful question for every project: how does the work move from a source dataset to something another person can understand and use?
My capstone is a useful example because it crosses those boundaries. Its public repository contains a pipeline over public hospital quality data and a regression analysis. Explaining it requires more than naming the services in its architecture.
Organizing the Work Around Three Disciplines
I use data engineering to describe the work that makes data available and prepares it for downstream use. Data analysis describes how I examine that data and interpret results. Business intelligence describes how I present information through reporting models and visual explanations. The site’s discipline sections introduce that framing before visitors reach the individual projects.
For my portfolio, these are connected parts of the work. A project may need several of them even when one discipline receives most of the attention. I do not want a pipeline project to stop at a diagram or an analysis project to start with a result that has no explanation of its inputs.
The capstone makes that connection concrete. Its Airflow workflow retrieves public data and runs the preparation jobs. Its joined dataset transformation combines the curated domains by hospital identifier. Its notebook contains the regression and saved analytical outputs.
That sequence gives the portfolio a structure: follow the data into the analysis, then explain the result. A tool name belongs where it helps explain a responsibility. Airflow matters here because it coordinates the workflow. The notebook matters because it contains the analytical method. Neither name substitutes for explaining the decision.
Turning a Project Into a Case Study
A home-page card can introduce a project, but I treat the case study as the place where its scope becomes clear. The capstone case study separates the problem, my role, the architecture, the decisions and the lessons. That structure gives me room to explain the work without asking a visitor to reconstruct it from the repository.
I start with the problem because a reader needs to understand why the project exists. Then I identify my contribution. I use first person to describe my contribution to this personal portfolio. The surrounding factual claims still need evidence. Saying that I built a workflow does not establish that it is a production service or that its analytical result is clinically useful.
The architecture explains how the parts connect. For the capstone, the workflow source shows a manually triggered process that runs the preparation jobs in sequence. I can describe that implemented boundary directly. A production scheduling claim would require different evidence.
The decision sections are where I explain why the implementation takes that form. I want the reader to see the relationship between a choice and its consequence. The lessons then make room for what the project exposed, including limitations that a short project summary cannot explain.
The same structure guides my editing. If a paragraph only repeats a service name or a diagram label, it probably adds little to the account. If it explains why a choice matters or where a result stops being useful, it has a clear job.
Connecting Claims to Evidence
I think of the portfolio as a route into the work. The home page introduces it, the case study explains it and the source lets a reader inspect the implementation. Each layer has a different amount of detail, but the claim should remain consistent as the reader moves between them.
A link also needs to support the claim beside it. A repository overview establishes project scope. A workflow file supports an orchestration description. A notebook supports a statement about the fitted analysis. Linking everything to a repository’s front page would make the account harder to check, even if the repository contains the right evidence somewhere.
I use the capstone to show why limits belong beside results. Its infection-measure transformation averages available standardized infection ratio measures into a hospital index. That is more specific than a general claim about predicting infections. The analytical target needs to be described as the value the code actually constructs.
The notebook also fits its median imputer before splitting the data. That means the held-out rows contribute to preprocessing. I can discuss that limitation without presenting the analysis as an independently validated predictor or treating a saved output as a newly repeated experiment.
These details do not need to crowd the home-page card. They do need a visible place in the fuller account. My goal is to make the implementation and the limits of its results clear.
What I Want the Portfolio to Explain
The rework gives me a clearer editorial purpose for the site: explain how I build, analyze and present data through the projects themselves. I do not need every project to tell the same story. I need each one to identify the problem, my contribution, the important decisions and the evidence behind its claims.
The capstone is useful because its pipeline and analysis can be discussed together without treating them as the same achievement. The workflow explains how data is prepared. The notebook explains the analytical method and its limits. The portfolio gives a reader a path between those parts.
That is what I mean by showing the work. A project should offer more than proof that I have used a tool. It should make my reasoning visible enough for a reader to ask a specific question, inspect a source or understand why a limitation matters.
I judge the account by that purpose. Does it explain a decision? Does its evidence support the wording? Does it distinguish what I built from what I can conclude? Those questions help me decide what belongs on the page.