H. Huetter, B. Peeters and D. Roeper - Managing Complexity in a CIAM Migration Project - A Case Study of the ‘Steinberg ID’ Project

Welcome to our talk. The last one, as Martin already mentioned before, we're getting close for the drinks. So we will give an insight into our story. And this is an to extend an existing infrastructure with the customer I am. And specifically we wanna focus on the complexity of such a project. Yeah. My name is Ben Peters and I'm the head of services at Stein media technologies. So I'm heading a team responsible for yeah. Development and operation of our mainly cloud based services for our end customers.
Hello evening, I'm HAI Hooter and I'm representing service layers. I guess you heard already a lot today. So I will make it short here. And we were the implementation partner in the Steinberg project. That's why I'm standing here.
Good evening. My name is Daniel Ropa. I'm the director of digital at Steinberg. I'm leading the team, which is basically responsible for doing this cm migration project we're talking about today. So who are we? If you happen to make music, you probably know, or come across one of our products, for example, Cubase wave flip. Do, if you listen to music, chances are as high that the song you're currently hearing, what's made using one of our products. So that's what we basically do. Yeah. Some facts to clarify this. As many companies these days, we have very aged online infrastructure, which is in fact, tying us down. So it's barely maintainable. It's very hard to update to current versions, everyone using it is forced into tedious workflows. So we think that we can't reach the next evolutionary level with what we have. So we are forced to update everything at the same time, which puts a lot of big strain on our whole organization. That's why we conceptualize the CIM project. For example, businesswise we used to sell our products in the past very much. We are local brick and mortar. And for some years now we observe that they are replaced by very often big online retailers, only few of them. So that's changing for us at the same time, we realize that selling our products via own online shop becomes increasingly important and takes or generat generates much more business than in the past.
So that's positive. We think another thing worth mentioning is that big ones like Google, apple, Amazon, Microsoft, Facebook are shaping very much expectations of our customers when it comes to service design and quality. So we think that it's safe to say that there is an implicit competition between us as a very small German company and those big international enterprises, which is quite a challenge. Fortunately, there are a couple of things we can build on this is for example, a big chunk of direct business. We have established, it's also quite solid customer base. We can build on. And there is a quite lively developer platform around our products. Con the aim of this cm project we are currently doing is to establish a Steinberg ID as a basis. We also want to leverage data, cultivate an ecosystem around our product and further strengthen our direct business in order to, and also put a counterweight to the size of the big online retailers we are dealing with. So how did we actually start then?
Yeah. How did we start? Okay. Maybe everybody knows the situation with, let's say unclear or at least distributed yeah. Accountabilities or responsibilities. So the same for us, let's say some roles or guys in our team now were assigned to the sales department, other to the marketing department, there was a third department involved and the classic it as well. So the first thing that we did is we unified all these people into a new department, which we call the digital unit. And here we are responsible for the strategy or the touchpoint for the development and this, without any dependency on any other department, what is really good. So we unified all our internal expertise. That was, was really good choice that we did, but it was clear that we need additional skills for this project. And at that moment, HaCo came into play.
Yeah. Well, so you already heard about the very luxurious position. I would say that Steinberg is in and luxurious with all the skills under one roof on both ways with the skills of course, but also with the ability to decide on their own. It can make sense to bring in an implementation partner for all sorts of reasons, for speech, for the workforce in times you need it, but also to manage the complexity, the technical complexity that comes with integrating such a yeah, big product that you maybe ball a license for on the define out where the boundaries of your products are, what is not of the box functionality and where you maybe have to extend it. And those complexities are in many cases, I'm doing this for many years now are hidden. And I want to show you this by an example of the registration process in this Steinberg idea project, when we first met and yeah, made a rough sketch about the requirements, what we knew is, okay, we have to register our customer.
We have to collect his email, address, his password. We have to collect his country. Of course he has to sign our terms and conditions. And that's basically it. Ah, and of course there are some usage in the legacy system that we also have to migrate. So this is the first sketch of the first architecture, but then you have a deeper look and discuss together what the user experience should look like. And the first thing we found out, okay, we don't think it's a good idea to well, have the register process and the identity management product. That's a good idea. But the problem is if the user registers there in this product and then later has to fill in this password only a couple of minutes later. That's not a great idea, especially if you have very important user journeys in mind where for example, a cyber customer wants to download the very new Cubase yeah.
Release as a trial. Yeah. And that can gets interrupted. So the first requirement that gets into place here is to very have a seamless experience for the whole process. So what we first did is, okay, we wrote a small plugin, still use the functionality in the IBM product, but had it as a part of the sign in process. So after registration, the users just locked in, but then you have a closer look. So you of course have to validate the email address of the user. We did that with the one time password so that he doesn't have to leave his browser tab and stays in. But then in Steinberg, there's a marketing tool. Every email has to be sent via this marketing tool. So you can't use the SMTP protocol. That's a standard functional that you have, but you have to call a small rest service to then this onetime password to use Unified's email templates and everything that comes with that.
And let's have a next look at the country. Yeah. You simply collect the country, right. But then you have there also a closer look and find out the country's not the country, the country's in fact, the market that Steinberg is operating in and in all those markets first, not in every, not every country is allowed for RGA reasons. And second, the country has impact on the user object itself because for some users, in some countries, they are distributors. They are responsible to support those users in those country, for example, in their native language. So even another service first to gig location service to collect the country. And pre-select it cause it's very tedious to select your country in a 300 plus top down list. And then of course match that to the worldview of Steinberg. So a couple of lines of code more, right? But that's not the end of the story that comes more.
I told you about these few users in the legacy system, right? If you look at them, you find out there are passport ES four kinds of passport hashes. One of them is proprietary. So you introduce just another service to do the password migration of the users. And then you collect a policy, you have a password policy that you of course configure, but then I say it and say it again. The seamless approach we used here, we didn't want to force the user. If it's kind of in a hurry to just change his password, we say to him, it's maybe an unsecured password you are having here. He can change it now or maybe later. So we introduced a kind of weak policy enforcement here down. And then in the end we wanted to collect at sometimes even more data about the user than the, that was clear in the beginning.
So what we have down here, the pro enhancement. So in his first login, for example, we ask user, do you like our nice newsletter? And maybe later ask him, well, do you want to share your data with the distributor to get premium support and have some other functionality? So if you are second and think of what this, yeah. Small requirements here took us. We're standing here now half later and actually, oh yeah. I forgot to mention, of course you have to have in mind that the services are maybe not there. So you have to mitigate all those risks to fulfill your SLAs. You want to provide, and this is actually the numbers. So 5,000 lines of code to just provide this small registration process, which in the first place didn't sound too hard.
And I won't go into details much here. As we heard a lot about DevOps today and dev sagos also, but I want to stress one single point. If you are starting a methodology or bringing that up in your company, like for example, devs ops approach, which Steinberg decided for, and that was also the fit risk service layers, where we build the CI CD platform to doing a DevOps ops approach, an IM project, not only can just put your Devon ops team together, give them shared responsibility over everything, and then help you magically get your faster time to market and your better quality collaboration and everything. You have to focus on the changes that are necessary to realize those benefits. This is very, very important. And you only have to have a focus and let things happen, but really foster those changes inside the team. So to change the mindset of all the people involved to change the tools that are used, that are necessary for the huge automation you will need. And of course you need a new skill set to realize all of that. But, well, now we have the team together. We have the technical access together. So everything else is a piece of cake, right?
Yeah. It's a piece of cake. Well, not really. Okay. We introduced the two teams that we mentioned, so our Seck team and the service layer team, but in fact there were many more people or teams involved. So we had a current integrator, a current hoster. We have expertss from Ford truck designer, data Analyst, and many, many stakeholders. So in fact, they all share one thing in common. They are all different. They have different background, different skills, different methodically. So it's very different. And so, although we choose the agile, the everything curing agile project management, okay. You can imagine that this setup creates many
Challenges. Yeah. We could probably go on for the next two hours going into all the details and implications we learned of, and now seeing this kind of project set up, but we decided to focus on one particular aspect. And that is communication from what we've said so far, you know, that there was certain teams developing a lot of services. They were tools they were using and they had specific cultures. So to be more precise, let's say our internal team developed these services, service layers, develop those freelancer contributed another one and a partner, another two services. They communicated via email and Microsoft teams that did some, or did the documentation and confluence created tickets in JIRA. And for example, our internal team had a very onsite mentality, meaning they're used to working with people who are all around them all the time. So whenever there's the question, there's the next guy to ask service layers on the other hand has an offsite way of working. So they're used to using tools to communicate. And so there's that. So in the course of the project,
This doesn't work. No, unfortunately, yeah, there we go. In the course of the project, we came across very strange phenomenon, Chinese whispers. You might recall this game from your childhood days. One child thinks up a funny message, whispers it into the ear of the next child, that child whispers what it under or what they understood into the next child's ear and so forth. And in the end, there's a strangely distorted message still funny. So everyone's laughing and having a great time and our context, this was rather giving us a headache because what we found out is that on systems level, even though everyone was developing their service, according to specification, it didn't add up to the whole we had in mind. So it sort of covered the whole use case, but there were still lots of things missing or not properly working on process level.
We found out that it was really hard to trace bug through all the services and pin down where exactly what happened causing the, the bug and on communication level. We found out that the teams were sort of caring very much for what they have done, what they had developed, but information got lost on the way on some occasions got distorted. So it was this kind of Chinese whisper situation where something's coming in, but not coming out as originally intended. So we were looking at this situation and found out that a important ingredient was missing and that is trust. And today we have heard about trust in several kinds and varieties, also no trust, but in our case, trust means establishing a culture of trust, where everyone is building up a positive attitude towards the whole project, towards what everyone is contributing to the project and starts opening up to others and share information freely and starts caring for the whole as such. This is something we think is very easily overlooked, but if you miss this opportunity to work on trust within these multi team project set up, you know, you end up with Chinese whispers and this is not good.
Okay, here, we're getting close to the end of our session. And as usual we wanna share our learnings. Okay. So the first, although maybe the most important one is just that what Daniel mentioned is that we think that working together requires a base of trust, that it is really efficient and it's its crucial factor for any kind of a bigger project. And kind of, it may, at the end of the day, mean it's a, it's a question about victory or defeat. So the point is this trust does not simply happen. No requires really your full attention. And it's an ongoing task.
Yeah. Also you should be working on avoiding this Chinese whisper situation. So in this project setup, we are having where a set of several teams is developing a microservice or yeah. Building a microservice architecture to complete the use case. It's very likely that these issues happen. We were talking about. So our learning is you have to actively try to avoid the situation. Well,
And third suggestion, maybe it's up to that. We came up with the idea to introduce a new kind of role in such projects. And this is kind of similar back then when big companies with many departments found out, well, not only departments are important, but also processes. So we should have process owners, right? And that's kind of similar when you have a project where you have many different product owners that are doing their thing, he should have also people that are caring for the whole user journey. So maybe have user journey owners or in this case, we called it use case owners that take care, the message gets through to all the systems and make sure that are all fitting together. Yeah. That was it from us. We are very happy to take any questions if you have one, but we are also available today in the evening and tomorrow the whole day. So feel free to get to us anytime.
Okay. Thank you very much.