Architecture is only as good as what it makes possible. A selection of systems I have designed and delivered.
I architected a framework for metadata-driven ETL generation, with configurable quality controls and operational monitoring. Repeatable logic becomes part of the platform; integrations evolve through shared rules.
Less manual development.
More consistency. Room to evolve.
I work across the entire platform lifecycle, connecting technical decisions to the people and products that depend on them.
Clear semantic models and engineering standards that give a platform room to grow.
Recovery, monitoring and SLA controls are part of the architecture from the start.
Open-source foundations, lower vendor dependency and deliberate decisions about TCO.
IRINA PAROSHINA / GEORGIAIP—01I’m Irina. I work across the full lifecycle of a data platform — from architectural decisions to production delivery.
My background spans physics and mathematical modelling, software development, data science and enterprise data architecture. I’ve worked across billing, CRM, finance and product — always with the whole system in view.
Master’s · Computer Modelling in Applied Electrodynamics
BSc · Physics & Mathematics
When adding people and infrastructure stops translating into faster, more reliable delivery, it is time to examine the platform itself.
The team and data volumes have grown, but delivery takes longer. Each new source requires a custom pipeline, while critical business logic lives in SQL understood by only a few people.
Stale or incorrect data, recurring incidents and manual recomputations. When a pipeline fails, someone has to trace which datasets, reports and decisions may be affected.
Infrastructure and engineering effort keep growing. It is difficult to distinguish necessary capacity from architectural overhead and repeated manual work.
A migration, a lakehouse, dbt, Databricks or Snowflake is on the table. Before committing, you need to understand whether the proposed change addresses the actual problem.
These symptoms can point to accumulated architectural complexity. They are a reason to investigate the platform — before assuming the answer is more engineering capacity.
A reasoned view of the constraints, risks and trade-offs, followed by prioritized changes: what to address first, what can wait, and where a stack change is justified.
Priorities, sequencing and dependencies.
Software and database engineering (2011–2016): payment systems, CRM, incident management and warehouse systems. Technology journalism (2008–2014): Computerra, CNews, IBM. Early development and research (2002–2009): C++, Fortran.
Have a complex data challenge?