Sturm ändert alles

Wir kommen aus einer Wachstumsphase und es lief alles super. Wir, als global Village Ökonomie. In dieser Zeit fragte ich einen CEO: „Wie atmen wir aus, wenn es mal anders läuft?“ und seine Antwort war: „Wir wachsen weiter – Das ist nicht notwendig“ … und dann kam CORONA!

Wie reagieren wir auf Sturm – richtig?

Jetzt müssen wir ausatmen. Alle miteinander. Viele Führungskräfte und Vorstände sind mit einem Szenario konfrontiert, mit dem in der Tat keiner so richtig gerechnet hat. Nicht in dieser Dimension. Als Berater habe ich ein Leben Lang eine leidenschaftliche Aufgabe – Nach vorne in die Zukunft zu schauen und Szenarien anzubieten, um sich mit geeigneten Maßnahmen vorzubereiten. „Digitalisierung“ steht dabei schon 30 Jahre auf meiner persönlichen Agenda. Nichts wirklich neues, aber die Notwendigkeit, diese jetzt konsequent umzusetzen ist offenbar für viele zwingend notwendig, um profitabel zu überleben. Also, wie geht das konkret?

Materialwechsel! Materialwechsel! Materialwechsel!

Windsurfing ist meine Leidenschaft in meiner Freizeit. Beim Windsurfen brauchst du eine Garage voller Material. Das meiste davon steht da einfach rum, weil du immer nur ein Brett und ein Segel fahren kannst. Warum also das Investment in das ganze Zeug? Wieso stehen an Surfspots die Jungs mit ganzen Anhängern voll Material, wenn doch klar ist, ob der Wind hart, super strong oder seicht ist. Wir haben doch alle gute Voraussagemodelle. Wieso so viel Zeugs?

Hier die einfache Antwort: Wenn der Wind sich ändert, brauchst du sofort anderes Material. Zumindest dann, wenn du „fliegen“ willst. Klar, es gibt auch Surfer, die zufrieden sind, wenn sie „herumsurfen“, aber die Cracks fliegen immer übers Wasser. Bei jedem Wind, ob Leichtwind oder Sturm. Warum ist das so?

Leichtwind oder Sturm?

Bei 4 Bft. Windstärke fahre ich ein Super Lightwind Raceboard mit 160 Liter Volumen und ein extrem bauchiges 10 qm-Segel, um zu fliegen. Das Board ist breit, damit es schnell Auftrieb produziert und das Segel ist riesig, um den geringen Wind in Speed umzuwandeln. Das alles erfordert viel Technik, Erfahrung und Kraft.

Im Sturm ist alles anders. Da kommt ein sehr kleines, schmales Surfboard zum Einsatz mit einem flachen, straffen 4,5 qm-Segel, um den brutalen Wind von 7-8 Bft. gekonnt in Flugenergie umzusetzen und dabei extrem wendig zu sein.

… und dann kam CORONA. Viele unternehmen waren mit ihrem großen alteingesessenen Material unterwegs. Es ist nicht möglich ein Segel mal eben zu verkleinern oder das Board abzuhobeln. Es muss getauscht werden, ansonsten zerreißt dich der Wind und du landest mit einem brutalen Crash unter Wasser. Vorbei der Spass.

Was ist der Materialwechsel im ökonomischen Sturm?

Wer auch im Sturm weiter über Wasser fliegen will, kann das tun. Materialwechsel ist angesagt! Was bei konstanten Wachstumsbedingungen gut war, ist jetzt komplett unbrauchbar. Jetzt sind kleine wendige Boards notwendig und die werden im übertragenen Sinn mit der Digitalisierung geliefert. Hyper-Skalierung ist angesagt. Wer allerdings die Rahmenparameter noch nicht installiert hat, muss jetzt ganz schnell handeln. Ohne Investment läuft da gar nichts mehr. Der Sturm wird dann auch den Rest gnadenlos zerfetzen.

Eine Lösung – Kunden sind #1

Interne Optimiererei bringt jetzt nicht wirklich viel, wenn keine Kunden mehr da sind. Also ist der Fokus auf die Kunden zu richten und alles zu tun, damit diese bewirtschaftet werden können. Digitale Zugangskanäle, Commerce-Lösungen und Mobilisierung im wahrsten Sinne des Wortes sind die Antworten, die im Crash-Modus die Zukunft absichern können. Marktbearbeitung Digital und zwar sofort!

Offen gesprochen: Hier ist die Lösung – (ja das ist Werbung): Mit über 350 Mitarbeitern setzen wir schon seit über 20 Jahren die richtigen Segel für unsere Kunden und liefern erfolgreiche Digitalisierungsprojekte an der Schnittstelle Marktbearbeitung. Materialwechsel ist angesagt – Jetzt sofort, denn der Sturm bläst noch einige Zeit. Windsurfer freuen sich über mehr Wind, wenn das Material stimmt. Also, Materialwechsel! Digitalisierung JETZT! Sehen Sie hier, wie.

So geht’s HOME OFFICE

Liebe MitbürgerInnen,

das virtuelle Arbeiten gewinnt in Zeiten der Globalisierung, Work-Life-Balance, aber auch aktueller Themen wie Covid-19 zunehmend an Relevanz. Internationale Teams kommunizieren via Chat und virtuellen Meetings, MitarbeiterInnen arbeiten vom Home Office aus, um flexibler auf Lebensbedürfnisse zu reagieren. Derzeit, sind außerdem viele Eltern auf Home Office-Optionen angewiesen, da Schulen und Kindergärten im Rahmen der Covid-19-Krise geschlossen werden. Provide-20 ist unsere Antwort auf Covid-19 und auf den generellen Need, Arbeiten flexibler zu gestalten.

Als Beratungsunternehmen, das bei der Digitalisierung von Kundenreisen und Prozessen unterstützt, wollen wir mit dieser Informationsseite dabei helfen, an Ihrer Seite zu stehen. Wir wollen kritische Services, Know-how und Best Practices zur Verfügung stellen, um sicherzugehen, dass die virtuelle (Projekt-) Arbeit effizient, flexibel und vor allem persönlich bleibt, um so auch das Vertrauen von MitarbeiterInnen und KundInnen zu stärken.

Mit freundlichen Grüßen

Ihr David D. Laux

Weitere Informationen, konkrete Fragen, Antworten und Hilfestellungen hier

Redaktioneller Hinweis: Diesen Beitrag habe ich 1:1 vom Vorstandsvorsitzenden der ec4u expert consulting ag übernommen.

Fine-grained or coarse-grained APIs

Bildergebnis für "API" symbol

As a great fan of API-led integration technology, I want to highlight some ideas and approaches that need to be considered before starting with the design for a API network. Actually, I am working with MuleSoft and some of the technical terms refer to this integration platform. Please bear with me but I believe it is the best solution, but I am convinced that the basic idea of this article applies to other API-led integration solutions as well.

The one or the other may remember discussions from the “Platform Architect” course. We discussed in and out the benefits and pitfalls of the fine grained and coarse-grained approach. After some months working with MuleSoft my understanding of the differences and reasons for the one or the other is more transparent as it was before.

Do you believe that API design is important? I hope you do. If not, you may run into serious problems in later stages of your integration project. The simple difference between “fine-grained” and “coarse-grained” is – please allow me a first and simple approach to it – the number of APIs based on the same number of system integrations and non-functional requirements.

In other articles, the concept was introduced as the “right-grained” APIs. This implies, that there is “one” correct approach. I doubt, that this is the case. I also heard about “right-grained”. Even within one network, it could be beneficial to balance between these two and slightly change the approach depending on the requirements. Does it make sense to mix both approaches within one network? I think not. There are many reasons, which will be outlined in the next chapters. Besides, I have not seen a working network where the team used “vanilla” fine-grained and coarse-grained together and was successful in the end.

Let’s look at some formal aspects of the two approaches:

Maintainance

At first glance, coarse-grained APIs seem easier to maintain because there are not so many APIs. If you already have a relevant number of APIs and try to fight your way through the jungle, you may know what I am talking about.

Error handling

Are you using APIkit implementations? Then you may use error-handling on the level of the Router Flow. Let’s talk about a practical example. You have either only ONE SAP System API or you have created 10-30 based on the required entities or business processes. More APIs give you more flexibility in defining alerts or error flows. However, they may also lead to unexpected complexity through redundancy.

Communication

If you use the network for communication and reporting to other lines of business, then the fine-grained network brings more benefits.

The description of an API is clearer and leads towards the real business process, if there are more APIs instead of just one “Order Process API”.

Elegant development

I am not sure, whether elegant development is a KPI for your team – probably not. However, from an API developer perspective, a fine-grained approach makes the most sense, because it allows the developer to structure the flows and therefore the implementation of the API more effective and transparent. The flip-side of the coin is the possible duplication of code/components. In order to avoid this, some experience is required, not only from the developer but also from the CoE (if there is one) or the project management.

Licensing

You always need more CloudHub workers if you have more APIs, even when they are “smaller” from a functional perspective. This is a potential downside in terms license-costs. License costs are measured in vCores as you probably know. Each CloudHub worker need at least 0,1 vCore to be created.

Readability

I think it is fair to say, that smaller APIs can be easier understood and read. The more assets you have, the better you control the network from a functional perspective. Does that contradict my previous statements, that that as more API’s you have that this is harder to maintain? Not necessarily, it is just the flip side of the coin. The decision of the Mule architect is simply what counts more in the specific case. Either you want to have atomic functions which are easy to understand, or you like less API’s which are better to maintain from a technical perspective.

You have to make sure, that everybody understands the meaning and interactions between the APIs.

Performance

Performance could be the most important non-functional requirement for a project that implements an API network. The number of APIs influences the performance in several ways. The most obvious reason is latency. The more APIs, the more transformations and probably more HTTP requests in and out which creates a higher latency. If this is critical for you, this leads to fine-tuning API parameters and requires caching or intelligent ways to parallelize the integration flow.

Believe me or not, in the end, the reliability and acceptance of your integration network will depend more on other factors. However, the way towards this holy grail can be dramatically influenced by the decision how you design your API network.

API FOREVER!