A small note in advance: The event in this blog post is a long time in the past. The pictures show a reality that we unfortunately cannot live in at the moment, as we are imposing and living clear contact restrictions in accordance with the current pandemic. And now on to the actual topic:
“We love APIs.” — That is one of our guiding principles at pentacor. For us, this means two things in particular:
- We do our job with passion and fun.
- We want every Pentacornese to understand and be able to provide information about APIs and API management.
It may seem strange for an IT consulting company that specializes in cloud applications to specifically approach its own core business at a special event. After all, APIs are a basic requirement of cloud applications and an elementary part of work. That's right, I completely agree. But: When we say “every pentacornese...”, we really mean every pentacornese in our colorful pile.
Target group
First and foremost, this target group includes our dear back office colleagues, who prefer to stay far away from all this technical stuff. With our hourly statements, breakfast and beverage supply, organization of trips and events, orders, marketing, assistance in preparing role-playing games and all the countless other things that make our work and life enjoyable, they have more than enough to do. They're always with us when we travel around the API world — and before we hang them out, we'd rather pick them up and join us.
On board are also the younger colleagues who may have just graduated from university or are even still studying and therefore have many new ideas in their luggage on the one hand, and on the other hand have had little or no contact with many topics that inspire and move us. They too should be made fit so that they can take over the wheel sooner or later.
The first step is to implement APIs. If you put your personal focus on development, you come into intensive contact with many components of API management, but sometimes you are not so aware of them and may not recognize the big picture and its connections.
Even those who speak API fluently, are at home in API management and do almost nothing else all day will still reach points that are not entirely clear. Many roads lead to the destination — they have to be selected anew on every trip. A change of perspective is good for that!
One thing is very clear: APIs, API management... It's a vast field! And all pentacorneses start with different requirements. So how can we work together on a [common] image and involve everyone equally in the discussion? A metaphor is needed! We need to get API management out of its meaning and transfer it to another, we need an image and have to approach the whole thing in a playful way.
We're playing. With wheels. We're playing a role-playing game. We're playing API!
Role-playing in practice — about preparation and implementation
We need a scenario, we need a script and a plot, roles, data and functions. And then it should also be very familiar to all of us...
However, we didn't have to search for long — a topic that connects us all and affects us in different ways was quickly found: time recording, time booking, performance records. We record our working time and book hours for projects and internal tasks, this must be ready by the end of the month, customers are interested in their project budget, performance records and invoices need to be prepared. It never really runs that smoothly, something always goes wrong, someone always books incorrectly, transmits their hours too late or only when asked. Everything is almost the same as in real API life — ideal conditions to replay it!
The context is defined. What kind of API do we need now? We need data, functionality, and someone who is interested in it. Booked hours are our data, stored in the time recording tool as a “database” or “backend system”, in front of which we place our API “Anke”. Let's go!
Over the course of several weeks, we meet again and again to discuss and prepare scenarios for the role-playing game. We quickly moved away from the original plan to transfer Anke's work in the offline world to the API world. Help, was that complicated, even without diving into the depths of API management. We won't understand accounting anytime soon, let's focus on our familiar world of APIs with a very simple use case: “I would like to have the hours for project X in month Y please. Thank you so much!”
What is supposed to go wrong there?
Oh, so much!
Timesheets are filled out incorrectly, invoices for other projects are queried, or someone comes back again and again who doesn't really know what they actually want. If everything goes well, Anke writes an hourly statement and says “200 OK”, but more and more often she also has to say “401, I don't know you” and “403, you can't do that.” It is only a matter of time before it also says “500, my coffee is gone.”
Gradually, a doorman (gateway), security (authorization server), identity provider, bouncer brain (API management backend), an evil bot and hacker (representing all unauthorized access) and others (consumer portal, reporting, client apps, end user) enter the stage. In the beginning (almost) everyone watched the hustle and bustle from the upper floor, later everyone is in the middle of it instead of just there. The instant camera whirrs when passes and permits are issued, suction claws (keys) are exchanged and API specifications are copied, distributed and adjusted again and again. In all the hustle and bustle, Chrizzy, our General Care Taker (Monitoring), hops around and asks how it works (“Are you okay? ... Ah!” — Alarming is yet to come).
What a mess!
For three hours, we basically play the same processes over and over again, each time with minor additions and modifications. There are more than a dozen scenarios on the agenda, and heads and backlog are full of further ideas.
When preparing and distributing roles, we tried to assign each character a suitable role that he or she could identify with. Even then, we imagined how he or she could fill and play the role. What fun we had with that alone! (We would like to take this opportunity to sincerely apologize for the laughter from the conference room and any inconvenience this may have caused! Fun at work — that won't happen again!)
Then seeing that it is implemented and carried out exactly as we had imagined before, without making any guidelines to that effect, is the biggest reward for all the preparation effort! But was it worth it in other respects?
Conclusion and feedback
Definitely! Even in the run-up to the performance date, everyone was very excited and excited about it later. One or the other surprise was also included. It was certainly an instructive morning of a different kind! But what did it do?
Basic tenor: understandable, logical, good, well prepared and it was fun.
Both native API speakers and beginners took away a lot of new things from the role-playing game and were able to deepen their understanding of API management and, above all, put it to the test in a playful way with lots of humor. Even those who are familiar with the topic were clearly shown what it takes to direct a request to the right service, and what else happens on the side and at the same time — an aspect that is easy to lose sight of.
The focus was on trying out and understanding connections together, reducing fears of contact, gaining an overview, and we have probably achieved this goal.
In other words (original sound): “I was able to explain to my mom what we're doing. And I think she understood it too.”
Role-playing as a method
Without it necessarily being the focus, we also tried out a method for workshops and discussions for ourselves on the side. We have discovered for ourselves that illustrating and abstracting complex topics is incredibly important and can work great in the form of a role-playing game and is also a real team event. Taking on a role creates a change of perspective that brings a breath of fresh air to the thematic exchange and interacting with others in a game world is tremendous fun.
Will we meet again for a role-playing game? Definitely: “That was absolutely awesome! I would definitely do it again!” However, a role-playing game regularly and on a large scale requires a lot of effort and is therefore not ideal in special contexts and in smaller groups. With focus, we see it as a great method!
Of course, the target group must be open to exploring a topic in this way. A large and complex scenario (such as APIs) can quickly become overwhelming and cause participants to lose track of things, especially if they themselves play a role and actively participate in what is happening. Anyone who can watch and observe for a long time has a clear advantage here.
However, the feedback showed us that all participants, regardless of their individual starting points, were able to gain at least one basic understanding. The first step towards further discoveries has now been taken.
What happened next
Time and again, we took breaks to technically classify what was seen and played. The details quickly raised questions and a need for clarification, which we wanted to address in a further, more technically focused round.
The original plan (actually) was to go one step further and in more technical detail on a second day after a brief summary and classification. Various OAuth flows could have been played — or constellations from our projects. That did not happen. Inspired by the impressions of the role-playing game, the summary moved seamlessly into a lively discussion on the details of API management. What does it all include? What roles and functionalities are there? A whole lot, everyone was able to experience that for themselves. And where does something actually happen? Is that always the case, does it always have to be this way? Or are there also situations and setups in which there is a specific deviation from this?
We quickly took a deep dive again — and realized that there was so much more to discover. APIs and API management... That's a very broad field!
