That's our building in Anrp. Just thought I'd throw it out there. Who am I? I'm Tom. I've been working for the company for nine years and a half now. Almost a media company. The biggest media company of the region. Belgium and Netherlands. A little bit of Denmark. Always a special case though. Denmark? I'm 37. I'm married. I've got two kids, one and three. So I'm in a permanent state of zombie. What did I, oh yeah. My role, I'm an IT area manager, which used to be called a delivery manager, which is kind of more, probably says more what it is. So what I am, I'm people responsible for a couple of teams. One of them is entity team, which is the four or five man team continuously working my entity in our identity platform. That's all they do. And I have also myself been working as a developer for a couple years on this, on these platforms as a product owner on these platforms.
And now for three years as a, in his junior management position. And I thought that it would be, oh yeah, that's more about the company. We're about 6,000, a little less now. I think three countries, like I said, Belgium, Netherlands, in Denmark, we have an international portfolio. Many brands, we do just about everything. Media, we do newspapers, podcast magazines, online services, streaming radio, linear TV still exists. We reach about 10 million readers every day. 3.5 million paying subscribers, 2 million streamers. I don't have the timeline. I don't know when, every day, every week. I tried to figure it out, but I couldn't get the corporate to give it to me. We have offices in Belgium, in net, in Denmark. Our revenue is 1.8 billion and our profit is 200 million. Gives you an idea of what DPG Media is. This is my goal for today. What I wanna do is I wanna tell you our story, which I think is having spoken to other media companies in our region, a little bit unique in my hopes and, and I hope to inspire and inform you.
Maybe some of you are trying to make such a decision or thinking about making a similar decision like the one we made. I hope this makes a decision easier somehow. I'm gonna give you a timeline. I'm gonna start the big timeline. So this is basically everything. My entire story is on this slide in very little detail, and I'm gonna dive into it obviously. But in 2016, we started as most, at the time, at least in, in, in our space as most media companies did. We bought a customer identity management package. One big one just implemented it, or rather had our teams implemented because my identity team is supportive. We have internal customers. Our internal customers are the people who build apps, websites, streaming services, that kind of thing. In 2018, we quite very quickly realized that we had a sort of an integration problem. Proprietary PIs really didn't work for us that well, they're very opaque for good reason because the people who sell you these things don't really want you to know how the, how this stuff works. But it also makes us, made it very hard for us to understand what is going on. Single sign-on is a good example. We implemented single sign-on based on a big platform, didn't work very well and very well not working very well for us as 10, 20, 10 or 20 complaints per day. If these are 20 paying customers per day, that that's absolutely unacceptable for us. So we ran into these kind of problems pretty quickly.
We thought we would solve them by solving the integration problem. And then we adopted ID OpenNet Connect, which was a great move. We thought it was the industry standard. Well, it is. What it did solve, we learned a couple years later is it did solve the integration problem. It made the integration between my team and the other teams easier, but it didn't solve the problems we had with the proprietary APIs. So in the end, we decided we're gonna build it ourselves, which is a pretty bold decision. We're very fairly small team, lucky enough to have an identity team. I mean many of our competitors in our space don't even have them, don't even luxury to build it or don't want to build an identity team. But that's what we decided. And ultimately what we, what we started as as a technical journey, you know, for us it was a technical problem. Integration wasn't going well. Our internal customers weren't happy, our external customers weren't happy either.
Eventually we realized that having done this, it freed us from the technical integration problem, which allowed us to focus on the actual problems, which is strategic problems helping our business. I, in the previous stock, I don't know if any of you were there, I I mentioned identity as a commodity. I, I still feel like many people think of identity as a commodity. They'll buy a a platform out of the box and think that solves all their problems. It doesn't. At least it didn't for us because for us it became a strategic pillar. Identity, the way users log in is super important to us.
What we set out to do, the overarching goal was this. We wanted to build a scalable, cost efficient customer identity and access management platform that is agile enough to support a rapidly changing business. Because that's what we're in, we're in media. We, we made newspapers. Many of you know, newspapers are not as popular as they used to be a hundred years ago. So that business is declining. We need to switch, we need to digitize the all sorts of digital solutions. We want those to grow rapidly, way more rapidly than the decline in, in the, in the, in the old business. Sorry. That means that our business is on tremendous pressure. We have to go so quickly change things all the time because nobody knows where we're going. You have to experiment and test your way forward. So that's what we set out to do. Why?
Well, these four things I think are the most important things. Why we did that, why we wanted to do that strategic importance. Like I mentioned before, it did not used to be back in 20 16, 20 17, but over time our business realized, you know, if you, if you want our digital strategy to work, you want all of these steps in a digital experience to be as frictionless as you possible to be as easy as possible. To be as safe, you know, security, I'm guessing all of you or most of you. Security is a big topic or an increasingly big topic the last couple of years.
So it's strategically important. Identity is strategically important. The big part of our strategy, the company strategy is, is dependent on a good time strategy. Agility ties into the same point, kind of our business requirements change rapidly. I, I'm a bit allergic to requirements because requirements always tries to sort of imp implies that people know what you need to get where you're going. That's not really true. We don't really know where we want to be in five years. But anyway, this gets a message across. I think this full digital transformation requires us to constantly adapt constantly. Not next quarter, tomorrow, next print sprint is two weeks the way we do it. Anyway, industry standard was important. It was important for us to use an industry standard because what we make is implemented across hundreds of apps sites across six to 12 teams. So we can't sort of help all these teams with as much detail as we would like. So an industry standard helped open a connect, you can just Google your problem, you can Google what open a connect is mobile teams and under IMS could very quickly in, in less than a day, set up an integration with us using libraries that are available for iOS and Android. They work fine. They would eventually not go in production using that, but it could build something that worked that way. So open Id connect was big for us. And lastly, touched upon it briefly before, but the, the big platforms just didn't work for us.
It always felt like they're in the driver's seat and not us. We, we wanna, we wanna do something and we want drive our business forward. We wanna help, we want to iterate, we wanna change test, experiment. And they were just never, it was always hard. We had to create tickets. Tickets took days to tweaks. Users couldn't log in and we had to tell 'em, well, we'll ask, we couldn't do anything. So big, big CM really didn't work for us. We still use it and I'll tell you in a minute why or where we still use it. But as, as as the singular platform, it just wasn't working.
So this is what we decided to do and we actually did. We were gonna build our own sound platform, but, and importantly we were going to u use partners for the hard stuff. We're not gonna build all of it cuz that would take us too long. We had a team of five men. Five men, actually men. Unfortunately, if we had to build our own open eight connect servers or that would've taken six months to a year easy. So we thought what if, what if, what if there are partners out there who do that? Only that part, not not a big platform and not all the features you wanna sell us with, but just that part that we can plug in our own platform, we'll build the rest around it and then we're good. And to our delight, it does exist. So it is possible. What we wanted to do is we wanted to maximize control for two things, important things.
User experience, obviously business strategy. What the business typically thinks about is how do, how does, how do user perceive login? How can we make it easier for users to log in? That's what I mean we user experience and platform quality, not entirely and important. I'm gonna take, take a little bit of time to explain what I mean with platform quality agility, which is not on this slide to my surprise, but ultimately results in the strategic upside. You can only keep being agile if you control the quality of your platform. I hope I'm preaching to the quiet here. But you, you need to keep your code under control. You need to keep, make sure you have a build pipeline that executes quickly. You want automate tests every time you deploy, which is multiple times per day. You wanna make sure that it works or at least the most important things still work.
So that's what I mean with platform quality deleting code. We regularly delete stuff from the platform to make sure that it doesn't grow out of control. Which is one of the features that I sometimes, one of the selling points that I sometimes hear the big platforms use is, yeah, but if you build it yourself, you're gonna end up with a platform that's unmanageable true. If you don't manage it, if you manage it, it's fine. So that's what I mean at platform quality. But we don't wanna do, oh, the icons missing actually from the slides anyway. What we don't wanna do is the hard stuff like Open ID connect or it's quite complicated specs, not easy to understand initially, not easy to build, not easy to update. They change all the time. Which I was very surprised about when I first sort of started learning about Open Connect.
And so what we decided on, we're gonna build a glue between these puzzle pieces. We're gonna connect all these things and make sure they work and we're have control over pretty much near full control over the whole platform. But the hard stuff, we're gonna buy something. We're gonna, we're gonna have someone else, an expert do that. And ultimately, again, the strategic upside for us is differentiated from the competition. None of our competitors in our market do this. And as a result, we have probably the best login flow of our competition or, or in our, in our particular media, very language focused. So within the, within the Dutch language space, we probably have the best long info and if it isn't, we can change it tomorrow. As opposed to if you use a big platform, you have to get them to help you, which they might not be inclined to do because your specific future might only work for you and they can't sell that to anyone else. So they're, they're not, they're not inclined to have that to their platform.
Examples of strategic upside, we're now building app to app as single sign on. So if you log into iOS and you use a different brand app, we're gonna log in automatically. It's possible we're gonna build it, we're gonna add it. This team also builds iOS Andra case by, by the way, we've built our single sign on solution ourselves, which was easier than what what we had expected. Still pretty tricky. But just because the browsers don't want you to, we talked about, we talked about Apple, about this and when they launched the whole intelligent tracking prevention thing and they said, we know we're, we're screwing with you guys, but unfortunately all the other guys are are abusing the third party cookies, so we're gonna kill it. But we know, we know we're screwing and we don't have an alternative. So they knew what they were doing.
Anyway, so those were two examples of why this gave us strategic or specific examples of where we can make the difference we think compared to the competition. This is what it kind of look very high level. If, if, if you guys had expected a sort of in-depth technical diagram, I'm sorry, I'm gonna give you, I, I can unex explain more about this. There's a part missing as well. By the way, I think I sent an update which didn't make it to production. There's a, there's a part missing which I'm gonna explain. But anyway, the, the, the dash line, that's what we do together with this thing. But I've, I've separated them because these are kind of a non identity specific services. These are also, might also be reusable. But anyway, that's what we built. There's a couple of examples of the screens there. We're in full control.
This is what we've built and changed and iterated for the last four or five years or three or four years. Different brands, different screens, all the same platform. So we service 14 million accounts. This platform, the glue is a lot of what's in that identity platform. So a lot of the code in that platform is glue flows, screens to screens, device flow because we are active on TV devices. So device flow it supports as well. It should have maybe added a screenshot there. What we've also then added is auxiliary services, things like challenges. We have a challenge api which could have been, could be used in other context. We use it. This is a particular screen set or screenshot. We do allow users to log in without a password once or currently if they want. This requires a challenge. API profile management, APIs, other services in the company might want to update an account for some reason or retrie an account for some reason.
So that's the kind of services and there's a couple more. And then more importantly the backend as a service. This is the stuff that we buy. So this is what does open eConnect and or for us, we never wrote a single letter of code concerning to open eConnect to directly. They do that for us and we just plug it in and that was very seamless. Works very well. What's missing on top is the account database and that's the part of the old big Siam platform that we still use. So we still have not a solution for the account database. So actually where our accounts are stored safely. Securely, yeah. So that's, there's a line missing there on top. So that's what it looks like.
Why do we believe this is a way to go? Well we think you get best of but worlds if you do this, you do have to have a development team. I'll get to the challenges that next, next slide. What I believe are the challenges to do this. Why is it, why is it hard? But you, you get best support worlds. You get to offload hard stuff to other people. You don't have to worry about it. You don't have to worry about the spec being updated. The partner that we use is, some of them contribute to the spec. So they're always up to date within days, weeks. If there is a new feature from the spec that we want to use, it's probably already there by the time that we think of it.
But we do remain in full control. If we want to change something tomorrow we can do so if you want to overhaul the screens, apply a new theme across the whole company, we can do that. We can probably do that next sprint. Put it live when it's done. No problem. Last one, there's middle one. A bit contentious sometimes I claim that this is potentially at least comparable to or cheaper than buying a big sound platform, including the development team. Unless you get specific rates from these big companies that we're not getting, they tend to cost a lot of money for 14 million users. So I say that when we calculate the tco, you get comparable results. If you have scenario one, you build, have a development team, you build it yourself, you buy the service for the hard part, you get comparable TCO and then buying the whole solution, which you need a team for anyway.
At least we do. We're not gonna have six different teams contact these guys directly. That's gonna be disaster. So comparable true agility, that's by the way the cheaper, that's not including the cost of being agile. I, I have no way to put a dollar cost on what it means that I can sell my business. You wanna change this? Fine. Ask the team. The team says it takes us one day, they do it next day. They deploy it the same day. I don't know what that costs, but it's a lot for us cuz that's what we need to agility again, we can react super quickly to changes in and outta the business. If they want something, we can do it. You get, we used to have a lot of discussions with our business about feasibility. Can we or can we not do something? The discussion has completely changed since we've done this. It's about value. Is it or is it not valuable? And if we do not know if something is valuable, we can test it and we can test it because we control the platform in many other platforms. I don't think, I haven't checked the last couple of years, you can't even test these things or not at least not in the way you would insufficient detail the way you would want it to.
Obviously it's not as easy as it sounds. Two biggest constraints we've noticed or I think are the cases, one, budget constraints. We were lucky enough to start with a small development team. We started this journey with a small development team, which makes things easier. If you have to bootstrap a team to do this, I think it gets significantly harder. I mean you have to get the budget for it. You have to do this because as much as we don't specifically write much code about open a connector raw, we still have to know how it works because we do touch it. I mean we do experience it. We do offer this experience to our users and our integrators. So we do have to know how it works. But yeah, the budget constraints difficult technical maturity in our market, which would be Belgium or Netherlands. Very hard to find openly connected. No experts, at least one's willing to work for us. Cuz we, we, we wanna compete with big tech, but we don't have big tech budgets, so we can't always pay people what they would pay them big tank companies. But anyway, these, these is what, these are what I think the two biggest constraints and that was it basically. Thank you. I wanna thank you. And that's it if you wanna get in touch. No
Have any questions. Okay. Thank you. Very interesting presentation. I was just wondering how you stay on top of your security game. Do you perform pentest? Any data breaches happen with your own implementation?
Yeah, the, the, this is not as, security is not as hard as people always claim it is. I think if, if you, if you have guys who can, who can understand, or N Y D C, they'll usually be smart enough to understand most security attacks. But we do do, we do do pen testing regularly, continuously on a request. If we do big changes which might, you know, change the fundamentals of the platform, we might sort of request a specific pen test. We use bounty platforms, so we have outsiders try and try and break the platform and shift left. You have to shift security left the team, the team that does this is supported by security experts, but they have to do it, they have to know what's, what, what, what the important parts are. They have to know what cross-site scripting is and protect against that. So due diligence.
We also have a few questions online. Okay. Hopefully short. One of the questions is, does your in-house build CIM solution also hand in any consent management use cases? That should be easy to answer
Consent as in GDPR consent or, or authorization consent as in con not really. We do ask for consent in as part of a registration flow, for example. So we have do have support for email consent or, or newsletter consent, I should say commercial offering consent. But these are simply logged and sent to other teams. So this is something that another team does. So we just log it and send it q q it for the other team to manage authorization. We do use authorization, so we do use fat GW gwt tokens and do some entitlement stuff from within our platform. So I hope that answers the questions.
It did. And the other one is also interesting. As someone asked if there is any intention to share with the community, the part of your code, which may be leveraged by other companies or users.
I don't think I may even if I wanted to, I think the code that we write is, is, is part of, is own owned by the company. As far as I know, there are no intentions also because we don't, at least right now within our sphere or within our domain, we feel like there is much need or much. And anyway, we would be mostly helping our competitors. So I don't think the, I don't think the the company would be very likely to do that, but yeah. Thank you. All right. Yep. Thank you very much. Thank you Tom. Yeah.
