OKRs
@EnBW
IT-Architektur Objectives & Key Results
Die OKRs unserer IT-Architekturgilde verknüpfen Unternehmensstrategien mit konkreten Umsetzungen. Sie bieten dadurch ein Rahmenwerk das als Orientierung für gute Architektur dient. Das Schaubild ist wie folgt aufgebaut: Die linke Seite stellen strategische Ziele dar. Die Tabs rechts davon zeigen einen Drill-Down der jeweiligen strategischen Ziele mit zunehmendem Detailgrad.
- Overview
- EnBW Business Objectives
- IT Objectives (Strategy)
- IT Architecture Objectives
- IT Architecture OKRs
| Cluster | Objective |
|---|---|
| Customer Centric | Client Orientation / Customer Experience |
| New sales channels | |
| Speed | |
| Agility | |
| Strong innovation culture | |
| Segment-Energie-System Solutions | |
| Offerings for third party | Product design with customers/partners |
| Partnership with customers | |
| Implementation Partnerships | |
| Development Partnerships | |
| Operational Efficency | Managing complexity |
| Efficiency and cost orientation | |
| Standardization | |
| Safety and Security |
| Business Objective | IT Strategy Objective |
|---|---|
| Client Orientation / Customer Experience | We are satisfying all consumers (users, technical systems,..) when interacting with our digital products. (We deliver an outstanding customer / user experience regarding performance, availability and data durability.) |
| New sales channels | We are innovating quickly! (We experiment and observe quickly). |
| We maintain over time the ability for fast innovation cycles. (We can experiment quickly – on a sustainable basis!) | |
| We turn successful experiments into production in a very short time. (We turn turn successful experiments into large scale production in very short time?) | |
| We recombine existing capabilities. (We assemble new experiences from existing capabilities in short time.) | |
| We are satisfying all consumers (users, technical systems,..) when interacting with our digital products. (We deliver an outstanding customer / user experience regarding performance, availability and data durability.) | |
| Speed | We are innovating quickly! (We experiment and observe quickly). |
| We maintain over time the ability for fast innovation cycles. (We can experiment quickly – on a sustainable basis!) | |
| We turn successful experiments into production in a very short time. (We turn turn successful experiments into large scale production in very short time?) | |
| We recombine existing capabilities. (We assemble new experiences from existing capabilities in short time.) | |
| We integrate partner/customer solutions. (We integrate partner/customer solutions very quickly.) | |
| Agility | We are innovating quickly! (We experiment and observe quickly). |
| We maintain over time the ability for fast innovation cycles. (We can experiment quickly – on a sustainable basis!) | |
| We turn successful experiments into production in a very short time. (We turn turn successful experiments into large scale production in very short time?) | |
| We recombine existing capabilities. (We assemble new experiences from existing capabilities in short time.) | |
| Strong innovation culture | We are innovating quickly! (We experiment and observe quickly). |
| We maintain over time the ability for fast innovation cycles. (We can experiment quickly – on a sustainable basis!) | |
| Segment-Energie-System Solutions | We recombine existing capabilities. (We assemble new experiences from existing capabilities in short time.) |
| Offerings for third party | We recombine existing capabilities. (We assemble new experiences from existing capabilities in short time.) |
| We integrate partner/customer/OT solutions. (We integrate partner/customer/OT solutions very quickly.) | |
| Managing complexity | We recombine existing capabilities. (We assemble new experiences from existing capabilities in short time.) |
| Efficiency and cost orientation | We experiment at progressively lower cost structures. (We avoid unnecessary spending.) |
| We use the scarce resource "software engineer" wisely. (We ensure that near / offshore sourcing scales?) | |
| Standardization | We experiment at progressively lower cost structures. (We avoid unnecessary spending.) |
| We use the scarce resource "software engineer" wisely. (We ensure that near / offshore sourcing scales?) | |
| Safety and Security | We comply with regulations. (We ensure regulations, security, privacy and safety while moving towards a decentralized and agile managed product organisation even in a regulated environment.) |
| IT Strategy Objectives | IT Architecture Objectives |
|---|---|
| We are innovating quickly! (We experiment and observe quickly). | We enable teams to start experimenting in minimal lead time. |
| We are mitigating incidents in the shortest time possible. | |
| We automate as much as possible and avoid manual activities. | |
| Our developed systems are independently deployable. | |
| WWe keep records of what kind of data is stored and managed by which systems | |
| We are tracing functional decisions and reasoning. | |
| We observe our systems from user perspective. | |
| We provide fast feedback within our development cycle. | |
| We maintain over time the ability for fast innovation cycles. (We can experiment quickly – on a sustainable basis!) | We use an integration architecture that prevents increasing system complexity over time. |
| Our IT Standards support developer productivity. | |
| We are enforcing current patch levels for our make and buy products. | |
| Opensource /3rd party software, which we use, has high quality and sufficient community. | |
| We deliver only high quality code. | |
| Our application architecture prevents applications from growing too complex for change. | |
| Our operational costs are optimized, rather than minimized. | |
| See “scarce resources”. | |
| We are managing risks of vendor-lock in. | |
| We turn successful experiments into production in a very short time (We turn turn successful experiments into large scale production in very short time?) | We integrate and deliver (deploy optional) continuously. |
| We automate as much as possible and avoid manual activities, | |
| Our experiments are outscaleable. | |
| Our experiments encapsulate SLA’s they depend on. | |
| See “scarce resources”. | |
| See “We comply with regulations!”. | |
| Our developed results are ready for production. | |
| We recombine existing capabilities. (We assemble new experiences from existing capabilities in short time.) | Capabilities must be public exposable and have clearly defined our API contracts. |
| We do not use the perimeter to establish trust. | |
| We use a minimal set of integration styles. | |
| Our productive systems handle traffic peaks without degradation of service SLA's. | |
| Our technical data and message formats are standardized. | |
| We are satisfying all consumers (users, technical systems,..) when interacting with our digital products. (We deliver an outstanding customer / user experience regarding performance, availability and data durability.) | We have low user-perceived latency for provided functionality. |
| We provide responsive designs with simple access. | |
| Our productive systems handle traffic peaks without degradation of service SLA's. | |
| Our built systems are resilient. | |
| We observe our systems from user perspective. | |
| Performance tests are mandatory. | |
| Our desired system qualities are challenged constantly. | |
| Our user / customer experience is improved constantly. | |
| See “experiment quickly” | |
| We experiment at progressively lower cost structures.(We avoid unnecessary spending.) | We limit resource usage to what is necessary at a given moment. |
| Our developers only spend time in activities, that provides value to the experiment. | |
| We automate as much as possible and avoid manual activities, | |
| We do not use the perimeter to establish trust. | |
| Our integration technologies (interfaces) minimize test efforts. | |
| Our developed systems are independently deployable. | |
| We comply with regulations. (We ensure regulations, security, privacy and safety while moving towards a decentralized and agile managed product organisation even in a regulated environment. | We use standard implementations of nonfunctional aspects. |
| Our effort on developer side in nonfunctional aspects (security, quality, compliance, architecture,…) is minimized. | |
| Mandatory compliance and architecture requirements are automatically enforced. | |
| We do not use the perimeter to establish trust. | |
| We automate as much as possible and avoid manual activities, | |
| We spend the scarce resource "software engineer" wisely. (We ensure that near / offshore sourcing scales?) | Our effort on developer side in nonfunctional aspects (security, quality, compliance, architecture,…) is minimized. |
| We prevent or regularly clear technical debts. | |
| We provide PaaS-products according to the needs. | |
| We deliver new needed PaaS-products quickly. | |
| Our products are easy understandable or self-explanatory. | |
| Our user experience for developers is state of the art. | |
| We are onboarding developers quickly. | |
| We deliver only high quality code. | |
| Our developer documentation is useful. | |
| We automate as much as possible and avoid manual activities, | |
| We integrate partner/customer/OT solutions very quickly. | Legacy systems are integrated via an explicit facade strategy. |
| We support onprem / edge locations | |
| Customization (everything beyond configuration) in COTS is minimized. |
| Objective | Key results | Gewichtung |
|---|---|---|
| Our deployed systems are independently deployable | Miteinander gekoppelte Systeme sind fachlich autark lauffähig | 50 |
| KR: Simulierte Systemausfälle sind Bestandteil von Integrationstests. Produktiver Check erfolgt via Chaos-Monkeys | ||
| Independent Deployment | 30 | |
| KR: Rolling-Update (via API-Contract, Abwärtskompatibilität) ist gewährleistet | ||
| Systeme sind via Standardprotokolle gekoppelt | 20 | |
| KR: Properitäre Protokolle werden nicht verwendet | ||
| We automate as much as possible and avoid manual activities | Verwende CI/CD | 30 |
| KR: Deployment nur aus der Pipeline heraus (automatisiert) und nicht von lokalen Entwicklungsrechnern | ||
| KR: Artefakte sind stageable (z. B. dev, test, prod) und versioniert | ||
| KR: Jedem Release sind eindeutige Informationen über Softwarestand und den CI/CD-Build zugeordnet. | ||
| Plattform- & Infrastrukturänderungen sind gescripted, werden versioniert und werden innerhalb der CI/CD Pipeline ausgeführt (IaC) | 30 | |
| KR: Auf der Produktionsumgebung sind keine manuellen Deployments möglich | ||
| KR: Alle IaC-Templates sind im SCM hinterlegt | ||
| KR: Die CI/CD Pipeline ist vollständig gescripted, im SCM hinterlegt und lässt sich ohne manuelle Schritte wiederherstellen | ||
| Metriken werden automatisiert ermittelt und sind nicht älter als 24 Stunden (nach einer Änderung) | 40 | |
| KR: zu jeder Änderung wurde die Testabdeckung ermittelt | ||
| KR: jeder Änderung ist eine statische Code Analyse zugeordnet, z. B. SonarQube | ||
| KR: jeder Änderung ist ein Security Scan zugeordnet, z. B. Auditor | ||
| KR: jeder Änderung ist eine Lizenzanalyse für 3rd Party Dependencies zugeordnet, z. B. Auditor | ||
| Capabilities must be publicly exposable and have clearly defined API contracts | Fachliche Fähigkeiten sind EnBW-Gobal via APIs publiziert | 50 |
| KR: Query via interenen API-GW ist möglich - Regelungen zum Access sind definiert | ||
| KR: API ist für public Internet accessable | ||
| APIs sind allgemeingültig und wiedervendbar | 30 | |
| KR: Weitere Konsumenten verursachen keine Anpassung der API | ||
| Jede API (damit jedes Attribut) ist eindeutig beschrieben und wird von allen Nutzergruppen verstanden | 20 | |
| KR: Techische und fachliche API-Dokumentation incl. SLA existiert, ist aktuell (unterliegt KVP) und ist allgemein zugänglich. SLA Inhalte: mittlere Antwortzeit bei def. Mengengerüst (concurrent req./sec), Verfügbarkeit,... |