clement13.net
Original photo: A bridge
Description
A bridge
Source
Wilfredor · original page
Licence
CC0 Public domain
Original photo, unretouched. The background is a version of it stylised by the site.

BI product — Trust and operations

What lets you rely on the product day to day.

≈ 4 min readReading

Access and permissions#

Who can see and do what, and how is it managed?

LevelSignatureCriteria to meet
0 · HandcraftedThe file is copied to whoever asks for it.Starting point: no criteria.
1 · Locally tooledFiles shared in a folder or protected by a password.
  • Access to shared files is restricted to a list of people.
2 · SharedAuthenticated access, named accounts.
  • Each user has a named account.
  • Access without an account is impossible.
3 · IndustrializedGroups and roles, centrally managed rights.
  • Rights are granted by group or by role.
  • Granting and removing rights follows a process.
  • Rights are managed in one place for all reports.
4 · Integrated and governedRow-level security, inherited scopes, periodic review.
  • Each user sees only the rows in their scope (row-level security).
  • Scopes are derived from the structure (groups, inheritance).
  • Rights are reviewed periodically.
5 · AutonomousPolicy-driven permissions: automatic granting, temporary rights, continuous audit.
  • Rights are granted and removed automatically from reference data (arrivals, departures, changes).
  • Exceptional rights have a limited duration.
  • Access is audited continuously, with alerts on anomalies.
Effect on the user

The user sees exactly what concerns them, without asking for it or filtering it themselves.

Security and compliance#

Are the data and the product protected, and can this be demonstrated?

LevelSignatureCriteria to meet
0 · HandcraftedNo specific measures: data lives on uncontrolled workstations or disks.Starting point: no criteria.
1 · Locally tooledSensitive data is identified.
  • Personal and sensitive data is identified.
2 · SharedBasic measures: encrypted exchanges, backups, updates.
  • Exchanges are encrypted.
  • Backups exist and are tested.
  • Components are updated regularly.
3 · IndustrializedSecurity by design: requirements, reviews, penetration tests.
  • Security requirements are written for the product.
  • Changes are reviewed from a security standpoint.
  • Penetration tests take place regularly, preferably by an independent team.
4 · Integrated and governedCompliance built into deliveries: check before each release, logged access.
  • A compliance check (GDPR in particular) is carried out before each release.
  • Access to sensitive data is logged.
  • A register of processing activities and retention periods is maintained.
5 · AutonomousAutomated checks in the delivery pipeline, continuous monitoring.
  • Security scans and automated penetration tests are part of the delivery pipeline.
  • Secrets are managed outside the code and rotated.
  • Security events are monitored and handled according to a plan.
Effect on the user

The user does not need to know the security rules: the product applies them by default.

Availability and performance#

Is the product there when needed, and at what cost?

LevelSignatureCriteria to meet
0 · HandcraftedAvailable when the author's workstation is.Starting point: no criteria.
1 · Locally tooledFiles on a workstation or a share, with no guarantee.
  • The file is backed up.
2 · SharedShared server, backups, announced maintenance.
  • The product runs on a shared server.
  • Planned outages are announced.
3 · IndustrializedAvailability targets defined and measured, monitoring.
  • An availability target is defined and measured.
  • Response times are measured on key user journeys.
  • Monitoring raises an alert in case of unavailability.
4 · Integrated and governedSized capacity, high availability, managed costs.
  • Capacity is sized from measured usage.
  • The failure of a component does not interrupt the service.
  • Operating cost is tracked and related to usage.
  • The availability target takes into account the combined availability of the services in the chain.
5 · AutonomousAutomatic adjustment: start, stop, scale up and down; self-healing.
  • Resources start, stop and resize automatically according to load or schedule.
  • Common incidents are repaired automatically.
  • A cost overrun triggers an alert or an action.
Effect on the user

The user never wonders whether the product will be available or fast: it is a given.

Support and observability#

Who helps when it does not work, and do we see problems coming?

LevelSignatureCriteria to meet
0 · HandcraftedThe author troubleshoots, when available.Starting point: no criteria.
1 · Locally tooledUsers know whom to contact.
  • A contact person is identified.
2 · SharedSingle entry point and request tracking.
  • A single entry point receives requests.
  • Each request is tracked until it is closed.
3 · IndustrializedSupport process, knowledge base, classified incidents.
  • Incidents are classified by severity with target response times.
  • A knowledge base captures the answers.
  • Root causes of serious incidents are analyzed.
4 · Integrated and governedObservability: logs, metrics and usage telemetry put to use.
  • Logs and metrics are centralized and searchable.
  • Usage and performance telemetry is collected.
  • Monitoring dashboards are used daily.
5 · AutonomousPredictive detection: drifts are anticipated before the incident.
  • Drifts (processing times, volumes) are detected by extrapolating trends before they are suffered.
  • Alerts are qualified to limit noise.
  • Frequent causes trigger an automatic fix or a prepared action.
Effect on the user

The user is warned before suffering the problem, and always knows whom to turn to.