docs: update HDI case study (asyncapi#3434)

Co-authored-by: asyncapi-bot <[email protected]>%0ACo-authored-by: Lukasz Gornicki <[email protected]>%0ACo-authored-by: Thorben Heins <[email protected]>

config/casestudies/hdi.yml

@@ -4,29 +4,31 @@ company:
   description: The HDI brand operates in Germany and internationally, offering life and property/casualty insurance services. They cater to both private individuals and corporate clients, and have been providing industrial insurance since 2016.
   customers: "5000"
   industry: Insurance
-  revenue: 9.1 Mrd. EUR
+  revenue: 9.1B EUR
   website: https://www.hdi.global/
   logo: /img/casestudies/hdi/hdi_logo.svg
   contact:
     - name: Vladislav Zwenihorodski
       link: https://www.linkedin.com/in/vladislav-zwenihorodski-9680a1209/
 challenges: |
-  The HDI has various platform teams, among them the Integration Platform Team, which offers three products: Azure API Management, Azure Event Hub, and the Azure Service Bus.  
-  For synchronous communication, we already use OpenAPI, as such we want to ensure the same level of transparency and discoverability for asynchronous scenarios as well.
-  Our central platform team offers the Azure Service Bus with self-service capabilities. 
-  Customers are able to manage their own topics and subscriptions by simply modifying the according values in their repositories. 
-  This means that most of the data required to document asynchronous communication is already available, although distributed between different repositories.
-  This necessitated the creation of a comprehensive catalog of existing topics, allowing potential subscribers easy access to messages from any topics of their choosing.
+  The HDI has various platform teams, among them the Integration Platform team, which offers three products: Azure API Management, Azure Event Hub, and the Azure Service Bus.  
+  For synchronous communication OpenAPI is used as a standard. For asynchronous scenarios we want to use AsyncAPI to achieve the same level of transparency and discoverability.
+  We as platform team offer the Azure Service Bus with self-service capabilities. Our customers are able to manage their own topics and subscriptions by maintaining a custom
+  configuration model in a GitOps fashion. 
+  We want to establish AsyncAPI as documentation standard in HDI's organization. Information about the available message formats and topics is already available in distributed 
+  sources (e.g. repositories) and needs to be aggregated. 
+  To achieve discoverability the creation of a comprehensive catalog of existing topics is necessary, allowing potential subscribers access to information about 
+  messages from the available topics, so they can choose which ones to subscribe to.
 
 
 solution: |
-  The solution was to create an an AsyncAPI document where each topic owned by the customer is represented as a channel. 
-  This document is automatically generated by a pipeline whenever there's a change in the topic configuration. 
+  The solution is to create AsyncAPI documents where each topic owned by the customer is represented as a channel. 
+  As we are using the GitOps setup it is straightforward to run pipeline whenever there is a change (commit) in the topic configuration. 
   The necessary information is read from the customer repositories and then passed to a bash script as input. 
   After successful creation, this file, along with a generated markdown for it, is saved within a documentation repository. 
   This documentation repository serves as the basis for our Azure DevOps wiki, ensuring that all project documentation is centralized and easily accessible.
-  This ensures that the information is readily accessible to every developer, allowing easy access to messages from any topics of their choosing.
-  This approach makes our asynchronous communication is as transparent and discoverable as our synchronous communication.
+  As the documentation wiki is public the information is accessible to every developer, allowing easy access to messages from any topics of their choice.
+  This approach makes our asynchronous communication as transparent and discoverable as our synchronous communication.
 technical: #We need some more technical information related to case study.
   languages:
     - java, .net, bash
@@ -198,7 +200,9 @@ asyncapi: #More specific details about AsyncAPI itself and how is it used.
   usecase: |
     - The AsyncAPI documents are used for documentation purposes by the platform team. 
       It provides a comprehensive overview of the asynchronous communication in our system, including the available topics and the structure of the messages.
-    - (Future Plans) The AsyncAPI document will be used to generate Java DTOs using the AsyncAPI Java generator, ensuring type safety and clear data structure understanding.
+    - (Outlook) The AsyncAPI document will be used to generate Java DTOs, ensuring type safety and clear data structure understanding.
+    - (Outlook) Having the AsyncAPI documents at hand we are currently planning to use them to configure an internal developer portal (IDP) that will aggregate async and sync APIs among other things.
+    - (Outlook) Evaluate if replacing the custom configuration model and use AsyncAPI documents in the center to configure asynchronous communication instead.
   versions:
     - '3.0.0'
   storage: |
@@ -209,7 +213,7 @@ asyncapi: #More specific details about AsyncAPI itself and how is it used.
     This pipeline uses a bash script to read the updated configuration from the customer's repository. 
     It then generates a new AsyncAPI document reflecting these changes.
 
-    The AsyncAPI document is validated using the AsyncAPI CLI to confirm that the document is correctly formatted and adheres to the AsyncAPI specification right after creation and befor being commited to the documentation repository.
+    The AsyncAPI document is validated using the AsyncAPI CLI to confirm that the document is correctly formatted and adheres to the AsyncAPI specification right after creation and before being commited to the documentation repository.
   maintainers: | 
     Customers maintain this document automatically by maintaining their own topic configurations.
   audience: #Specify if AsyncAPI audience is internal or external or both.