Like I said at the beginning, I, I did a talk last year here on called Tilting at White Towers, and it was supposed to be about trying to improve the, the state of our identity architecture programs and some of the problems that I personally had run into just, I'm not gonna 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, the presentation, one of which I, I disagree with, but Martin presented right before me and I had to contradict like one of the things.
And I, 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, 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 that you represent. I, I'm Martin Inger.
I am Mattias Bauer. Just kidding.
No, for those who dunno me. I was, I have the luck in my life to be one of the co-founders of a company called Work Informatic here in Berlin. And by that evolved into a position that made me a 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 Naim and I'm founder and CEO of ra. Prior to RA I was a core architect and one of the two principal engineers who built the access solution, which was bought by RSA, excited to be here and participate and be part of the humor that touch is gonna bring out in this conversation.
Hi all. Craig Ramsey based outta
Scotland, so apologies for bringing the wind, rain and cloud at lunchtime. I'm Matt Omada, senior solution and 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 organizations in the uk. So experience of doing the job, delivering. And then in pre-sales itself,
I'm Ian Glaser and typically it's my fault.
I'm Mike Kaiser, do strategy and standards for SailPoint. I was a solution architect for a while for IBM like 10 years or so, and I'm also a part-time cleric and my character name would be schlock, just
Ian.
And I actually had a, an interview with the, the guys at Identity at the center and I had promised to do an identity professional based d and d campaign, have yet to do that. So the the first question I wanna ask everybody is why, why do we still struggle with this? I don't mean struggle to get identity programs and things done, but I mean really the the architecture piece of it, which is it should be defining our domain. I know Martin Cooper, Cole has come out with like 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 program itself. Engineering usually goes through tasks, but we, we struggle with defining the strategy that the engineering team should be going through. What is your, you, you guys are obviously more successful in these programs. What are some of the things that you've done within your own organizations to try and make that architecture program more successful?
I'm happy to go first.
I mean I it 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. And I think as you said, it's 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, you forget to take into consideration the other areas of architecture in your organization 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 that it comes from the top down.
If it's understood at that level and it comes down, your engineers know the architecture they're trying to do.
It's, it's far easier. I think the example I could give is we were speaking to an organization that was responsible for the, 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 that was, well, you know, or the road networks go offline, people can't access tunnels and bridges.
Okay, what systems have control the access to that? These ones, these ones, these ones. And do you know everybody that's got access to that and your confidence? Correct. No. So if you can talk that that level that's understood and then build it down into the architecture and spread it out, I think that's, you make it impactful for not just the people you're speaking to deploying it, but the people that as you said, and you put it perfectly with your d and d analogies, getting that buy-in and was it your Quest sanctioned at the start?
So I'm not, not good with the terminology, but exactly that getting that buy-in
So hu on my mind. I mean this is coming from my, my experience at Salesforce where there was a very formalized role of architect role of architecture and programs. And although the artifacts that they produced were incredibly valuable, right? More than just arrows and boxes, the skillset of the architect mattered a lot in the programs, not from the ability to draw those boxes and arrows, but to make, to humanize what the architecture goals and codified in those artifacts actually meant.
And so I as a, 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 socializing that mission on in my channels.
And so I, I won't want to rush to overlook that identity architecture program is great. The humans that participated in it are also part of that architecture are incredibly important to the outcome.
So I think it's not an I am 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, 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, we are generally speaking it not good in architecture, it's just something which also happens than to IM but it's a much bigger problem.
Yep.
I 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 at customers. The larger they get the more it's still in silos, not talking to each other and nobody there with an overarching architecture idea.
And this is what we see at, 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 in the new economy phase, I was once at a one of these new economy companies and I think there were about 700 people at a peak and I think two of them knew what an enterprise service buses.
Yeah, I, I think it, it largely, you know, there's no universal model as everybody knows. It kind of depends on couple of things, you know, starting from the characteristics of the organization. So there are the business process update cycle and then the technology update cycle.
You know, every organization has different measures their own that. And if you don't align your program with that, you'll see 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 I'm directors program owners go from one or another go, they think that they can take the same model and apply it there, it won't 'cause 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, a solution that aligns with your thinking as well. It's not that, you know, every soli solution will fit into your, you know, program, right? And if you're a 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 ability to give you those changes, right? It's not a capability issue necessarily from feature set, but it aligns with your chain cycle and, and how you adapt to it.
Yeah, that's that's great and I appreciate you teeing that up for me because one of the points I wanted to make because I, I as, as I said, one of my, my, 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. 'cause normally that's, 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, can keep up with it. So what are some things that you've been able to do to try and make sure that, or 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 I, I think the, the, the question is what do we define? So do we look at the, the details or do we look at how we enable that speed of the business? So I think in architecture, our job is, is not to, to have the, 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, in, in our world probably the point is how do we enable an architecture that is built for change?
So focusing on, on, on the aspects that enable the change to have sort of the right setup for how can we ensure that we don't kill ourselves with customization? How can we or go for orchestrations that are so bringing in the flexibility? And I think we probably need to take a different perspective and it's a different way of thinking architecture than it's for instance, when building house or architecting houses.
So Mike, oh, I'm sorry. I didn't mean to interrupt you. Go ahead.
Go ahead, go ahead. You first I was gonna ask you, coming from SailPoint for example, do you guy, what, what is the, the methodology that the architecture team uses to produce like artifacts and stuff? Is it similar to like an engineering program? Is it agile?
Is it,
Yeah, I, you know, coming from IBM first and then SailPoint, I think there are 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? 'cause if you produce artifacts that, that when 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. 'cause when I joined we were 300 people and so that pathway wasn't as defined.
But I, I think what, what SailPoint architecture has been good at is not just drawing out the, 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 what we're, here's where we're going, but here are the steps we're taking today in these systems, in these mechanisms that are gonna get us there long term. So it's a already and not yet kind of vibe.
And I think just to sort of add to that as well, you're right, it's the incremental value that you add along the, 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 don't, 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 the what you're, where, where you're trying to get to that you'll continue to, as you said, realize that value in the way, but you, as you said, the business, the, the, the velocity of the business vastly outpaces the velocity of the, 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, it's going to be future-proofed for whatever, not whatever changes. You can't foresee everything through sight as you said. But you know, try and be as flexible as possible and open-ended for what challenges may come
For from our point, or from my point, I, 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 in, 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 in the business side where you have to integrate end users with nice UIs, with access request, with three certification, with segregation of duty, stuff like that. So there are two parts of the story and I think what what we did is, is more building an engine or a platform that allows extensibility so we can react quickly to new requirements.
And I think this is a 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, right? People will ask for, oh I want this kind of requests. Those kind of requests.
I think it's important to go back and say, why are you spending so many time, 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 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 and you know, 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 I think was trying to improve communication, not just 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, 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, in a communication program with your senior leadership, what, 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 alternative to talking to senior leadership. And we'd be very conscious about, oh, well such and such leader responds better to architects, but some 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, 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 wanna 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, but 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 K eyes, if you wanna 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 K eyes, 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, the point I would make maybe being bit the here, I doubt that these KPIs are architecture or KPIs or krs, you can so to speak have it derived by saying if you, if you have or 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 KRS and KPIs which really allow us to measure the quality and success of architecture directly in a way that a business leader would understand.
I, I have to admit that is not the answer I was looking for.
You should have asked a better question, but
That is but that is, that that is absolutely, you know, my experience, we, we seem to have really good ties to like our engineering teams. The engineering teams don't need KPIs or anything they understand the value of, of a partnership with, with architecture.
But that almost seems to set up a reliance on us to like, could, could you go tell my leadership that I'd, I'd love for there to be some better way to explain the value of what that does to my own leadership. Yeah.
Sanjay, you were gonna say, so
Yeah, a couple of things. One is the coverage you can get in terms of the systems, applications and users with architecture, right, is important, right?
And the, the speed of bringing that coverage into play, right? That also can be represented from the architecture, but 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, you know, the ability to integrate these systems, you know, are things that you can largely, you know, gather through the architecture.
Yeah, I would, 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 is, 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 along with, and it's never just KPIs because I think that's just, that's a bunch of pretty graphs that I could draw or Justin could do after effects and do amazing things with. But, but you're, 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, 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.
And I yeah, totally agree that architecture can be quite an abstract concept to these people. They're not, they're not, they are intelligent people, they can't understand it. But that's not their wheelhouse. It's not fair enough.
But you know, it's, as you said, it is telling the story, making them understand that the, the architecture that we have designed, these are the business processes that it's gonna touch in terms of how much more efficient and how more, 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, you're reducing the inappropriate access across the organization 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, you're offsetting the cost of that breach happening with the investment you're making. And that's the kinda 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, 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're, we've got this IGA stuff in place and we are through the roof on access requests, look how many we've got going on. And I'm like, 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, you know, massive success. But you have to set that context I think.
But still at the end we are not measuring architecture.
I think, you know, as an analyst, we, we, we look at a lot of, at products and I I like architectural slides, I ask vendors for architecture slides because when you look at architectural slide, you, you, you can frequently easily spot whether this is sort of better or diverse side. And basically the question which I so to speak have is, is this built for change for growth for EVO evolution?
And, and I think this is instance why I'm very skeptical against regarding MVPs. 'cause a lot of MVP things fall apart when you say, okay, right now I need to scale and evolve if the architecture's not right and this is, I think this is the, the proof to putting them, thus what you do withstand change and evolution. This is still not something you can measure with, with, with numbers in as a KRI or KPI. But I think you can easily look at it and, and if you have experience, you, 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, you code against the, the database of another product because you don't use build an abstraction layer of APIs. It's a hundred percent sure as the 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, the initial thing was to put it into a more generic security domain.
Matter of fact, Martin, I used your diagram to show that it's like, oh, okay, 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 in if in your organizations you actually had a, 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.
I mean at Salesforce we did, and it was interleaved it, 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 within 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 is the way, at least 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 32nd kind of wrap up of their thoughts.
Hi. So going back to DD you can't always assume that the DM is benevolent.
Sometimes you are given impossible challenges, right? And I, we've, 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, this is, this is why I only played d and d once I, my party lasted for 45 seconds and we got eaten by a nursery of giant babies. Not giant 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 and 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, it's kind of, it's trying to match what their goal was to the requirement. Now granted that was a very special case 'cause it wasn't like I was reporting into this chain, so I had a little more freedom.
Yeah, I mean to sort of build upon a similar theme to that, the, literally the, 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, best practice, make it configuration first.
And we, we do that with, as you said, trying to align with best practice, trying to remove that complexity, trying to simplify, not ate, it's still a very complex problem, but simplify the way people do things. So as you said, if if they've got a very determined way to, 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, to innovate faster.
And it's, it's no longer this huge tech debt of, of customization and complexity.
Go ahead.
Go me. Okay. 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, 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 be solved, but it will bring you to your goal.
And this one things that always annoy me and always fail when you come to customers that have a homegrown system or an 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, I think I have a bit of the analyst advantage here because I usually get asked about which vendor 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 went out and say, you know, the, the, 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, the analyst advantage, but sometimes it's maybe another good and I think this is also role we sometimes plays. So, you know, the the external one is sometimes more trusted than in, in telling that story and saying, okay, you know, nice idea.
I like, it's great and you will need to spend a lot of thinking here and you probably can make it work with, with some effort, but you will really be an innovator if we tell it. Sometimes we are more trust than internals.
Okay. I can feel eeb standing behind me. So we have, we have just under three minutes left, I'd like each of the panelists to kind of gimme your 32nd wrap up. The the one thing you would like people to take away from this plus we'll start with you Mike, and we'll go down the road.
Martin, we'll give you the last word.
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, the power of the narrative. Whether that narrative is technical in nature, whether that narrative is outcome in nature. It 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 power of, 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 your architecture, sometimes big assumptions can be made about how simple this step is and you've just moved 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.
Yeah, there's the two cycles that are 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, in this industry and we are not seeing as much, especially now with the advent of gene 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 say, I see does your product utilize AI slash ml without any further use case I would call it. So the answer is yes. So does not make sense to ask the question that way in second, even using ai, your data needs to be clean.
Yeah, it's really sorry for the German word shit in shit out. Yeah. And be careful with that. And as I said, have a good selection process. Make sure you cover your use cases and yeah, that's it basically.
Yeah.
But, but, but these RFPs are a bit like vendor marketing r and they, oh, we use ai ml basic, 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 make, build your things so that they don't break, that they are built for the future, that they can grow. This is the the key thing, not the nitty gritty detail. It's this level of architecture you do think about.
Thank you everybody.
Thank you all.