Mit dem Konzept der IT-Architekturgilde fördern wir bei der EnBW den Austausch unserer IT-Architekten innerhalb der EnBW. Nach dem Spotify-Vorbild setzen wir dabei auf das Format einer Gilde. Das bedeutet, wir kommen in einer freiwilligen Community zusammen, die den fachlichen Austausch seiner Mitglieder fördert. Inhaltlich bietet unsere Architekturgilde dabei zweiwöchentliche Treffen und eine Mailingliste, in der die Erkenntnisse unserer Treffen zusammengefasst werden.
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,... |