This page describes Quantexa's process-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:
- Ensure that each interface between components has a documented specification.
- Ensure that interfaces between teams are well-defined.
- Ensure there is a documented release process which is followed by all use cases.
- Ensure there is a documented process for onboarding new use cases to the Quantexa platform.
Note: a degree of process is important for the smooth and scalable operation of a multi use case deployments. However, these should be kept lightweight, and should be designed to increase and ease collaboration, rather than introducing friction.
1. Ensure that each interface between components has a documented specification.
Clearly-defined interfaces between components will help minimize the coordination required between teams, and ensures a common understanding between all stakeholders.
Each team should be responsible for owning the interfaces between its components and consumers. The interface definition should make clear what downstream teams can expect as consumers of the component. This should include all of the elements below:
- Output data specification: files formats, schemas, data types.
- Usage guidance and practicalities, e.g. file locations.
- Testing to be performed before each release. This will prove the component still meets the interface, to give consumers confidence.
- Compatibility matrix: which versions of the component work with other components?
- Definition of breaking vs. non-breaking changes.
- SLAs, if applicable.
The Design Authority should review and approve interface definitions.
Note that a component may have multiple consumers. For example, in a banking environment, multiple use cases will have batch modeling/scoring pipelines which will all consume the Customer ETL outputs.
2. Ensure that interfaces between teams are well-defined.
Like the technical interfaces between components, the interfaces between teams should also be clear. Each team should understand what their responsibilities are when it comes to interaction with other teams.
A good definition of interfaces between teams will include the following:
- How teams can request changes to components which are owned by other teams.
- How the roadmap for shared components will be decided and communicated.
- How urgent changes will be prioritized and incorporated into existing plans.
- Clear processes for documenting, releasing, and announcing changes to shared components.
- Processes for investigating and resolving defects which may involve multiple teams.
- Clearly assigned ownership and responsibilities.
- Communication channels to ensure that cross team communication is effective and efficient.
- Escalation paths, especially for resolving any conflicting feature requests or feature prioritization challenges.
An important aspect of the interface between teams is how they can develop alongside each other. This will necessitate some technology changes, such as regular ‘development releases’ which allow downstream components to stay aligned with changes as they are made, rather than accumulating migration effort until a formal release. These changes are described on the Technology best practice page:
https://community.quantexa.com/kb/articles/383-6-multi-use-case-best-practice-technology#5-ensure-each-repository-is-owned-by-a-single-team-and-is-published-regularly
The following point refers to releases to production.
3. Ensure there is a documented release process which all use cases follow.
A well-thought-out release process is important for two main reasons:
- For shared components, a good process will allow new versions to be released whilst minimizing the impact on consumers.
- For use-case-specific components, a good process will allow changes to be released independently from other use cases.
Key elements of a good multi use case release process include the following:
- A process for running multiple versions of a shared component in parallel for a limited period. On occasion, breaking changes components will be necessary. This approach allows consumers to adopt the new version at any point within a window, rather than being forced to do so in unison.
- A versioning strategy. Each component should be versioned independently, with semantic versioning used to express component compatibility. For clarity, a compatibility matrix should also be maintained.
- Roles and responsibilities:
- Who provides the final go/no-go decision for a release to production?
- Which team is responsible for triaging defects?
- When multiple components are released simultaneously, who is responsible for overall release coordination?
- What is the acceptable level of defects? Who is responsible for deciding if defects are showstoppers?
4. Ensure there is a documented process for onboarding new use cases to the Quantexa platform.
As well as benefitting existing use cases, having a set of shared Quantexa components makes it easier and cheaper to deploy new use cases. To ensure that this process is efficient, document the process through which new use cases can get up and running on the platform.
The process should lead new use cases through the following questions. The process should make it clear who needs to be involved in each decision, and should refer to relevant guidance or standards for your organization. The Design Authority should make key architectural decisions related to the new use case, such as which common components it reuses.
Data provisioning
- Are the existing shared Quantexa data sources sufficient for the new use cases, or is additional data required?
If new data is required:
- How can the new data be sourced? How can this be automated?
- Would the new data source be valuable to other use cases, or is it specific to the new use case?
Infrastructure provisioning
- How should additional infrastructure be requested?
- How do you determine how much infrastructure is required for the use case?
- Who will do the work to create the infrastructure?
Resourcing
- What skills are required to deliver the new use case? Are these available within the pool of resources?
- What effort/capacity is required to deliver the new use case? Is this available within the pool of available resources?
- What activities are required from other teams? How do these dependencies fit into their planned roadmaps?
Further reading
For further information on Quantexa's best practices for multi use case deployments, see:
