Tilting at White Towers: Making Your Identity Architecture Actionable

Yes, my name is Steve Hutchinson. You can call me Hutch. I am a former board member of ID Pro, which I'm very proud of, and currently the Director of Security Architecture for Mitsubishi Bank of Tokyo. Just real quick, a little bit about me. I'm a proud cavalier, the University of Virginia, where I studied history. Fortunately I had a computer science minor cuz that's what's paid the bill for the last 30 years. So I started out in c plus plus programming. I moved into network engineering.

That led me to an opportunity in 2001 to do enterprise architecture for a healthcare company that I was working for. From there I went on to enterprise security architecture, which got me a job at ge, which is probably still the greatest job that I ever had because they're the ones who introduced me and asked me to dive deep into the identity space and I'm forever grateful for that.

In 2017, I was incredibly fortunate to have Ian approach me to be on the inaugural board for ID Pro. Also in 2017, I don't know if anybody remembers one world identity, but I got named one of the top 100 influencers an Identity, and I said I'm gonna include this on every presentation for the rest of my life. And about three years ago took the job at Mitsubishi U F J Financial Group, which is the part of the Bank of Tokyo. I get to speak a lot of conferences, which makes me super happy. But why?

What is it about me that lets me talk about identity and matter of fact present some criticism of identity? Well again, I've been doing this since 2001. I have over 20 years of experience.

So, so much experience and all due respect to Oscar Wild, I'm not sure they were all mistakes, but it was certainly an opportunity to see what works and what doesn't work. So hopefully I'm gonna share some of that stuff that that didn't work. When we started way back in 2001, we did what everybody else did.

We, we first, we started with with Zack man and we looked at togaf. We ended up standardizing on zackin, but we only did it for about six months because it seemed really rigid for our organization. We found a company called Meta Group that had a model that was a lot more flexible for us. They got bought by Gartner. So we essentially have been, have been using a modified form of Gartner's strategy. When I got to ge, we started using the scaled scaled agile framework for enterprise called Safe for all the visual complexity that's on there.

This was actually my favorite of the, if you have to assume a methodology, this was a good one because it was the first place where it actually introduced agile concepts into the architecture process, which I appreciate and we'll talk about a little bit when we get it. So why tilting up these white towers? Why pick up the lance and go after the windmills of this architecture industry and practice? That has been my bread and butter for over 20 years and I think it's because I see the enterprise, the architecture practice not keeping up with the times.

There's a lot, we're still seeing people who are slavishly tied to the the methodologies to the, the toe gaps, the to the expense of forgetting what the purpose of architecture was, which is to bring greater alignment between business and IT so that business can satisfy their goals. It is a function of that to allow that to happen. And I'm very passionate about the architecture product. I wanna make sure you understand. I love architecture, I love being in architecture. So how do we save it? How do we bring it back to do this? We're gonna have to embrace some uncomfortable truths.

A number of these we are going to cover in this thing. So let's just quickly go into the first one. Let's go right after the big sacred Cow of architecture, which is architecture focuses too much on the future state. And I'm desperately gonna try to avoid making eye contact with Dr. Messerschmidt and Martin over there. And why do we do the, I mean that's what architecture is, right? It's you define the future state. You build out your five year project to try and get to that future state so that you can satisfy the needs of the business.

And architects love this because the future state is a beautiful place to be. All the complexity in your organization is gone in a future state. All your systems are modern and brand new. They talk to each other flawlessly. Data's available wherever you need it. Breaches don't happen. Security is solid and the business has the systems that they need to achieve anything they want. Why wouldn't you wanna live there? But we don't live there. Our organizations live like here.

I don't mean everybody lives in Los Angeles, which is what that is, but I mean that our IT organizations grew organically over a long period of time. And we built, whenever we did get new systems as part of our future state, we built them right next to our old systems. A lot of times we didn't tear down those old systems either. Turns out there was like one or two processes that really needs to use it and there were very important business processes.

So they, they have to stay there. But sure you've got the big shiny tower next to it.

That's, that's the important piece. So how did we get to this? Why does it happen?

Well, ever since it was a thing, since the first information technology division was formed, the business realized that the IT that they had wasn't the IT that they wanted or what they needed. And that's where architecture came in. Architecture was designed to improve that business IT alignment. But there's a fatal flaw in that too. And that's the, the business goals are much more fluid and volatile than the architecture is.

It's very, very hard following these methodology. And of course I'm not talking about architects in this room. I'm sure everybody's architecture program is fine, we're talking about people elsewhere. But it's hard following those methodologies and those practices to allow the architecture to be as fluid as the business needs it to be, to match the speed of the business.

Also, as the business is making decisions and the business is not waiting for architecture to move on. Every one of those decisions, every one of those actions changes the future state. It's not the future state that determines our actions at that point. It's our actions that are determining what the new future state is going to look like. So quickly we realized that the the future state wasn't going to solve everything for the development processes. So architecture couldn't be everywhere. So we came up with architecture principles that design teams could follow.

Well, uncomfortable truth number two is that architecture principles honestly have little effect and actually can sometimes hurt your efforts. They're usually a council of elders who say, and maybe several councils of elders who come up with architecture principles that sound really good. And it's great because now you can provide a set of rules to follow. These aren't suggestions. These are things that development teams must comply with or explain why they're not complying with them. So they sound great, but they don't always work. And why?

Because first of all, architecture principles have always been espoused as a way to make future designs good. And they're written down as desired outcomes. And I encourage you to go look at your own to see if that's true. Usually they're written as desired outcomes, but it doesn't mean that following them gets you to that outcome.

In fact, following them, just blindly following them can actually lead you to bad outcomes and can be a bad decision. I was personally involved with a project where an architecture principle was written around cloud deployment from a team that didn't fully understand all the implications of the cloud deployment because they weren't the cloud team, they were architects who were working with the architectural review board and they were in the the architecture domain area and it meant at least half a dozen deployments had to be backed out at great cost to the company.

So the idea that you can get that a simple set of design rules by themselves are gonna get you a well-defined IT landscape, it's just simply too good to be true. So a lot of this is because many times your architects are often far removed from your frontline engineering teams. For example, if your organization will say Berlin, then your architects would be up here and having drinks in the restaurant in the TV tower.

Meanwhile, your engineers are over at the Sony Center outside of town. And lest you think that this is just a cute metaphor, let's go back to that safe now. This is an actual framework that many, many people use. Here's the architect in this process at the top at the beginning where everything starts. Here's your engineering team. Three levels down many, many processes later. Our goal should be to get these teams better aligned. So there's a great book by G Vegar, I believe it's called Chess in the Art of Enterprise Architecture.

And in it he talks about the tendency for architects to focus on very high level stuff and say that the details don't matter. His response was, organizations don't stumble over mountains, they stumble over mole hills. Which is true if your goal is the future state and that's what you're looking at and you're walking and you're only looking at that mountain, you're gonna stumble all over the the little bull hills because you don't have a full understanding of what all the complexity duties are.

The only way to do that is to talk to the people who are there because frameworks don't create architectures. People do. And those people aren't just architects. Those people should be your developers, your designers, and your frontline engineers as well. So if you're going through it, what makes a good architect? And the thing, and it's a question that I think we're only in the profession coming to grips with my opinion is a good architect is somebody who's got a deep domain knowledge.

So you can see all, not just all the good solutions, but you can see the bad ones as well and be closely aligned to that engineering team to help them or to help you understand what all of those are. Again, because of all the uncomfortable truths that we've had before. The fourth uncomfortable truth is most of our architecture diagrams are just not very useful. We've all seen the comically, we've all seen the comically complex one, but honestly who hasn't seen a diagram? Maybe not quite this complex, but this is what a lot of architecture diagrams look like because architects have a desire.

Once you start drawing a diagram, you want it to explain everything. So let's get everything on the thing. And even when we don't, even when you have a gorgeous slide, one of the most beautiful architecture slides this scene. And it's not just because it's mine, it's a slightly redacted version, but it was meant for a specific audience and it was meant for a specific purpose. The audience was senior leadership, so people who were managing directors and our C level officers and up and its purpose was to get me three and a half million so I could build out our PAM and IGA solutions.

And it worked. So this diagram solved it. But is this the diagram that I used with the engineering team? It might have been where I started, but every single one of those boxes. Now I don't mean the big boxes, the little boxes had to all be blown out and in some cases smaller boxes within those. The differences, as you start getting closer to those engineering teams, your diagrams need to reflect reality, need to reflect actual things taking place.

This diagram didn't include the plethora of legacy systems that still existed that we still needed for a while before we could make all this happen. But it was meant to convey a message and that message worked. So what do we take from this that architects need to target the audience, not a methodology. Let your audience determine what your diagrams are gonna look like and less is more. So you don't have to make one architecture diagram. You can make a multitude of architecture diagrams, each of them designed for a specific purpose and a specific audience.

The other thing is that we tend in architecture to work in the abstract. Well those abstractions at some point need to be correlated to the the actual details of the systems that are being maintained by your frontline engineering teams. And how do we do that? We need to improve communication and alignment to those teams. So uncomfortable. Truth number five is that architecture. Architecture needs to communicate more openly with its stakeholders. You gotta have an XKCD cartoon in every presentation. I love random Monroe.

And this one was great because the first two rows kind of describe what architecture traditionally is, which is somebody who experience something has some knowledge of a problem, tries to explain it in their language and in their terms completely fails to understand it. And in this one, all three people end up in a pit. It's only on the bottom row where it's not just somebody talking to and explaining to another person.

They take them and they have a shared experience, a shared journey, and they're allowed to understand what the problem is and they can both walk away with a better understanding. So what do we take from this? Governance is good and governance is important. I'm not trying to say architecture should, should stop being architecture and should stop doing governance. But we need to be more agile. We need to have more collaboration.

We need to open this process up to people who normally don't participate in it because if we can crowdsource that knowledge, we can make sure we capture information that we might not have gotten if we don't include those people in the process. I feel like I have a really deep domain knowledge in the identity space, but I didn't have a full appreciation of the issues that were taking place within our system until I embedded myself with those I am teams. So architecture should also get yourselves aligned to a small set of engineering teams who they empower to make architecture decisions.

So we talked about a lot of things. Where do we go from here? There's a great movie called As Good As It Gets, Jack Nicholson, Cuba Gooding Jr. Helen Hunt in in one scene, Cuba Gooding Jr. Is telling Jack Nicholson basically everything he's done wrong the whole time. And Jack Nicholson screams at him.

Finally, I'm drowning and you're describing the water. So we've described a lot of water today. What are some of the lifelines that we can take back with us? We need to make architecture more agile and I mean fully adopt the same agile practices that your development and engineering teams are using. You need a backlog for your architecture, AR arch architecture artifacts. We need to change that name. We need to open up the conversation with our technical engineering teams. You need to transition your architecture efforts from a project to a product.

So you need to treat your IAM architecture as a product again, with a backlog, with work effort, develop it in sprints, keep it agile, keep it fresh. And then finally the decentralization and democratization of architecture by including as many people in that process as possible. Thank you very much. So Incredibly you've managed to be on time. Thank you very much. We have a couple of questions here. I think we'll, we'll pick one of these questions, Phillip. So one of the question is, based on your experience frameworks like toga or zekman, do they help or hinder you?

If, if You don't have, If you don't have an existing architecture, you don't have experience building an architecture and building these relationships? I will say something like a zackin can be a very good process to categorize and understand your IT inventory and get a, a picture of your business knowledge. It's not that zackin and toga are bad, it's the, when you think that that's the goal rather than the the, the business enablement is the goal. There are a lot of tools to get you there and those can be one of them.

I I, I have to admit that when I think about architecture frequently and, and sometimes as a customer, I have to squeeze my thinking into these tools and that hindered me in thinking. That's the other side of the coin. But unfortunately we don't have time to discuss about it. We probably could spend hours next time I ask you to set up a panel where we don't continue it with the conversation. Thank you very much Steve. Thank you.