As part of the Operate accelerator strategy we are developing accelerator specific design principles to ensure we have a consistent and scalable design approach.
These are design principles, not rigid rules. Exceptions are permitted where there is a clear, value-driven reason to deviate.
1. Designed as Foundations, Not Ready-to-Use Solutions
Accelerators are not intended to be deployed as ready-to-use solutions for client implementations. Instead, they provide the foundational configuration for a particular subject area, which clients build upon to deliver their full business solution.
In the legal enterprise sector, every client operates differently. It is the responsibility of those implementing an accelerator to ensure that the final implementation:
- Meets the client's specific business requirements
- Aligns with internal policies and procedures
- Complies with relevant regulatory and legislative obligations
2. Matter Type and Non-Matter Type Accelerators
Accelerators broadly fall into two categories:
- Matter work type accelerators — built around a specific matter or case type, e.g. real estate residential sales or claimant personal injury.
- Accelerators used in relation to a matter work type — not tied to a specific matter type, but used in addition to them, e.g. undertakings, mediation, or hearings.
Where possible, accelerators in the second category should be jurisdiction and matter-type agnostic. This allows us to deliver value to more clients and implementations, more quickly. It also means that clients who cover multiple jurisdictions and matter types can utilise a consistent approach and starting point for driving standardised implementations.
3. Self-Contained and Exportable
Accelerator configuration should be as self-contained as possible, so it can be exported reliably:
- No third-party system integrations
- No inherited configuration or references to other work types, wherever avoidable
- Typically no more than one work type per accelerator, with no dependencies on other work types or Operate features
Dependencies of this kind limit exportability and create unwanted dependencies for client implementations.
4. Recognising Reusable Functional Elements
If a functional element identified within a matter work type accelerator could apply to other matter types, it should become a standalone accelerator rather than remain embedded.
For example, undertakings are used on both real estate and family matter types. Undertakings should therefore become a standalone accelerator, usable across both.
5. Avoid Abstract Work Types
Accelerators should not use abstract work types. If two work types share enough commonality to suggest an abstraction layer, they are more likely one work type which could use sub-types for differentiating the minor variations.
6. Designed to be Added to, Not Stripped Back
Accelerator content should be designed on the assumption that clients will add to it to meet their needs — not that they will need to remove content that isn't relevant.
For this reason, accelerators generally exclude elements known to vary significantly between clients and environments — for example, approval processes or time recording — as these are defined by each client's own operational and business requirements.
7. Supporting Scaffolding
A minimal config scaffold should be provided to enable accelerators to be demo-able and enable gap analysis. A simplified instruction work type and a simplified mandate work type will be provided in the future to further support matter work type accelerators, enabling a realistic implementation context.