The Argument: Better Architecture Everyday
The Argument: Better Architecture Everyday
Architectural Design Thinking & Digital Transformation with Simon Field
Have you ever wondered how architecture can be made inclusive, or how artificial intelligence could assist an architect? Prepare to have your curiosity satiated as we chat with the esteemed Simon Field from RDoC, who leaves no stone unturned in the realm of architecture. He takes us on an intriguing journey through the SARM system, his association with Volkswagen in Germany, and the fascinating concept of architecture as a service that will change your perspective on how you view architectural design.
We unravel how the power of graph models can make architecture accessible to everyone by visualizing data and giving us a shared picture. Simon also enlightens us on how AI can be our ally in identifying patterns, and how architectural thinking can be applied to IT systems, service design, and even business model design. This episode is a blend of innovation, creativity, and intelligence that emphasizes how technology has revolutionized the world of architecture.
This episode is a goldmine for:
- Architectural Design Thinking: How it's revolutionizing the industry.
- Vendor Tools: The gap between what's available and what architects truly need.
- Architecture as a Service: Simon's innovative vision of breaking down architectural processes.
- Machine Learning in Architecture: The untapped potential of AI and machine learning.
- Stakeholder Management: Navigating the complex world of stakeholder communication.
- Digital Transformation: The pivotal role of architectural thinking.
As we conclude, Simon shares his three golden rules for success in architecture: automating tasks to save time, harnessing the power of AI technologies, and engaging others in architectural thinking. We also discuss the battles many architects face with existing tools and the idea of creating a toolset exclusively for architects.
Don't miss this unique opportunity to gain valuable insights from a revolutionary in the field and elevate your architectural thinking. Buckle up for an enlightening ride into the future of architecture with Simon Field.
Welcome to the argument. This is Paul Price, ceo and founder of ISA, the largest global association for architects. Today I have Simon Field on to talk about the, to talk about in general, just architecture excellence. He's from RDoC, one of our great sponsors, so we thank you for that, and also he is known for inventing SARM, which is an architectural analysis method, as well as the author of our architecture analysis article on the Bidwok. So, simon, welcome.
Speaker 2:Thank you, paul. Thank you for inviting me. Looking forward to it.
Speaker 1:Me too. Lots of questions today. What are we going to talk about today? You're my first guest in a while for my component of the interview series, so I'm excited about that. Obviously, you're also now a sponsor, which is great, and we're very grateful for that, but then also there's the other stuff that we haven't talked about for a while SARM and those kinds of deals, and then just kind of state of the industry stuff. What do you feel, like, gabin, about today?
Speaker 2:Well, Simon's been there for 20 odd years in my head, so that's not going to go away anytime soon.
Speaker 1:Well, I still think you and I should talk about getting that launched under the Bidwok. It's open source. It will stay a part of the body of knowledge forever. It will always get moved forward, whether you work on it or not.
Speaker 2:Yeah, well, I'm happy to do that and actually I created that training course and even used it and further developed it in partnership with rather strange partnership with Volkswagen in Germany and not coming together with the Bank of England and Volkswagen. But they'd done some really interesting work on in design thinking, in architectural workshops and quality and therefore that connection with evaluation and quality and their work in design thinking. I came together nicely. We published a paper, I think at a conference, on that.
Speaker 2:Yeah, it was a nice happenstance that we bumped into each other, as it were. So there's that stuff. I mean, what I've also been doing recently, which I guess is part of my journey that led me to Atoch, is when I chose to leave the bank. I didn't kind of have anywhere to go, I just decided that I had some ideas I wanted to develop and I didn't only want to implement them in one place, I wanted to make them more widely available, and I'd been thinking about architecture as a service and how you can so very similar in some ways to what you're doing in BTABOK break it down into pieces and articulate how those pieces actually work, how you do them, how they connect together. Part of my original thinking was how do you do that and then, possibly, as an organization, outsource it to someone or something. Nowadays, perhaps is another conversation. But how do you join the pieces with an engage with a wider group of people to make it happen? Because architecture teams can't cope and they're falling apart. So my first thought was partnering with other organizations that have more people, more capable people. My more recent thought well, actually a more sensible thought is partner with the rest of your organization and get them to do your work for you and get them engaged in architecture. And nowadays also, actually can we involve machines and help you just do what we're trying to do, because I wouldn't say they're getting smart, but they're good at doing certain things, which is also what we do as architects Looking for patterns, looking where you can reuse patterns, writing text, explaining things to people. So all of those things.
Speaker 2:I developed this model and then actually that led me to realize that maybe, going to, I needed a partner to push it out, and the right partner I first thought would probably be a consulting firm and that's just employing more and more people to go out and do it. And a call with a former colleague of mine. A Gartner said why don't you think about some of the tool vendors? Because they're looking at actually embedding this knowledge and the automation capabilities in their tools. And that was actually what led me to look more closely at the tool providers and realize that actually I could put that knowledge and spread that knowledge, if you like, through working with one of the tool vendors, and that led to me coming to our doc, so we can talk about some of that.
Speaker 1:Well, we're already talking about it, so we'll just splice these things in. It's kind of interesting that you say that, because I tend to be pretty dissatisfied with the vendor space in our field. I see a lot of architects struggle, struggle, struggle. I get what you're saying at the sort of enterprise metadata level, but as a practicing, the number of practicing architects that I talk to that are able to get what they need out of a tool for just for them to do their job are very, very low. The rollouts are slow, the stuff that architects do. I hesitate because, again, I guess let me take it from a different angle and ask you this Do tools help the individual architect a great deal beyond modeling?
Speaker 2:Yeah, I see where you're coming from. I think one of the questions I've got is if you only ever address what the architects tell you that they want, is there is a danger that that tool still becomes architecture for the sake of architecture and that you're helping. I want to stop you on that.
Speaker 1:What the hell is wrong I'm so. What is wrong with that? There are medical tools that are for doctors. Nobody else ever sees them. Matter of fact, the ideal of the medical tools are for doctors and nobody else ever sees them. And everybody knows my rant about doctors. So what is wrong with a tool set that actually helps us do our job instead of being a reporting tool for the CIO?
Speaker 2:I don't think it's just a reporting tool for the CIO, but I think I think here it depends on you probably have to break apart the role of architect, because I don't think there is one job that's called architect.
Speaker 2:If I'm a data architect, I need stuff that is actually going to help me get into the weeds of how data relates to each other and how, possibly how I'm going to implement it. I'm using that data and lots of quite complex views around that information. Same is probably a different story and a different set of needs for a software architecture who's deep into the design of the system. So I think where I'm coming from, at the moment at least, is thinking about that enterprise architecture view where actually the purpose of doing that is to actually help deliver business benefits to your business colleagues, and I think if it just remains a tool for the architect, it doesn't work. Architects can't cope with the change and the volume of information that they're trying to deal with simply by modeling stuff by hand. It needs to help them. They need help to reach out to other people and engage other people, and that's not something that they instinctively ask for because it's not something they've had in the tools that they've had in the past.
Speaker 1:Well, so you're talking about the changing things, so why is that not a CMDB problem as opposed to an architect tool problem? I think we update the drivers on or we patch the SAP or the Oracle or the whatever in production. Why is that not updated in a CMDB, which an architect tool set would then just read from that's perfect as far as it goes.
Speaker 2:If you can get that data from somewhere else where it's used operationally, of course, that's much better than asking for somebody to rekey it and type it in again, though I've seen a very large number of organizations which have a CMDB over there and have a bunch of architects who are busy reinventing the same information, remodeling the same information in a tool. But I agree, if you can synchronize those.
Speaker 1:Is that because the tool doesn't go bidirectional? Or is that because they chose not to use that as a source of information? Or is that because the CMDB was not up to date? I?
Speaker 2:think I've seen all of those Right.
Speaker 1:You too. That's why I asked.
Speaker 2:Yeah, I've seen plenty of organizations that say don't touch it, don't look at our CMDB because it's never kept up to date, so it's not very current.
Speaker 2:I've seen others where the architects kind of live in their own world and want to model stuff and they almost use modeling stuff as an excuse I would say an excuse not to do other things, but it's a world that they're very comfortable with. I've seen others where the technical difficulty is getting it from one place to another. Even if you can smoothly populate stuff from the CMDB and its current take the perfect situation, you've still got lots of quite independent information. As we all know, the knowledge is really in the links. It's in the links about which organizational units most use this, who has expertise in this particular technology, what business processes, what business services and products are these things connected to? That connection to CMDB gives you a great starting point, but it doesn't allow you necessarily to ask big questions. If you try and ask those big questions just of the CMDB, you're not going to get anywhere. So you need to expand the knowledge base beyond what that CMDB has given you.
Speaker 1:But isn't that still an operational documentation and CMDB problem space? Let's just run this against the numbers. What is the lowest number, percentage wise, of employees in any tech-related activity that we have by role? In any IT shop, in any technology related group, what is the role that has the fewest number of employees ratio? The percentage of employees that are in that title.
Speaker 2:You mean the chief architect and the architect team.
Speaker 1:Yes, so it's. Either it would be IT management, which probably not, because you've got 2 to 3% there, or it would be architects. So why are we giving a documentation activity to the lowest ratio and one of the highest costs People who are supposed to be our most strategic?
Speaker 2:I mean, that's exactly my point that's what we have historically done.
Speaker 1:We've turned expensive, highly qualified. It's a tragedy.
Speaker 2:It is, and we turned them into data entry clocks and who never have enough time to think about, to really have their thinking time and space, which is what they need to do, what they were hired to do in the first place. So that's why I do think we need the tool, not just to help them do what they would like to do we do need that but we need to free them up from what they've been trapped into having to do all the time and look at our policy.
Speaker 1:If it doesn't work in the architects tool, then they have to make it work. So they're still documenting the freaking enterprise. Aren't we still in the old way of thinking? Shouldn't all of that be an operational problem? I mean again, I'd rather use a blank piece paper. In fact, the Bidabuck uses canvases, we use stuff you can just throw into Miro or throw on literally. We print them out and put them on walls because they're better that way, because I can put them up in 3D space, right, and I can print them out and we can all put our little dots on them.
Speaker 1:The question I have for you and I love the tool, some of the tool concepts, right, I mean, but the vast majority of enterprise focused tools that I see are change management tools and CMDBs and they're not targeted at what you and I agree is the architects role, which is digital advantage, digital transformation, you know, tip of the spear, focusing on business outcomes, and I would argue that software and data architects are absolutely as important to that as business and enterprise architects, not even, as they just do the same job.
Speaker 1:All of them should be doing that same job with different specialization stories. So, but but I mean, this is what I'm troubled by is? It seems to be. You know how they say in politics if you don't know the answer to the question, deny the viability of the question. Right, change the question. I deny your right to ask me that question because the question's wrong. See that this is. We're solving a problem that to me, and I'm just curious what your thoughts are, because it seems to me, by solving the problem in an architect tool, we're validating the problem is ours.
Speaker 2:I don't agree with that. That's why this is called the argument.
Speaker 1:I like it. I don't agree with that.
Speaker 2:Because I think one of the dangers of just pigeonholing a tool and saying this is the tool for the architects, here's your world and we'll give you everything that you'd love to do to draw the pictures you want to draw Then if something is connected to that but possibly sit somewhere else, there's another tool somewhere else and we're going to have all of these wiring problems to link them together. I actually would maybe reject the idea that that's all that we have at our dock is only for architects. I don't think it is an architects tool. It has architectural thinking, if you like, at its core, because underneath it is this wonderful graph model of things connected to things that you can actually then start to ask questions of, you can populate and ask questions of and visualize things from that. I don't see why that has to be restricted. That world has to be restricted to the people who've got a job title that says architect, as you said, or a tiny percentage of the organization. I'd love to get that way of thinking, that way of looking at stuff and that way of using information, providing and using information out to lots of people. If you can do that.
Speaker 2:Getting each of them their own separate tools is probably not the answer, because they'll let us continue to work in the red silos. You want their thinking to be joined up. You want them to be contributing, if you like, to that same picture. I don't think what we're doing in our dock is trying to push a load of extra work into the architect. What we're saying is actually architecture has to engage with everybody. It has to engage with the whole organization, possibly even beyond the organization. We want to enable that to happen, rather than building walls around it. Actually, if everyone can help everybody else, they can see things from their own perspectives and work in a common way, rather than giving each of them siloed tools.
Speaker 1:Now that's interesting, because I don't. I mean there really aren't. I mean, as you said, you got into our dock for a reason. Obviously, architects have this wonderful and intimidating elevator. Right, they're up and down levels of scope and we also are horizontally flexible, right Into business meetings, back into technology meetings, etc.
Speaker 1:But that means that we do touch all the concepts, and this has been a very frustrating facet for every architect who's ever done the job. That is, we touch everything and own nothing. Where do you? What is that for you Like? Again, what do we own in your mind? What is those things that are then the pure architectural things? Because I don't think anybody would argue we want to build siloed activities and materials, but that we know exactly which ones belong to us, because I see a lot of architecture teams out there churning on things that someone else should be doing well and just has chosen not to right. They've said, oh, that's not our problem, we don't want to do that. So the architects have picked that burden up and then they get overburdened because they don't have enough of them. I mean that's absolutely true.
Speaker 2:I think if we can free the architects away from that data entry job of just trying to populate a model and what we're seeing now is that is the reality that they're trying to model is moving at downside fast and they can feed it in. So they're just getting further and further away from that reality. So we think we need to engage more people to give that process a chance to happen and then I think the architects can focus on things. I think a lot of what we do as architects can start to be passed on to other people, maybe other things, as we're into that AI world. We're pretty good at spotting patterns. That's one of the things that architects kind of flying at different altitudes and seeing a pattern, an abstracted pattern that can be applied here and can be applied there, and we like to think we're quite good at writing these things down, describing them nicely and then looking for opportunities or recommending where they should be applied. Because they have good outcomes, they're a good compromise, they're a good set of trade-offs for a given situation. Well, we're seeing that machines are actually quite good at spotting patterns. Machines are quite good now are getting quite good at spotting where a pattern could or should be applied. So one of the roles we've traditionally given architects that says actually we've got some principles here. How do you apply these principles? I'm looking now at someone's proposed design oh, but I think that is likely to break this particular principle or this quality outcome is going to be threatened by this design. I think you'd be better off applying this pattern in this situation. Maybe we're getting closer to the point at which machines can at least help us look for those, sit on our shoulder and find those. What those machines are probably not going to be able to do is recognize a need for a new pattern. They might find the gap, but they won't be able to invent that pattern. I don't believe, not yet. Anyhow, I think the AI world is still largely learning from the past, from vast quantities of data, but it's still past situations.
Speaker 2:So, being inventive about we do need a new pattern here, what should it be? Or? And also making those judgments, or at least helping people facilitating the making of judgments that says is this quality characteristic more important than that one in this particular context? And driving that way of thinking with a group of people to arrive at the least worst or the best solution or outcome for a particular design or problem that you're trying to come up with, and I think that can apply to design of IT systems. That's where we've grown up, if you like. That's where these methods have come out, but I believe it can also be applied to things like business process design, service design and, effectively, almost business model design as well. So that architectural way of thinking is something that perhaps, as facilitators, we can actually apply, which is why you're pointing out software architects, solution architects, data architects, enterprise architects have something in common with the way they think and the way they want to work, and that's something I think, as facilitators, we can help spread across an organization as it gets to grips with change.
Speaker 1:So let me just I'm gonna get a ranking from you on a few concepts based on how much well, three. I will go through each one and I just like your thoughts just kind of. I'm just gonna pick randomly five operational activities from the VitaBuck that we've identified that most architects, architect teams, do in some capacity and I wanna get your thoughts on how well or how the tools help us, how well they apply today, and just get your thoughts in general. So I'm gonna pick five or six of them kind of randomly, because we were talking about if we were to identify the competencies of an architect and the activities of an architect team and that's kind of what we focused on. So I'm gonna hit on a couple that are some of your favorites. So let's talk about decisions. You just talked about that trade-offs and the least worst versus the best, which is often the best we can do. So decisions, architectural decisions what are they? How well do the tools help us right now?
Speaker 2:I think you mean the architecture and enterprise architecture tools. I think they go some way, but probably not the sort of support that I'd like to see we're back to. Why did I decide to join our lot? Because I could see potential to bring some of the work that I've been doing over the last five, 10, 15 years and improve the sort of support the tools bring. So what are they good at doing? They're good at helping you organize thoughts, to organize visualizations and to present possibilities, scenarios, different options to, if you like, draw pictures or present models of those things. Are they good at supporting you really understand the strengths and weaknesses of each one of those options and highlighting what you're going to win or lose if you choose one over another?
Speaker 2:I think that's where there's a bit of a weakness at the moment. To be honest, I would worry if they tried to go too far, because otherwise we'll end up in the world that, dare I say it is this kind of world that I see with procurement sometimes, where people say, actually, what I've got is this massive scoring sheet. Just answer all of these questions, press the button and it will tell you which one you should buy. Remove the humans from it, and I don't want to see that. I don't think that's right. I've seen disasters flow from that, where people have ended up buying the wrong thing because there weren't any humans, if you like, making the decision. But support for those decisions and casting a light in the right places is something that some tools do well, but I think all tools could probably improve that.
Speaker 1:Okay, I'm going to pick another one here. Investment planning prioritization for architecture activities. Architecturally relevant activities.
Speaker 2:Well, almost every activity involving investment in business changes, like Italy, architecture in one way or another, particularly if you're changing the business architecture, let alone IT, will nearly always be involved in any change as well. I think this is something that historically hasn't been a focus of architecture tools. They've come out of the technical world of let me work out how this system has been put together or how one system talks to another system. It's something certainly at our job that we've seen a massive growth of interest in since we published a strategy to execution use cases. Use cases are worked examples that people can use to accelerate their own use of those.
Speaker 2:I think historically, most architecture teams start by looking at their applications of state Very traditional embedded inside the IT organization. What applications talk to, what applications maybe then go into what infrastructure is it looking at and eventually start thinking about business capabilities and which applications link to which business capabilities. Then eventually, then from there, all this business capability is it a focus of our priorities, our strategic priorities or not? And they work their way around and up to that strategy space. I don't think it's been the historical focus of a lot of the older architecture tools. We've made it a priority at RDoC and that's one of the attractions I think that's there is that some of our customers now are actually coming to us starting with their architecture efforts from that position. In other words, we want to start with strategy formulation, objectives, identifying the right initiatives and then what needs to change underneath those initiatives.
Speaker 2:But they're in a very small minority at the moment but it's growing. I see more attention there and I think there is more recognition generally that big change means technology change means you need to think architecturally. Perhaps the higher stakes if you don't change fast enough, possibly you're dead as a business means some have done that knee-joke thing of let's just change stuff and worry about architecture later, but others have actually said we need to do this right. We need architectural thinking at the heart of that change initiative and prioritization process. I'm encouraged that a small number are getting that and growing.
Speaker 1:Here's a third one, then I'll give you a third one. I think that was great. Stakeholders and advanced stakeholder management, or even capable stakeholder management.
Speaker 2:How well architect tools deal with that. Yeah Well, this takes us back a little bit to your conversation about what. Shouldn't the architect tool only be for the architect? I think I would dare to suggest. I think that that's changing again. I think we're seeing more recognition, certainly at our dock. We're seeing that recognition that different stakeholders have different needs and want to see things in a different way. The presentation of information to an architect maybe a completely different style of presentation, style of navigation, almost the language that they use to interact with it needs to be different from the interaction that an application owner might have if you're giving them their view of the world from their perspective, or develop it.
Speaker 1:I'm going to challenge you on this one, because you're giving me the definition of views. Now, views are a view of a system or a system of systems related to a stakeholder's concerns. Whether or not it's actually targeted in an individual or not is not actually required by the ISO standard. What I'm actually curious about, though, stakeholder management is one of our biggest, nastiest jobs, not views. So the application portfolio lead would like to see the view of the change management, not that Talking about.
Speaker 1:I've got an ecosystem of semi-Harry apes running around causing havoc with the thing that I'm trying to get out there and the change that's being created, and I need to figure out what's going on with them and communicate with them well and track them well and understand them as people and facilitate meetings with them, when they all have different styles and some of them are blue and some of them are red, some of them are INFJs and some of them are Tauruses, whatever, right, and so how well do you think the tools help us do that portion of our job Not just the views, but really that portion of our job?
Speaker 2:Yeah, well, I think that they do help with some of the communicating Communication, but usually in a very structured way. So where you, and possibly where you've solved the problem of spotting something dashing across there in the distance and not knowing what it is, I'm not sure how far one should or would want to expect at all to do too much of this. It enormously varies by culture and by organization, and you know to have a tool understand the culture of an organization. Funnily enough, I've been working working with some colleagues in the British Computer Society on leadership and leadership topics, and one of the things we've been Discussing is not only the leadership traits that a good architect needs to have in their kit bag and needs to be skilled at. But there's no point in having that wonderful kit bag If they haven't been able to, if you like, reach out and manage the, the stakeholders that they need to engage with the different people across their organization. So, building that network of people or organizational units within your organization and Creating that relationship so that More than just you have that interest in in architecture and architectural thinking on what you're doing, that is something that is so particular to an organization.
Speaker 2:If you're in a very hierarchical organization, you can't reach people. I've worked in one organization where it really would not have worked for me to say I just want to go and talk to the finance director, you know, let me, let me send them an email, or lift up the phone or try and try and arrange to bump into them in that you know the coffee machine, and say why don't we have a chat? I think you should be really interested in what I'm doing. You need, then, to be quite Machiavellian in plotting a route to reach them, perhaps through the people who they do have a More ready connection to and, and finding ways eventually of finding a path through there. I'm not sure a tool is going to help you much with that.
Speaker 2:That's social and Cultural. I've been in other places where, actually, the door was always open and I I could turn to that turn, turn up to the chief executive and say I'd like to interview for an hour to talk about where you think the major threats are to the business model and and, and that happened, and you know, not long after that I was invited to lead a workshop to do scenario planning about what was going to happen to that business and the industry that they're in in Three to five years time. But I can think about other organizations where I was miles away from being able to achieve that. I was in the same kind of role, in the same kind of position, if you like, but but some of them are very much more open and have those social networks that can be very flexible. Others are very, very strict in communications and I don't know how well a tool can, can, can really help you with that.
Speaker 1:And this is where I'd like to challenge the two questions of how we deal with this culturally, because you know, everybody's seen the power interest grid. It's a common tool in project management. It's a very powerful one. It works very, very well. Is that a tool by itself? Yeah, I mean, arguably it's a tool as any, much as anything. We just don't automate them right. So culture hacking Workshops use tools all the time, use the canvases and tools, and we actually have about seven to eight of those in the bit of Box.
Speaker 1:The question is, can we write those down right in a way that stored it? You know, a day, you know, I think so that culture question does impact the use of a codified, stored data, you know, related tool that then other people could see. Because obviously, if you, you know, there are certain interest, there are certain, there are certain activities where high ranking people are not super powerful over an initiative or what not. There you know they're, they're just not that interested in there. Then maybe they super powerful but they're not interested at all. But then they see that and then they go. Oh well, I am interested, I'm interested in everything. Now I'm gonna come check up on you every day, you know. So I guess that that the question becomes how well do we, as a you know, as architects actually systemically manage this, versus Hacking something together or treating it as a kind of human Skill that then we can never get better at because we don't have any tools to help us?
Speaker 2:Yeah, I think you're right and I mentioned earlier in our conversation that that I, that I went away and took nearly six months out To think about how you can break down All the things I've done in architecture both enterprise architecture and more at the solution sort of project program space, and break it down into components and elements that can be more codified, can be more structured, can have Interfaces attached to them because they connect to each other, that can have tools and templates attached to them so that you can say, actually I'm gonna do this and I can teach it to other people. I could maybe, as an organization, choose to outsource some of these activities and keep others inside my organization and and have an understanding what's going to be delivered. And, not surprisingly, actually doing that kind of stakeholder analysis was indeed one of those. You know, one of those Activities that I identified and and separated out as a as a particular services. I called them, I affected, you call that a service Model and that was one of those services that you need to be able to break out.
Speaker 2:Yeah, I agree with you, I think and I came up with 40, something, I think, 40 old services, you know, are they all implemented in all the tools. No, as I said, my first instinct was this is something I could teach. I could maybe go and work with a consulting firm to break down what they offer into all of these little elements. And then I realized that actually some of the tool vendors like I said, I think I'm going to be able to do that Some of the tool vendors, like our doc, are thinking very much in terms of Baking ways of doing things and enabling enabling their customers to pick those up, sometimes with automation Baked into it, and that this was almost a better way of disseminating that knowledge, I felt, than just teaching lots of people to do it.
Speaker 1:Wonderful. Well, you know what I'm going to say. Thank you very much for the interview today. This has been a lot of fun, very dynamic. You've been great. I'd actually like to sit down and talk to you more about. You know some of the other things, so we may have to have you back again soon, but let's see. I always like to end these with just kind of you know, three rules of the road. What do you? What do you? What are your three current recommendations for architects to be doing to be successful?
Speaker 2:I would say that Think about automation.
Speaker 2:Think about pushing the work that you're tied up in all the time and either getting other people to do it or looking to see whether you can bring information in that you're the moment busy trying to model Because you need to clear your desk for the stuff that you've been hired to do. You're never going to win by trying to chase your tail. So I think that's a big one. I think think about the impact of the sorts of new technologies that go under that umbrella banner AI. There's a lot there that actually can help you do what you do and may actually help you free up that time. So I think that's another area definitely worth looking at. I don't like it being all all all cold one label, but there's a lot of stuff in there that I think is evolving fast and can help us achieve that. And I think the last one is that that engagement. Always keep thinking about how you can have achieved that wider engagement beyond the architecture team and engage other people in architectural thinking and then contributing to what you're doing.
Speaker 1:Wonderful. Thank you, simon. It's been a wonderful time having you on.
Speaker 2:Thank you very much for inviting me. I've enjoyed it. Good conversation.