Service Management 🕹️
Problem
As organizations scale, they lose visibility and consistency in managing applications. A framework is needed to standardize processes, provide ownership, enable better cost-tracking, and much-needed visibility as the organization grows.
Scope Definition
As an Organization
Non-Technical
| Name | Description | Implementation |
|---|---|---|
| App Tier Definition | Defines the tier or criticality level of an application, based on business impact. | Tier 1 - Critical services [...] Tier 4 - low-impact internal tools |
| App State Definition | Defines the development and operational states of an application. | In development, In production, Retired |
| Change Management Process | The process for reviewing, approving, and implementing changes to applications on production. | Change request required for T1 applications |
| Incident Criticality Definition | Criteria for defining the severity and priority level of incidents. RCA recommended and required if high severity. | Sev-0 - Entire service down [...] Sev-2 - Small issue or degradation |
| Escalation Process | The predefined path for escalating high priority incidents or issues to senior engineers, managers etc. | T2 Sev-0 incident - If not resolved in 1 hr, escalate to manager. If not resolved in 2 hrs, escalate to VP |
| Data Classification | Categorization of data by levels of sensitivity and required protections. | Public, Internal, Confidential |
| Documentation Standards | Standards for style, formatting, content and maintenance of technical documentation. | Use succinct and clear language (SHOULD/MUST/MAY encouraged), diagrams and examples |
| Vendor Review Process | The process of evaluating and onboarding vendor products and services. | Review against standards for security, reliability with SLAs |
Technical
| Name | Description | Implementation |
|---|---|---|
| Tech Radar | Technology tracking dashboard highlighting approved/deprecated technologies. | Adopt, Trial, Assess, Hold (e.g. Thoughtworks) |
| Design Review | Process of validating design against all the standards. | Checklist and templates |
| Architecture Documentation Standards | Standards for documenting application architecture. | Overview diagram, component diagrams, data flow docs, performances (throughput and scalability), dependencies and point of contacts |
| Testing Standards | Standards defining test strategy, coverage, types. | Unit testing, integration testing, user acceptance testing |
| Telemetry Standards | Standards for logging, metrics and tracing. | Structured logs, Tagging, Distributed tracing |
| Infrastructure Design Standards | Standards and visibility on the company infrastructure stack. | Network topology, Ingresses, Kubernetes clusters, CDN, domain names, ... |
| Database Standards | Approved database types and recommendations. | Postgres, DynamoDB, Redis |
| Security Standards | Standards for authentication, data classification and encryption, secrets management | OAuth, TLS version and ciphers, app visibility |
| BCDR Documentation | Standards for disaster recovery docs. | RPO/RTO definitions, DR testing procedures |
| Messaging Standards | Metadata standards for requests/events. | e.g. HTTP/Kafka Headers MUST contain source and be propagated |
| Entity Schema Standards And Review | Standardized data schemas covering all business use cases | Schemas saved in a repository and code reviewed |
As an Engineer
In general, it's compliance to the standards above. The goal is not to take time away from engineers but bring consistency and agility to the org with their resources. Standards are living and should be versioned, teams have to keep applications up-to-date against these evolving standards.
Standards have to be defined in an abstract enough way to leave room for creativity and innovation to bubble up from teams.