Merge branch 'development' into feature/IPCEICIS-724-work-out-concept-for-repository-process-and-structure-especially-poc

content/en/docs/project/intro-stakeholder-workshop/_index.md

@@ -0,0 +1,94 @@
+---
+title: Stakeholder Workshop Intro
+weight: 50
+description: An overall eDF introduction for stakeholders
+---
+
+
+## Edge Developer Framework Solution Overview
+
+> This section is derived from [conceptual-onboarding-intro](../conceptual-onboarding/1_intro/)
+
+1. As presented in the introduction: We have the ['Edge Developer Framework'](./edgel-developer-framework/). \
+    In short the mission is:
+    * Build a european edge cloud IPCEI-CIS
+    * which contains typical layers infrastructure, platform, application
+    * and on top has a new layer 'developer platform'
+    * which delivers a **cutting edge developer experience** and enables **easy deploying** of applications onto the IPCEI-CIS
+2. We think the solution for EDF is in relation to ['Platforming' (Digital Platforms)](../conceptual-onboarding/3_platforming/)
+    1. The next evolution after DevOps
+    2. Gartner predicts 80% of SWE companies to have platforms in 2026
+    3. Platforms have a history since roundabout 2019
+    4. CNCF has a working group which created capabilities and a maturity model
+3. Platforms evolve - nowadys there are [Platform Orchestrators](../conceptual-onboarding/4_orchestrators/)
+    1. Humanitec set up a Reference Architecture
+    2. There is this 'Orchestrator' thing - declaratively describe, customize and change platforms!
+4. Mapping our assumptions to the [CNOE solution](../conceptual-onboarding/5_cnoe/)
+    1. CNOE is a hot candidate to help and fulfill our platform building
+    2. CNOE aims to embrace change and customization!
+
+
+## 2. Platforming as the result of DevOps
+
+### DevOps since 2010
+
+![alt text](DevOps-Lifecycle.jpg)
+
+* from 'left' to 'right' - plan to monitor
+* 'leftshift' 
+* --> turns out to be a right shift for developers with cognitive overload
+* 'DevOps isd dead' -> we need Platforms
+
+### Platforming to provide 'golden paths'
+
+> don't mix up 'golden paths' with pipelines or CI/CD
+
+![alt text](../conceptual-onboarding/3_platforming/humanitec-history.png)
+
+#### Short list of platform using companies
+
+As [Gartner states](https://www.gartner.com/en/newsroom/press-releases/2023-11-28-gartner-hype-cycle-shows-ai-practices-and-platform-engineering-will-reach-mainstream-adoption-in-software-engineering-in-two-to-five-years): "By 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery."
+
+Here is a small list of companies alrteady using IDPs:
+
+* Spotify
+* Airbnb
+* Zalando
+* Uber
+* Netflix
+* Salesforce
+* Google
+* Booking.com
+* Amazon
+* Autodesk
+* Adobe
+* Cisco
+*  ...
+
+## 3 Platform building by 'Orchestrating'
+
+So the goal of platforming is to build a 'digital platform' which fits [this architecture](https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering) ([Ref. in German)](https://www.gartner.de/de/artikel/was-ist-platform-engineering):
+
+![alt text](image.png)
+
+### Digital Platform blue print: Reference Architecture
+
+The blue print for such a platform is given by the reference architecture from Humanitec:
+
+[Platform Orchestrators](../conceptual-onboarding/4_orchestrators/)
+
+### Digital Platform builder: CNOE
+
+Since 2023 this is done by 'orchestrating' such platforms. One orchestrator is the [CNOE solution](../conceptual-onboarding/5_cnoe/), which highly inspired our approach.
+
+In our orchestartion engine we think in 'stacks' of 'packages' containing platform components.
+
+
+## 4 Sticking all together: Our current platform orchestrating generated platform
+
+Sticking together the platforming orchestration concept, the reference architecture and the CNOE stack solution, [this is our current running platform minimum viable product](../plan-in-2024/image-2024-8-14_10-50-27.png).
+
+This will now be presented! Enjoy!
+
+
+

content/en/docs/solution/design/_index.md

@@ -0,0 +1,7 @@
+---
+title: Design
+weight: 1
+description: Edge Developver Framework Design Documents
+---
+
+This design documentation structure is inspired by the [design of crossplane](https://github.com/crossplane/crossplane/tree/main/design#readme).

content/en/docs/solution/design/proposal-local-deployment.md

@@ -0,0 +1,23 @@
+---
+title: Agnostic EDF Deployment
+weight: 2
+description: The implementation of EDF must be kubernetes provider agnostic
+---
+
+* Type: Proposal
+* Owner: Stephan Lo (stephan.lo@telekom.de)
+* Reviewers: EDF Architects
+* Status: Speculative, revision 0.1
+
+## Background
+
+EDF is running as a controlplane - or let's say an orchestration plane, correct wording is still to be defined - in a kubernetes cluster.
+Right now we have at least ArgoCD as controller of manifests which we provide as CNOE stacks of packages and standalone packages.
+
+## Proposal
+
+The implementation of EDF must be kubernetes provider agnostic. Thus each provider specific deployment dependency must be factored out into provider specific definitions or deployment procedures.
+
+## Local deployment
+
+This implies that EDF must always be deployable into a local cluster, whereby by 'local' we mean a cluster which is under the full control of the platform engineer, e.g. a kind cluster on their laptop.