Senior Business Analyst

Data Modelling

• Run data modelling workshops with business SMEs, domain owners, analysts. 
• Design conceptual and logical data models across multiple business domains, working from business definitions as well as from existing data structures in mastering systems.
• Model business complexity appropriately: e.g. class hierarchies, inheritance, controlled vocabularies, reusable patterns, shared data domains, business rules, and define where cross-domain references exist.
• Present models back to stakeholders for review, information-sharing, and agreement 
• Ensure every model element traces back to a business term from data governance, and that the trace survives all the way to the delivered column. Help to resolve conflicts or missing inputs/outputs where they exist
• Review other domain data models from the modelling team. We envisage a small team of modellers who contribute to the federated data model as a whole.

Standards and federation

• Contribute to and enforce the modelling standards that make federated delivery safe: naming conventions, data type standards, model layering rules, and the conventions that prevent domains colliding as the model grows
• Define reusable enterprise-level structures — shared types, reusable/common patterns, balancing core versus domain-local

Delivery and automation

• Work in Git and GitHub as your primary environment: branches, pull requests, code review, releases
• Review model changes raised by others — including, ultimately, any changes drafted by AI agents — and apply the judgement that automated checks cannot
• Version models, assess the impact of breaking changes on downstream consumers in order for migration planning
• Contribute to the automated checks that enforce standards in CI, in collaboration with engineering 
• Have input into the logical-to-physical mapping — deciding and documenting where a normalised structure can/should be denormalised for query performance or analytics (e.g. a data product), an define agreed and named patterns for these transformations rather than ad-hoc judgement so they can be automated.

Key Responsibilities

• Substantial data modelling experience, with a track record of conceptual, logical modelling that powered physical models that went into production, consumed, iterated upon & versioned accordingly. You must be competent in the principles of abstraction, inheritance, normalisation. Experience with dimensional/denormalization techniques.
• Demonstrable domain knowledge in asset/investment management, or a closely related financial services area — sufficient to hold a credible conversation with a SME, e.g. a portfolio manager, a fund accountant or a risk analyst about what their data actually means. 
  We are building out domain by domain. You would be expected to develop working depth across more than one area. We expect some in depth asset management knowledge in at least 3 of these areas:

• Instrument/Security reference, Index & Benchmarks, Party, Counterparty/ Client, Portfolio, Holdings & Valuations, Execution, Trade Life cycle, Performance & Attribution, ESG/sustainability, Fund Accounting, Sales & Marketing
• Working fluency with Git and GitHub: branching, pull requests, resolving conflicts, reviewing others’ changes. You do not need to be a software engineer, but you must be comfortable that your model lives in a repository and moves through code review.
• Comfort authoring in YAML, and working with JSON data – plus the willingness to learn a schema language – prior exposure is welcome but not expected.
• Experience establishing or working to modelling standards — naming conventions, data dictionaries, glossaries, and the ability to add/enhance those standards as part of the platform maturation and greater automation.
• Soft Skills: The ability to run a workshop with business stakeholders and leave with clarity, and not a list of open questions. Precision with language. Dealing with ambiguity. Much of this role is writing definitions that all stakeholders can agree on.

Nice to have:

• Databricks, Delta Lake or a comparable Lakehouse platform
• Data contracts, particularly ODCS, or equivalent interface-versioning practice
• CI/CD concepts 
• Experience of developing/using agentic workflows for delivering model artefacts 
• Experience of a federated or data mesh operating model, and its failure modes
• Traditional modelling tools such as Erwin, ER/Studio is useful, for reference, however our way of working will be different.