This page describes Quantexa's people-related recommendations for multi use case deployments. Many of the practices described on this page will also benefit single use case deployments.
These best practices are:
- Identify a single platform owner for the whole Quantexa service.
- Form a Design Authority to set the technical direction of the deployment.
- Form a team who focus on platform-level work.
- Form a team to own centralized data sources.
- Schedule a regular Scrum of Scrums session.
- Ensure you have a scalable self-sufficiency strategy for technical staff.
1. Identify a single platform owner for the whole Quantexa service.
Business sponsors may only have the motivation and funding to build use-case-specific functionality. A multi use case deployment will require a platform owner with the appropriate mandate and budget to make decisions on behalf of the organization, especially where there maybe conflicting requirements and priorities between use cases. This platform owner will generally sit in the IT or Technology team.
Key benefits that having a platform owner will bring include:
- Reducing long-term Total Cost of Ownership (TCO) via investment in the health and maturity of the multi use case common platform.
- Preventing deadlock by making the final decision on any conflicting requirements between business stakeholders.
- Ensuring that synergies between use cases are identified and realized.
- Ensuring that the programme has a clear vision and aims, which feed into priorities across the use cases.
2. Form a Design Authority to set the technical direction of the deployment.
The Design Authority will be comprised of senior technical resources from each team, plus programme-level architects and representatives from supporting teams.
The Design Authority should meet every 1-2 sprints.
Design Authority purpose
- Make technical decisions impacting multiple use cases.
- Design the approach for collaboration between teams including interface management and release processes.
- Make decisions around which components should be shared and which should be use case specific.
- Resolving conflicting functional or technical requirements from different use case teams.
- Support use cases in technical designs, where expertise is required.
- Prioritize improvements to the platform, which will typically be implemented by the Platform team.
- Assure documentation which specifies interactions between different teams, such as component interface definitions.
Design Authority membership
The following roles may be adapted if needed to suit organization-specific titles and divisions of responsibilities.
- An Enterprise Architect.
The person with accountability for the technical health of the Quantexa platform as a whole. This person will chair the Design Authority. - Solution Architect(s) for the use cases, if applicable.
- Technical Lead for each use case.
- Lead Business Analyst
- Data Provisioning Lead
- Platform Operations Lead
- Infrastructure Lead
3. Form a team who focus on platform-level work
The objective of this Platform team will be to facilitate Quantexa use-case development in a scalable and efficient manner. The team will not be measured by use-case-specific functionality.
The team should treat application teams as consumers, soliciting requirements and improvements, but should also set standards for application teams to follow, and should promote best practice across projects.
This team’s backlog will be fed by the Design Authority.
The top priority responsibilities for this team are as follows:
Priority area 1: The Software Development Lifecycle (SDLC)
The Platform team should determine how applications teams should develop, how they can make best use of resources, and how the programme can ensure consistency across all Quantexa projects.
This will include defining and developing:
- Development methodology
- Development tooling (scripts, configuration)
- CI processes and tooling
- Release and deployment processes
- Testing approach
- Testing frameworks and test automation (e.g. API testing framework)
- Upgrade methodology
Priority area 2: The System Architecture
- Infrastructure & environment usage patterns
- Underlying infrastructure version and obsolescence management
- Interfaces to other systems
- Security management
- Infrastructure operations, where this is not owned by a separate team
Priority area 3: Operational Tooling & Processes
- Scheduling, e.g. Airflow
- Monitoring tooling, e.g. Grafana
- Performance testing tooling
- Infrastructure billing
Non-priority responsibilities
The team responsibilities may include the following, provided they do not distract from the primary goals of the team:
- Ownership of common data sources (if there is no dedicated central data team).
- Ownership of common Quantexa functionality, such as upgrades, shared utilities, common auth patterns.
- Operations: monitoring, OAT execution, L1 support.
4. Form a team to own centralized data sources
Centralizing the processing and storage of common data sources is one of the most beneficial activities for a multi use case Quantexa deployment. You can read more about centralized data sources here:
https://community.quantexa.com/kb/articles/231-5-centralized-data-sources
A dedicated team should own these data sources. This team should treat application teams as consumers, soliciting requirements and improvements, such as additional fields for ingestion or cleansing improvements.
This team will have a Product Owner who can consolidate the requirements from all of the use-cases into a single design and will prioritize feature requests.
The top priority responsibilities for this team are:
- Owning the common data design combining the requirements from all the use cases.
- Development of the data ingestion including cleansing and compound creation.
- Ownership and documentation of the interfaces.
- Managing the versioning including documentation of the changes.
- Tuning of Entity Resolution across the common data sources to meet requirements from all the use cases.
- Testing to understand the level of change in the data and entities and to provide guidance on the level of testing needed by downstream use case teams.
For data sources which will only ever be used by a single use case, it is better for the use case pod to develop and own these. Examples of such data sources include FX trades for a Markets AML use case.
5. Schedule a regular Scrum of Scrums session
This session will be used to ensure all use cases to communicate and coordinate dependencies between teams.
Agenda
- Brief update from all teams on current status (RAG), major challenges, next planned release dates.
- Upcoming usage requirements of shared infrastructure.
- Upcoming changes to shared infrastructure (e.g. a Spark version upgrade).
- Open production defects which are relevant to more than 1 use case.
- Upcoming/planned functional changes to interfaces between use cases (e.g. new fields being added to data model, changes to transaction aggregation logic).
- Key learnings raised from sprint retrospectives.
Attendees
- Platform owner
- Product Owner for each use case
- Design Authority representative(s)
- Infrastructure/operations team representatives
- TDO
Optional – not required unless agenda items require their contributions:
- TLs for each use case
- BAs
- Business representatives
Suggested timing
- 30 minutes per week, or 1hr per sprint.
- Adjust based on number of use cases and degree of interdependency between use cases.
Pitfalls to avoid
- Avoid excessively detailed updates – schedule further meetings for follow-ups if needed.
- Avoid having too many attendees – more than 2x the number of use cases is excessive.
6. Ensure you have a scalable self-sufficiency strategy for technical staff.
Having a self-sufficient programme team is essential to scaling the value that you get from your Quantexa platform whilst managing TCO.
This should not just focus on how to deliver/own current use cases self-sufficiently, but how to continue to scale as new use cases are added.
The number of Quantexa consultants on the programme should not generally need to increase as the number of use cases increases. It is expected that there may need to be some ongoing Quantexa support, but this should be a relatively small and static set of roles, for example a TDO, an architect, plus one or two technical leads for the newest or most innovative use cases only.
Key elements of this strategy will include:
- Recruitment strategy for technical staff.
- Start with a small core of technical leads or senior developers and expand from there.
- Focus on quality over quantity.
- Approach for onboarding new people and getting them productive quickly.
- Relationship with partner organization(s).
- Regular competency assessments to identify gaps in the team’s skills.
- Strategy for more specialized roles (e.g. architects, BAs).
- Options include partners, internal/external recruitment or promoting from within the development team.
Further reading
For further information on Quantexa's best practices for multi use case deployments, see:
