Like I said at the beginning, I did a talk last year here called Tilting at White Towers and it was supposed to be about trying to improve the state of our identity architecture programs, and some of the problems that I personally had run into, I'm not going to go over that whole presentation, but there were five points that I had, and one of them was that the architecture focuses too much on the future state. Architecture principles honestly have little real effect on architecture program. Architecture is usually far removed from the frontline employees.
Architecture diagrams are typically not very useful, and architecture needs to communicate more openly with stakeholders.
This is in general, this is not for, I'm sure, the intelligent people who come to the European Identity Conference, but talking with Martin after the presentation, one of which I disagree with, but Martin presented right before me, and I had to contradict one of the things, and while Martin was sitting on the stage, and I'm trying to avoid eye contact with him, but because Martin's a wonderful person, he said, we really should do a panel on this, so Martin was great and helped facilitate getting like one of the best groups of people I could imagine pulling together.
I would like to make sure that we get, introduce everybody, Martin, if you could start with you and we'll just go down the line, real quick intro for who you are and the company I'm Martin Klippinger. I'm Matthias Bauer. For those who don't know me, I have the luck in my life to be one of the co-founders of a company called Völkerinformatik here in Berlin, and by that evolved into a position that made me development manager, product owner, kind of pretending to be a part-time PM for a product that became one identity manager today, which is in the IGA market now for quite a while as well.
Hi, I'm Sanjay Narinpally, and I'm the founder and CEO of Tubora. Prior to Tubora, I was a co-architect and one of the two principal engineers who built the Amexa solution which was bought by RSA, excited to be here and participate and be part of the humor that Touch is going to bring out in this conversation.
Hi all, Craig Ramsey, based out of Scotland, so apologies for bringing the wind, rain and cloud at lunchtime. I'm Matt Omada, senior solution architect, I've been there for around four years, prior to that I was at RSA security and prior to that doing identity on financial services organisations in the UK, so experience of doing the job, delivering and then pre-sales itself. I'm Ian Glazer, and typically it's my fault.
I'm Mike Kaiser, I do strategy and standards for SailPoint, I was a solution architect for a while for IBM, like ten years or so, and I'm also a part-time cleric, and my character name would be Shmebulog. Ian and I actually had an interview with the guys at Identity at the centre and I had promised to do an Identity professional-based D&D campaign, I've yet to do that. So the first question I want to ask everybody is why do we still struggle with this?
I don't mean struggle to get Identity programmes and things done, but I mean really the architecture piece of it, which should be defining our domain. I know Martin Cooper-Tricolle has come out with a really good model for here's how you can do the breakdown, I think you guys have 40-some different capacities in it, but we seem to struggle with the value of the architecture programme itself. Engineering usually goes through tasks, but we struggle with defining the strategy that the engineering team should be going through.
What is your, you guys are obviously more successful in these programmes, what are some of the things that you've done within your own organisations to try and make that architecture programme more successful? I'm happy to go first, more being the prospects that we speak to in terms of helping them understand the part of their Identity architecture we'd plug into and why that would be important to them.
I think as you said, a lot of it can be done in isolation and I think that's the problem often that you're focusing so much on what you know, what your expertise is, that you forget to take into consideration the other areas of architecture in the organisation that it'll touch and then not just from a technical perspective, the business processes, the business risk and making sure that's aligned. So people don't understand the value, they don't understand the risks you're mitigating, so I mean if you don't have that all set up at first, as you said, it comes from the top down.
If it's understood at that level and it comes down to your engineers know the architecture they're trying to do, it's far easier. I think the example I could give is we were speaking to an organisation that was responsible for the road network and you were trying to bring that back to why identity and controlling access was important and you said to them, so what does a bad day look like for you?
And I was, well, you know, the road networks go offline, people can't access tunnels and bridges. Okay, what systems have controlled access to that? These ones, these ones, these ones. And do you know everybody that's got access to that and you're confident it's correct? No.
So if you can talk that, that level that's understood and then build it into the architecture and spread it out, I think that's, you make it impactful for not just the people you're speaking to and deploying it, but the people, as you said, and you put it perfectly with your D&D analogies, getting that buy-in and was it your quest sanctioned at the start? So I'm not good with the terminology, but exactly that, getting that buy-in.
So a hunch on my mind, this is coming from my experience at Salesforce where there was a very formalised role of architect, role of architecture in programmes and although the artefacts that they produced were incredibly valuable, right, more than just arrows and boxes, the skill set of the architect mattered a lot in the programmes. Not from the ability to draw those boxes and arrows, but to make, to humanise what the architecture goals codified in those artefacts actually meant.
And so I, as a product owner, met with my architects every week. It was some of my closest relationships which allowed us to be incredibly successful because I could take some of the burden of socialising that mission on in my channels. And so I won't want to rush to overlook that identity architecture programme is great, the humans that participated in it are also part of that architecture and are incredibly important to the outcome. So I think it's not an IAM problem, it's an IT problem.
So and also software development, I think in software development we have solved it a bit by saying we just do it agile and don't care about architecture anymore, which is a bit of a solution, but it doesn't really solve the problem. And then we have sometimes the enterprise architecture thing which is just too big. So I think we are generally speaking IT not good in architecture, it's just something which also happens to IAM, but it's a much bigger problem.
I think coming back to the dungeon and dragons thing, in a lot of cases in the end the dungeon master fails to set up the quest correctly, and by that you have poor selection processes and nothing works together in the end. And in a lot of cases coming to the IT problem, it's still silos. We have so many things in identity and access management from privilege, I think you named almost everything here, and it's still that customers, the larger they get, the more.
It's still in silos, not talking to each other, nobody there with an overarching architecture idea, and this is what we see, or I see at least as one of the biggest challenges, that the problem starts before the project starts. And you need a ton of knowledge. I remember in the new economy phase, I was one of these new economy companies, and I think there were about 700 people at the peak, and I think two of them knew what an enterprise service bus is.
Yeah, I think largely there's no universal model as everybody knows. It kind of depends on a couple of things, starting from the characteristics of the organization. So there are the business process update cycle, and then the technology update cycle. Every organization has different measures around that, and if you don't align your program with that, you'll see a lot of impotence mismatch and frictions caused across the organization, and that would derail, even though you have a nice strategy in place, it might not fit in your organization, right?
So as IAM directors, program owners go from one org to another org, they think that they can take the same model and apply it there, it won't, because the frequency of the change needs to be aligned with you, and once you have that figured out, the other thing that comes into play is you have to pick a solution that aligns with your thinking as well. It's not that every solution will fit into your program, right?
And if you're an org which has changes that you would like to see every few weeks, you need to find a vendor that gives you those changes, or has the ability to give you those changes, right? It's not a capability issue necessarily from future set, but it aligns with your change cycle and how you adapt to it.
That's great, and I appreciate you teeing that up for me, because one of the points I wanted to make, because as I said, one of my pet peeves that I expressed last year was when I said, you know, architects spend too much time focusing on the future state, which sounds ridiculous, because normally that's where we live. We live in the future state. That's our job. Our job is to define the strategic direction. What I meant by it was we spend so much time thinking about the future state, we don't realize that the architecture process doesn't move as fast as the business does.
The business velocity is so much faster than the architecture group can keep up with it. What are some things that you've been able to do to try and make sure that, or what can we do as an architecture program, to make sure that we don't fall into the trap of living in a utopian future state, but that we're actually addressing strategically the more tactical needs of the business?
Yeah, so I think the question is, what do we define? So do we look at the details, or do we look at how we enable that speed of the business? So I think in architecture, our job is not to have to, as in other architecture areas, to have the perfect blueprint with all the power lines and the water lines, et cetera, in the house, which is to the very detail. I think in our world, probably the point is, how do we enable an architecture that is built for change?
So focusing on the aspects that enable the change, to have the right setup for how can we ensure that we don't kill ourselves with customization? How can we go for orchestrations that are bringing in the flexibility? I think we probably need to take a different perspective, and it's a different way of thinking architecture than it is, for instance, when building houses or architecting houses.
So Mike, I'm sorry, I didn't mean to interrupt you. Go ahead. Go ahead. You first. I was going to ask you, coming from SailPoint, for example, what is the methodology that the architecture team uses to produce artifacts and stuff? Is it similar to, like, an engineering program? Is it agile? Is it? Yeah.
You know, coming from IBM first and then SailPoint, I think they're very different models. Like, IBM's was very built up on a technological path that your architecture team was from engineering. They came up through engineering, which helped them in some ways, because what you want, in part, is an architect who is trusted and trustworthy and has the trust of both the business side and especially the technical side, right? Because if you produce artifacts that, when you create them and you're not listened to, that's not quite ideal, right?
I think SailPoint's architecture approach is a little bit more organic, only because when I joined, we were 300 people. And so that pathway wasn't as defined. But I think what SailPoint architecture has been good at is not just drawing out the future state and saying, here's where we're going. They do some of that. But they also are involved with the day to day. Not every minute detail, but what I would call the felt need of the immediate.
So they're meeting, they're saying, here's where we're going, but here are the steps we're taking today in these systems, in these mechanisms that are going to get us there long term. So it's a already and not yet kind of vibe. I think just to sort of add to that as well, you're right, it's the incremental value that you add along the way with that. So when you're designing these architectural programs and artifacts, they need to be scalable with that in mind. So there's a little bit of looking ahead, but don't solely focus on a very specific end goal that can't be flexible.
So it needs to be where you're trying to get to, that you'll continue to, as you said, realize that value on the way. But as you said, the velocity of the business vastly outpaces the velocity of the architecture. So you need to make sure that whatever you are putting in place will add value incrementally as you go. Keep adding that value. But then it's going to be future proofed for whatever, not whatever changes. You can't foresee everything through sight, as you said, but try and be as flexible as possible and open-ended for what challenges may come.
From our point, or from my point, I'm in the IGA space as well, so I speak mostly IGA driven, I have to admit. But we have the problem that we are sometimes, or mostly in both worlds, there is an infrastructure world which comes to the sync with target systems, stuff like that, which no business is interested in, and you have a business side where you have to integrate end users with nice UIs, with access requests, with free certification, with segregation of duties, stuff like that. So there are two parts of the story.
And I think what we did is more building an engine or a platform that allows extensibility so we can react quickly to new requirements. And I think this is kind of the strength of our product, or where we think we're coming from is that extensibility, and easy extensibility, and not to rebuild everything from scratch or add a small silo here and a small silo there, but build it into the platform, basically. So I think one of the things also to look at here is a lot of times you're not told about the series of things that are coming your way.
People will ask for, oh, I want this kind of request, this kind of request. I think it's important to go back and say, why are you spending so much time on request systems and bells and whistles around the request flows, instead let's focus on what is it that you can do to reduce the number of requests, right? So those are things that are never told to you, but as a vendor, it's your job to go back and tell them, hey, here is some mining that you can do and reduce the velocity of requests instead of creating these fancy forms and everything else and workflows surrounding that, right?
And that's something that you should proactively bring out as well. So one of the things that I've struggled with personally, one of the things I mentioned was trying to improve communication, not just for the sake of communicating, but really open communication about what we're doing to our stakeholders. I feel like the one I have the most issues with is in trying to explain the value of certain aspects of the architecture, the domain architecture program to our senior leadership who is looking for KPIs and is looking for metrics and is looking for ROI numbers.
For those of you who have been successful in a communication program with your senior leadership, what are KPIs that you've focused on, again, what are the architecture KPIs that resonate with senior leadership? I mean, the one that, so two parts. One of it was the architects were always good about enlisting a buddy, right? Someone who could, in some regards, act as an intermediate or an alternate to talking to senior leadership. And we'd be very conscious about, oh, well, such and such leader responds better to architects, but some of the architect, not the product owner.
So there was some conscious selection of who wanted to talk about it, but specific to the metrics in the final years when I was at Salesforce, the thing that mattered almost more than anything else was cost to serve. Every conversation we had was about for these services that we want to deploy, how much is that costing us today in operations and where can we get to? Now that was for the generic executive experience, let's say, which sounds like a horrible yacht rock band. In the security domain, then it was the conversation about more tangible risk in the business that we were in.
A lot of it had to do with availability and those kinds of metrics. Not so much classic IAM metrics as you would necessarily recognize, but more programmatic ones that those senior executives were receptive to.
Regarding KPIs or KRIs, if you want to call it that way, I still believe that there is a good white paper, sorry for that, Martin, by a guy called Mike Small, who wrote such a white paper I think back in 2017 or 18 about KRIs, which I think is still really good to read and an important foundation for getting an idea because it really covers a lot of such KPIs around access management, governance, identity management, stuff like how many applications are using a central directory, are covered by MFA, so more that security side of the story, which is that tangible savings, because I doubt that there is a real net money saving by an IGA or identity management system, but that indirect saving, if they call it that way.
And I know the paper. The point I would make, maybe being a bit the avocado diaboli here, I doubt that these KPIs are architecture, KPIs or KRIs.
You can, so to speak, have it derived by saying, if you are good in the other measures, then probably your architecture can't be that bad. But I think measuring the architecture, I don't know whether we have KRIs and KPIs that really allow us to measure the quality and success of architecture directly in a way that a business leader would understand. I have to admit that is not the answer I was looking for. You should have asked another question. But that is absolutely my experience. We seem to have really good ties to our engineering teams. The engineering teams don't need KPIs or anything.
They understand the value of a partnership with architecture, but that almost seems to set up a reliance on us, like, could you go tell my leadership that I'd love for there to be some better way to explain the value of what that does to my own leadership? Sanjay, you were going to say something.
Yeah, a couple of things. One is the coverage you can get in terms of the systems, applications, and users with architecture is important, and the speed of bringing that coverage into play. That also can be represented from the architecture. Specifics around the IAM activities and the success rates and error rates and all that, those would come in only after it goes into production. But from a coverage as well as the ability to integrate these systems are things that you can largely gather through the architecture.
I would say that even if KPIs aren't technically part of architecture, you have to have some measure of how well you have sold the dream of all those little boxes you drew on the whiteboard and walked away from, right? And coverage, I think, whether it's apps or number of users using your MFA service, whatever it is, gives you some indication of how well not only has your engineering bought in, but has the business bought into the value, right?
And it's never just KPIs, because I think that's a bunch of pretty graphs that I could draw, or Justin could do After Effects and do amazing things with, but what you're selling is a story, a narrative, right? So you need a bigger narrative arc to say, this is where we are, this is where we're going, here's the data to support it, and here's the end result. And what you're doing is you're handing your constituency the narrative they can go back and tell their people, because people suck about talking about risk and telling stories, but we're all wired to respond to stories.
I totally agree that architecture can be quite an abstract concept to these people. They are intelligent people, they can understand it, but it's not their wheelhouse, it's not... Fair enough.
But, you know, as you said, it's telling the story, making them understand that the architecture that we have designed, these are the business processes that it's going to touch. In terms of how much more efficient and how much more effective it can make those processes, here are the benefits, here are the risks that are being mitigated. So whether that's reductions in calls and requests to the service desk, so you're saving an FTE, that's pounds, dollars, euro sign, whatever you want it to be, that's one very classical metric.
But then if you start looking at maybe the remediation rate and recertification, so you're reducing the number of... You're reducing the inappropriate access across the organisation, so you're reducing the impact of a potential breach. If you then look at wider, in terms of the stronger authentication, you're reducing the likelihood of the breach. And then when you start to say, what is the impact of this breach happening or this risk being exploited, if you then say that this is now 20% less likely, 20% of the impact...
You're offsetting the cost of that breach happening with the investment you're making. And that's the kind of language and the story you're telling that these people understand, as opposed to architectural diagrams and, you know, the low-level elements of it, which interest all of us, but not so much those people. And you set context for those KPIs, right? I had one customer years ago who came to me and said, Mike, look, we've got this IGA stuff in place, and we are through the roof on access requests. Look how many we've got going.
And I'm like, if your major feature that you're using is one-off, out-of-band access requests, then maybe your policy-based approach isn't quite delivering the value you think it is. So massive success, but you have to set that context, I think.
But still, at the end, we're not measuring architecture. I think, you know, as an analyst, we look at a lot of the products, and I like architectural slides. I ask vendors for architecture slides, because when you look at an architecture slide, you can frequently easily spot whether this is sort of a better or the worse side. And basically, the question which I, so to speak, have is, is this built for change, for growth, for evolution?
And I think this is, for instance, why I'm very skeptical regarding MVPs, because a lot of MVP things fall apart when you say, OK, right now, I need to scale and evolve if the architecture is not right. And this is, I think, this is the proof of the pudding, then, does what you do withstand change and evolution? This is still not something you can measure with numbers as a KRI or KPI, but I think you can easily look at it. And if you have experience, you can probably very well argue and point out what is better and what is worse. What are the things that break, that are made to break?
So simple example, you code against the database of another product, because you don't use a built-in abstraction layer of APIs. It's 100% sure this thing will break sooner or later. So you can trust this quite well, but it's nothing which I could put into a KRI. One of the things I was curious about, too, when at Mitsubishi, we actually have identity as its own architecture domain. And that was a fight, because the initial thing was to put it into a more generic security domain.
Martin, I used your diagram to show that's like, oh, OK, so security architect, you are going to handle these 42 specific identity capabilities. And then they didn't want any part of that. I was curious if in your organizations, you actually had a specific identity domain program separate from, well, not separate, but working with security and such, but somebody who was actually an architecture program built just around the identity domain. At Salesforce, we did. And it was interleaved. It was part of the overall platform team.
So Salesforce is a platform as a service, application platform as a service. And so the platform architecture set certain north stars.
In that, our architects had remit to set certain north stars that were more domain specific. Security had its own architecture, but it was more of a horizontal, if you will, right? So it was something that had set requirements and set north stars for them and was rationalized by our architects, the way we approached it. I would second that. The most successful customers were exactly acting like that, putting identity really into that platform, infrastructure, whatever you call it, and have security and business as a horizontal.
That solves a lot of problems with responsibilities, with funding for upgrades, for security patches, et cetera. And it gives you all those abilities. I wanted to give a chance for a couple of questions from the audience before I let each person get like a little 30 second kind of wrap up of their thoughts. Hi. So going back to D&D, you can't always assume that the DM is benevolent. Sometimes you are given impossible challenges, right? And I think we have all been in that position.
And I would really like to hear this panel's take on how you react to being given a direction that you either know is a bad idea or you just don't know what it actually means. This is why I only played D&D once. My party lasted for 45 seconds and we got eaten by a nursery of giant babies. Babies who were giants. I was once in a very small town in Germany and was doing a solution architecture and they had a set of requirements and there was one requirement that didn't seem to fit and was frankly seemed impossible at the time. This was 2008. And so as part of my review, I presented the solution.
I said we didn't do this requirement and here's kind of why maybe you should either delete the requirement or you should change it to match this and this is how it kind of fulfills what I think is the same use case. The response I got was that's a very American idea. Which was true. But it's kind of, it's trying to match what their goal was to the requirement. Now granted, that was a very special case because it wasn't like I was reporting into this chain. So I had a lot more freedom.
Yeah, I mean, to sort of build upon a similar theme to that, literally the project that won the IAM award last night was one of ours with Zurich Airport and they went from the journey where the previous on-premise architecture was extremely complex, highly customized and we went on a journey with them to align it with best practice, make a configuration first and we do that with, as you said, trying to align with best practice, trying to remove that complexity, trying to simplify, not simplicate, it's still a very complex problem, but simplify the way people do things.
So as you said, if they've got a very determined way to do something but you can get to the same end goal but by using best practice and standardized configuration, you're massively simplifying the architecture, enabling them to then build upon that and then enabling them to innovate faster and it's no longer this huge tech debt of customization and complexity. As a chairman, first reaction always is no. First reaction is over-engineer it. The second action is over-engineering, correct.
The third reaction is, okay, please try to explain to me what you want to achieve and we will find a way in our architecture that might reach the goal in a different way that you might expect it to resolve but it will bring you to your goal. One thing that always annoys me and always fails when you come to customers that have a homegrown system or an older on-prem system or whatever and say, but the new system must work the same way as the old did, this is always the moment in time where I say, okay, see you in 18 months when you have failed.
I think I have a bit of an analyst advantage here because I usually get asked about which way can support me in doing this or how can I do that or can you connect me with a peer who has done that and say, you know, there's no one out there, basically, so you would be the pioneer, then this discourages most of the organizations because most don't want to be the pioneer who does it first but want to be doing something which others have done successfully. So, as I said, I have a bit of the analyst advantage.
But sometimes it's maybe also good and I think this is also a role we sometimes play, so, you know, the external one is sometimes more trusted in telling that story and saying, okay, you know, nice idea, I like it, it's great and you will need to spend a lot of time thinking here and you probably can make it work with some effort but you will really be an innovator. If we tell it, sometimes we are more trust than the internals. I can feel Yves standing behind me, so. We have just under three minutes left.
I'd like each of the panelists to kind of give me your 30-second wrap-up, the one thing you would like people to take away from this, we'll start with you, Mike, and we'll go down the road and Martin will give you the last part. Don't do it in isolation, ask questions, listen really carefully, echo the language you hear back to the person you're trying to convince, and craft a narrative, tell a story, make it a bigger picture that they can buy into and identify with and then move on.
So I think I'll say a plus one on the power of the narrative, whether that narrative is technical in nature, whether that narrative is outcome in nature, it allows you to enlist support that other people can then mimic, and that builds a full mission that people can get behind. So it's really part of that narrative. Plus two.
No, in the, it's make it, I think you need to make sure your message is adaptive. So align it with risk, align it with value and make sure that whatever you're trying to do, you can communicate to different people, and I think one thing that we haven't touched on as well is that a lot of the time when you're doing an architecture, sometimes big assumptions can be made about how simple this step is, and you just move on to the next word. Never make assumptions.
Never, ever make assumptions and make sure the prerequisites are clearly outlined to make sure the architecture is a success. There's the two cycles that we're talking about. Business process update and technology update. Make sure you understand what appetite you have for those things. Align your processes and activities around that, and last but not least, there is so much going on in the AI space. We need to see more adoption of the technology in this industry, and we are not seeing as much, especially now with the advent of AI, there are so many things we could do.
So take a look at that and see what it means to you. There's hardly anything to add. Maybe regarding AI, in a lot of RFPs, I see, does your product utilise AI slash ML without any further use case, I would call it? So the answer is yes. So it does not make sense to ask the question that way, and second, even using AI, your data needs to be clean. It's really, sorry for the German word, shit in, shit out. And be careful with that, and as I said, have a good selection process, make sure you cover your use cases, and, yes, that's it, basically.
But these RFPs are a bit like vendor marketing, aren't they? Oh, we use AI and ML, basically the same on the other side. So we didn't sound like good advocates for architecture, but I think we all believe in architecture. Spend the time on architecture and focus on how to build your things so that they don't break, that they are built for the future, that they can grow. This is the key thing, and not the nitty-gritty detail, it's this level of architecture you just think about.
Thank you, everybody. Thank you all. Thank you.
